device/Modul - AssignIoPort

[Elektrolurch]

Hallo,

ich schreibe gerade ein Modul, mit dem eine 5 Kanal-Vernbedienung mit Hilfe von einem FS20 SM8 angesteuert wird.
Mit dummys ging der proof einwandfrei, ein Modul wäre allerdings schicker. Jetzt geht alles, bis auf die Zuordnung zu einem CUL.
Am Ende der xxx_Define - Routine habe ich folgenden Aufruf eingefügt (aus dem FS20 abgekupfert ):

AssignIoPort($hash);
oder
AssignIoPort($hash,'CUL');
oder
AssignIoPort($hash,'TYPE=CUL');
Es kommt aber immer die Meldung im Log nacham ende der define-Routine:
2014.05.02 19:41:54 3: No I/O device found for Somfy
Das Attribut IODev gibt es in der attrlist für das Modul, ist natürlich beim define einer Instanz noch nicht belegt.
Ich habe mir die Routine in der fhem.pl angesehen, so ganz durchblicke ich aber nicht, wie ich den zweiten (optionalen) Parameter belegen muss, damit die Routine sich einen CUL sucht.

Jemand einen Tipp?
Mit einem grep über alle .pm - Dateien bin ich auch nicht fündig geworden.

Gruß


Elektrulurch

[C_Herrmann]

Hallo Elektrolurch,

das Problem hatte ich auch beim UNIRoll-Modul, weil das Protokoll früher nicht direkt von der culfw unterstützt wurde. Es betraf aber nur die automatische Erkennung beim define. Wenn das IODev per Attrbut eingetragen war, wurde es auch benutzt.

Gruß,
Christian

[Elektrolurch]

Hallo Christian,

ist natürlich schön, wenn das dann trotzdem funktioniert. Ich bin aber ein "Generalist", d.h. der Autor von der AssignIOPort hat sich ja wahrscheinlich bei dem optionalen Parameter was gedacht....
leider aber nicht dokumentiert. Ein bis zwei Zeilen Kommentar wären ja da hilfreich, ich möchte, dass es universell funktioniert, d.h. das device soll sich auch ohne gesetztem Attribut IODev den nächsten CUL schnappen können.

Ich hoffe, dass ein Entwickler die Frage hier liest...
Danke.

Elektrolurch

[C_Herrmann]

Hallo Elektrolurch,

der zusätzliche Parameter ist, wie Du es richtig interpretiert hast, ein Vorschlag. Er wird aber nur verwendet, wenn das Modul im CUL-Modul unter Clients aufgeführt ist.

Gruß,
Christian

[Elektrolurch]

Hallo Christian,

d.h.:
1. Man kann also nur Module schreiben, bei denen erst nach dem Setzen von attr name IODev eine feste Zuordnung zu einem Ein- und Ausgabedevice definiert wird.
2. Dann kann ich mir im define - Teil wohl auch den Aufruf von AssignIOPort ersparen.
Na schön, dann verstehe ich aber nicht, warum es überhaupt diesen Mechanismus mit dem AssignIOPort überhaupt gibt. Klarer wäre doch dann, dass jede Instanz das Attribut IODev haben muss.

Du scheinst Dich ja mit der Thematik schon etwas auseinander gesetzt zu haben. Frage:
Ich habe ein Modul, dass holt über http-Request aus einer Heizungsanlage die Werte ab. Derzeit habe ich das einstufig gelöst, d.h. ich warte auf die Antwort. Teilweise kann das aber bis zu einigen Sekunden dauern, in der Zeit fhem ja dann blockiert.
Wo finde ich da eine Anleitung oder ein Modul, in dem es einigermaßen ersichtlich ist, wie ich den Sendeteil vom Empfangsteil trenne (für TCP/IP - http)? Hast Du da ev. einen Tipp für die Vorgehensweise?

Gruß

Elektrolurch

[C_Herrmann]

Hallo Elektrolurch,

d.h.:
1. Man kann also nur Module schreiben, bei denen erst nach dem Setzen von attr name IODev eine feste Zuordnung zu einem Ein- und Ausgabedevice definiert wird.

Nicht unbedingt. Das gilt nur für Module, die nicht im FHEM-Verzeichnis sind. Deswegen habe ich das UNIRoll-Modul so zu sagen "adoptiert" und weiterentwickelt. Dazu habe ich mich als Entwickler registriet, das Modul überarbeitet und die notwendigen Veränderungen im CUL-Modul an Rudi, den Hauptentwickler geschickt, der sie dann eingebaut hat. Bei eigenen Modulen musst Du wohl damit leben, dass die automatische Zuordnung nicht geht. Da das Attribut ja nur einmal zu setzen ist, sollte das aber kein Problem sein.

2. Dann kann ich mir im define - Teil wohl auch den Aufruf von AssignIOPort ersparen.
Na schön, dann verstehe ich aber nicht, warum es überhaupt diesen Mechanismus mit dem AssignIOPort überhaupt gibt. Klarer wäre doch dann, dass jede Instanz das Attribut IODev haben muss.

Das kann ich nicht genau beantworten. Ich gehe aber davon aus, dass AssignIOPort notwendig ist, um den hash-Wert dafür zu erzeugen. Nur die automatische Erkennung funktioniert eben nicht. Es gibt auch Module, die kein Ein-/Ausgabegerät benötigen, die brauchen das natürlich nicht.

Du scheinst Dich ja mit der Thematik schon etwas auseinander gesetzt zu haben. Frage:
Ich habe ein Modul, dass holt über http-Request aus einer Heizungsanlage die Werte ab. Derzeit habe ich das einstufig gelöst, d.h. ich warte auf die Antwort. Teilweise kann das aber bis zu einigen Sekunden dauern, in der Zeit fhem ja dann blockiert.
Wo finde ich da eine Anleitung oder ein Modul, in dem es einigermaßen ersichtlich ist, wie ich den Sendeteil vom Empfangsteil trenne (für TCP/IP - http)? Hast Du da ev. einen Tipp für die Vorgehensweise?

Damit habe ich keine Errfahrung. Ich hoffe, es lesen andere Entwickler mit und geben Dir Tipps dazu. Sonst ist diese Frage besser in der Gruppe Automatisierung aufgehoben.

Gruß,
Christian