Sensoren am Gateway

[KarlHeinz2000]

Hat schon mal jemand Sensoren direkt ans Gateway gehängt und in FHEM eingebunden? Wie macht ihr das?

[Beta-User]

...hatte ich immer eigentlich vor, war aber bisher nicht wichtig genug.

Aber was sollte das Problem sein? Der Code darf halt keine sleep()-Anweisungen enthalten, ansonsten kann nach meinem Kenntnisstand "ganz normaler code" verwendet werden.

Wenn du ein spezielles Problem hast (wie bastle ich eine non blocking loop()), dann poste doch einfach die Codeteile, mit denen du nicht klar kommst .

[KarlHeinz2000]

Ich kann in FHEM beim GW keine Readings anlegen (mapReading...). Scheinbar unterstützt das FHEM nicht?!
Ich bin ja davon ausgegange, dass die Sensoren auch in FHEM unter dem GW angezeigt werden. Aber selbst wenn man eine Node ID im GW Sketch vergibt, kommen die Daten immer auf Node 0 (=GW) an.

[Beta-User]

Das ist soweit korrekt, es wird immer zwischen der eigentlichen GW-Funktion und der Sensorik (MYSENSOR_N) unterschieden - alle ChildID-bezogenen Dinge werden dann mit MYSENSOR_0 verbandelt.
Blöd ist allerdings, dass es scheinbar wirklich keine Auswirkungen hat, wenn man bei mehreren GW's versucht, eine andere ID als "0" zu verwenden. Jedenfalls hat ein kurzer Test erstmal bestätigt, dass alle GW's trotzdem ihre Informationen auf MYSENSOR_0 mappen. Bei Gelegenheit schaue ich mir mal den code an, glaube aber nicht ernsthaft, dass ich - sollte das wirklich so vercoded sein - in der Lage bin, das zu fixen. Aber vielleicht findet sich jemand anderes...

[Markus.]

Hallo Zusammen,

denke wenn eine Unterscheidung der Sensornetzwerke in den Devices möglich wäre, wäre das Problem behoben.
Also eine Differenzierung nicht alleine über die NodeID. Der IODev-Eintrag macht jaeigentlich die Unterscheidung aber da ist eben das Problem wenn ein neuer Sensor erkannt wird, wird dieser auf das zuletzt definierte Gatway gemappt unabhängig von dem eigentlichen Sensor-Netzwerk wo er erkannt wurde.
Hab das auch mal bei MySensors angefragt..
https://forum.mysensors.org/topic/8958/mulitple-gatways-and-nodeid0/3
Zur Zeit habe ich ja zwei Gateways laufenund nur an einem einen Sensor. Dasfunktioniert soweit. Bisauf eine Kleinigkeit.
Die beiden Gatways haben eine unterschiedliche Software Version. Bei jedem Neustart von FHEM wird hat dieses Attribut als "geändert und zu speichern" angezeigt. Dann klick ich eben auf save und fertig.

Gruß

Markus

[Beta-User]

@Markus:
Danke für's Posten bei MySensors. Nachdem ich mir den code mal (mit meinen eher begrenzten perl-Kenntnissen) angesehen habe, scheint es wirklich so zu sein, dass alle GW's zwingend auf "0" mappen, wobei die Ursache überwiegend im MySensors-code zu liegen scheint - käme aus dem GW was anderes raus, dürfte der DEVICE-perl-code damit auch umgehen wie mit jeder anderen Node.
Das allerdings MySensors-seitig zu ändern dürfte wieder andere Seiteneffekte haben: MYSENSORS.pm unterscheidet nämlich anhand der Radio-ID (=Node-ID) auch, ob es GW-code (bzw. internal Messages) oder "normaler Node-code" ist (Zeile 339). Wenn, dann müßte der MySensors-firmware-code intern beide Teilaspekte (GW- und Sensorik) wirklich sauber trennen und dafür auch saubere ID-Infos liefern (also die interne Sensorik so behandeln, als würde nur was von einer anderen Node durchgereicht).

Im Ergebnis kommt es mir so vor, als sollte man damit leben, eben bestenfalls ein GW mit eigener Node (bzw. besser gesagt mit irgendwas, was auch was empfängt wie switches oder V_VARx-Infos) versehen zu können (und GW's möglichst auf demselben SW-STand zu haben, um dieses ständige Ändern der Versionsangaben zu vermeiden).

Ansonsten lassen sich die Netze ganz gut über die IO-Zuordnung trennen, das macht eigentlich keine Probleme.

An sich war ich erst mal auch der Meinung, dass das keine Seiteneffekte mit der ID-Vergabe haben dürfte, aber wie es aussieht (MYSENSORS.pm ab Zeile 367) hatte ich bislang schlicht Glück, weil die jeweils letzte Nummer am letzten definierten GW vergeben war...

Lasse mich aber gerne eines besseren belehren...

[Beta-User]

Zwischenergebnis aus dem MySensors-Post:
Es dürfte ziemlich schwierig werden, einem GW eine andere ID als die "0" zu verpassen. Damit bleibt es dabei, dass max. ein GW auch als Info-empfangende-Node eingesetzt werden könnte, und der Rest auf die "0" vermantscht wird.

Wer mag, kann sich ja ausgehend von dem Thread bei MySensors mal dran wagen, das aufzusplitten, da sind auch ein paar Hinweise, wo das im Code zu finden ist.

Die Alternative wäre, den perl-code aufzubohren, um zusätzlich die Quelle (im Dateisystem) als "Kennung" für eine MySensors-Node (neben der ID) zu verwenden. Das ist erstens über meinen Kenntnissen und zweitens viel Aufwand für wenig Effekt.

Ich lasse mich aber gerne eines Besseren belehren .

[Markus.]

Also um ehrlich zu sein macht es für mich nur eingeschränkt Sinn ein Gateway als Sensor Node zu "missbrauchen".
Meiner Meinung nach sollten Funktionen immer klar getrennt sein, also Gateway sollte auch nur Gateway sein und nicht Gateway-Sensor. Gut ich hab eins mit Sensor ausgerüstet weil es von der Position gut war -> Gateway im Gehäuse mit anderen Komponenten und da wollte ich die Gehäuseinnentemperatur erfassen.
Was ich hingegen viel Problematischer finde, ist die Tatsache bei mehren Gateways (unterschiedliche Radios) die "fehlerhafte" Zuweisung des IODEVs bei der Erkennung neuer Sensoren auf einem speziellen Sensor-Netzwerk. Da wäre ich über einen Fix mehr als Happy ...

Gruß

Markus

[KarlHeinz2000]

Für mich ist das auch kein Beinbruch, wenn es mit den Sensoren am GW nicht funktioniert. So lege ich halt einen weiteren Arduino neben das GW und binde den mit RS485 an.
Neben der richtigen IODev Zuordnung wäre SmartSleep noch ein "wichtiges" Feature...

[Beta-User]

Nochmal zur Klarstellung: eine reine Sensorik dürfte gar kein Problem sein, man kann nur nichts _an_ mehrere GW-Nodes senden (Zählerstände oä).

Ich brauchte das bisher auch nicht (hätte vielleicht eines noch als Zähler verwendet, wenn ich nicht doch noch ein Kabel hätte verlegen müssen), das ist also auch kein wirkliches Problem. Interessant wäre evtl. ein Statusdisplay gewesen, aber auch das ist nicht tragisch, zumal man m.E. eh überlegen sollte, ob es Sinn macht, weitere (blockierende?) Augaben für ein GW vorzusehen. Tendiere dagegen...

Bleibt das mit der Einschränkung, dass man a) aufpassen muss bei der automatischen Vergabe von ID's und b) die Nodes ggf. nochmal an ein anderes IO "umhängen".

Mit beidem kann in aber bequem leben, ist ja jeweils nur eine Einmal-Aktion.