FHEM Start und Definition von IO Devices

Thorsten Pferdekaemper · 02 April 2017, 09:13:47

Zitat von: rudolfkoenig am 02 April 2017, 08:38:55
Ich gehe davon aus, dass dein fhem.pl nicht aktuell ist.

Ah ja, da hast Du Recht. Das ganze ist auf meiner Entwicklungsbox und ich habe updates vermieden, da das auch meine Änderungen kaputt machen würde. Da muss ich wohl meinen Entwicklungsprozess etwas nachbessern.
Was mir noch nicht ganz klar ist:
Momentan wird im define bei mir noch direkt AssignIoPort aufgerufen. Das müsste dann verzögert stattfinden (InternalTimer) oder? ...oder braucht man das dann gar nicht mehr?
Gruß,
Thorsten

rudolfkoenig · 03 April 2017, 12:07:02

ZitatDas müsste dann verzögert stattfinden (InternalTimer) oder? ...oder braucht man das dann gar nicht mehr?

Nein, braucht man nicht, da dafuer eine Sonderfunktion gibt: falls waehrend der Initialisierung IODev fehlt, dann wird in AssignIoPort bzw. "attr XX IODev" IODevMissing gesetzt, und nach dem Einlesen von fhem.cfg wird fuer alle solche Geraete nochmal die Zuweisung versucht.

Nur falls du mit dem Geraet direkt im DefineFn kommunizieren willst, musst du es verzoegern.

Thorsten Pferdekaemper · 03 April 2017, 23:17:04

Hi,
ich habe das jetzt mal ausprobiert, aber folgendes Szenario macht Probleme: Es gibt zwei IO-Devices, nennen wir sie mal A und B. Jetzt gibt es ein Device (D), welches IO-Device B benutzt. Dummerweise wird aber A vor D angelegt und B erst danach. Dann ordnet AssignIoPort erst einmal das IO-Device A zu, da das schon vorhanden ist und theoretisch passt. Danach kommt dann "attr D IODev B", wodurch "mein" Kram versucht IO-Device B zu verwenden, aber irgendwie funkt trotzdem noch A dazwischen. Das geht schief.
So ganz verstehe ich noch nicht, warum das nicht klappt, aber vielleicht hat sonst jemand noch eine Idee.
Gruß,
Thorsten

rudolfkoenig · 04 April 2017, 07:32:34

ZitatDanach kommt dann "attr D IODev B", wodurch "mein" Kram versucht IO-Device B zu verwenden, aber irgendwie funkt trotzdem noch A dazwischen. Das geht schief.

Kannst du bitte das genauer beschreiben? Vlt mit eine "verbose 5" Log?
IODev dient eigentlich nur zum Schreiben, beim Lesen wird es nicht beruecksichtigt.

Thorsten Pferdekaemper · 04 April 2017, 09:20:21

Zitat von: rudolfkoenig am 04 April 2017, 07:32:34Kannst du bitte das genauer beschreiben? Vlt mit eine "verbose 5" Log?

Ich werde mir das selbst nochmal genauer ansehen müssen. Ich dachte nur, dass vor mir auch schon jemand ähnliche Effekte hatte. Es kann aber gut sein, dass das alles sehr spezifisch für HM-Wired ist.
Ich werde dann von meinen Ergebnissen berichten.
Gruß,
Thorsten

igami · 04 April 2017, 09:46:56

Könnte man nicht einfach alle Zeilen die in der cfg einen Fehler beim einlesen verursachen zwischenspeichern und dann erneut einlesen nachdem die cfg das erste mal vollständig eingelesen wurde?

Thorsten Pferdekaemper · 04 April 2017, 09:53:52

Zitat von: igami am 04 April 2017, 09:46:56
Könnte man nicht einfach alle Zeilen die in der cfg einen Fehler beim einlesen verursachen zwischenspeichern und dann erneut einlesen nachdem die cfg das erste mal vollständig eingelesen wurde?

Es wird ja formal kein Fehler verursacht. Woher soll FHEM den wissen, dass da in meinem Modul was falsch läuft?
Nein, meiner Meinung nach ist die einzig vernünftige Lösung die, dass die Reihenfolge der Device-Definitionen keine Rolle spielen darf.
Gruß,
Thorsten

rudolfkoenig · 04 April 2017, 11:56:02

Zitatdie Reihenfolge der Device-Definitionen keine Rolle spielen darf.

_Wenn_ ein logisches Geraet beim Definieren aus der fhem.cfg ueber das zugeordnete IODev kommunizieren will,
_dann_ muss diese Kommunikation per notify oder InternalTimer auf spaeter (nach Beenden der Initialisierung) verschoben werden.

Mir ist noch nicht klar, warum so eine Kommunikation notwendig ist, ich wuerde versuchen sowas zu vermeiden.
Schliesslich wird das bei jedem fhem Neustart oder rereadcfg ausgefuehrt.

Thorsten Pferdekaemper · 04 April 2017, 12:26:22

Zitat von: rudolfkoenig am 04 April 2017, 11:56:02
_Wenn_ ein logisches Geraet beim Definieren aus der fhem.cfg ueber das zugeordnete IODev kommunizieren will,
_dann_ muss diese Kommunikation per notify oder InternalTimer auf spaeter (nach Beenden der Initialisierung) verschoben werden.

Das ist klar.

Zitat
Mir ist noch nicht klar, warum so eine Kommunikation notwendig ist, ich wuerde versuchen sowas zu vermeiden.

Vielleicht nicht 100% notwendig, aber es passiert halt momentan so in meinem Modul, zumindest wenn nach dem AssignIoPort ein Device zugeordnet ist. Blöderweise kann das halt erst einmal ein falsches IODevice sein.
Notwendig ist eine Kommunikation mehr oder weniger direkt nach dem define, da bei HM-Wired der Gerätetyp und die Einstellungen aus dem Gerät gelesen werden. Das ist zumindest beim ersten define notwendig, später wenn es aus der fhem.cfg geht könnte man das umgehen.
Um das ganze aber sinnvoll umzubauen würde ich aber zuerst komplett verstehen, was da momentan (nicht) funktioniert. Ich denke aber, dass ich das selbst rausfinden werde.

Zitat
Schliesslich wird das bei jedem fhem Neustart oder rereadcfg ausgefuehrt.

Das ist ja nicht so schlimm. Mein Haupt-FHEM hatte die letzten 239 Tage keinen Neustart oder rereadcfg. Selbst wenn man jeden Tag einen Neustart machen würde, wäre das Einlesen der Gerätekonfiguration kein Problem.

Gruß,
Thorsten

rudolfkoenig · 04 April 2017, 14:10:48

ZitatSelbst wenn man jeden Tag einen Neustart machen würde, wäre das Einlesen der Gerätekonfiguration kein Problem.

Das mag sein, aber es gibt Leute, die in FHEMWEB, Edit-Files die notifiy, at, usw. aendern und debuggen, und deswegen staendig ein rereadcfg ausfuehren. It es auch kein Problem, wenn rereadcfg alle 10 Sekunden kommt?

Thorsten Pferdekaemper · 04 April 2017, 14:58:51

Zitat von: rudolfkoenig am 04 April 2017, 14:10:48It es auch kein Problem, wenn rereadcfg alle 10 Sekunden kommt?

Nein, das ware wahrscheinlich kein Problem. Dann wird das Lesen der Konfiguration vorzeitig abgebrochen und neu gestartet. Außerdem kann man es auch komplett abschalten.
Gruß,
Thorsten

Thorsten Pferdekaemper · 04 April 2017, 23:24:34

So, jetzt habe ich das ganze nochmal betrachtet.
Die Probleme kamen vor Allem daher, weil ich Depp für die beiden IODevices denselben USB-Port verwendet habe. Das ging dann natürlich ein bisschen durcheinander.
Also tatsächlich gab es kein Problem, wenn AssignIoPort aufgerufen wird bevor das IODev-Attribut gesetzt wird. Allerdings hat AssignIoPort zuerst das falsche IO-Device zugeordnet. Wenn das Attribut nicht gesetzt ist, dann sucht es halt irgendeins. Kurz danach wird dann zwar das richtige über das Attribut gesetzt, aber trotzdem gefällt mir das nicht. Ich habe deshalb jetzt doch AssignIoPort verzögert.
Eine Ausnahme ist, wenn das IO-Device direkt im define steht, da es dann sofort an AssignIoPort übergeben wird und es dann auch richtig behandelt wird.
Gruß,
Thorsten