Kompromisse von XBee vs. Wifi für Remote-Sensor und Kamera

Ich plane, einen Fernsensor für mein Einfahrtstor zu bauen, das etwa 250 'vom Haus entfernt ist (Standortlinie). Die Grundvoraussetzung ist, mein HA-System zu benachrichtigen, wenn sich das Tor öffnet oder schließt, aber ich möchte auch jedes Mal, wenn es sich öffnet, ein Foto des Tors machen. Ich habe 120 VAC Strom am Gate-Standort. Ich denke, eine Raspberry Pi + Kamera wäre ideal für diese Anwendung, aber ich muss eine drahtlose Kommunikationsmethode wählen.

Der Standort befindet sich am Rande der Stelle, an der mein Telefon unser WLAN-Netzwerk aufnimmt, sodass WLAN möglicherweise eine Option ist, obwohl das ausgewählte spezifische Gerät ein Faktor wäre. Wenn ich ein WLAN-Gerät mit ausreichender Reichweite finde, wäre dies das Einfachste, da ich einfach HTTP und/oder FTP für Benachrichtigungen und Dateiübertragungen verwenden kann.

XBee scheint, insbesondere bei den leistungsstärkeren Pro-Versionen, eine große Reichweite zu haben (und ich habe bereits einen dedizierten Pi in meiner Garage, der das empfangende Ende sein könnte), aber ich müsste ein Protokoll erfinden, um Statusaktualisierungen zu verschieben und Fotoinhalte über die serielle XBee-Verbindung oder konfigurieren Sie eine SLIP-Verbindung.

Gibt es noch andere Kompromisse, die ich berücksichtigen sollte?

Antworten (2)

Ein WiFi-Netzwerk ist darauf ausgelegt, eine kontinuierliche Verbindung aufrechtzuerhalten. Daher müssen alle Geräte, die kommunizieren werden, entweder eine beträchtliche Menge an Energie verbrauchen, um die Verbindung aufrechtzuerhalten, oder sie müssen jedes Mal, wenn sie kommunizieren möchten, eine beträchtliche Zeitspanne (typischerweise 10 bis 30 Sekunden) damit verbringen, eine Verbindung herzustellen.

Wenn Sie xBee verwenden und eine "Basisstation" ständig eingeschaltet ist, können Einheiten, die mit dieser Basisstation kommunizieren möchten, einschalten, kommunizieren, eine Antwort erhalten und wieder ausschalten, oft in weniger als 100 ms. Bei einigen Arten der Sensorüberwachung kann der Unterschied zwischen dem Einschalten für 15 Sekunden und 100 ms ziemlich groß sein. Damit dies gut funktioniert, ist es jedoch erforderlich, entweder eine Basiseinheit zu haben, die "immer eingeschaltet" ist, oder die Remote-Einheiten wissen zu lassen, wann die Basiseinheiten eingeschaltet sein werden. Digi-Module enthalten einen Modus ("Synchronous Sleep Mode"), der letzteres theoretisch automatisieren soll, aber es erfordert, dass alle Module in einem Netzwerk immer gleich lange hochfahren, unabhängig davon, ob sie etwas zu sagen haben. Schlechter,

Gute Informationen; In meinem Fall habe ich Wechselstrom zur Verfügung, daher ist der Stromverbrauch nicht so wichtig wie die einfache Einrichtung.
@TomG: Wenn die Stromversorgung kein Problem darstellt, würde ich mich für XBee entscheiden und einfach alle Einheiten ständig mit Strom versorgen. In diesem Modus übertragen sie nichts, es sei denn, sie haben etwas zu sagen. API-Modus mit Escapes verwenden; Im transparenten Modus können die Module möglicherweise mit einigen Geräten mit serieller Schnittstelle verwendet werden, die nichts über Digi-Module wissen, aber Code, der "HE" [Pause] "LLO" empfängt, kann nicht wissen, ob das, was gesendet wurde, "HELLO" war, aber die der zweite Teil einige Wiederholungen benötigte, oder wenn der Absender versucht hatte, "HEALTHY ARMADILLO" zu senden, aber der mittlere Teil nicht durchkam.
Der Nachteil, den ich bei XBee sehe, ist, dass ich mehr Code schreiben und/oder eine funktionierende SLIP-Implementierung für den Pi finden muss; Andererseits habe ich einen Anfang in einem XBee-Sensornetzwerk ...
@supercat Ich war davon ausgegangen, dass XBee selbst im transparenten Modus einige Wiederholungen usw. durchführt, um sicherzustellen, dass alle Daten empfangen werden?
@geometrikal: Das tut es, aber es wird nicht zwischen Daten unterschieden, die erfolgreich gesendet wurden (möglicherweise mit Wiederholungen) und Daten, die nach Erreichen des Wiederholungslimits abgebrochen werden.
@TomG: Ich würde mich nicht um SLIP kümmern. Wenn Sie den API-Modus verwenden, werden alle gesendeten und empfangenen Pakete als Einheit empfangen; Sie müssen sich keine Gedanken über Teilpakete machen oder dass der Kopf eines Endes mit dem Ende eines anderen empfangen wird.
@supercat: Das Schreiben und Debuggen eines API-Modus-Programms zum Kopieren von Dateien würde wahrscheinlich länger dauern, als SLIP einzurichten, und mit SLIP habe ich nicht nur Zugriff auf curl/ftp/scp, ich habe den Vorteil, dass ich dazu in der Lage bin ssh an die Box, um den Code von der Wärme meines Büros aus zu aktualisieren.
@TomG: Selbst wenn Sie IP-basierte Kommunikation verwenden möchten, wäre es meiner Meinung nach besser, eine IP-Schicht über dem API-Modus zu implementieren, als zu versuchen, SLIP im transparenten Modus zu verwenden. Fehlerkorrigierende DFÜ-Modems können garantieren, dass entweder jedes gesendete Byte der Reihe nach empfangen wird, oder die Verbindung abbricht und beide Seiten es wissen. Der API-Modus garantiert, dass Pakete vollständig oder gar nicht empfangen werden. Keine der Garantien gilt im transparenten Modus.
Am Ende habe ich Ethernet über Powerline verwendet. Es war Plug and Play und war felsenfest.

Die einfachste Lösung, die ich über WLAN habe, ist: eine Webcam, ein Himbeer-Pi, eine Bewegungssoftware ( http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome ) und nach Abschluss des Bewegungsereignisses synchronisieren Sie das Bilddateien über WLAN.

Die Webcam funktioniert reibungslos mit Motion. Die Verwendung der Himbeer-Pi-Kamera ist besser für die CPU-Berechnung als für die USB-Schnittstelle. Aber eine USB-Kamera auf einem Himbeer-Pi wird gut funktionieren.

Dieses Setup erfordert sehr wenig Codierung, es muss lediglich Motion konfiguriert werden. Ich würde zuerst die WLAN-Reichweite versuchen, wenn es hervorragend funktioniert! Wenn nicht, versuchen Sie es mit xbee.

Kompromisse von XBee vs. Wifi für Remote-Sensor und Kamera
AntwortenHierDatenschutz-Bestimmungen1y, 0v