[gelöst] Nodes schalten Relais am GW mit!?

[frober]

Hallo zusammen,

ich habe im GW mehrere Relais mit eingebunden.
Nun schalten meine 2 Nodes mit Relais die Relais am GW mit!
Die ChildIDs sind überall gleich, die NodeIDs unterscheiden sich.
Vermutlich funktioniert die Unterscheidung zur NodeID 0 nicht.
Wobei diese automatisch angelegt wird, oder muss die NodeID (RS485) vom GW in meinem Fall im Sketch mit deklariert werden?

Zwischen den Nodes funktioniert alles wie es soll, wenn ich z.B. Relais 1 von Node 2  schalte, reagiert nur Relais 1 vom GW mit, bei Node 3 reagiert das Relais nicht.

Wenn ich die Relais am GW schalte reagieren auch nur diese, die Nodes bleiben inaktive.

Die Relais der Nodes sind intern zeitgesteuert, die Zeitsteuerung schaltet auch die Relais am GW wieder mit aus. Wahrscheinlich durch das Senden des neuen Status an Fhem.

Nachtrag: Mysensors Vers. 2.3.1

Grüsse Bernd

   

[Beta-User]

Ähm, hatte ich irgendwo mal angemerkt, dass man das GW GW sein lassen sollte und sonst für nichts nutzen...?

Das ist m.E. eine "unerwünschte Nebenwirkung", wenn man es doch tut... . Vermutlich kommst du aus dem Problem entweder raus, wenn du sehr andere ChildID's für die Relais verwendest, oder eben den Absender identifizierst (ungetestet: könnte mit "message.getSender == 0" in receive() klappen).
Ansonsten ist die Logik die: GW=(zwangsweise, nicht änderbar!) Node 0. Alle Info geht (per "default") an Node 0 und wird dort eben ausgegeben, weil das GW-feature aktiv ist, aber das GW selbst kann nicht unterscheiden, ob es _auch_ eine Schaltanweisung an Node 0 sein soll - die sieht afaik 1:1 identisch aus, nur dass sie eben nicht vom Controller kommt, sondern "Node-2-Node". Kann aber sein, dass das beim GW eben nicht klappt mit getSender...

[frober]

Ähm, hatte ich irgendwo mal angemerkt, dass man das GW GW sein lassen sollte und sonst für nichts nutzen...?

So weit ich mich erinnere, war die Anmerkung, dass man das GW nicht zu sehr "belasten" soll, da sonst die Nachrichten verloren gehen

Meine loop ist leer und ab und zu Mal ein Relais steuern dürfte nicht stören.

Deine Vorschläge werde ich testen, danke.

Ich bin davon ausgegangen, da von MySensors die Möglichkeit besteht, das GW dies bzgl. zu nutzen, dass es auch die NodeID entsprechend unterscheidet

[frober]

...oder eben den Absender identifizierst (ungetestet: könnte mit "message.getSender == 0" in receive() klappen).

getSender funktioniert nicht, da auf die Variable anscheinen kein Zugriff zugelassen wird (Fehlermeldung beim kompilieren).

Mit "message.destination" gibt es zwar keine Fehlermeldung, die Relais schalten jedoch weiterhin.

Nur das ändern der ChildID hat geholfen. Nun funktioniert es

Verstehen tue ich jedoch nicht, dass das GW seine eigene NodeID nicht filtert und so seine eigene Anweisungen erkennt. Ist das ein Bug in der MySensors-Lib?

[Beta-User]

Ich halte das nicht für einen Bug, denn wenn das GW das täte, könntest du gar nichts darauf schalten bzw. direkt dahin senden (z.B. Displayinfo oder sowas).

Es ist imo eher eine systemimmanente Begrenzung der Funktionalität und evtl. schreibe ich irgendwann nochmal ausdrücklich in den Starter-Guide, dass man das GW GW sein lassen sollte und "gut ist"...

Wg. des Fehlers beim compilieren: Das getSender war nur irgendwo in irgendeinem alten Code zu finden. Kann durchaus sein, dass das heute anders heißt, z.B. message.sender... Bei destination ist jedenfalls einigermaßen klar, dass es nicht geht, denn die ist immer == 0 bei allem, was (absichtlich) an das GW geht und nicht an eine andere Node weiterzugeben ist (das GW "kann" ja auch "Repeater" - notfalls auch ohne Controller) .

Wie dem auch sei: Schön, dass du eine für dich funktionierende Lösung gefunden hast!

[frober]

Danke, nochmals für die Erläuterung.

Destination hatte ich als Ziel gesehen, damit das GW weis wohin die Nachricht gehen sollte. Bzw. die Node weiß, dass die Nachricht für sie ist.

Bezgl. der NodeID, wenn das GW seine ID für sich filtert und die anderen IDs weiterleitet, sollte doch auch alles funktionieren!?

Irgendwie fehlt mir noch einiges an Hintergrundwissen...

[Beta-User]

Das "Problem" besteht darin, dass es zwei "spezielle" NodeID's gibt: 0 und 255. 255 bedeutet "broadcast", also "das interessiert alle" und "0" bedeutet halt, dass es "an" das GW (bzw. in der Regel: den Controller dahinter) soll - dort wird aber afaik _nicht_ unterschieden zwischen
- "an das GW zur Weiterleitung an den Controller" (das passiert automatisch mit allen Nachrichten, die von MyS-Netz her kommen) und
- "an das GW zur eigenen Verarbeitung".

Vielleicht solltest du mal den seriellen Output von einer Repeater-Node mal etwas näher betrachten, da wird eventuell klarer, wie die Messages - von der Struktur her - gestrickt sind. Hier gäbe es auch etwas Info dazu: https://www.mysensors.org/build/debug#debug-message-format, beachte dort vor allem das "von-über-an"-format: 12-4-0

Anders gesagt: Bei praktisch allen anderen Systemen gibt es dezidierte GW's, die wirklich nur als Interface taugen. Dass man bei MySensors dann das GW noch zusätzlich was machen lassen kann, ist ein nettes Feature, aber man sollte eben dann auch mit gewissen Einschränkungen leben können bzw. die aus der Doppelfunktion folgenden Beschränkungen hinnehmen...

[frober]

Danke nochmals, jetzt ist einiges klarer.

Bei Gelegenheit muss ich mir Mal anschauen, was Fhem an das GW sendet.
Danach sollte das Verständnis komplett sein...

[Beta-User]

Das Zusammenbauen der Messages in Richtung des GW findest du hier: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_MYSENSORS.pm#L930.

Ansonsten ist es simpel: in https://www.mysensors.org/build/debug#debug-message-format findest du:

The serial protocol used between the Gateway and the Controller is a simple semicolon separated list of values. The last part of each "command" is the payload. All commands ends with a newline. The serial commands has the following format (see the Serial Protocol documentation for more info):

node-id ; child-sensor-id ; message-type ; ack ; sub-type ; payload \n

0;0;3;0;9 means node 0 , sensor 0, internal message (3), not an ack message (0), log message (9). This means that it's the gateway that prints this info as a log after already having received the message from a node.

Ergo unterscheidet sich das eigentlich nur in dem Teil "von-über-an" von einer normalen Log-Ausgabe; das "über" wird dabei afaik auf allen Repeater-Type nodes gespeichert bzw. auf den einzelnen Nodes als "Parent", also der derzeitige nächste Übergabepunkt in Richtung zum GW hin (falls nicht direkt erreichbar). Startet eine Node, versucht sie als erstes, den bekannten Parent zu erreichen, klappt das nicht, wird versucht, via broadcast eine neue Route zum GW/Controller zu finden (ähnlich, wenn der entsprechende Lösch-Befehl empfangen wird ). (Kann sein, dass es für andere destination auch jeweils eigene Routing-Tabellen gibt, aber Node-2-Node-Communication ist sowieso was eher spezielles...).