[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

[viegener]

@eldrik: Du hast völlig recht, ich habe einen Fix ins github gestellt

[viegener]

Den Hinweis aufs Wiki haste vielleicht auch schon gelesen im anderen Thread. Kommt (noch) ein bisschen kurz dort...

Danke für den Hinweis (und vor allem das Erstellen) des wiki-Eintrags. Ich hatte den noch nicht gesehen.

[Manylion]

Moin!

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

Ich probier auch mit dem Modul rum. Scheint bisher ganz gut zu klappen.
Habs so definiert

Code Auswählen Erweitern

define IR IrBlaster 192.168.1.5 IR_
attr IR userattr IR_.* IR_CD_Pause IR_CD_Play
attr IR IR_CD_Pause [{'data':'45BAE817', 'type':'NEC', 'length':32}]
attr IR IR_CD_Play [{'data':'45BA18E7', 'type':'NEC', 'length':32}]

und noch ein bisschen aufgehübscht mit

Code Auswählen Erweitern

attr IR widgetOverride _send:uzsuSelectRadio,CD_Pause,CD_Play
attr IR webCmd _send


Danke an Euch!

[giovanne]

Hi, ich bin noch fhem Anfänger, habe aber das IrBlaster Modul bereits ans Laufen bekommen 
Funktioniert super.

Ich habe ein, zwei Fragen bzgl. der Realisierbarkeit meines Vorhabens.

Ich habe einen per IR Fernbedienung steuerbaren Staubsaugerroboter, die Umsetzung/Ansteuerung per IRBlaster funktioniert (alles Codes liegen vor). Evtl. soll der NodeMCU später in den Sauger wandern. Derzeit hockt er für das PoC noch auf dem 'Dach' 

Der IR Saugroboter soll per IRBlaster etwas 'smarter' werden 

In Fhem/IRBlaster ist alles soweit eingerichtet, jedoch würde ich gerne:
- (config) wissen, wenn ich in einem Commando mehrere Signale 'data' definiere, wie schnell hintereinander werden die abgefeuert? (kann ich dazu das 'pdelay' nutzen, wenn ich z.B. mal eine Pause von 1 oder 5 sec. haben möchte?)
- (execute) wissen, ob ich  eine Timer starten kann, der wenn ich ein Commando losgefeuert habe startet und nach z.B. 10 min. einen weiteres Commando startet?
Wozu soll das sein: der Roboter soll per IR Befehle in die Küche fahren, saugen und nach 10 min. zurück in die Station/Home fahren.
Etwas Erklärung dazu auch unten, bzw. die entscheidenden Stellen.

Verzeihung, wenn dies allg. fhem Fragen/Themen sind und nicht das Modul spezifisch betreffen 

Code Auswählen Erweitern


Definition:
define RoboIR IrBlaster 192.168.0.29 IR_
attr RoboIR userattr IR_.* IR_HOME IR_PLAY_PAUSE IR_KITCHEN...
...
attr RoboIR IR_HOME [{'data':'AAAA8877', 'type':'NEC', 'length':32}]
...
[color=red]#Sequence Kitchen: PLAY-PAUSE,(1sec),PLAY-PAUSE,(1sec),RIGHT,(1sec),RIGHT,(1sec),UP,(5 sec),UP,(1sec), ...
attr RoboIR IR_KITCHEN [{'data':'AAAA2DD', 'type':'NEC', 'length':32}, {'data':'AAAA2DD', 'type':'NEC', 'length':32}, {'data':'AAAA4BB', 'type':'NEC', 'length':32}, {'data':'AAAA4BB', 'type':'NEC', 'length':32}, {"data":"AAAA5AA", "type":"NEC", "length":32}, {"data":"AAAA5AA", "type":"NEC", "length":32}][/color]

[color=red]Execution:
set RoboIR _send IR_KITCHEN #drive to kitchen
??? wait/timer 10 minutes
set RoboIR _send IR_HOME #drive back home
[/color]

eine weitere Frage noch, kann ich den 'set RoboIR _send IR_KITCHEN' command auch direkt per URL aufrufen (inkl. dann wird der Timer... gestartet)), also
"http://fhem-server/fhem/???set RoboIR _send IR_KITCHEN???" , damit ich mich nicht durcvh fhem durchklicken muss, sondern nur einen Aufruf habe?

[Pfriemler]

Deutschland, dein mobiles Internet ... normalerweise kopiere ich meinen frisch geschriebenen Beitrag immer in die Zwischenablage bevor ich ihn abschicke ...

Also nochmal:
Das Modul IrBlaster kümmert sich vorzugsweise um die Kommunikation zwischen dem ESP8266 und FHEM, inkl. Zwischenpufferung und Fehlermeldungen bei Problemen. pdelay dient eigentlich eher der Verzögerung im Millisekundenbereich. Selbst wenn man das hinreichend groß bemisst, bleibt das Modul für diese Zeit blockiert und kann keine anderen Codes senden.
Ich würde die Zeitsteuerung komplett in eine andere Programmroutine verlegen, inklusive Auslöse- und Cancelbedingung. Ich verwende für sowas DOIF. Das kann auf eine Zeitsteuerung, eine Taste, ein anderes Ereignis reagieren und mehrere Befehle zeitversetzt (über wait-Attribut: 600s = 10min) ausführen. Dazu eine Cancelbedingung, um das Saugen vorzeitig abzubrechen und den Sauger zurückzurufen.

Code Auswählen Erweitern


defmod di_Command2BotKitchen DOIF (<Auslösebedingung>)
   (set RoboIR _send IR_KITCHEN)
   (set RoboIR _send IR_HOME)
DOELSEIF (<Cancelbedingung>)
   (set RoboIR _send IR_HOME)

attr di_Command2BotKitchen do always
attr di_Command2BotKitchen wait 0,600:0


Jm2c.

Nachtrag: Befehlsaufrufe an FHEM über eine URL sind natürlich möglich. Würde ich in diesem Fall aber auf das DOIF lenken. Aber warum überhaupt? Eine Reaktion von FHEM auf ein Ereignis von außen ist doch meist sinnvoller.

[giovanne]

...
pdelay dient eigentlich eher der Verzögerung im Millisekundenbereich. Selbst wenn man das hinreichend groß bemisst, bleibt das Modul für diese Zeit blockiert und kann keine anderen Codes senden.

   ...

Nachtrag: Befehlsaufrufe an FHEM über eine URL sind natürlich möglich. Würde ich in diesem Fall aber auf das DOIF lenken. Aber warum überhaupt? Eine Reaktion von FHEM auf ein Ereignis von außen ist doch meist sinnvoller.

Für den langen Zeitraum von z.B 10 Minuten würde ich es über deine vorgeschlagene DOIF Lösung versuchen.
Aber für eigentliche Fahrt in die Küche, wo zw. den Befehlen z.B jeweils eine Sekunde vergehen soll, wäre es über pdelay machbar? Das das Modul in den kurzen Zeiten blockiert ist, ist egal, da es nur für den Roboter zuständig ist.
Also in folgender Form:

Code Auswählen Erweitern


attr RoboIR IR_KITCHEN [{'data':'AAAA2DD', 'type':'NEC', 'length':32, 'pdelay':1000}, {'data':'AAAA2DD', 'type':'NEC', 'length':32, 'pdelay':1000}, {'data':'AAAA4BB', 'type':'NEC', 'length':32, 'pdelay':1000}, {'data':'AAAA4BB', 'type':'NEC', 'length':32, 'pdelay':1000}, {"data":"AAAA5AA", "type":"NEC", "length":32, 'pdelay':1000....

Nachtrag: wenn ich z.B. die DOIF (bzw. Auslösebedingung) von aussen ansprechen möchte, wie erfolgt dies (per URL)? Ich möchte nicht jedem im Haus 'zumuten' sich durch FHEM durchzuhangeln und würde einen einfachen z.B. php/js Aufruf bereitstellen (oder abgespeckte FHEM Gui bereitstellen).

[Pfriemler]

Ja, wenn Du in IR_Kitchen mehrere Einzelcodes sendest, ist pdelay das Mittel der Wahl.
Beim DOIF kann man per set-Befehl (glaube set <doifnam> cmd_1|cmd_2|...) einen Zustandswechsel herbeiführen, ohne dass die Triggerbedingung vorliegen muss, d.h. man kann die jeweils vorgesehenen Befehle so auf Anforderung abarbeiten lassen. "set di_Command2BotKitchen cmd_1"
Ich glaube so:

Code Auswählen Erweitern

http://<fhem>:8083/fhem?cmd.dummy=set%20%di_Command2BotKitchen20cmd_1&XHR=1
Ich persönlich fände eine abgespeckete GUI deutlich komfortabler.

Aber wir schweifen hier ab - eigentlich geht es um das 84_IrBlaster.pm-Modul.

[gloob]

Gibt es eigentlich einen Plan das Modul per FHEM Update auszuliefern? Ich denke es macht es einfacher.

[charlie0815]

Hallo Leute,
ich würde auch gern das Modul einsetzen, bekomme aber das Modul beim define nicht zum laden in fhem. Beim reload 84_IrBlaster.pm steht dann folgender Fehler:

Excessively long <>operator at ./FHEM/84_IrBlaster.pm line 21.

Kann jemand mit dieser Fehlermeldung was anfangen?? Muss ich vielleicht noch was updaten (ich hab fhem auf ner jessie installation)
Vielleicht noch was: ich hab das Modul per wget als pi-user direkt ins FHEM Verzeichnis geschoben. Ist das so richtig??
Grüße charlie

[Pfriemler]

Sicher dass Du die richtige Datei dort hast?

Code Auswählen Erweitern

/opt/fhem/FHEM/84_IrBlaster.pm [s]32.587[/s] 32.667 ...

edit: ist ja tatsächlich eine geringfügig andere als meine, funktioniert aber.
Hast Du den Code binär heruntergeladen oder als Website? 

[charlie0815]

Sicher dass Du die richtige Datei dort hast?

Code Auswählen Erweitern

/opt/fhem/FHEM/84_IrBlaster.pm [s]32.587[/s] 32.667 ...

edit: ist ja tatsächlich eine geringfügig andere als meine, funktioniert aber.
Hast Du den Code binär heruntergeladen oder als Website? 

Hallo Pfriemler,
ich bin in den FHEM Ordner gewechselt und hab dort die Datei mit
wget https://github.com/viegener/Telegram-fhem/blob/master/IrBlaster/84_IrBlaster.pm
runtegezogen.
Das hatte auch geklappt und die Datei ist da zu finden. Gibts da einen anderen Weg??

[Pfriemler]

... in den FHEM Ordner gewechselt und hab dort die Datei mit wget https://github.com/viegener/Telegram-fhem/blob/master/IrBlaster/84_IrBlaster.pm runtegezogen.
Das hatte auch geklappt und die Datei ist da zu finden.

Stimmt, aber das zieht - wie ich vermutete - seltsamerweise eine HTML-Datei mit 333k herunter, habe ich gerade probiert. Die funktioniert dann natürlich nicht.
Bisher löste ich das so (als Linux-Noob): Seite im Browser laden, auf "RAW" wechseln (kleiner Button oberhalb des Anzeigefensters) und dann die Datei mit Rechtsklick und "Speichern unter" am PC speichern und per FTP übertragen. Ohne "RAW" wird es die gleiche Datei, die Du per wget gezogen hast.

edit: (handvordenkopfschlagend) - RAW wechselt zu einem anderen Link, der dann mit wget direkt funktioniert (gerade zur Reparatur erfolgreich durchgeführt):

Code Auswählen Erweitern

wget https://raw.githubusercontent.com/viegener/Telegram-fhem/master/IrBlaster/84_IrBlaster.pm
vorher aber die alte löschen, sonst wirds eine /84_IrBlaster.pm.1
Sonst Ausgabedatei einfach angeben, überschreibt dann direkt:

Code Auswählen Erweitern

wget https://raw.githubusercontent.com/viegener/Telegram-fhem/master/IrBlaster/84_IrBlaster.pm -O ./84_IrBlaster.pm

[rabehd]

Ich habe mich heute mal hier eingelesen und das Modul installiert.
Jetzt ist der Schwibbogen ("alte" IR-Kerzen) in meinem Weihnachts-DOIF drin.

Danke allen die an der Entwicklung beteiligt waren, incl. der Hart- und Firmware.

[charlie0815]

Stimmt, aber das zieht - wie ich vermutete - seltsamerweise eine HTML-Datei mit 333k herunter, habe ich gerade probiert. Die funktioniert dann natürlich nicht.
Bisher löste ich das so (als Linux-Noob): Seite im Browser laden, auf "RAW" wechseln (kleiner Button oberhalb des Anzeigefensters) und dann die Datei mit Rechtsklick und "Speichern unter" am PC speichern und per FTP übertragen. Ohne "RAW" wird es die gleiche Datei, die Du per wget gezogen hast.

edit: (handvordenkopfschlagend) - RAW wechselt zu einem anderen Link, der dann mit wget direkt funktioniert (gerade zur Reparatur erfolgreich durchgeführt):

Code Auswählen Erweitern

wget https://raw.githubusercontent.com/viegener/Telegram-fhem/master/IrBlaster/84_IrBlaster.pm
vorher aber die alte löschen, sonst wirds eine /84_IrBlaster.pm.1
Sonst Ausgabedatei einfach angeben, überschreibt dann direkt:

Code Auswählen Erweitern

wget https://raw.githubusercontent.com/viegener/Telegram-fhem/master/IrBlaster/84_IrBlaster.pm -O ./84_IrBlaster.pm

...Tausend Dank Pfriemler, das wars auch, es ging jetzt ohne Probleme...jetzt kann ich mich auch der Weihnachtsbaumbeleuchtung widmen
Schönen Abend noch

[RaspiLED]

...Tausend Dank Pfriemler, das wars auch, es ging jetzt ohne Probleme...jetzt kann ich mich auch der Weihnachtsbaumbeleuchtung widmen
Schönen Abend noch

Moin,
Aber denkt dran ein

Code Auswählen Erweitern


sudo chown fhem:dialout 84_IrBlaster.pm

oder

Code Auswählen Erweitern


sudo chown fhem:dialout *

auszuführen, damit die Datei auch FHEM gehört und evtl. Später durch ein fhem update verändert werden kann.
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[Benni]

Hallo,

ich wollte mich nur schnell für das Modul bedanken!

Ich habe es seit heute mit dem IRBlaster und meinen Billig-LED-Teelichtern aus China im Einsatz.
Einrichtung war einfach und läuft wie geschmiert! 

Danke!

gb#

[mi.ke]

Hab jetzt auch das Modul installiert.

Vielen Dank dafür

Grüße

mi.ke

[wagenkna]

Hallo allerseits,

ich habe zwei Module seit Weihnachten im Einsatz. Das empfangen und senden klappt soweit und die Geräte sind angelernt. Ich möchte über ein DOIF mit einer Fernbedienung 3 Infrarotempfänger ansteuern. (Dreambox, Beamer, Leinwand)
Leider bekomme ich das DOIF nicht zum laufen. Bei der Recherche fiel mir folgender Hinweis auf.

"Auf die Änderungen von CR0x_JSON_... kann dann entsprechend reagiert werden. Die Funktion ist aber derzeit noch nicht wirklich stabil und vor allem für eine zeitnahe Auswertung von empfangenen Codes zu langsam, zudem ist der Code-Interpreter im ESP8266 nicht sehr sicher und liefert viele Fake-Codes. Dessen Funktion ist eigentlich auch nur zur einmaligen Ermittlung von IR-Codes vorhandener Fernbedienungen gedacht. "

Ist das vielleicht irgendwann mal angedacht, gibt es hierfür eine Lösung?? Es wäre schon eine schöne smarte Lösung per Infrarot doif auslösen zu können.

Besten Dank, auch für das Modul

Grüße

Axel

[Pfriemler]

Ein funktionierendes DOIF zu bauen ist kein Problem. Ich nutze z.B. sowas:

Code Auswählen Erweitern

define di_IR_Blaster_Wz_Received_Commands DOIF ([KVP_IR_Blaster_Wz:CR01_Json_Local_IP] =~ "'data':'FF20DF', 'type':'NEC") (set set IRWz send KerzenAUS)

Das eigentliche Problem liegt in der Firmware des Blasters: Er erkennt zuviel was nicht da ist. Das lässt sich auch aus FHEM nicht wirklich abfangen.


Tipp:
Um auch im WebIF ein freundlicher lesbares Ergebnis zu bekommen, habe ich mir ein userReading gebaut:

Code Auswählen Erweitern

attr KVP_IR_Blaster_Wz userReadings lastCode {\
my $v = "-";;\
if (ReadingsVal($name,'CR01_Json_Local_IP','0')  =~ /data':'(.+?)'/) {$v = $1};;\
if (ReadingsVal($name,'CR01_Json_Local_IP','0')  =~ /type':'(.+?)'/) {$v = $1."-".$v};;\
$v\
}
Das wird dann mit

Code Auswählen Erweitern

attr KVP_IR_Blaster_Wz stateFormat [$name:lastCode] ([$name:lastCode:t])
im Webfrontend angezeigt - Data, Type und den Zeitstempel. So kannst Du schon mal besser beobachten was da reinschippert...

[wagenkna]

Hallo Pfriemler,

Danke für den Hinweis, ich probiere es die Tage mal aus und gebe nocheinmal Bescheid.

winterliche Grüße

Axel

[CatWeazle]

Hallo viegener,

ich finde das Modul 84_IrBlaster ist schon mal recht praktisch.

Neue Befehle anlegen per Copy & Paste aus dem Terminal heraus ist eigentlich okay, aber bitte, das kannst du besser!

Ich nutze immer noch MiniIrCUL, der wirklich gut ist, einziger Nachteil, wenn man überhaupt von einem Nachteil reden kann, er besteht aus einem ESP und einem AVR.
Aber darin sehe ich kein echtes Problem. Als alter Bastler (habe schon mit Germanium Transistoren gebastelt) schuster ich mir meine Klamotten eh gerne auf Lochraster zusammen.

Ja aber ein echtes Highlight des alten MiniIrCul .... ist ... " set myir irLearnForSec "   

Also das ist mein Osterwunsch: " set IrBlaster irLearnForSec "   


Bis Ostern bekommst du das sicher hin ... hope so

[Pfriemler]

Wieso Terminal? Ich habe da so ein KVP-Device definiert, da sehe ich die letzten Codes vom Blaster direkt in FHEM. Gut, umkopieren muss man sie dann auch einmal ...

Wenn wir schon bei einer Wunschliste sind: Viel besser fände ich, eine Art externe Datenbank einzurichten. Ich nutze künftig 3 Blaster und mit etwas search&replace und Raw definition kriegt man schon kopiert, aber trotzdem - eine Datenbank wäre besser...

[RaspiLED]

Hi,
ja genau entweder die lirc (was: Kirche) Definitionen anzapfen oder Die Logitech Harmony DB anzapfen
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[Pfriemler]

Ein Hoch auf die Autokorrektur. ...   

[RaspiLED]

Naja lirc -> Kirche ist schon schön Aber dafür gibt es ja die Beichte zur Autokorrektur!

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[Pfriemler]

Amen, Bruder, Amen. Leider weiß jetzt keiner mehr warum Du die Kirche anzapfen wolltest...

[vbs]

Hallo zusammen, von mir auch vielen Dank für das Modul und nachträglich frohes Fest & frohes Neues

An einem Problem hänge ich gerade:
Da mein LG TV keine eigenen IR-Kommandos kennt, um z.B. den Bildmodus umzuschalten, muss ich recht komplexe IR-Abläuft ausführen und mich durch die Bildschirm-Oberfläche hangeln (z.B. Menü, 3x hoch, OK, 2x links, OK, OK...). Zwischen bestimmten IR-Kommandos, muss man sleeps einbauen, um dem TV Zeit zu geben, auf die neue GUI-Seite zu wechseln. Eigentlich klappt das auch ganz gut.

Aber:
Das Modul schickt ja bei jedem Befehl einen HTTP-Request an den Blaster. Manchmal (ganz grob 1 Mal bei 50 Befehlen), gibt es irgendwo einen Hänger und der HTTP-Request kommt erst nach einer Sekunde zurück. Evtl. weitere IR-Kommandos, die man in der Zeit absetzen wollte, werden ja im Modul gequeuet. Wenn dann der hängende Befehl ausgeführt wurde, dann werden alle weiteren (die Gequeueten) nacheinander ohne Pause rausgefeuert (weil die verwendeten fhem-sleeps nicht mehr wie geplanten greifen). Das ist dann in meinem Fall ein Problem.

Beispiel für eine Befehlsfolge:

Code Auswählen Erweitern

set wz_irblaster _send IR_LG_TV_Input;sleep 1;set wz_irblaster _send IR_LG_TV_Up;sleep 1;set wz_irblaster _send IR_LG_TV_OK;sleep 3.0;set wz_irblaster _send IR_LG_TV_Right;set wz_irblaster _send IR_LG_TV_Right;set wz_irblaster _send IR_LG_TV_OK;set wz_irblaster _send IR_LG_TV_ProgUp;set wz_irblaster _send IR_LG_TV_ProgUp;set wz_irblaster _send IR_LG_TV_ProgUp;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_Down;set wz_irblaster _send IR_LG_TV_OK;sleep 1;set wz_irblaster _send IR_LG_TV_Exit

Frage:
Gibt es eine Chance, eine solche Pause in eine Befehlskette einzuqueuen, die auch eingehalten wird, wenn es mal einen Hänger gab. Wenn nicht: haltet ihr es für sinnvoll, sowas einzubauen (könnte ich probieren).
Oder gibt es andere/bessere Ansätze für eine solche Problematik?

[CarstenF]

Moin Moin,
Ich wollte mir mal eine Backup Instanz für meine Rollosteuerung schaffen und komm gerade nicht weiter. Bislang nutze ich lediglich die 360° IR Gateways in SW - Version 1.41 oder sowas ähnliches und verbinde das ganze mit DOIFS/GetHttpFile. Das läuft auch schon lange sehr zufriedenstellend.
Als Software a.d. Gateway  hab ich nun mal die V 2.5 aufgespielt. Das Modul habe ich in Fhem eingebunden. Modul und Gateway sprechen auch miteinander.
Jetzt versuche ich gerade meine "bekannten" Rollo-Befehle dem Modul beizubringen. Ich erhalte bei Aufruf aus FHEM (set send) jedoch immer einen http-Error 401.

Wenn ich die "gehörten" Befehle vom Gateway aus der Weboberfläche der Gateway Software heraus kopiere und im Browser einsetze, wird der Befehl vom Gateway korrekt umgesetzt und gesendet.

Ich glaube jede erdenkliche Version schon durchprobiert zu haben, deshalb meine Frage, wo mein Fehler liegen könnte.
Hier mal ein List meines Device

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.1.195 IR_ acbdef
   FUUID      60125dc4-f33f-d709-67f1-c5ba61fbde564b1b
   HOST       192.168.1.195
   INTERVAL   60
   NAME       irblaster
   NR         10658
   PASS       acbdef
   PREFIX     IR_
   STATE      present
   TIMEOUT    300
   TYPE       IrBlaster
   VERSION    0.0.5
   doStatus   
   lastresponse HTTP-Error returned: 401
   HU_SR_PARAMS:
     NAME       
     action     /json?plain=[{'data':[3800,550, 3750,550, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3700, 550,3750, 600,3700, 600,3700, 600,3700, 550,3750, 600], 'type':'raw', 'khz':38}]
     addr       http://192.168.1.195:80
     auth       0
     buf       
     compress   1
     conn       
     displayurl http://192.168.1.195:80/json?plain=%5b%7b%27data%27%3a%5b3800%2c550%2c%203750%2c550%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3700%2c%20550%2c3750%2c%20600%2c3700%2c%20600%2c3700%2c%20600%2c3700%2c%20550%2c3750%2c%20600%5d%2c%20%27type%27%3a%27raw%27%2c%20%27khz%27%3a38%7d%5d&pass=acbdef
     header     
     host       192.168.1.195
     httpheader HTTP/1.1 401 Unauthorized
Content-Type: text/html
Content-Length: 16
Connection: close
Access-Control-Allow-Origin: *
     hu_blocking 0
     hu_filecount 1
     hu_port    80
     hu_portSfx
     loglevel   4
     method     GET
     path       /json?plain=%5b%7b%27data%27%3a%5b3800%2c550%2c%203750%2c550%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3700%2c%20550%2c3750%2c%20600%2c3700%2c%20600%2c3700%2c%20600%2c3700%2c%20550%2c3750%2c%20600%5d%2c%20%27type%27%3a%27raw%27%2c%20%27khz%27%3a38%7d%5d&pass=acbdef
     protocol   http
     redirects  0
     timeout    30
     url        http://192.168.1.195:80/json?plain=%5b%7b%27data%27%3a%5b3800%2c550%2c%203750%2c550%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3750%2c%20600%2c3700%2c%20550%2c3750%2c%20600%2c3700%2c%20600%2c3700%2c%20600%2c3700%2c%20550%2c3750%2c%20600%5d%2c%20%27type%27%3a%27raw%27%2c%20%27khz%27%3a38%7d%5d&pass=acbdef
     SR_READINGS:
     args:
       [{'data':[3800,550, 3750,550, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3700, 550,3750, 600,3700, 600,3700, 600,3700, 550,3750, 600], 'type':'raw', 'khz':38}]
       1611822545.11847
       undef
       1
     hash:
     sslargs:
   READINGS:
     2021-01-28 09:38:28   presence        present
     2021-01-28 09:29:05   requestAction   /json?plain=[{'data':[3800,550, 3750,550, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3700, 550,3750, 600,3700, 600,3700, 600,3700, 550,3750, 600], 'type':'raw', 'khz':38}]
     2021-01-28 09:29:05   requestResult   HTTP-Error returned: 401
     2021-01-28 09:38:28   state           present
   actionQueue:
   helper:
Attributes:
   IR_R_AZ_Code [{'data':[3800,550, 3750,550, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3750, 600,3700, 550,3750, 600,3700, 600,3700, 600,3700, 550,3750, 600], 'type':'raw', 'khz':38}]
   IR_R_AZ_HOCH [{'data'[3850,500,3850,500,650,3650,650,3650,650,3650,650,3650,650,3650,650,3700,650,3650,650,3650,650,3650,650,3650,3850,500,3850,500,3800,500,3850,500,650,3650,650], 'type':'raw', 'khz':38}]
   interval   60
   room       System
   userattr   IR_.* IR_IR_R_AZ_HOCH IR_R_AZ_Code IR_R_AZ_HOCH
   widgetOverride IR_R_AZ_Code:textField-long

Gruß Carsten

[Pfriemler]

a) ich bin nicht sicher, ob Leerzeichen (noch) ein Problem in den RAW-Datenblöcken sind
b) im IR_R_AZ_HOCH fehlt hinter 'data' ein :

[CarstenF]

a) ich bin nicht sicher, ob Leerzeichen (noch) ein Problem in den RAW-Datenblöcken sind
b) im IR_R_AZ_HOCH fehlt hinter 'data' ein :

Danke für Deine Antwort.
a) Das mit den Leerzeichen hatte ich nur mal als eine mögliche Variante probiert, weil es so im "Help" des Moduls steht. Auch ohne Leerzeichen gehts nicht.
b) mit IR_R_AZ_HOCH probiere ich gar nicht rum, solange das  erste attr  nicht funktioniert, das hatte ich nur schon mal so eingefügt.
Trotzdem erstmal Danke.

[Pfriemler]

Also Dein Code passt schon mal, bei mir tut er.

Unauthorized ist eine andere Baustelle.
Wenn ich in meinem IR-Blaster ein password setze, gibt es eine Fehlermeldung, bis ich es auch im FHEM eintrage.

Sicher, dass Dein password acbdef keinen Dreher beinhaltet?

P.S.: Umgekehrt ist auch so: wenn im Blaster kein Password hinterlegt ist und man definiert in FHEM eines, gibt es auch einen 401.

[CarstenF]

Also Dein Code passt schon mal, bei mir tut er.

Unauthorized ist eine andere Baustelle.
Wenn ich in meinem IR-Blaster ein password setze, gibt es eine Fehlermeldung, bis ich es auch im FHEM eintrage.

Sicher, dass Dein password acbdef keinen Dreher beinhaltet?

P.S.: Umgekehrt ist auch so: wenn im Blaster kein Password hinterlegt ist und man definiert in FHEM eines, gibt es auch einen 401.

Oha..... habe dieses abcdef völlig falsch interpretiert. *Schäm*. Da kann ich ja dann lange in die falsche Richtung suchen. Danke Dir für den Hinweis. Jetzt läufts.....
Gruß Carsten

[paulbaumann]

Also ich sterbe an gleicher Stelle.
HTTP-Error returned: 401
Aber ich habe nirgends ein Passwort, habe ich einen Denkfehler??
Also bei mir steht somit:
DEF 192.168.178.39 IR_
und sonst nix da das Passwort doch optional ist, Jemand eine Idee?

[Pfriemler]

Die DEF müsste so tun, wenn im Blaster selbst kein Passwort hinterlegt ist.

[CarstenF]

Also ich sterbe an gleicher Stelle.
HTTP-Error returned: 401
Aber ich habe nirgends ein Passwort, habe ich einen Denkfehler??
Also bei mir steht somit:
DEF 192.168.178.39 IR_
und sonst nix da das Passwort doch optional ist, Jemand eine Idee?

Bei mir gehts auch mit dieser def. Vielleicht irgendwo ein Leerzeichen, welches dort nicht hingehört...

[paulbaumann]

Was kann ich schicken um Klarheit zu haben, bin so ein dau der viel falsch macht?
Hier ein kurzer Abriss:
84_IrBlaster in Verzeichnis mit Rechten/Gruppe wie andere Module befördert
IR-Blaster an Strom gesteckt, über die Weboberfläche 2 Zeilen Code abgegriffen (siehe unten Leiser und Powertaste der Fernbedienung)
Ist auch online, benannt von mir als "IRBlaster"
Herkömmlich mit DOIF und Dummy versucht, wieder gelöscht weil bekomme ich nicht gebacken (auch Schreibfehler möglich)
Nun nur zum Test alles weg außer der IRBlaster selbst und nur 3 Zeilen Code wie ich Ihn durch das Fernbedienungdrücken entnahm dann mit

Code Auswählen Erweitern


attr IRBlaster userattr IR_.* IR_LEISER IR_POWER
attr IRBlaster IR_LEISER [{'data':'D5B3F20D','type':'NEC','length':32}]
attr IRBlaster IR_POWER [{'data':'D5B350AF','type':'NEC','length':32}]

(vorher hatte ich das TV_POWER und TV_LEISER genannt, das kannte er gar nicht, hat wohl mit dem Präfix zu tun...)
nun gehe ich auf UNSORTED IRBlaster set IRBlasetr send und gebe ein IR_POWER
Ergebnis:

Code Auswählen Erweitern


presence
present
2021-02-03 18:32:44
requestAction
/json?plain=[{'data':'D5B350AF','type':'NEC','length':32}]
2021-02-03 19:49:23
requestResult
HTTP-Error returned: 401
2021-02-03 19:49:23
state
present
2021-02-03 18:32:44

Hier noch der Log-Eintrag dazu

Code Auswählen Erweitern


2021.02.03 19:49:23 3: IrBlaster_HU_Callback IRBlaster: No retry for (ret: HTTP-Error returned: 401) for send request [{'data':'D5B350AF','type':'NEC','length':32}] :

Hier noch mein IRBlaster wie definiert:

Code Auswählen Erweitern


DEF
192.168.178.39 IR_

FUUID
5ea48e8d-f33f-878f-e827-a8b890463c1eaa70
HOST
192.168.178.39
INTERVAL
0
NAME
IRBlaster
NR
15
PREFIX
IR_
STATE
present
TIMEOUT
300
TYPE
IrBlaster
VERSION
0.0.5
doStatus

lastresponse
HTTP-Error returned: 401


[Pfriemler]

Das in der DEF angegebene Präfix IR_ ist optional. Es wird vorangestellt bei Definitionen neuer Befehle. In Deinen Codeauszügen finde ich keine Fehler.

Kannst Du direkte Aufrufe in der Browserzeile erfolgreich absetzen?
also nach Deinen Angaben:

Code Auswählen Erweitern

http://192.168.178.39:80/json?plain=[{'data':'D5B350AF', 'type':'NEC', 'length':32}]

P.S.: bitte setze ein "list IRBlaster" in der Kommandozeile ab und kopiere die Zeilen aus dieser Ausgabe in Codetags, nicht direkt aus der Ansichtsseite des Devices.

edit: Nur interessehalber: NEC ABCD-0A ... was isn das für ein Gerät? Habe nichts dazu gefunden...

[paulbaumann]

Im Browser kommt da: Invalid passcode

Hier nochmals der Ausschaltknopf gedrückt "Codes Received" des IRBlasters laut Oberläche:
Details            Command             Type Length Address
22:20:09.501  FFFFFFFFFFFFFFFF NEC  0       0x0
22:20:09.346  D5B350AF            NEC  32      0xcdab
Die erste Zeile ist immer gleich, ich dachte an D5B350AF als den Code zu nehmen, oder?
Ist eine Fernbedienung einer SAT-Box LX3, um die Frage zu beantworten.
Hier das "list IRBlaster":

Code Auswählen Erweitern


Internals:
   DEF        192.168.178.39 IR_
   FUUID      5ea48e8d-f33f-878f-e827-a8b890463c1eaa70
   HOST       192.168.178.39
   INTERVAL   60
   NAME       IRBlaster
   NR         15
   PREFIX     IR_
   STATE      present
   TIMEOUT    300
   TYPE       IrBlaster
   VERSION    0.0.5
   doStatus   
   lastresponse HTTP-Error returned: 401
   HU_SR_PARAMS:
     NAME       
     action     /json?plain=[{'data':'D5B350AF','type':'NEC','length':32}]
     addr       http://192.168.178.39:80
     auth       0
     buf       
     compress   1
     conn       
     displayurl http://192.168.178.39:80/json?plain=%5b%7b%27data%27%3a%27D5B350AF%27%2c%27type%27%3a%27NEC%27%2c%27length%27%3a32%7d%5d
     header     
     host       192.168.178.39
     httpheader HTTP/1.0 401 Unauthorized
Content-Type: text/html
Content-Length: 16
Connection: close
     hu_blocking 0
     hu_filecount 1
     hu_port    80
     hu_portSfx
     loglevel   4
     method     GET
     path       /json?plain=%5b%7b%27data%27%3a%27D5B350AF%27%2c%27type%27%3a%27NEC%27%2c%27length%27%3a32%7d%5d
     protocol   http
     redirects  0
     timeout    30
     url        http://192.168.178.39:80/json?plain=%5b%7b%27data%27%3a%27D5B350AF%27%2c%27type%27%3a%27NEC%27%2c%27length%27%3a32%7d%5d
     SR_READINGS:
     args:
       [{'data':'D5B350AF','type':'NEC','length':32}]
       1612382360.06577
       undef
       1
     hash:
     sslargs:
   READINGS:
     2021-02-03 22:27:46   presence        present
     2021-02-03 20:59:20   requestAction   /json?plain=[{'data':'D5B350AF','type':'NEC','length':32}]
     2021-02-03 20:59:20   requestResult   HTTP-Error returned: 401
     2021-02-03 22:27:46   state           present
   actionQueue:
   helper:
Attributes:
   IR_LEISER  [{'data':'D5B3F20D','type':'NEC','length':32}]
   IR_POWER   [{'data':'D5B350AF','type':'NEC','length':32}]
   icon       IR
   interval   60
   maxRetries 0
   userattr   IR_.* IR_LEISER IR_POWER


[Pfriemler]

Invalid passcode? Es ist ganz sicher kein Passwort im IR-Blaster gesetzt???
Ich habe genau diese Befehlsfolge (mit für hier angepasster IP) problemlos an meinen IRBlaster gesendet mit Erfolgsrückmeldung

Code sent: /json?plain=[{'data':'D5B350AF', 'type':'NEC', 'length':32}]

Die Code-Ermittlung ist sonst korrekt. Ich hatte im Zuge letzter Ermittlungen auch regelmäßig FFFFFFFFF-Blöcke. Gerade bei NEC sind 8er-Blöcke (oder 7er oder 6er bei führenden Nullen) mit Länge 32 als sehr wahrscheinlich richtig zu betrachten.

P.S.: So sieht ein Listing richtig aus, vielen Dank, bitte weiter so!

[paulbaumann]

Oh Mann, oh Mann. Also ich habe die Lösung gefunden, wie gesagt ich bin halt doch ein DAU, habe ja gewarnt.
Das Gerät habe ich ja schon ein paar Monate und hatte es ja schon eingetippt vor einiger Zeit.
Da wir gerade drüber redeten hier bin ich in die Config des IRBlasters (v 2.7.6) reingegangen und da hatte ich vor einigen Monaten ein Passwort vermerkt.
Das jetzt hinter IR_ in die DEF reingehämmert und alles ist gut. Das Gerät funktioniert.
Na da kann ich ja morgen doch meinen Dummy schreiben und mit Alexa steuern.
Sorry aber solche Fehler sind die schlimmsten, man vergißt was man mal so eingegeben hat...

[Pfriemler]

Die DEF müsste so tun, wenn im Blaster selbst kein Passwort hinterlegt ist.

Dass im IR-Blaster und in FHEM der gleiche Passcode eingegeben werden müssen, war ja von Anfang an mein Reden...
Also: "Wer hat's gefunden?" 

[paulbaumann]

Klar der Hero Member hat's gefunden

[vbs]

Ganz vergessen: ich hatte letztes Jahr mal in das Modul Support für ein sleep-Kommando eingebaut, so dass man eine Pause zwischen Befehlen einbauen kann.
So:

Code Auswählen Erweitern

set wz_irblaster send IR_YAM_AVR_Menu @sleep:0.4 IR_YAM_AVR_Menu

Commit:
https://github.com/verybadsoldier/Telegram-fhem/commit/b9cc86296c5f0bcab93d0e55b20b42332d6de2df

Hat da jemand Intresse dran? Dann würde ich einen PR auf Github machen.

[Pfriemler]

Mich deucht, das war mal Thema irgendwo. Konkret ging es darum, einen Mindestabstand zwischen zwei Befehlen sicherzustellen, Probleme gab es, wenn aus irgendeinem Grund der erste Befehl verzögert gesendet wird und der zweite dann zu früh kommt, wenn man es bspw. aus FHEM verzögert. Eine kombinierte Übermittlung zweier (unterschiedlicher) Befehle mit definierter Verzögerung und deren Abarbeitung in der Hardware selbst (also im Sketch) wäre vermutlich sicherer. Wenn das Supportmodul in FHEM die Verzögerung für den zweiten Befehl erst startet, wenn der Blaster die Ausführung des ersten quittiert hat, wäre das aber schon ein guter Workaround.

[vbs]

Konkret ging es darum, einen Mindestabstand zwischen zwei Befehlen sicherzustellen, Probleme gab es, wenn aus irgendeinem Grund der erste Befehl verzögert gesendet wird und der zweite dann zu früh kommt, wenn man es bspw. aus FHEM verzögert.

Hm, kann das wirklich passieren? Die Kommunikation zum IR-Blaster läuft doch über ein normales HTTP-Get, oder? Das FHEM-Modul schickt ja erst den nächsten Befehl (EDIT: bzw. startet das sleep), wenn das HTTP-Get inkl. Response des vorherigen Befehls abgeschlossen ist. Also vorausgesetzt, dass der Blaster den HTTP-Request erst beantwortet, wenn er die IR-Sequenz auch wirklich gesendet hat, besteht doch kein Problem?
Bei normaler Nutzung von HTTP seh ich sonst erstmal keine Chance für FHEM eine Quittung zu bekommen.