[84_IrBlaster] - Modul zur Ansteuerung des (360 Grad) IR WLAN Gateways

[viegener]

Ich habe mich mal drangesetzt, für das IR WLAN Gateway ein Modul zu machen, das die Kommandos für den IRBlaster verwaltet und per http an das gateway senden kann

Die Diskussion zur Hardware - 360 Grad IR WLAN Gateway findet sich hier: https://forum.fhem.de/index.php/topic,72950.0.html

Das Modul 84_IrBlaster.pm findet man erstmal nur in github und im Modul findet sich auch eine (englische) commandref

https://github.com/viegener/Telegram-fhem/tree/master/IrBlaster

Idee ist, dass man IR-Codes (also alles nach plain= im URL) als Attribute (mit einem Präfix) verwaltet (per add werden die attribute befüllt) und per send diese vordefinierten Codes versenden kann. Ausserdem kann man auch ad hoc entsprechende Codes versenden (direct)

Per internem presence-check (ping) wird bei Einstellen eines Intervalls regelmässig überprüft, ob das gateway erreichbar ist und wenn nötig soll das Senden der Befehle erst fortgesetzt werden, wenn das gateway wieder erreichbar ist.

Einen neuen device legt man mit define an:

Code Auswählen Erweitern

define <name> IrBlaster <hostname or IP> <prefix für Attribute> [ <passcode> ]

zum Beispiel so

Code Auswählen Erweitern

define irblaster IrBlaster 192.168.100.200 IR_ acbdef

[Pfriemler]

Eingerichtet, ausprobiert, läuft. Für mich persönlich jetzt kein Komfortgewinn - statt einen Dummy mit dem gewünschten Befehl zu setzen, den ein DOIF abholt und per getHttp an den IrBlaster schickt, tut es jetzt das Modul. Aber es ist übersichtlicher. Und vermutlich viieeel eleganter.

Nur als Randbemerkung: Ich bekomme keine "Device Specific Help" angezeigt. Der deutsche Bereich im .pm ist natürlich noch leer. Wenn man die html_DE-Tags entfernt, wird automatisch die englische Hilfe angezeigt, mir ist das lieber, solange es keine deutsche Hilfe gibt.

[viegener]

Eingerichtet, ausprobiert, läuft. Für mich persönlich jetzt kein Komfortgewinn - statt einen Dummy mit dem gewünschten Befehl zu setzen, den ein DOIF abholt und per getHttp an den IrBlaster schickt, tut es jetzt das Modul. Aber es ist übersichtlicher. Und vermutlich viieeel eleganter.

Nur als Randbemerkung: Ich bekomme keine "Device Specific Help" angezeigt. Der deutsche Bereich im .pm ist natürlich noch leer. Wenn man die html_DE-Tags entfernt, wird automatisch die englische Hilfe angezeigt, mir ist das lieber, solange es keine deutsche Hilfe gibt.

Der Komfortgewinn ist sicher subjektiv, für mich ist aber schon das Hinzufügen eines einzelnen IR-Codes einfacher, weil ich nur noch zwei Schritte brauche. Aber sicher wäre es noch interessanter, wenn man einen Code direkt aus dem Gateway hinzufügen könnte, aber dazu muss ich noch etwas einbauen um die HTML-Seite zu parsen.

[Pfriemler]

Jetzt habe ich ein Problem. Grobe Vermutung: Das Modul ist zu ungeduldig, besonders wenn auf anderem Gebiet gerade mehrere Events einschippern. Habe mal auf Verbose 5 gestellt und erhalte

Code Auswählen Erweitern

2017.12.13 17:02:00 5: STARTING SENDREQUEST: http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d
2017.12.13 17:02:00 5: Sub IrBlaster_SendRequest (IRWz) - Action /json?plain=[{'data':'3D','type':'RC6','length':20}]  Par1:1513180920.30612: 
2017.12.13 17:02:00 4: IrBlaster_SendRequest IRWz: call url :http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d:
2017.12.13 17:02:00 4: IrBlaster IRWz: called function IrBlaster_Set()
2017.12.13 17:02:01 4: IrBlaster_HU_Callback IRWz: status err :http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d: empty answer received:
2017.12.13 17:02:01 5: IrBlaster_HU_Callback IRWz:   data :
2017.12.13 17:02:01 4: IrBlaster_HU_Callback IRWz: resulted in Error returned: http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d: empty answer received
2017.12.13 17:02:01 4: IrBlaster_HU_Callback IRWz: retry count so far 1 (max: 0) for send request [{'data':'3D','type':'RC6','length':20}] : 1513180920.30612 : <undef>
2017.12.13 17:02:01 3: IrBlaster_HU_Callback IRWz: Reached max retries (ret: Error returned: http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d: empty answer received) for msg [{'data':'3D','type':'RC6','length':20}] : 1513180920.30612


Die Details:

Code Auswählen Erweitern

Internals:
   DEF        192.168.178.60 IR_
   HOST       192.168.178.60
   INTERVAL   600
   NAME       IRWz
   NR         819
   PREFIX     IR_
   STATE      off
   TYPE       IrBlaster
   VERSION    0.0.5
   doStatus   
   lastresponse Error returned: http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d: empty answer received
   HU_SR_PARAMS:
     NAME       
     action     /json?plain=[{'data':'3D','type':'RC6','length':20}]
     addr       http://192.168.178.60:80
     auth       0
     buf       
     compress   1
     conn       
     displayurl http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d
     header     
     host       192.168.178.60
     hu_blocking 0
     hu_port    80
     hu_portSfx
     loglevel   4
     method     GET
     path       /json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d
     protocol   http
     redirects  0
     timeout    30
     url        http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d
     SR_READINGS:
     args:
       [{'data':'3D','type':'RC6','length':20}]
       1513180920.30612
       undef
       1
     hash:
     sslargs:
   READINGS:
     2017-12-13 16:57:12   presence        present
     2017-12-13 17:02:01   requestAction   /json?plain=[{'data':'3D','type':'RC6','length':20}]
     2017-12-13 17:02:01   requestResult   Error returned: http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d: empty answer received
     2017-12-13 10:57:06   state           off
   actionQueue:
   helper:
Attributes:
   IR_KerzenAN [{'data':'FF807F','type':'NEC','length':32}]
   IR_KerzenAUS [{'data':'FF906F','type':'NEC','length':32},{'data':'FF20DF','type':'NEC','length':32}]
   IR_LeinwandAB [{'data':[1263,421,1263,421,1263,421,1263,421,421,1263,421,1263,421,1263,421,1263,421,1263,1263,421,421,1263,421,1263,421,1263,1263,421,421,1263,1263,421,1263,421,1263,421,1263,421,421,1263,1263,421,1263,421,1263,421,421,1263,1263,421,1263,421,421,1263,421,1263,1263,421,421,1263,421,1263,1263],'type':'raw','khz':38}]
   IR_LeinwandAUF [{'data':[1263,421,1263,421,1263,421,1263,421,421,1263,421,1263,421,1263,421,1263,421,1263,421,1263,1263,421,421,1263,421,1263,1263,421,421,1263,1263,421,1263,421,1263,421,421,1263,1263,421,1263,421,1263,421,421,1263,1263,421,1263,421,421,1263,1263,421,421,1263,1263,421,421,1263,421,1263,1263],'type':'raw','khz':38}]
   IR_LeinwandSTOP [{'data':[1263,421,1263,421,1263,421,1263,421,421,1263,421,1263,421,1263,421,1263,421,1263,421,1263,421,1263,1263,421,421,1263,1263,421,421,1263,1263,421,1263,421,1263,421,421,1263,421,1263,1263,421,1263,421,421,1263,421,1263,421,1263,1263,421,1263,421,1263,421,1263,421,421,1263,421,1263,421],'type':'raw','khz':38}]
   IR_PhilipsTVAmbilight [{'data':'8F','type':'RC6','length':20}]
   IR_PhilipsTVMUTE [{'data':'D','type':'RC6','length':20}]
   IR_PhilipsTVOFF [{'data':'3D','type':'RC6','length':20}]
   IR_PhilipsTVON [{'data':'3F','type':'RC6','length':20}]
   IR_PhilipsTVPOWER [{'data':'1000C','type':'RC6','length':20}]
   IR_SonyBeamer2XPOWER [{'data':'542A','type':'SONY','length':15,'rdelay':4000,'repeat':2}]
   IR_SonyBeamerPOWER [{'data':'542A','type':'SONY','length':15}]
   IR_SonyBlurayEJECT [{'data':'68B47','type':'SONY','length':20}]
   IR_SonyBlurayOFF [{'data':'F4B47','type':'SONY','length':20}]
   IR_SonyBlurayON [{'data':'74B47','type':'SONY','length':20}]
   IR_YamahaReceiverHDMI1 [{'data':'5EA1E21C','type':'NEC','length':32}]
   IR_YamahaReceiverHDMI2 [{'data':'5EA152AC','type':'NEC','length':32}]
   IR_YamahaReceiverHDMI3 [{'data':'5EA1B24C','type':'NEC','length':32}]
   IR_YamahaReceiverMUTE [{'data':'5EA138C7','type':'NEC','length':32}]
   IR_YamahaReceiverPOWER [{'data':'7E8154AB','type':'NEC','length':32}]
   group      Schnittstellen
   icon       IR
   interval   600
   room       System
   userattr   IR_.* IR_KerzenAN IR_KerzenAUS IR_LeinwandAB IR_LeinwandAUF IR_LeinwandSTOP IR_PhilipsTVAmbilight IR_PhilipsTVMUTE IR_PhilipsTVOFF IR_PhilipsTVON IR_PhilipsTVPOWER IR_SonyBeamer2XPOWER IR_SonyBeamerPOWER IR_SonyBlurayEJECT IR_SonyBlurayOFF IR_SonyBlurayON IR_YamahaReceiverHDMI1 IR_YamahaReceiverHDMI2 IR_YamahaReceiverHDMI3 IR_YamahaReceiverMUTE IR_YamahaReceiverPOWER
   verbose    5

Angesteuert wird das von diesem DOIF:

Code Auswählen Erweitern

Internals:
   DEF        ([FB12_Btn_07:"Long.5"] or [DispFB_Btn_09:"Long.5"] or [HM_PB4Dis1_Btn_03:"Short"])
    (set IRWz send PhilipsTVOFF,                                       ## schalte Fernseher aus
     IF ([DB500HD:state] eq "absent") (set PWRSW_TV off)           ## prüfe ob Dreambox sofort stromlos werden darf
      ELSE (IF ([DB500HD:recordings] == 0 and ([DB500HD:recordings_next_counter] == 0 or [DB500HD:recordings_next_counter] > 3600)) ## wenn nicht aus, keine Aufnahmen laufen und in der nächsten Stunde keine startet
        (set DB500HD shutdown, define tmpDB500off at +00:02:00 set PWRSW_TV off) ## sende shutdown, Steckdose 2min später aus
      )
     )
    (set PWRSW_HIFI off) ## mit Verzögerung von 20 Sekunden, um den Fernseher abschalten zu lassen.
DOELSEIF ([FB12_Btn_07:"Short"] or [DispFB_Btn_09:"Short"] or [HM_PB4Dis1_Btn_04:"Short"])
    (set PWRSW_TV on)                                         ## sofort
    (set PWRSW_HIFI on)                                       ## nach 2s zur Stromstoßentzerrung
    (set IRWz send YamahaReceiverHDMI2)                           ## 13s (Yamaha muss erst hochfahren)
    (IF ([PhilipsTV] ne "present") (set IRWz send PhilipsTVPOWER)) ## erst nach 2:15 min  prüfen und ggf. TV einschalten

Problem macht der erste, also der Ausschalt-Zweig, genauer: set IRWz send PhilipsTVOFF. Der zweite Zweig (getriggert durch einmalige Short-Events) funktioniert tadellos.

Setze ich stattdessen mein altes "set IRcmd PhilipsTVOFF" ein, gibt es keine Probleme (IRcmd ist ein Dummy, auf dessen Änderung ein anderes DOIF triggert und direkt {GetHttpFile("192.168.178.60","/json?plain=[{'data':'3D','type':'RC6','length':20}]")} sendet.
Starte ich den Ausführungszweig des DOIF manuell ("set <DOIF> cmd1"), gibt es keine Fehler. (!)
Nur wenn das DOIF durch eine der drei Fernbedienungen getriggert wird, hakelt es im IRWz:

Error returned: http://192.168.178.60:80/json?plain=%5b%7b%27data%27%3a%273D%27%2c%27type%27%3a%27RC6%27%2c%27length%27%3a20%7d%5d: empty answer received

die restlichen Befehle laufen immer störungsfrei durch. Dass es den Raspi durch die Long-Events wirklich in die Knie zwingt, glaube ich kaum, aber es sieht danach aus.

Was kann ich noch zur Erhellung beitragen?

[viegener]

@Pfriemler: Wird denn der Befehl ausgeführt - sprich das IRCMD gesendet (set IRWz send PhilipsTVOFF)

Das mit dem ungeduldig kann ich mir nicht vorstellen, denn normalerweise sollte der Teimout bei 30 Sekunden liegen, bei Dir kommt aber bereits nach einer Sekunde eine leere Antowrt zurück.

das direkte gethttpfile geht vermutlich weil dabei eine leere Antowrt ignoriert wird?

[Pfriemler]

Nein, der Befehl wird im fraglichen Fehlerfall nicht ausgeführt.

das direkte gethttpfile geht vermutlich weil dabei eine leere Antowrt ignoriert wird?

Eigentlich nicht - wann immer ich den inkludierten Befehl manuell per Webbrowser absetze, bekomme ich die gleichen Antworten, die auch Dein Modul als lastResponse liefert.
Aber Du sagst es: Wieso ist von einer leeren Antwort die Rede, wenn es nicht einmal einen retry gibt? Was passiert da überhaupt? Unter 30 s hatte ich mir auch was anderes vorgestellt.

Und: Jede normale Aussendung per "set IRWz send PhilipsTVOFF" klappt immer - ich habe es etliche Male hintereinander probiert, immer einwandfrei. Nur nicht, wenn das DOIF anspringt, wenn die Long-Trigger von HM einlaufen (da kommt ja alle 0,4 Sekunden einer, fortlaufend hochnumeriert), aber nur die benannten einzelnen lösen aus, eine Mehrfachauslösung des DOIF ist also ausgeschlossen, auch über meinen Dummy wird stets nur EIN Befehl gesendet. Hier ist die Fehlerquote ebenfalls konstant ohne einmalige erfolgreiche Ausreißer.

Ich könnte jetzt einfach den Dummy und das DOIF weiterverwenden, aber das hilft Deiner Modulentwicklung ja nicht weiter. Um meine Geräte zu schonen, baue ich eine Doppelaussendung mit Zeitverzögerung ein und beobachte weiter - geht der TV sofort aus, klappt Dein Modul. Dann sehen wir mal weiter. Ich nutze das DOIF als Ausschaltmakro eigentlich jeden Abend.

Ich werde mal morgen abend ein weiteres DOIF als Test anlegen (LED-Kerzen bspw.). Dann kann ich nach Herzenslust testen, ohne dass der Fuhrpark mitläuft.

Ich hätte noch eine Idee: Der HM-Empfang läuft größtenteils über ein HM-CFG-LAN, kommt also über Netzwerk herein. Vielleicht kommen sich die Pakete da ins Gehege. getHttp interessiert das aber nicht. Naja.

edit: Ich habe noch eine Verzögerung eingebaut - der erste Befehl wird vom DOIF erst nach 2 Sekunden gesendet. Dann sind die Telegramme von HM durch. Mal sehen ob das was bringt.
Was mich jetzt noch wundert: Auch die Ausschaltsequenz über das Short vom HM_PB4Dis1 war betroffen. Seltsam.

[viegener]

Aber Du sagst es: Wieso ist von einer leeren Antwort die Rede, wenn es nicht einmal einen retry gibt? Was passiert da überhaupt? Unter 30 s hatte ich mir auch was anderes vorgestellt.

Ich hätte noch eine Idee: Der HM-Empfang läuft größtenteils über ein HM-CFG-LAN, kommt also über Netzwerk herein. Vielleicht kommen sich die Pakete da ins Gehege. getHttp interessiert das aber nicht. Naja.

edit: Ich habe noch eine Verzögerung eingebaut - der erste Befehl wird vom DOIF erst nach 2 Sekunden gesendet. Dann sind die Telegramme von HM durch. Mal sehen ob das was bringt.
Was mich jetzt noch wundert: Auch die Ausschaltsequenz über das Short vom HM_PB4Dis1 war betroffen. Seltsam.

Also das mit der leeren Antwort heisst einfach, dass als Rückgabe statt der erwarteten Antwort nur die Verbindung geschlossen wurde.
Die dreissig Sekunden beziehen sich ja auch nur, wenn die Antwort länger dauert, hier ist die leere Antwort ja sofort da.

Das Problem liegt möglicherweise eher auf Seiten des IR WLAN Gateways - kann es sein, dass von woanders ebenfalls ein Befehl an das WLAN Gateway gesendet wird?

[Pfriemler]

Das Problem liegt möglicherweise eher auf Seiten des IR WLAN Gateways - kann es sein, dass von woanders ebenfalls ein Befehl an das WLAN Gateway gesendet wird?

Nee. Das hatte ich zuallererst geprüft.

Die dreissig Sekunden beziehen sich ja auch nur, wenn die Antwort länger dauert, hier ist die leere Antwort ja sofort da.

Von was auch immer, das ist das seltsame.

Nach den letzten Updates und zwei Neustarts nebst der Verzögerung stellt sich die Sachlage deutlich stabiler dar: Im Prinzip funzt es. Jetzt habe ich die Sendeverzögerung im DOIF wieder herausgenommen, das Backup über den Dummy IRcmd bleibt. Im Idealfall sehe ich das Gateway also sofort und nach 5 Sekunden nochmal blitzen. Alle Versuche heute früh waren erfolgreich.

Ich HASSE das!!! 

Als nächstes hätte ich mal ein oder zwei Retrys versucht. Wobei das global kontraproduktiv sein kann, wenn man toggles sendet. Wenn dann nur die Antwort unkorrekt ist, wird u.U. zweimal gesendet...?

[Pfriemler]

Gibt es eigentlich noch jemanden außer mir und viegener, der das Modul nutzt?

Verbesserungsvorschlag: Ich hatte gestern einen Totalausfall des Gateways, aus unbestimmtem Grund. (Es ist denkbar, dass wir hier eine Spannungsspitze hatten, es sind noch mehr sonderliche Dinge passiert). Ein simpler Neustart, und es war wieder da.
Dass mir das angezeigt wird, kann ich mal gelegentlich nachrüsten, aber wenn ein IR-Befehl mal nicht funktioniert, bringt mich das auch nicht um.

Was mir aber nicht wirklich gefällt, und deswegen frage ich vorsichtig:
1. Nachdem das Gateway wieder am Leben war, wurde es vom IrBlaster nicht bedient. Ich musste erst ein "set ... presence" absetzen.
a) ich würde mir wünschen, dass bei Nichtpräsenz die Abfragen öfter erfolgen. Ich pinge Geräte, die ich suche, durchaus im 15-s-Abstand, zur Überwachung im 60s. Hier war das Gateway auch nach mehr als einer Minute noch nicht wieder zu beschicken.

2. Als ziemlich kontraproduktiv empfinde ich (absichtlich vorsichtig formuliert), dass zwischengespeicherte Sendefolgen nachgeholt werden. Das hat prinzipiell wunderbar funktioniert, die testweise bedienten LED-Kerzen vollführten nach dem "set presence" eine sekundenlage wilde Blinkerorgie. Leider waren die Befehle zu der Zeit bereits mehr als fünf Minuten alt. Ich würde mir also ein maximales Alter der Befehle wünschen, am besten konfigurierbar, alles ältere soll verfallen. Oder gibt es da bereits eine Schwelle?
Konkret bedeutet das bei mir: Das IR-Gateway hängt bei mir an einer normalerweise dauerhaft stromversorgten (weil fernbedienten), aber dennoch mit einem Wandschalter abschaltbaren Deckenlampe. Wenn mal wieder ein Dödel das Licht versehentlich an der Wand ausgeknipst hat, wäre es eben sehr unschön, wenn die am Vorabend von den TV- und Heimkinomakros abgesendeten Befehle für Receiver, Beamer und Leinwand die Bude in ein Geisterhaus verwandeln.

Die in den vorherigen Beiträgen genannten Probleme treten sporadisch immer wieder mal auf. Ich merke es an der Verzögerung der Fernseherausschaltung: geht er erst nach fünf Sekunden aus, dann hat erst der GetHttp-Aufruf in der Reserve das Kommando abgeschickt. Seltsamerweise ist nur in diesem Zusammenhang ein Problem. Alle anderen Aussendungen sind fehlerfrei. Es funzt, was soll's...

[CarstenF]

Also ich bin gerade (seit gestern) dabei, mich mit dem Modul zu beschäftigen und würde es gerne nutzen. Leider ist zur Zeit etwas wenig Luft für das Hobby, so das ich nur sporadisch dazu komme. Aber grundsätzlich fände ich es sinnvoll, wenn es für dieses tolle Gateway ein Modul gibt. Für die ,,Nicht Erreichbarkeit" des Gateway, könnte man sich ja ein notify oder ein DOIF bauen, welches nach einer gewissen Zeit ein ,,set presence" absetzt. Ansonsten müßte des doch programmiertechnisch möglich sein, z.B. Nach 5 Minuten oder so, den ,,Cache" zu leeren, damit alte Befehle gelöscht werden. Leider sind Programmierkenntnisse bei mir nur rudimentär vorhanden, so das ich da nicht wirklich helfen kann. Gruß Carsten


Gesendet von iPad mit Tapatalk

[viegener]

Gibt es eigentlich noch jemanden außer mir und viegener, der das Modul nutzt?

Verbesserungsvorschlag: Ich hatte gestern einen Totalausfall des Gateways, aus unbestimmtem Grund. (Es ist denkbar, dass wir hier eine Spannungsspitze hatten, es sind noch mehr sonderliche Dinge passiert). Ein simpler Neustart, und es war wieder da.
Dass mir das angezeigt wird, kann ich mal gelegentlich nachrüsten, aber wenn ein IR-Befehl mal nicht funktioniert, bringt mich das auch nicht um.

Was mir aber nicht wirklich gefällt, und deswegen frage ich vorsichtig:
1. Nachdem das Gateway wieder am Leben war, wurde es vom IrBlaster nicht bedient. Ich musste erst ein "set ... presence" absetzen.
a) ich würde mir wünschen, dass bei Nichtpräsenz die Abfragen öfter erfolgen. Ich pinge Geräte, die ich suche, durchaus im 15-s-Abstand, zur Überwachung im 60s. Hier war das Gateway auch nach mehr als einer Minute noch nicht wieder zu beschicken.

2. Als ziemlich kontraproduktiv empfinde ich (absichtlich vorsichtig formuliert), dass zwischengespeicherte Sendefolgen nachgeholt werden. Das hat prinzipiell wunderbar funktioniert, die testweise bedienten LED-Kerzen vollführten nach dem "set presence" eine sekundenlage wilde Blinkerorgie. Leider waren die Befehle zu der Zeit bereits mehr als fünf Minuten alt. Ich würde mir also ein maximales Alter der Befehle wünschen, am besten konfigurierbar, alles ältere soll verfallen. Oder gibt es da bereits eine Schwelle?
Konkret bedeutet das bei mir: Das IR-Gateway hängt bei mir an einer normalerweise dauerhaft stromversorgten (weil fernbedienten), aber dennoch mit einem Wandschalter abschaltbaren Deckenlampe. Wenn mal wieder ein Dödel das Licht versehentlich an der Wand ausgeknipst hat, wäre es eben sehr unschön, wenn die am Vorabend von den TV- und Heimkinomakros abgesendeten Befehle für Receiver, Beamer und Leinwand die Bude in ein Geisterhaus verwandeln.

Die in den vorherigen Beiträgen genannten Probleme treten sporadisch immer wieder mal auf. Ich merke es an der Verzögerung der Fernseherausschaltung: geht er erst nach fünf Sekunden aus, dann hat erst der GetHttp-Aufruf in der Reserve das Kommando abgeschickt. Seltsamerweise ist nur in diesem Zusammenhang ein Problem. Alle anderen Aussendungen sind fehlerfrei. Es funzt, was soll's...

- Das Modul sendet nur die Befehle aus den letzten 5 Minuten neu alle anderen sollten ignoriert werden - ich kann das auch noch konfigurierbar machen (bis hin zum Abschalten)
- Das mit der presence-überprüfung (Intervall) ist ja konfigurierbar - hast Du ein Intervall gesetzt? problem ist, dass die jetzige Überprüfung relativ teuer ist - ich würe da gerne erst etwas simpleres einbauen

- Ich überprüfe mal, ob das Modul bei mir auch nicht automatisch wieder verunden wird - bei mir geht es aber ich habe auch ab und an mal WLAN-Verbindungsabbrüche

[Pfriemler]

Spät, aber nicht minder herzlich danke für die Antwort.
Ja, interval habe ich erfolgreich übersehen. 10 Minuten (600) waren natürlich noch nicht um. Habs jetzt auf 60, schauen wir mal wie sich das auswirkt, ebenso maxRetries auf 0.
Wenn es eh nur die Befehle der letzten 5 Minuten sendet, ist meine Angst unbegründet. Wollte ja nur mal gefragt haben.

Last but not least: Wieso ist der Ping "teuer" (wohl im Sinne von aufwändig)?

[viegener]

@Pfriemler: Nimm mal die neueste Version aus github, da gibt es auch ein konfigurierbares wiederholen und auch den pingtype über SYN

Das mit dem aufwändig bezog sich auf den Ablauf und wie stark ich sehe, dass das auf einem raspberry auf die last geht

[Pfriemler]

... neueste Version aus github, da gibt es auch ein konfigurierbares wiederholen und auch den pingtype über SYN

Ah ... stimmt. War mir anhand der stehengebliebenen Versionsnummer erst im Textvergleich aufgefallen. Aufgespielt, mal sehen.

Das mit dem aufwändig bezog sich auf den Ablauf und wie stark ich sehe, dass das auf einem raspberry auf die last geht

OK. Seit ich aber auf 60 s herunter bin, hat das keinen messbaren Einfluss auf die Systemlast meines RPi, zumindest bewegen sich die 15-min-Werte genauso unauffällig unter der 20%-Marke.
Alles andere würde mich auch schwer wundern.
Seit heute mit "shell" und timout=75. Wunderbar.
Den Hinweis aufs Wiki haste vielleicht auch schon gelesen im anderen Thread. Kommt (noch) ein bisschen kurz dort...

[eldrik]

Moin,

ich habe gestern ein Problem mit dem Modul gehabt.

Reproduktionsbeschreibung:
Modul definiert mit passcode zur Nutzung mit dem IR Gateway, erfolgreiches senden von Befehlen möglich.

Aus irgendeinem Grund scheint mein Gateway jedoch nicht die ihm mitgegebenen Werte (Hostname, Port, Passcode usw.) zu speichern, nach einem Reboot des Gateways bekam ich vom Modul die Meldung 401 welches nach Prüfung des FHEM Logs auf den nun fehlenden Passcode zurückzuführen war.

Ich konnte die Definition des Moduls jedoch nicht dahingehend abändern, dass nun kein Passcode mehr genutzt werden soll, trotz Löschung des Passcodes aus der Definition wurde der Passcode weiterhin im Modul unter PASS angezeigt und verwendet.

Erst mit der Definition einer weiteren IrBlaster Instanz ohne Passcode konnte ich hier fortfahren.

Greetz
Eldrik