FHEM2FHEM CUL im RAW Modus betreiben. Ist zusätzlich noch LOG:.* notwendig?

[TeeVau]

Sprachlos?! 
Dass du den Fehler nicht nachstellen kannst ist natürlich problematisch. Ich biete natürlich an, alles Mögliche bei mir zu machen/loggen/ändern.

[rudolfkoenig]

Ja, sprachlos.

Ich habe etwas ueber CUL_WS.pm und FHEM2FHEM.pm gebruetet, und folgendes festgestellt:
- der AssignIoPort($hash) Aufruf (der den IODev Eintrag anlegt) in CUL_WS_Define ist ueberfluessig/verwirrend, da CUL_WS nur empfangen wird, und das IODev "Internal" nur beim Senden verwendet wird. Ich glaube aber nicht, dass er als Ursache herhalten kann.
- UNDEFINED (und damit der autocreate Aufruf) wird erzeugt, wenn der Eintrag $modules{CUL_WS}{defptr} fuer Code 1 in CUL_WS_Parse nicht gefunden wird. Das kann passieren, wenn (temporaer?) ein IODev Attribut gesetzt wird, oder nach dem Loeschen (z.Bsp. durch rereadcfg) der Eintrag nicht sofort angelegt wird, sondern z.Bsp. erst nachdem FHEM2FHEM eine CUL_WS Nachricht empfangen hat. Ich habe letzteres im Verdacht (verwendest du rereadcfg bzw. "Edit files->fhem.cfg"?), allerdings sehe ich trotzdem nicht konkret, wie das passieren kann, weil FHEM2FHEM erst nach dem kompletten Einlesen der fhem.cfg mit Abarbeitung der Nachrichten anfaengt.

Um das Problem zu lokalisieren koennte man in FHEM/CUL_WS.pm vor jede Zeile, wo defptr modifiziert wird (CUL_WS_Define, CUL_WS_Undef, CUL_WS_Attr) eine Debugausgabe (Log 1, "Zeile XX") einfuegen, und darauf warten, dass das Problem auftritt.

[TeeVau]

fhem.cfg bearbeite ich nicht. Reicht dir die logausgabe Zeile xxx, oder soll noch irgendwas mit rein. Inhalt einer Variable oder so?

Dann setzte ich mich gleich mal dran und füge die log Einträge Ein

[TeeVau]

Ich habe jetzt folgende LOG Meldungen eingefügt und das Modul neu geladen:

Code Auswählen Erweitern

Line 54:   Log 3, "DEBUG CUL_WS: CUL_WS_Define(), Zeile 54";
Line 65:   Log 3, "DEBUG CUL_WS: CUL_WS_Undef(), Zeile 65";
Line 66:   Log 3, "DEBUG CUL_WS: CUL_WS_Undef(), Zeile 66" if($hash && $hash->{CODE});
Line 360:   Log 3, "DEBUG CUL_WS: CUL_WS_Attr(), Zeile 360";

Die CUL_WS Devices haben ich nun wieder alle konfiguriert und richtig umbenannt. Mal schauen wann etwas im Log zu sehen ist.

[TeeVau]

Der Fehler ist gerade wieder passiert. Ich vermute, ich weis nun auch, wann der Fehler genau auftaucht. Ich habe die alten Devices (Die ja eigentlich schon seit 3 Jahren funktionieren) gerade gelöscht und siehe da, auf einmal werden neue CUL_WS angelegt.
Noch einmal zur Erläuterung: 2 Devices funktionierten seit 3 Jahren. Das sind die "alten". Die 2 neuen Devices wurden plötzlich angelegt, als ich FHEM2FHEM eingerichtet habe. Das sind für mich die "neuen". Seit der Umstellung auf FHEM2FHEM wurden die Sensordaten nur für die neuen Devices erkannt, nicht für die alten. Damit ich mir die ganzen Einstellungen von Attributen nicht merken muss habe ich die alten Devices angelegt gelassen. Natürlich hatten die alten Devices auch die Sensor ID der jeweiligen Sensoren.

Die alten devices habe ich gerade gelöscht. Dabei taucht im Log das folgende auf:

Code Auswählen Erweitern


2015.02.21 18:55:28 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 65
2015.02.21 18:55:28 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 66

2015.02.21 18:55:37 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 65
2015.02.21 18:55:37 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 66


Direkt danach haben die Sensoren wieder Daten gesendet...die ja eigentlich bei den neuen Devices angezeigt werden sollen. Ich vermute jedoch, dass das nicht passiert ist, da die alten Devices ja die selbe Sensor ID haben, wie die neuen Devices. Und beim löschen der alten Devices wurde vermutlich die Sensor ID komplett entfernt, so dass das Modul denkt, es gibt gar kein Device, mit der passenden Sensor ID?!

Auf jeden Fall kam im Log folgendes:

Code Auswählen Erweitern


2015.02.21 18:56:19 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2015.02.21 18:56:19 2: autocreate: define CUL_WS_1 CUL_WS 1
2015.02.21 18:56:19 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 18:56:19 2: autocreate: define FileLog_CUL_WS_1 FileLog ./log/CUL_WS_1-%Y.log CUL_WS_1:T:.*
2015.02.21 18:56:19 2: autocreate: define SVG_CUL_WS_1 SVG FileLog_CUL_WS_1:temp4hum6:CURRENT
2015.02.21 18:56:32 1: CUL_WS UNDEFINED temp/hum sensor detected, code 2
2015.02.21 18:56:32 2: autocreate: define CUL_WS_2 CUL_WS 2
2015.02.21 18:56:32 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 18:56:32 2: autocreate: define FileLog_CUL_WS_2 FileLog ./log/CUL_WS_2-%Y.log CUL_WS_2:T:.*
2015.02.21 18:56:32 2: autocreate: define SVG_CUL_WS_2 SVG FileLog_CUL_WS_2:temp4hum6:CURRENT


Zum Testen habe ich nun mal folgendes gemacht.
Die gerade erstellen Devices CUL_WS_1 und CUL_WS_2 gelöscht. Danach ein "save" und dann ein restart shutdown.
Durch den Restart dürften eigentlich nur richtigen 2 Sensoren als Device erkannt werden.

Beim restart kommen die folgenden Meldungen (Wieso eigentlich 5 mal ein Define?!)

Code Auswählen Erweitern

2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54

[rudolfkoenig]

Wenn man mit dem gleichen Code mehrere CUL_WS Geraete definiert, und dann eins davon loescht, dann geht die modul-interne Zuordnung auch zum nicht-geloeschten Geraet (mit dem gleichen Code) verloren, und deswegen wird beim Eintreffen einer Nachricht ein neues Geraet angelegt. Das koennte man als Bug bezeichnen, ich will aber nicht mehrere CUL_WS mit dem gleichen ID unterstuetzen, und fixe es deswegen erstmal nicht.

Das urspruengliche Problem wird aber damit mAn noch nicht erklaert.

[TeeVau]

Als bug würde ich es auch nicht bezeichn n. Ist ja eher Ein Zustand gewesen, der so nicht vorgesehen ist.
Ein Workarounds ist ja ebenfalls beschrieben, falls es mal einen trifft.

Aber warum das Device einmal neuangelegt wurde kann ich auch nicht nachvollziehen. Ich möchte auch nicht meine Installation noch einmal umstellen

Danke für die Unterstützung. Ohne wäre ich nie auf dieses Verhalten gekommen