[gelöst]MYSENSOR node vs FHEM Neustart

Begonnen von simonTS, 04 März 2019, 11:13:01

Vorheriges Thema - Nächstes Thema

simonTS

Hallo Forum,

ich habe mich vor geraumer Zeit mit ein paar Arduino mit verschiedenen Sensoren ausgestattet. Die Dinger sind für zB Zisterne, Aussentemperatur, Temperaturen auf dem Speicher, etc. via Funk und Batterie ziemlich praktisch.

Kürzlich habe ich mal wieder einige Sachen in FHEM geändert und habe dieses darauf hin mehrfach neugestartet. Dabei verlieren allerdings immer die Nodes die Verbindung. Das Funkgateway (auf einem raspberry im lokalen Netz) initialisiert sich, die Nodes senden Ihre Werte und FHEM quittiert im Log mit
MYSENSORS: ignoring set-msg from unknown radioId 103, childId 1 for V_TRIPPED
Allerdings zeigt es auch die "abgelehnten" Werte für Feuchtigkeit, Temperatur usw. Also senden funktioniert.

Mein Problem ist, dass ich jetzt alle Nodes einmal resetten muss, dann geht es wieder. Also laufe ich einmal überall rum, packe die Dinger fein aus, drücke reset und packe sie wieder ein ... Sehr blöd das Ganze!

Habe versucht, die Sensoren 1:1 mit den Attributen anzulegen, die sie sich selber bei einer Autoanlage nach reset geben. Fkt. aber auch nicht.

Wie kann ich meine Nodes automatisch auch nach einem FHEM Neustart einbinden lassen, sobald sie wieder senden. Also quasi ohne das die MYSENSOR presentation() Funktion aufgerufen wird. Oder muss ich das umgekehrt machen, und den nodes vorher einen neustart Wunsch senden? Mit der Empfangsrichtung zum Node habe ich mich noch nicht befasst.

Jeder Schubser ist willkommen ;-)

Schönes Fasching!
Christian
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

Beta-User

Moin;

kannst du das mal in den MySensors-Bereich verschieben? (Hier geht es evtl. auch bei mir unter, dort lesen ggf. noch mehr mit, die auch mal nachsehen können, ob sie ähnliche Effekte haben).

Ich schaue mir das gerne mal bei Gelegenheit näher an, das kann allerdings etwas dauern.

Zum Senden: Wenn du kein smartSleep aktiviert hast, kannst du schlafende Nodes nicht dazu überreden, die Presentation zu wiederholen.

Zum Setup: das ist also ein Pi-GW, oder? Kein entferntes via ser2net durchgereichtes serielles GW?

Was passiert, wenn du das GW neu startest?

Und noch: verwendest du die aktuellen Versionen der Module?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Ergänzende Frage noch:

Kann es sein, dass das GW in der fhem.cfg hinter den Nodes definiert ist? (da ich nur configDB nutze: da ggf. eine höhere Nummer hat).

Wenn ja: kannst du mal testen, ob da weiter so ist, wenn du das GW vor die Nodes verschiebst?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

simonTS

#3
Hey, Danke schonmal für die Antworten!

SmartSleep habe ich tatsächlich nicht im Code. Schaue ich mir an, wenn es zur Wiederholung der presentation() führt, sollte es das Problem ja beheben.

setup ist RPI im LAN mit angestöpseltem nrf24 und mysgw als service. FHEM läuft auf einem anderen Rapsberry, dort ist das GW dann wiederum über die IP-Adresse definiert.

Das Gateway ist tatsächlich vor den Nodes definiert. Ein Neustart des Gateways ändert ebenfalls gar nichts.

Blöde Frage zur Version: damit sind die bibliotheken gemeint? wo verdammt nochmal finde ich deren version  ... In der Readme im Sketchordner im Verzeichnis MySensors steht v2.2.0.


Nachtrag:
smartsleep ists wohl eher nicht. habe mir noch MY_TRANSPORT_SANITY_CHECK und ACK angeschaut. Die werde ich mal noch implementieren...
Allerdings, da die Nodes sich ja brav melden und sogar konkret v_HUM / TEMP / tripped ... senden, scheint das ja bis zu fhem zu funktionieren. Nur fhem lehnt ab und sagt, die ID sei unbekannt. Muss ich da vllt die FUUID der Node mitgeben, oder sowas?
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

Beta-User

Danke für die Rückmeldung und die Info zur Architektur der Geräte.

Bei smartSeep-Nodes kann man die Presentation anfordern; das brauchst du aber nicht, das müßte anders zu lösen gehen (das sieht mir schon nach einem modulinternen Thema aus, aber abgesehen von dem Reihenfolgethema habe ich im Moment keine Idee).

Mit "Version" waren die FHEM-Module (00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm gemeint (=>FHEM-Befehl version), also ob die auf dem aktuellen Stand sind. Wenn nein, bitte aktualisieren, sonst kann ich ggf. keine Änderungen im Code vorschlagen zum Testen.

Die MySensors-Hardware bzw. die firmware brauchst du nicht anfassen, das sollte so gehen.

Kannst du mal RAW-Definitionen (list -r) von zwei exemplarischen Geräten liefern (das GW und eine Node, am besten dann noch den passenden Logauszug dazu (du schreibst im Ausgangspost was von einer Motion-Info, die (lt. log) nicht zuzuordnen war, danach folgen Infos, dass Temp/Luftfeuchtigkeit aktualisiert würde; ich bräuchte die zusammengehörenden Infos).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

simonTS

mhh... Was soll ich sagen. Es geht jetzt.

Was habe ich gemacht?
nach dem reset der node habe ich deren automatisch angelegte attribute 1:1 in ein manuelles define übertragen. Danach habe ich fhem neu gestartet.

Das GW wird initialisiert, danach die Nodes. Und schon kommen nach wenigen Momenten die ersten Readings rein.

Ich habe keine Ahnung, warum mich das einen halben Tag gekostet hat. Ich kann mir nur noch vorstellen, dass ich zwischendurch beim kopieren der cfg Dateien durcheinander gekommen bin.

Spiele nachher mal noch etwas damit, aber scheint für den Moment genau so zu funktionieren, wie gewollt: Wenn die Nodes in fhem definiert wurden (also nicht die Autoanlage mit MYSENSOR_10*), dann empfangen diese auch nach einem Neustart von FHEM automatisch wieder ihre Readings.

Module sollten übrigens nach dem Update vo gestern die aktuellsten sein ;-)
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

Beta-User

Zitat von: simonTS am 04 März 2019, 15:56:43
Ich habe keine Ahnung, warum mich das einen halben Tag gekostet hat. Ich kann mir nur noch vorstellen, dass ich zwischendurch beim kopieren der cfg Dateien durcheinander gekommen bin.

Spiele nachher mal noch etwas damit, aber scheint für den Moment genau so zu funktionieren, wie gewollt: Wenn die Nodes in fhem definiert wurden (also nicht die Autoanlage mit MYSENSOR_10*), dann empfangen diese auch nach einem Neustart von FHEM automatisch wieder ihre Readings.
Ähm, zwei Anmerkungen dazu:
1. Manuelles cfg-Editieren ist immer für (unangenehme!) Überraschungen gut (so hört sich das mit dem rumkopieren an). Ich gehöre daher zur Fraktion derjenigen, die dringend davon abraten. Es geht genausogut anders, wenn man weiß, wie...

2. Es wäre mir nicht bekannt, dass die autocreate-Methode irgendeinen Hau hätte; nach meinem Kenntnisstand funktioniert die, auch einschließlich der automaitschen Vergabe einer NodeID.
Wenn das anders sein sollte, bitte ich um Rückmeldung, dann habe ich anscheindend bei den letzten updates doch versehentlich irgendwas verbogen oder es ist etwas anderes aus dem Umfeld die Ursache...

Bitte Thema dann bei Gelegenheit als [gelöst] kennzeichen, wenn es dauerhaft wie gewünscht laufen sollte.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

simonTS

#7
Ja, die Anregung zu den cfg kann ich nachvollziehen ...

Zum Thema: funktioniert, wenn manuell (wo auch immer) defniert wurde. Funktioniert nicht mit autocreate.

Szenario:
FHEM läuft, Nodes wurden resettet und sind in FHEM verfügbar, hier MYSENSOR_100. Jetzt ein manueller FHEM neustart und die nodes werden nicht mehr angelegt. Im log taucht ein Eintrag mit ignoring unkown radioid auf.
Zugehörige Einträge:


define mysensors MYSENSORS 192.168.1.110:5003
attr mysensors autocreate 1
attr mysensors room Sensoren
attr mysensors stateFormat connection

setstate mysensors startup complete
setstate mysensors 2019-03-04 15:49:30 connection startup complete
setstate mysensors 2019-03-04 13:15:10 heartbeat last
setstate mysensors 2019-03-04 15:49:28 state opened


MYSENSOR_100 wird nicht mehr angelegt. Im Log steht:

2019.03.03 23:16:13 3: AT_N_eg_fl_sensoren: current value for eg_fl_sensoren (5/1/20) requested
2019.03.04 16:13:01 3: MYSENSORS: ignoring set-msg from unknown radioId 100, childId 1 for V_TEMP
2019.03.04 16:13:01 3: MYSENSORS: ignoring set-msg from unknown radioId 100, childId 0 for V_HUM
2019.03.04 16:13:13 3: cKLog eg_wz_sensoren | day_home | off - strom.* licht.* --> off


Im selben Szenario geht jetzt übrigens mein manuell definierter sensor_1, welcher vorher - vor dem fhem neustart - als MYSENSOR_103 angelegt wurde.
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

Beta-User

Ähm, verstehe ich das richtig: Du willst jedes mal beim FHEM-Neustart die Nodes automatisch anlegen lassen?

DAS funktioniert in der Tat nicht, der autocreate-Mechanismus wird nur bei Presentation-Meldungen gestartet.

Aber wenn die Nodes in der cfg gespeichert sind, dürfte der Effekt nicht auftreten. Sowas kann ich mir im Moment nur damit erklären, dass die Nodes nach der Presentation gelöscht wurden... (Ich kann aber grade keinen Grund erkennen, warum man sowas macht - evtl. abgesehen von einem Umzug. Aber da kann man den RAW-Import nutzen und die "alten" cfg-Daten einfach rübernehmen (was du ja scheinbar gemacht hast).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

simonTS

Ja, genau so wollte ich das machen. Damit sitzt der DAU mal wieder vorm REchner ;-)

Also: ohne presentation kein autocreate. D.h. ohne speichern der config in fhem nach einem neustart von fhem auch kein autocreate mehr, bis die nodes resetten wurden und damit deren presentation nochmal durchläuft.

Wie gesagt ... Schönes Fashing !!!
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

Beta-User

Yup, die Minimalversiuon ist eine einzige define-Zeile mit der NodeID...
Dann haben die Module was zum Zuordnen und die Readings werden nach und nach gefüllt. Aber ohne passendes Objekt geht die Message halt mit dem entsprechenden Hinweis im log ins digitale Nirvana :P .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files