Fehler nach update

[KarlHeinz2000]

Ich habe heute morgen ein FHEM update gemacht.
Seit dem wird das NRF24 Gateway nicht mehr richtig connected (USB). Es wechselt im Sekundentakt von connected zu disconnected. Wenn ich das letzte Backup einspiele, ist alles wieder ok. Der letzte Stand von FHEM ist 6(?) Monate alt. Die Firmware vom GW habe ich auch aktualisiert (war Mysensor 2.0.1) - keine Ändrung. Die anderen beiden GWs scheinen zu laufen (1x USB, 1x Ethernet).

Code Auswählen Erweitern


2020.11.01 13:50:00 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.01 13:50:00 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.01 13:50:01 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.01 13:50:01 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.01 13:50:01 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.01 13:50:01 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.01 13:50:01 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.01 13:50:02 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)


Zu dem sind beim FHEM Start noch weitere Fehler im Log:

Code Auswählen Erweitern


2020.11.01 13:49:27 3: MYSENSOR_53: unknown attribute version. Type 'attr MYSENSOR_53 ?' for a detailed list.
2020.11.01 13:49:27 3: MYSENSOR_54: unknown attribute version. Type 'attr MYSENSOR_54 ?' for a detailed list.
2020.11.01 13:49:27 3: MYSENSOR_55: unknown attribute version. Type 'attr MYSENSOR_55 ?' for a detailed list.
2020.11.01 13:49:27 3: MYSENSOR_100: unknown attribute version. Type 'attr MYSENSOR_100 ?' for a detailed list.
2020.11.01 13:49:27 3: MYSENSOR_101: unknown attribute version. Type 'attr MYSENSOR_101 ?' for a detailed list.
2020.11.01 13:49:27 3: MYSENSOR_102: unknown attribute version. Type 'attr MYSENSOR_102 ?' for a detailed list.


Hat jemand eine Idee?
Ich bin erstmal wieder auf dem alten Stand, der läuft.

[Beta-User]

Ist das mit dem GW jetzt weg oder nach dem update auf eine halbwegs aktuelle MySensors-Version noch vorhanden?

Wenn ja, bin ich etwas ratlos und würde auf Spannungsversorgungsprobleme oder Adressierungskonflikte  tippen (mehrere Prolific-USB-Seriell-Wandler im Einsatz? Oder andere "ttyUSB0"-defines?).
Falls sie weg sind, könnten sie durch eine bereits sehr lange (>12 Monate?) implementierte regelmäßige heartbeat-Anfrage entstanden sein, die hilft, ggf. nicht mehr verbundene Netzwerkgeräte zu resetten und damit wieder verfügbar zu machen. Die Intervalle sind da aber länger, nämlich 5 Sek./300 Sek., so dass ich vorläufig noch keinen Zusammenhang sehen würde.

Was das mit dem Attribut angeht: Das war mAn. völlig nutzlos und wurde daher entfernt - die Versions-Daten stehen ja auch im betreffenden Reading, und da machen sie auch mehr Sinn...

[KarlHeinz2000]

Das mit dem GW ist seltsam. Nach einem FHEM-update spielt das eine GW verrückt. Wenn ich mein vorheriges backup wieder eingepielt habe ist alles wieder gut. Das habe ich mehrmals probiert. Update und zurück. Ergebnis immer gleich. Die Firmware vom GW ist jetzt auch aktuell -> keine Änderung. Die Konstellation mit dem GW läuft ansonsten schon seit 5 Jahren unauffällig, über verschiedene RPis und FHEM updates hinweg.
Ich bin (und bleibe) erstmal auf meinem alten backup Stand. Vielleicht mache ich gg Weihnachten wieder einen Versuch.

[Beta-User]

Na ja, eigentlich hatte ich nicht vor, an dem Code zu schrauben und würde schon gerne wissen, wo sowas herkommt.

Falls es die reguläre Timer-Geschichte ist, sollten bei verbose 4 am GW auch entsprechende Log-Einträge kommen, falls dauernd die sub "Start" durchlaufen wird, wäre ggf in der "start"-Routine noch eine Log-Anweisung sinnvoll (falls DevIO die nicht sowieso macht).

[KarlHeinz2000]

Habe nochmal ein update gemacht. Selbes Verhalten. Habe mal auf einen anderen USB Port umgesteckt. Da gibt weniger disconnects, sind aber noch da. Mit der alten Version hatte ich das vielleicht 1x im Jahr.
Kann man da was draus lesen?

Code Auswählen Erweitern


2020.11.02 21:13:40 1: /dev/ttyUSB0 reappeared (MYSENSORS_0)
2020.11.02 21:13:40 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.02 21:13:40 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.02 21:13:40 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2020.11.02 21:13:40 5: SW: 303b303b333b303b323b0a
2020.11.02 21:13:40 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.02 21:14:50 4: MYSENSORS/RAW: /
2020.11.02 21:14:50 4: MYSENSORS/RAW: /�
2020.11.02 21:14:50 4: MYSENSORS/RAW: �/�
2020.11.02 21:14:50 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.02 21:14:50 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.02 21:14:50 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2020.11.02 21:14:50 5: SW: 303b303b333b303b323b0a
2020.11.02 21:14:50 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.02 21:15:05 4: MYSENSORS/RAW: /0;255;3;0;9;311
2020.11.02 21:15:05 4: MYSENSORS/RAW: 0;255;3;0;9;311/100-0,s=255,c=3,t=33,pt=5,l=4,sg=0:300000

2020.11.02 21:15:05 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '311100-0,s=255,c=3,t=33,pt=5,l=4,sg=0:300000'

2020.11.02 21:15:05 5: MYSENSORS gateway gateway: 311100-0,s=255,c=3,t=33,pt=5,l=4,sg=0:300000
2020.11.02 21:15:05 4: MYSENSORS/RAW: /00-0,s=255,c=3,t=32,pt=5,l=4,sg=0:500

2020.11.02 21:15:05 5: MYSENSORS Read: 00-0,s=255,c=3,t=32,pt=5,l=4,sg=0:500is no parsable mysensors message
2020.11.02 21:15:05 4: MYSENSORS/RAW: /00

2020.11.02 21:15:05 5: MYSENSORS Read: 00is no parsable mysensors message
2020.11.02 21:15:05 1: /dev/ttyUSB0 disconnected, waiting to reappear (MYSENSORS_0)
2020.11.02 21:15:05 3: Setting MYSENSORS_0 serial parameters to 115200,8,N,1
2020.11.02 21:15:05 1: /dev/ttyUSB0 reappeared (MYSENSORS_0)
2020.11.02 21:15:06 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.02 21:15:06 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.02 21:15:06 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2020.11.02 21:15:06 5: SW: 303b303b333b303b323b0a
2020.11.02 21:15:06 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.02 21:15:06 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.02 21:15:06 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.02 21:15:06 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2020.11.02 21:15:06 5: SW: 303b303b333b303b323b0a
2020.11.02 21:15:06 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.02 21:15:06 4: MYSENSORS/RAW: /0;255;3;0;2;2.3.2

2020.11.02 21:15:06 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 '2.3.2'

2020.11.02 21:15:06 1: /dev/ttyUSB0 disconnected, waiting to reappear (MYSENSORS_0)
2020.11.02 21:15:07 3: Setting MYSENSORS_0 serial parameters to 115200,8,N,1
2020.11.02 21:15:07 1: /dev/ttyUSB0 reappeared (MYSENSORS_0)
2020.11.02 21:15:07 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.02 21:15:07 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.02 21:15:07 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2020.11.02 21:15:07 5: SW: 303b303b333b303b323b0a
2020.11.02 21:15:07 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.02 21:15:07 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 disconnected, waiting to reappear (gateway)
2020.11.02 21:15:07 3: Setting gateway serial parameters to 115200,8,N,1
2020.11.02 21:15:07 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2020.11.02 21:15:07 5: SW: 303b303b333b303b323b0a
2020.11.02 21:15:07 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 reappeared (gateway)
2020.11.02 21:15:07 4: MYSENSORS/RAW: /0;255;3;0;2;2.3.2

2020.11.02 21:15:07 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 '2.3.2'

2020.11.02 21:15:07 1: /dev/ttyUSB0 disconnected, waiting to reappear (MYSENSORS_0)
2020.11.02 21:15:07 3: Setting MYSENSORS_0 serial parameters to 115200,8,N,1
2020.11.02 21:15:07 1: /dev/ttyUSB0 reappeared (MYSENSORS_0)


[Beta-User]

...so richtig was ablesen kann ich daran auch nicht, aber irgendwie sieht mir die Rückmeldung vom GW "kaputt" aus - und da kann es schon sein, dass der erneuerte Parser etwas empfindlicher ist als bisher.

Allerdings stellt sich die Frage, wo der eigentliche Fehler liegt, ich würde meinen, dass das Risiko nicht unerheblich ist, dass das Ding ggf. auch teilweise kaputte Messages durchstellt, was dann ggf. auch komische Readings ergibt. Also falls du da entsprechende Beobachtungen hattest, könnte das die Ursache gewesen sein.

Btw.: ich hatte mal einen Signalduino mit PL-Chipset, der auch irgendwann "komisch" wurde. Hab's nie vertieft, aber evtl. ist es ein Hardware-Thema? Kann wenig dazu sagen, mein einziges Langzeit-GW ist derzeit ein Pro-Micro-basiertes RS485-GW, das keine solchen Mucken zeigt. Aber auch sonst gab es bisher nichts in diese Richtung, und wie geschrieben: die Module sind schon eine ganze Zeit geändert...

[KarlHeinz2000]

Heute noch etwas probiert - ohne Erfolg.
- GW neu aufgebaut, mit anderem Serial-USB (der alte war ein PL..) -> keine Änderung
- Die "alten" 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm in das update kopiert -> keine Änderung, die sind nicht schuld
- Andere USB Geräte ab/umgesteckt -> keine Änderung

Schlussendlich wieder das alte backup eingespielt und alles läuft sofort problemlos.
Evtl versuche ich das auf einem Zweitsystem mal nachzustellen.

[Beta-User]

- Die "alten" 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm in das update kopiert -> keine Änderung, die sind nicht schuld

Hmm, deute ich das richtig, dass du davon ausgehst, dass die Ursache woanders liegt und nicht in den MySensors-Modulen?

Dann wäre DevIO naheliegend, vielleicht machst du da mal einen testweisen downgrade auf die Version, die bei dir im Backup liegt? (Könnte dann nämlich auch Auswirkungen auf andere Module haben; komisch ist aber, dass das dann nur bei dir auftritt).

[KarlHeinz2000]

Abhilfe gefunden.
Mein GW lief mit 115200Baud. Das geht mit dem aktuellen FHEM Stand bei mir nicht. Mit 38400 läuft es jetzt seit gestern Abend ohne Probleme.
Es hat aber definitv was mit FHEM zu tun und nicht mit dem GW. Auf einem zweiten System hatte ich das gleiche Verhalten. Den USB-Serial Ada hatte ich auch gg ein anderes Fabrikat getauscht. Die RX/TX Signale am Arduino waren auch sauber. Und mit der alten FHEM Version gibt es auch keine Probleme...

Code Auswählen Erweitern

Hmm, deute ich das richtig, dass du davon ausgehst, dass die Ursache woanders liegt und nicht in den MySensors-Modulen?
Ja, die Mysensors Module würde ich ausschließen.

Was mir noch aufgefallen ist, aber nicht klar nachvollziehbar:
Das GW ließ sich in FHEM teilweise nicht auf disconnected setzen, es hat sich sofort automatisch wieder connected.
Wenn es doch disconnected geblieben ist, waren im log Meldungen wie

Code Auswählen Erweitern

ignoring set-msg from unknown radioId 57, childId 2 for V_TEMP
Hätte gedacht, dass dann nichts mehr durchkommt.

[Beta-User]

Danke erst mal für die Entwarnung.

Das mit dem Versuch des reconnects kann ich nachvollziehen, ggf. müßte man da in Richtung disable noch nacharbeiten - du bist aber seit Jahren der einzige, der dazu was an Rückmeldung gegeben hat, von daher würde ich das vorläufig unter "feature" verbuchen...

Was diese ignoring-Message angeht: Bist du sicher, dass die GW-Zuordnung für Node 57 iO. ist? Sowas _könnte_ (aus dem Kopf) daher kommen, dass es (derzeit) kein gültiges Interface gibt und die Daten von einem anderen IO empfangen und weitergegeben werden (=Verhinderung der Auswertung fremder Devices?).

[KarlHeinz2000]

Das mit den ignoring Messages war nur auffällig bei der Konstellation FHEM update und GW mit 115220 (also der initiale Fehler). Da hatte ich das GW auf disconnected gesetzt, um das log nicht zuzumüllen. Dann kamen die ignoring Messages ins log, genau von den Nodes, die zu dem GW gehören.
Kann es sein, dass sich verschiedene USB Schnittstellen in die Quere kommen?

PS:
Das disable hätte ich gern für die Nodes 
PPS:
bei den Attributen gibt es mode Repeater und Node. Was ist der Unterschied?
Was macht das model Attribut?

[Beta-User]

Wie gesagt: Wenn die Messages durch mehrere GW's reinkommen können (Funk?), könnte das die Ursache sein für die log-Einträge.

Disable: Ähm, mal schauen, wenn, dann nicht gleich...

mode: Wird (vermutlich) von den Nodes gesendet, mit dem tieferen Sinn habe ich mich nie beschäftigt, aber was da steht, hat immerhin einen gewissen Sinn...

model ist für attrTemplate (ja, MySensors unterstützt das, da SetExtensions "schon immer" gingen; also habe ich da ein paar aufgenommen, ist evtl. für den einen oder anderen interessant, v.a. das Ding mit dem Relay...).

[Beta-User]

Das disable hätte ich gern für die Nodes 

Ähm, irgendwie ist da der Groschen langsam gefallen und eigentlich immer noch unterwegs... Warum das denn? Würde es gerne verstehen, denn ob Info von einer Node kommt, hat man ja in der Regel selbst in der Hand...

[KarlHeinz2000]

Mit dem disable könnte ich die Nachrichten vom node unterbinden. Das ist gut, wenn ich zB. die Batterien wechseln muss und durch das Abbauen/Öffnen Daten generiert werden, die eigentlich gar nicht real sind. Das ist vor allem relevant bei min/max Auswertung und der Statistik. Da bekommt man die nicht wieder raus.
Also zB. Batteriewechsel beim Außensensor im Winter, der zum Öffnen ins Haus geholt wird. Oder der Klip-Klap Regensensor, der beim Abbauen einige Pulse zusätzlich bekommt.
Aktuell behelfe ich mir so, dass ich das IODev vom node auf ein anderes GW lege. Funktioniert auch. Ist nur nicht elegant...

[Beta-User]

...leuchtet ein...

Anbei - allerdings nur grob angetestet - entsprechende Aktualisierungen beider Modulteile.

Was ggf. noch fehlt, wäre dann in Device auch noch die Timer zu stoppen. Aber das ist dann die Kür, die eigentlichen Änderungen sind im IO-Modul drin - es sollte jetzt nichts mehr weitergegeben werden, wenn das betr. Node auf "disable 1" steht...

Hab's mal bei mir am laufen, will aber nicht groß rumtesten.

Vielleicht änderst du den Titel auch entsprechend, dass es ab jetzt um "disable" als Test geht? Sonst sieht es so aus, als hätte es je ein Problem gegeben .