Hi, um ein Zigbee Netzwerk aufzubauen, müssen zumindest ein Coordinator UND ein Router (oder ein End Device) vorhanden sein. Ist dieses Verständnis korrekt? Ciao Owen
Wobei du mir meiner Meinung nach den Router zu sehr betonst: einfache Netzwerke kommen eher ohne Router aus, also nur coordinator und end device(s).
Hallo allerseits,
> ... einfache Netzwerke kommen kommen eher ohne Router aus ...
bevor man sich entscheidet, einen Router oder ein Enddevice zu
verwenden, muss man sich die Unterschiede vor Augen führen
(siehe Kap. 3 XBee ZigBee Networks - End Device Operation und Kap. 7.
Managing End Devices):
Ein Enddevice ist als batteriegestütztes Device konzipiert, das die
meiste Zeit im stromsparenden Sleep-Modus verbringt. Selbst wenn awake,
ist der Empfänger abgeschaltet (Erfolg: nur 1/3 der Stromaufnahme eines
Routers).
Die Kommunikation zwischen Parent und Enddevice wird vom Enddevice
angestoßen:
wenn es aus dem Sleep geweckt ist, dann sendet es Poll Requests und das
Parentdevice meldet zurück, ob Daten zur Auslieferung anstehen.
Per default werden die Poll Requests in 100ms Abstand gesendet.
Hätte ein Parent 10 Childdevices, die alle awake sind, dann würden im
Mittel alle 10ms Poll-Requests an den Parent gesendet !
Um Daten empfangen zu können ist das Enddevice von seinem Parent
abhängig:
das Parentdevice puffert alle Daten, die an das Enddevice gesendet
werden bis zum nächsten Poll Request (die Größe des Puffers ist aber
endlich !).
Ein Enddevice kann nur Verbindung zu seinem Parent aufnehmen.
Ein Parentdevice kann nur eine beschränkte Anzahl von Enddevices
verwalten (ca. 10-12).
Sollen mehr Enddevices benutzt werden, dann müssen zusätzliche Router
zur Verwaltung eingesetzt werden.
Beim Router entfallen viele Einschränkungen des Enddevice:
- der Router ist immer empfangsbereit
(deswegen hat er auch einen höheren Energiebedarf),
- es können beliebig viele Router im Netz verwaltet werden,
- jeder kann direkt mit jedem kommunizieren.
Meine Schlussfolgerung:
Ein Enddevice ist gut geeignet, um (batteriebetrieben) Daten zu
aquirieren und an einen Datenkollektor zu versenden.
Es ist weniger geeignet, wenn es selbst häufiger Daten empfangen soll
oder wenn kurze Reaktionszeiten gefordert sind.
mfg
Michael S.
Du schreibst: "Selbst wenn awake,ist der Empfänger abgeschaltet (Erfolg: nur 1/3 der Stromaufnahme eines Routers)." "Um Daten empfangen zu können ist das Enddevice von seinem Parent abhängig:" Ist das etwa widersprüchlich? Wird der Empfänger im Enddevice nach dem Zigbee Standard überhaupt abgeschaltet? Kann das passieren, dass Kollisionen vorhanden sind wenn mehrere Enddevices gleichzeitig Daten senden? Ciao Owen
Owen Senmeis schrieb: > Wird der Empfänger im Enddevice nach dem > Zigbee Standard überhaupt abgeschaltet? Ja, natürlich. Im Extremfall ist der Empfänger nur eingeschaltet, um das ACK vom Router/Coordinator zu empfangen, danach geht die Kiste wieder schlafen. > Kann das passieren, dass Kollisionen vorhanden sind wenn mehrere > Enddevices gleichzeitig Daten senden? Dafür gibt's CSMA/CA. Das "CA" steht für "collision avoidance", das heißt, dass natürlich Kollisionen passieren können, man versucht nur, sie zu vermeiden.
Was ist mit dem Status im Netz wenn Enddevices in den Standby-Modus gehen? Müssen diese vom Coordinator neu erkannt werden, wenn die wieder wach sind? Ciao Owen
Owen Senmeis schrieb: > Was ist mit dem Status im Netz wenn Enddevices in den Standby-Modus > gehen? Müssen diese vom Coordinator neu erkannt werden, wenn die wieder > wach sind? Der coordinator weiß nicht einmal, dass sie sich schlafen gelegt haben. Das hat natürlich zur Folge, dass, wenn du ein solches device jetzt final aus dem Netz entfernst, der coordinator u. U. auf ewig die Verbindung der MAC-Adresse zur short address in seiner Tabelle vorhält. Insofern täte ein coordinator natürlich gut daran, devices, die sich gemäß für die konkrete Funktion bereits ungewöhnlich lange nicht mehr gemeldet haben, dann irgendwann doch auszutragen. Im beacon-enabled network weiß zumindest das device, wenn es die Verbindung zum coordinator verloren hat (beacon wurde mehr als zweimal [oder so] nicht mehr gehört).
Owen Senmeis schrieb: > Wird der Empfänger im Enddevice nach dem > Zigbee Standard überhaupt abgeschaltet? Der Empfänger wird abgeschaltet, alleine an der Stromaufnahme, die sich auf wenige uA reduziert, kann man das erkennen (und die Energieeinsparung ist ja der Sinn des Sleep - für den man sich ja auch einige Nachteile einkauft). > Was ist mit dem Status im Netz wenn Enddevices in den Standby-Modus > gehen? Müssen diese vom Coordinator neu erkannt werden, wenn die wieder > wach sind? Nach meiner Kenntnis (die sich aber nur auf die Lektüre des manuals stützt) ist das Parent-Device für das Enddevice zuständig. Dort werden Anfragen an das Enddevice zwischengespeichert - aber der verfügbare Puffer ist sehr begrenzt. Wenn das Enddevice über einen längeren Zeitraum schläft und mehrere Anfragen eingehen, dann muss das Parent-Device die Daten verwerfen, für die es keinen Speicher bereitstellen kann. Darum ist es eine sinnvolle Strategie, dass die Aktivität vom Enddevice ausgeht: es sendet eine Nachricht, der Empfänger erkennt, dass das Enddevice aufgewacht ist und schickt sofort seine Daten auf die Reise. Das Enddevice muss die Antwort abwarten, bevor es sich wieder zur Ruhe legt. Im Netzwerk ist im Normalfall bekannt, welches Device ein Enddevice ist. Entscheidend ist, die Parameter SN und SP so zu setzen, dass die maximale Sleeptime abgedeckt ist. Ist das Produkt aus SN und SP kleiner als die Dauer des Sleep, dann wird das Enddevice als abwesend registriert aus dem Netz geworfen (das konnte ich bei meinen Versuchen nachvollziehen - bei zu kleinen SN/SP Werten wird die Verbindung abgebrochen, obwohl das Enddevice immer wieder zu senden versucht. mfg Michael S.
Michael S. schrieb: > Wenn das Enddevice über einen längeren Zeitraum schläft und mehrere > Anfragen eingehen, dann muss das Parent-Device die Daten verwerfen, für > die es keinen Speicher bereitstellen kann. Es gibt ja auch devices, die grundsätzlich nie etwas gesendet bekommen müssen (außer einem ACK), sondern die nur selbst senden. Das klassische Beispiel dafür wäre ein Lichtschalter. Der kann schlafen, solange er will, er muss erst aufwachen, wenn der Nutzer ihn betätigt, dann sendet er seinen neuen Zustand, und verfällt wieder ins Träumen.
Jörg Wunsch schrieb > Es gibt ja auch devices, die grundsätzlich nie etwas gesendet bekommen > müssen (außer einem ACK), sondern die nur selbst senden. Ja, ich halte es auch für sinnvoll, dass ein Enddevice ausschließlich sendend eingesetzt werden sollte. Michael S.
Wenn ich mich richtig errinere wird das beacon-enabled network in Zigbee nicht verwendet. Bezüglich des Empfängers im Enddevice: Der Empfänger muss aktiviert werden, um im Parent-Device zwischengespeicherten Daten abzuholen, also doch nicht abgeschaltet. Habe ich Recht? Ciao Owen
Ja, deswegen sollte man die sleep period im Coordinator/ Router auch gleich oder größer der des Enddevice setzen. Markus
Owen Senmeis schrieb: > Wenn ich mich richtig errinere wird das beacon-enabled network in Zigbee > nicht verwendet. Der Standard kennt es sehr wohl. Ob es auch eine aktuelle Implementierung gibt, die es wirklich benutzt, entzieht sich jedoch meiner Kenntnis. > Bezüglich des Empfängers im Enddevice: Der Empfänger muss aktiviert > werden, um im Parent-Device zwischengespeicherten Daten abzuholen, also > doch nicht abgeschaltet. Habe ich Recht? Nein, hast du nicht, siehe mein Beispiel mit dem Lichtschalter oben. Niemand schreibt einem End-Device vor, dass es wirklich Daten abholen muss. Natürlich sollte derjenige, der versucht, dem Device Daten zu schicken, besser darüber Bescheid wissen, dass dieses Device gar keine Daten haben will. ;-) Im Übrigen werden Daten vom Router/ Coordinator zum Device normalerweise indirekt geschickt, eben damit das Device nicht ewig seinen Empfänger an lassen muss: sowie das Device bereit ist, Daten entgegenzunehmen, fragt es beim Router nach, ob er welche hat. Danach kann es sich wieder schlafen legen. In einem beacon-enabled network muss das Device gar nicht auf Verdacht fragen, denn die Information, für wen Daten da sind, wird an den beacon angehängt. Dafür müssen natürlich dort alle Devices regelmäßig zum Verfolgen des beacons ihren Empfänger einschalten.
Wie macht man wenn der Sensor im End Device kalibriert werden soll? Es scheint unmöglich ohne eingeschalteten Empfänger. Gruss Owen
Hallo, vielleicht den CB drücken, dann sollte das Enddevice für einige Zeit aufwachen und wach bleiben ?? Michael S.
Owen Senmeis schrieb: > Wie macht man wenn der Sensor im End Device kalibriert werden soll? Es > scheint unmöglich ohne eingeschalteten Empfänger. Du kannst ein solches System nicht losgelöst auf der ISO-Schicht 3 allein betrachten. Das Gesamtsystem muss schon in sich stimmig konzipiert sein: wenn die Endgeräte irgendwie gelegentlich Daten empfangen müssen, um ihre reguläre Funktion aufrecht zu erhalten, dann muss das Gesamtsystem ein Schema haben, nach dem sie sich dann auch mal aktivieren und ihre Daten abholen. Der zuständige Router wiederum muss genügend Speicherkapazität haben, dass er für die angedachte Anzahl von Devices und den zu erwartenden statistisch maximal auftretenden Abfragezeitraum die Daten auf Abruf vorhalten kann. Auf Ebene 3 kannst du das Ganze nicht festmachen, daher wollte ich dir nur mal Beispielen nennen für potenzielle Devices, die grundsätzlich eben nie etwas empfangen müssen. Die kann es geben, und Zigbee selbst muss, falls im System solche Devices existieren, halt damit zurecht kommen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.