Autoinclusion lässt FHEM abstürzen

[Komaandy]

Hallo,

ich habe bereits mehrer baugleiche Nodes die tadellos funktionieren.  Sowohl in meiner Testumgebung als auch in meinem Produktivsystem.
Nun gibt es aber einen Node, ein PIR, mit dem Namen 47, wenn ich den in mein Produktivsystem verbinden will stürzt mir sofort das FHEM ab.
Wie gesagt, die Nodes sind alle Bauchgleich, also ich habe ca. 20 Bewegungsmelder (PIR), alle den gleichen Sketch, alle die gleiche Hardware.

In meiner Testumgebung funktionieren alle Nodes inklusive die 47, nur eben im Produktivsystem führt die 47 zum sofortigen Absturz beim Hinzufügen per "Inclusionmode"

Kann mir jemand einen Tipp geben WO FHEM die mysensor-devices anlegt ? Das ich dort mal anfangen kann nach dem Problem zu suchen.
Oder wie ich quasi im laufenden Betrieb "nur" das MySensor-Modul austauschen kann, quasi resetten.

Danke und viele Grüsse

Komaandy

[Beta-User]

Sorry, aber ich verstehe die Frage nicht:

Kann mir jemand einen Tipp geben WO FHEM die mysensor-devices anlegt ? Das ich dort mal anfangen kann nach dem Problem zu suchen.
Oder wie ich quasi im laufenden Betrieb "nur" das MySensor-Modul austauschen kann, quasi resetten.

Die Routinen zum Anlegen von Devices sind nach meinem Verständnis folgende:
00_MYSENSORS.pm Zeilen 298-315 iVm. fhem.pl ab Zeile 1885.
Das Ergebnis landet dann in der fhem.cfg (oder wo auch immer deine config liegt). Hier scheint aber nicht das Problem zu liegen, sonst würde sich das Testsystem nicht besser verhalten. Auch die Sketche (bzw. die konkret verwendete MySensors-Version) würde ich tendenziell eher nicht für verdächtig halten.

Glaskugel tendiert zu der Behauptung, dass die 47 im Produktivsystem bereits definiert ist und auch aktiv zu erreichen, es also zu Problemen wegen überkreuzender Kommunikation kommt. Was sagt ein "list" dieser "47" (vor dem Versuch, die zu includieren)?

Zur effektiven Problemanalyse solltest du aber zuallererst mal in's log sehen, ggf. den verbose-level des Gateways erhöhen und uns verraten, wie deine Umgebung sonst so aussieht (GW-Typ, Plattformen, auf denen FHEM jeweils läuft, perl- und Modul-Stände etc.).
Dann wäre noch wichtig zu wissen, was "Absturz" heißt: nur FHEMWEB nicht mehr zu erreichen, aber der service fhem noch laufend?

Gruß, Beta-User

[Komaandy]

Hallo also was ich auf jeden Fall schnell mal remote testen konnte war, dass das device nicht vorher angelegt ist.
list TYPE=MYSENSORS_DEVICE gibt nur die bekannten, funktionierenden Devices zurück.

Im Log ( verbose 5 ) erscheint das device 47 garnicht (!)

FHEM ist Version 5.8 mit regelmässigen Updates
Als Gateway benutze ich im Produktivsystem ein ESP8266
Auf der Testumgebung habe ich sowohl  ESP8266 als auch ein serielles Gateway (Arduino Nano)
Die Gateways sind alle auf Version 2.0

Ich denke auch dass der Fehler irgendwo in der Konfig vom Produktivsystem ist, aber habe keine Idee wo ich da ansetzen soll

[marvin78]

Hast du zur Sicherheit auch mal ein

Code: [Auswählen]

list DEF=47

gemacht?

[Komaandy]

das hat leider auch keine Ergebnisse gebracht ...
Ich habe noch nach anderen Attributen versucht, aber das device ist nicht vorhanden.

Kann es sein dass es eventuell im Gateway falsch registriert ist und ich da mal ansetzen soll ?

[Beta-User]

Das GW leitet eigentlich nur Daten weiter, da wird bestenfalls das routing hinterlegt (wenn man repeater nutzt), aber noch was sehr spekulatives:

Du schreibst das hat Version 2.0 (ist wohl 2.0.0?). Bei den noch älteren ESP-GW's gab's mal das Problem, dass das Timing bei mehreren Sensoren nicht gepaßt hat und dann nur noch Datenmüll als readings rauskamen; hing vermutlich auch von der lib-Version der ESP-Sachen ab. Vielleicht ist das eine neue Spielart, die nur dann auftritt, wenn sehr viele Nodes im Netz hängen?

Und 2.0.0 (?) bis 2.1.0 hatten ein Problem mit den nRF, aber wenn es das wäre, würde die Kommunikation recht schnell gar nicht mehr funktionieren, hmmm.

Hattest du wirklich alle 20+ Nodes gleichtzeitig erfolgreich im Testsystem am laufen, oder war das nacheinander?

Für's testen würde ich jetzt mal zum einen versuchen, ob das Problem mit dem Absturz (? offen: komplett oder nur FHEMWEB nicht erreichbar) auch auftritt, wenn du das Nano-GW nutzt.
Alternativ könnte es auch an der speziellen Node-Id liegen => diese anders im Sketch definieren...

[Komaandy]

Ich korrigiere mich etwas .
Ich habe den 47 gerade neu geflasht auf 88 und habe nun folgende Fehlermeldung im LOG
Der Absturz von FHEM bleibt der selbe

Code: [Auswählen]

pi@raspberrypi:~ $ sudo /etc/init.d/fhem status
fhem is not running

Code: [Auswählen]

017.11.21 18:09:52 5: MYSENSORS/RAW: /88;255;3;0;6;0

2017.11.21 18:09:52 5: MYSENSORS Read: Rx: fr=088 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=0 '0'

2017.11.21 18:09:52 5: Starting notify loop for MYSENSOR_88, 1 event(s), first is parentId: 0
2017.11.21 18:09:52 5: End notify loop for MYSENSOR_88
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 577.


[Beta-User]

Mysensors-device.pm kaputt?

[Komaandy]

also dann habe ich mal eine frische 10_MYSENSORS_DEVICE.pm aus dem Fhem5.8.deb genommen und meine aktuelle "kaputte" ersetzt.
Stürzt leider noch immer ab

[Komaandy]

Wir können hier zumachen.
Ich habe ein Backup eingespielt.
Ohne dass ich erklären kann woran es liegt geht das Backup von Mitte November einwandfrei und nein ich weiss nicht wirklich was ich verändert haben könnte.

Schönen Abend noch
Gruss
Komaandy

[Beta-User]

Schön, dass es wieder funktioniert.

Das solltest du im Auge behalten. M.E. sieht das nach einem defekten Dateisystem aus.

Ansonsten bitte den Thread mit [Gelöst] kennzeichnen (bitte auch auf Mysensors.org). Dazu ersten Beitrag editieren (siehe Hinweise in dem Link aus meiner Signatur).