Broadlink als IR + HF gateway

[dev0]

Vor dem Einchecken ins SVN solltest Du das Senden der udp Pakete auf nonblocking umstellen. FHEM stellt zu diesem Zweck DevIo bereit. Die Beschwerden (und die Suche nach der Ursache) sind sonst schon vorprogrammiert.

[daniel2311]

Ja, die gab es schon
Aber so wie ich es jetzt umgebaut hat, blockiert er quasi kaum noch, wenn nur kurze Zeit und läuft dann in Timouts und zwar wirklich in Timeouts.
Ich gucke mir aber mal devio an. BlockingCall hatte ich mir mal angeguckt, das funktioniert aber unter Windows nur eher schlecht.
Hast du ein Beispiel, wo ich mal gut reinschauen könnte?

[dev0]

Mit einem FHEM unter Windows bist Du auch ein Exot Aber auch ein 3 Sekunden Timeout kann schon störend sein und ich würde es nicht einsetzen.

Module die DevIo verwenden:

Code Auswählen Erweitern


./00_DFPlayerMini.pm:
./00_FBAHA.pm:
./00_HMLAN.pm:
./00_HMUARTLGW.pm:
./00_KM271.pm:
./00_MAXLAN.pm:
./00_MQTT.pm:
./00_MYSENSORS.pm:
./00_NetzerI2C.pm:
./00_OWX.pm:require
./00_PROTOTYPE.pm:
./00_SIGNALduino.pm:
./00_SONOS.pm:
./00_TCM.pm:
./00_THZ.pm:
./00_ZWDongle.pm:
./10_DUOFERNSTICK.pm:
./10_FRM.pm:
./10_pilight_ctrl.pm:require
./19_VBUSIF.pm:
./20_N4HBUS.pm:
./24_PM20.pm:
./26_KM273.pm:
./34_NUT.pm:
./34_panStamp.pm:
./36_EleroStick.pm:
./36_JeeLink.pm:
./36_LaCrosseGateway.pm:
./37_SHC.pm:
./40_RFXCOM.pm:
./42_Nextion.pm:
./44_TEK603.pm:
./45_Plugwise.pm:require
./45_TRX.pm:
./47_OBIS.pm:
./50_TelegramBot.pm:
./70_KODI.pm:
./70_MEDIAPORTAL.pm:
./70_ONKYO_AVR.pm:
./70_PIONEERAVR.pm:
./70_STV.pm:
./70_XBMC.pm:
./89_HEATRONIC.pm:
./89_VCONTROL.pm:
./98_ArduCounter.pm:
./98_autocreate.pm:
./98_ComfoAir.pm:
./98_ModbusAttr.pm:
./98_Modbus.pm:


[daniel2311]

Ja, ich merke das auch... habe gestern versucht Presence an laufen zu bekommen und mir ist alles so übelst um die Ohren geflogen! Werde mit Windows schon sehr benachteiligt;)

DevIO Zeile 81 - zumindest glaube ich, dass ich hier an einer ganz guten Stelle bin:
# NOTE2: This works on Windows only for TCP connections

Ich glaube, das wird auch ein Problem sein, da habe ich nämlich ganz fies dran gebastelt und dann festgestellt, die komplette Timeout-Funktion bei den Verbindungen ist im offziellen Perl-Code wohl auskommentiert ist.

Nur mal so - was bringt mir die Verarbeitung über DevIO? Wird die Abfrage ausgelagert in einem Thead oder ähnliches oder sind das her Helper-Funktionen, wie mir zumindest ohne genauere Analyse und Test es zu sein scheint?

[dev0]

Der Kommentar in Zeile 81 bezieht sich wohl eher auf Netzwerkverbindungen im Gegensatz zu seriellen Verbindeungen. Das Sonos Modul nutzt mWn DevIo mit udp.
Such mal im Developerbereich nach DevIo, ich meine da gibt es den einen oder anderen Thread zu, eine Doku, außer den Quellcode, kenne ich nicht.

[daniel2311]

Naja, er würde zumindest auf das passen, was ich generell zu Timeouts mit Perl bei Netzwerkverdindungen gelesen habe und die UDP-Verbindung ist ja in diesem Falle dann dummerweise die Netzwerkverbindung und keine serielle. Ich lese mich mal ein und probiere mal und mal gucken, ob sich da etwas tut

[joerg_AC]

Hallo zusammen,
bei mir hat ist das ganze bei Schritt:
sudo python setup.py install
beim pycrypto ausgestiegen.
Habe die verschiedenen Tips zum nachinstallieren mit pip cpan .... befolgt -->Ohne Erfolg

Lösung war für mich:
sudo apt-get install python-dev libgmp-dev
hier gefunden.
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=110468

Vielleicht mit Spatzen auf Kanonen geschossen, hat aber funktioniert.
Gruss

Jörg

[daniel2311]

Das Modul befindet sich jetzt im SVN

[dev0]

Das Modul arbeitet immer noch blockierend.
Die Logausgaben lassen keinen Rückschluß auf das Modul zu.

Damit ist Mehraufwand (für andere Helfende) im Forum jetzt schon abzusehen.

[daniel2311]

Das Modul arbeitet immer noch blockierend.
Die Logausgaben lassen keinen Rückschluß auf das Modul zu.

Damit ist Mehraufwand (für andere Helfende) im Forum jetzt schon abzusehen.

Das mit dem DevIO muss ich mir noch anschauen. Aber so dauerhaft blockierend ist es nicht. Kurz allerdings schon.

Edit: Habe es doch mit den Log-Ausgaben verstanden. Ich übergebe zwar den Device-Namen, aber du meinst, ich soll noch mal in der Nachricht den Namen des Devices in der Nachricht loggen? Hmm, ich dachte, das würde automatisch passieren.

[dev0]

Nee, das blockiert nicht.
...
Kurz allerdings schon.

Per Default blockiert es für 3 Sekunden, wenn das Gerät nicht erreichbar ist.

Code Auswählen Erweitern


       my $timeout = AttrVal($hash->{NAME}, 'socket_timeout', 3.0);


Das mit den Log-Ausgaben musst du mir erklären

Woher soll man wissen zu welchem Modul die Ausgabe: "Problem with socket" gehört?

Code Auswählen Erweitern


or Log3 $hash->{NAME}, 5, "Problem with socket";

Zudem ist der verbose 5 für eine Nichterreichbarkeit (und blockieren von FHEM) nicht ganz passend.

[daniel2311]

Ja, das mit der Dokumentation habe ich verstanden
Danke. Das werde ich ändern. Auch mit 5 ist ein guter Hinweis, wobei wenn der Timeout erreicht werden würde, müsste er ein paar Zeilen später auch noch mal den Timeout melden...

Ich probiere das jetzt gleich mal mit DevIO...

[derchrome]

Hallo zusammen,
2 kurze Fragen hätte ich:
1) Läuft das Modul auch mit dem Mini 3?
2) Ich würde das ganze verwenden wollen um mit meiner Harmony FB das Licht zu schalten, also Befehle per IR einzulesen und dann im FHEM ans Lightify Gateway weiter zu leiten. Geht das?

[daniel2311]

Hi derchrome

1) Läuft das Modul auch mit dem Mini 3?
2) Ich würde das ganze verwenden wollen um mit meiner Harmony FB das Licht zu schalten, also Befehle per IR einzulesen und dann im FHEM ans Lightify Gateway weiter zu leiten. Geht das?

Zu 1) ja das geht
Zu 2) nein das geht nicht. Vom Grundsatz her kann das Ding zwar lesen, aber muss erst in den lesemodus versetzt werden. Mit einem harmony hub müsstest du das aber soweit ich weiß machen können...

[derchrome]

Danke für die schnelle Antwort. Dann ist es ja gut das ich noch nicht bestellt hab. Geht das mit der Pro Version?