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

Begonnen von viegener, 05 Dezember 2017, 00:06:48

Vorheriges Thema - Nächstes Thema

Pfriemler

#45
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

CarstenF

Zitat von: Pfriemler am 28 Januar 2021, 14:42:33
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
Raspberry Pi4
CUL 868, CUL 433, LaCrosse Gateway, Zigbeetomqtt2, HUE, Homematic
Max-Cube umgeflasht
MAX!, FhemtoFhem, Homebridge, FhemConnector, IR_Gateway und sonst auch noch allerlei Spielzeug....

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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

CarstenF

Zitat von: paulbaumann am 03 Februar 2021, 18:56:07
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...
Raspberry Pi4
CUL 868, CUL 433, LaCrosse Gateway, Zigbeetomqtt2, HUE, Homematic
Max-Cube umgeflasht
MAX!, FhemtoFhem, Homebridge, FhemConnector, IR_Gateway und sonst auch noch allerlei Spielzeug....

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

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:

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

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:

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

#51
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:
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...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

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":

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
ZitatCode 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!
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

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

Zitat von: Pfriemler am 03 Februar 2021, 19:55:53
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?"  ;D
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

paulbaumann


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:
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

vbs

Zitat von: Pfriemler am 01 Februar 2022, 22:28:35
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.