Adapter: broadlink2

[Neuschwansteini]

@MathiasJ
Um dir richtige Tipps geben zu können, müssen wir wissen, auf welchem System dein iobroker läuft, Windows, Linux, Docker, als Container, VM oder was auch immer?
Dann welche Version von js-controller, node, nodejs und npm du verwendest.

Mit diesen Angaben kann man schonmal mehr sagen...

Update: das mit dem Ändern des Configfiles war nach dem Umstieg von js-controller 1.5.x nach 2.x, ist aber seit dem Update von Broadlink 2.0.1 gefixt. Jetzt V2.1 einfach installieren.
Bei updates oder sonstigen Versuchen immer Backup von den Einstellungen und den Objekten machen, damit die angelernten Befehle nicht weg sind.

[MathiasJ]

@ilovegym
Hat sich eh erst mal erledigt.
Ich habe den Adapter deinstalliert und neu installiert.
Jetzt müssen die Geräte sowieso neu angelernt werden. Laut Log keine Verbindung, warum auch immer.
ich verwende überall die letzte Version. ich gucke jeden Tag nach, ob was upzudaten ist.
Im Moment läuft IObroker auf dem Raspberry PI4B.
Das wird sich aber ändern. Ich schätze in 2 bis 3 Monaten dann unter Proxmox.........
Gruß,
Mathias

[Knallochse]

Mit der neuen Version 2.1.0 habe ich das Phänomen , dass der Broadlink die RF-Codes 3mal hintereinander sendet. Kann man das irgendwo ändern?

[Christoph1337]

@frankjoke
Moin moin,
ich hätte eine Frage. Ich habe einen Ventilator via IR über den broadlink verfügbar gemacht. Zum ein und ausschalten gibt es nur ein Steuersignal. Diesen DP habe ich via IOT in Alexa verfügbar gemacht. Nun habe ich folgendes Problem mit dem "Tantchen". Die Garstige Dame kann anscheinend nur "Einschalten" an den Ventilator senden. Wenn ich "Ausschalten" steuere antwortet Sie nur mit "Das Gerät reagiert nicht".

Muss in dem DP möglicherweise irgendwas eingetragen werden damit das geht?

Beste Grüße

[deta]

@Christoph1337 sagte in Adapter: broadlink2:

@frankjoke
Moin moin,
ich hätte eine Frage. Ich habe einen Ventilator via IR über den broadlink verfügbar gemacht. Zum ein und ausschalten gibt es nur ein Steuersignal. Diesen DP habe ich via IOT in Alexa verfügbar gemacht. Nun habe ich folgendes Problem mit dem "Tantchen". Die Garstige Dame kann anscheinend nur "Einschalten" an den Ventilator senden. Wenn ich "Ausschalten" steuere antwortet Sie nur mit "Das Gerät reagiert nicht".

Muss in dem DP möglicherweise irgendwas eingetragen werden damit das geht?

Beste Grüße

hast du den als Schalter in iot definiert?

[Christoph1337]

@deta so. Passt das?

[deta]

@Christoph1337 Wie ist er in der Alexaapp erkannt worden? Als Schalter? Kannst du über die App ein und ausschalten?
Geht es wenn du in den Obekten, mal das Manuell versuchen tust in Broadlink2 ?

[P-A-L-A-D-I-N]

@frankjoke
Bei mir ist das Szenario gar nicht mal so unähnlich - angefangen von den verschiedenen Systemkomponenten unterschiedlichster Hersteller bis hin zur Frau, die keine Lust auf "Technik-Kram" hat und erwartet, daß die Lichter (am besten per Schalter) einfach funktionieren!
Allerdings sieht bei mir die Realität leider so aus, daß mein(e) ioBroker Installation(en) schon seit Ewigkeiten nichts als Ärger machen und ich nur noch dauergefrustet von dem ganzen Schrott bin. Ich wünschte, ich wäre damals nicht auf den ioBroker gestoßen (aber "früher war eben noch alles besser"!), sondern hätte von Anfang an auf eine andere Lösung gesetzt, z.B. FHEM. Mir ist das alles definitiv viel zu viel "Gebastel" - dauernd fällt irgendetwas aus, funktioniert nicht zuverlässig, zerschießt gleich den ganzen ioBroker etc. pp. Da nutzt mir dann auch der recht einfache Einstieg und die angenehme Oberfläche nichts. In den Wochen (sic!), die ich schon für ioBroker aufgewendet habe, hätte ich wohl genauso gut ein weniger intuitives FHEM-System einrichten können...
Ich werde jetzt heute endlich den Schritt gehen, den ich schon sehr, sehr lange vor mir herschiebe: Ich schaue nach einer Alternative zum ioBroker, die dann hoffentlich besser läuft, mir weiger graue Haare und verlorene Zeit beschert und hoffentlich trotzdem auch alle Geräte unterstützt, die ich nutze. Und sollte es diese "eierlegende Wollmilchsau" da draußen nicht geben, fliegt der ganze ioBroker-Mist wohl trotzdem vom Rechner und es kommt zur Not eben ein Xiaomi-Hub für mein Zigbee-Geraffel und die Broadlinks mit den RF- und IR-Geräten dahinter werden dann nur noch per App bzw. mit Alexa-Unterstützung gesteuert.
Zu guter Letzt ein großes Dankeschön für Deine Arbeit! Würde der ioBroker selbst und auch die anderen Adapter so "sauber" laufen wie Dein Adapter, würde ich jetzt nicht "fremdgehen" müssen!

[joergeli]

@frankjoke
Hi, ich nutze Deinen Adapter schon ca. 1/2 Jahr mit meinem Broadlink RM pro+.
Bis auf die Tatsache, daß der Broadlink im Adapter ein Mal umbenannt wurde, hat er problemlos funktioniert.
Die ungewollte Umbenennung nach broadlink2.0.RM:RMPRO-MOVE315-55-3a-50 konnte ich durch editieren der enstpr. JSON fixen, bzw. korrigieren, ohne sämtliche Befehle neu anlernen zu müssen.
So weit, so gut.

Mit dem Update auf Broadlink 2.1.0 habe ich jetzt allerdings Probleme:
1.) Ich bekomme jetzt ständig Warnings:

broadlink2.0	2020-06-22 14:05:29.089	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!
broadlink2.0	2020-06-22 14:05:29.042	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!
broadlink2.0	2020-06-22 14:05:26.667	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!
broadlink2.0	2020-06-22 14:05:26.618	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!

Ich nutze ein JavaScript, um verschiedene Broadlink-Befehle nacheinander abzusetzen (IR für TV und 433 MHz für Schaltsteckdosen). Ich hatte in das JS auch mal testweise mehrere setTimeout(function() eingebaut, in der Annahme, daß die Befehlsaussendung zu schnell hintereinander erfolgt. Aber auch mit Wartezeiten von ca. 5 Sekunden nach jedem Befehl kommen immer noch die "still waiting for previous command".

2.) Auch das hier schon angesprochene Problem, daß der Key expired ist, tritt ab und zu jetzt bei mir auf.
Da hilft dann nur ein Neustart des Adapters

Wohlgemerkt: Der Broadlink RM pro+ ist immer noch der Gleiche und diese Probleme hatte ich mit der älteren Adapterversion nicht.

Falls es hilft, hier meine Konfiguration:
ioBroker auf Raspi 4 (4GByte) mit Raspbian Buster light
/usr/bin/nodejs
v12.16.3
/usr/bin/node
v12.16.3
/usr/bin/npm
6.14.4

Gruß
Jörg

[frankjoke]

@Knallochse sagte in Adapter: broadlink2:

Mit der neuen Version 2.1.0 habe ich das Phänomen , dass der Broadlink die RF-Codes 3mal hintereinander sendet. Kann man das irgendwo ändern?

Das sollte nicht der Fall sein, der Adapter versucht aber nochmals zu senden wenn ein Fehler beim Senden aufgetreten ist.

Kannst mal auf debug schalten und was senden und schauen/zeigen was im log steht?

[Christoph1337]

@deta Auch über die app kann ich nur auf "AN" drücken. Da das signal ein toggle ist, kann ich damit natürlich auch den Ventilator ausschalten. Von dem Befehl her ist es nur irgendwie doof

[deta]

@Christoph1337 sagte in Adapter: broadlink2:

@deta Auch über die app kann ich nur auf "AN" drücken. Da das signal ein toggle ist, kann ich damit natürlich auch den Ventilator ausschalten. Von dem Befehl her ist es nur irgendwie doof

Kannst du den über die Objektdaten Manuell mal schalten. Geht es dann an und aus? Das muss auf jedenfall gehen.

DU kannst mal in iot das auf Switch stellen. Löschen in der Amazon App und neu suchen lassen.

[frankjoke]

@Christoph1337
@deta

Wenn geräte nur eine Toggle-Funktion haben ihr aber einen state haben wollt der true/false ist dann gibt's da eine Möglichkeit.
Angenommen du hast Ventilator_EinAus als für den ToogleState angelkern, nun kannst du in der Konfig unter States folgendes anlegen:
Name Ventilator
Ein-Signal: Ventilator_EinAus
Aus-Signal: Ventilator_EinAus

Damit erzeugst du dann einen State mit Namen States.Ventilator in dem RM den du dann der Alexa als switch angeben kannst, allerdings ist nicht sicher ob er ein ist wenn du ein sagst, wenn das falsch herum ist dann halt einmal mehr sagen...

[frankjoke]

@alle
Habe gerade auf git ein update für 2.1.0 gestellt.
Der Grund ist dass ich bei den states leider Fehler eingebaut hatte da die neuen handler mehr Fehler erkennen und der alte code diese Fehler nicht behandeln konnte.

Bitte updaten, speziell wenn ihr sendTo, States oder Scenes verwendet, ich versuche noch alles zu testen was mir hier so wie von @joergeli gemeldet wird.

[Christoph1337]

@frankjoke Danke für die Flotte Reaktion. Kannst du mir das aber nochmal erklären? Ich bin glaube ich noch auf dem falschen Dampfer^^

[frankjoke]

@joergeli

Der neue Adapter erkennt und meldet mehr Probleme die beim alten Adapter oft unter den Tisch gekehrt wurden.

Dein Beispiel

broadlink2.0	2020-06-22 14:05:29.089	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!
broadlink2.0	2020-06-22 14:05:29.042	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!
broadlink2.0	2020-06-22 14:05:26.667	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!
broadlink2.0	2020-06-22 14:05:26.618	warn	(19190) RMP, RM:RMPRO-MOVE315-55-3a-50, 34:ea:34:55:3a:50, 192.168.192.175 still waiting for previous command [object Object]!

zeigt dass mindestens zwei, wenn nicht sogar 3, Befehle gleichzeitig gesendet wurden. Der erste Befehl hat keinen Fehler erzeugt und war aber noch nicht fertig.
EIn neuer Befehl wird um 14:05:29.042 gestartet und da läuft der alte noch.
Um 14:05:29.089 wird noch einer gestartet der auch gemeldet wird.
Um 14:05:26 war es ungefähr auch so.

Der genannte Fehler tritt auf wenn der Adapter einen Befehl an das Gerät sendet und die Antwort vom Gerät erwartet. Das Timeout ist eine Sekunde und normalerweise antwortet das Gerät in 50-200 ms, wenn das Gerät aber nicht bestätigt hat und schon wieder ein neuer Befehl gesendet wird dann kommt der Fehler wobei er bis zu 4 mal angezeigt werden kann da er dazwischen 200ms wartet und dann nochmal versucht.

Bei dir ist die Zeit zwischen den Fehlern aber nur 40-50ms und deshalb ist es ein neuer Befehl der das Verursacht. Die neuen Befehle werden jedoch binnen der nächsten ca 200ms ausgeführt da sie keine weitern Einträge verursachen.

Dein 2. Problem mit dem expired key wird von dem Adapter so behandlelt dass er ein reAuth bei nächster Gelegenheit macht. Ich habe keine Ahnung warum das bei alten RM's überhaupt auftritt aber es scheint so zu sein.

Der alte Adapter hat die Fehler nicht unterschieden und angezeigt, hat nur 3x probiert wenn's einen Fehler gab und hat dann stillschweigend aufgegeben.

[Knallochse]

@frankjoke sagte in Adapter: broadlink2:

@Knallochse sagte in Adapter: broadlink2:

Mit der neuen Version 2.1.0 habe ich das Phänomen , dass der Broadlink die RF-Codes 3mal hintereinander sendet. Kann man das irgendwo ändern?

Das sollte nicht der Fall sein, der Adapter versucht aber nochmals zu senden wenn ein Fehler beim Senden aufgetreten ist.

Kannst mal auf debug schalten und was senden und schauen/zeigen was im log steht?

Hier mal das Debug-Log

broadlink2.0	2020-06-22 20:58:56.894	info	(10707) debug: sendPacket error: command 0x6a/0x2 error after 3 trials!: null for RMP, RM:RMPROPLUS-4a-2e-b8, 34:ea:34:4a:2e:b8, 192.168.178.87
broadlink2.0	2020-06-22 20:58:53.768	info	(10707) debug: Change broadlink2.0.RM:RMPROPLUS-4a-2e-b8.L.Doppelrollo-Kueche-Hof-Fav to { val: true, ack: false, ts: 1592852333764, q: 0, from: 'system.adapter.admin.0', user: 'system.user.admin', l
broadlink2.0	2020-06-22 20:58:32.919	info	(10707) found macs: 34:ea:34:4a:2e:b8
broadlink2.0	2020-06-22 20:58:32.919	info	(10707) 1 were not found: RM:RMPROPLUS-4a-2e-b8
broadlink2.0	2020-06-22 20:58:32.918	info	(10707) broadlink2.0 started and found 1 devices named RM:RMPROPLUS-4a-2e-b8
broadlink2.0	2020-06-22 20:58:32.917	info	(10707) Poll every 30 secods.
broadlink2.0	2020-06-22 20:58:32.917	info	(10707) debug: created State broadlink2.0._SendScene
broadlink2.0	2020-06-22 20:58:32.866	info	(10707) debug: created State broadlink2.0.RM:RMPROPLUS-4a-2e-b8._LearnRF
broadlink2.0	2020-06-22 20:58:32.849	info	(10707) debug: created State broadlink2.0.RM:RMPROPLUS-4a-2e-b8._SendCode
broadlink2.0	2020-06-22 20:58:32.839	info	(10707) debug: created State broadlink2.0.RM:RMPROPLUS-4a-2e-b8._Learn
broadlink2.0	2020-06-22 20:58:32.829	info	(10707) debug: created State broadlink2.0.RM:RMPROPLUS-4a-2e-b8
broadlink2.0	2020-06-22 20:58:32.821	info	(10707) debug: created State broadlink2.0.RM:RMPROPLUS-4a-2e-b8.Temperature
broadlink2.0	2020-06-22 20:58:32.812	info	(10707) debug: Device RM:RMPROPLUS-4a-2e-b8 returned { here: true, temperature: 0 }
broadlink2.0	2020-06-22 20:58:32.674	info	(10707) Did not find { host:{ address: '192.168.178.87',family: 'IPv4',port: 80,size: 128,devtype: 10141,type: 'rm',name: 'RM:RMPROPLUS-4a-2e-b8',devname: 'RM3 Pro Plus',mac: '9d:27:57:b2:a8:c0' } }
broadlink2.0	2020-06-22 20:58:32.672	info	(10707) debug: broadlink2 has 78 old states!
broadlink2.0	2020-06-22 20:58:32.671	info	(10707) debug: created State broadlink2.0.RM:RMPROPLUS-4a-2e-b8._notReachable
broadlink2.0	2020-06-22 20:58:32.658	info	(10707) debug: created State broadlink2.0.States.TVWZKanal
broadlink2.0	2020-06-22 20:58:32.608	info	(10707) debug: created State broadlink2.0.States.Lüfter_A
broadlink2.0	2020-06-22 20:58:32.539	info	(10707) debug: created State broadlink2.0.States.Steckdose_A
broadlink2.0	2020-06-22 20:58:31.748	info	(10707) debug: ChangeState ack:true of _NewDeviceScan = false
broadlink2.0	2020-06-22 20:58:26.783	info	(10707) discover [ '192.168.1.199' ] from 0.0.0.0:53538
broadlink2.0	2020-06-22 20:58:26.783	info	(10707) debug: UDP listening on 0.0.0.0:53538
broadlink2.0	2020-06-22 20:58:26.781	info	(10707) debug: Try to discover 192.168.1.199
broadlink2.0	2020-06-22 20:58:21.943	info	(10707) Device RM:RMPROPLUS-4a-2e-b8 dedected: address=192.168.178.87, mac=34:ea:34:4a:2e:b8, typ=rmp, id=0x279d devtype=RM3 Pro Plus
broadlink2.0	2020-06-22 20:58:21.835	info	(10707) debug: UDP listening on 0.0.0.0:34061
broadlink2.0	2020-06-22 20:58:21.569	info	(10707) discover [ '192.168.178.255', '172.17.0.255', '255.255.255.255', '224.0.0.251' ] from 0.0.0.0:55539
broadlink2.0	2020-06-22 20:58:21.568	info	(10707) debug: UDP listening on 0.0.0.0:55539
broadlink2.0	2020-06-22 20:58:21.566	info	(10707) debug: ChangeState ack:true of broadlink2.0._NewDeviceScan = true
broadlink2.0	2020-06-22 20:58:21.522	info	(10707) debug: created State broadlink2.0._NewDeviceScan
broadlink2.0	2020-06-22 20:58:21.514	info	(10707) debug: UDP listening on 0.0.0.0:15001
broadlink2.0	2020-06-22 20:58:21.509	info	(10707) Discover Broadlink devices for 10sec on broadlink2.0
broadlink2.0	2020-06-22 20:58:21.504	info	(10707) debug: ChangeState ack:false of broadlink2.0.Scenes.Fernsehen = false
broadlink2.0	2020-06-22 20:58:21.460	info	(10707) debug: created State broadlink2.0.Scenes.Fernsehen
broadlink2.0	2020-06-22 20:58:21.446	info	(10707) debug: Config IP-Address end to remove: .fritz.box
broadlink2.0	2020-06-22 20:58:21.445	info	(10707) macObjects: [ '34:ea:34:4a:2e:b8', '9d:27:57:b2:a8:c0' ]
broadlink2.0	2020-06-22 20:58:21.444	info	(10707) debug: interface to be used: { address: '172.17.0.1', netmask: '255.255.0.0', mac: '02:42:89:6d:69:2a', cidr: '172.17.0.1/16' }:
broadlink2.0	2020-06-22 20:58:21.443	info	(10707) debug: interface to be used: { address: '192.168.178.86', netmask: '255.255.255.0', mac: '00:11:32:8f:34:d3', cidr: '192.168.178.86/24' }:
broadlink2.0	2020-06-22 20:58:21.441	info	(10707) Devices to rename: LB:hostName-aa-bb-cc=LB:SmartBulb
broadlink2.0	2020-06-22 20:58:21.440	info	(10707) Devices to add: 0xabcd,RM4 0xabcd=RM4
broadlink2.0	2020-06-22 20:58:21.440	info	(10707) Scanning additional IP's: 192.168.1.199
broadlink2.0	2020-06-22 20:58:21.436	info	(10707) broadlink2 initialization started...
broadlink2.0	2020-06-22 20:58:21.435	info	(10707) debug: broadlink2 received 78 objects and 78 states, with config ip,scenes,switches,poll,new,rename,additional,interface,lang,latitude,longitude,adapterConf,loglevel
broadlink2.0	2020-06-22 20:58:21.430	debug	(10707) system.adapter.admin.0: logging true
broadlink2.0	2020-06-22 20:58:20.706	info	(10707) starting. Version 2.1.0 in /opt/iobroker/node_modules/iobroker.broadlink2, node: v10.20.1, js-controller: 3.1.4
broadlink2.0	2020-06-22 20:58:19.890	debug	(10707) statesDB connected
broadlink2.0	2020-06-22 20:58:19.889	debug	(10707) States connected to redis: 127.0.0.1:9000
broadlink2.0	2020-06-22 20:58:19.848	debug	(10707) States create System PubSub Client
broadlink2.0	2020-06-22 20:58:19.822	debug	(10707) States create User PubSub Client
broadlink2.0	2020-06-22 20:58:19.782	debug	(10707) Redis States: Use Redis connection: 127.0.0.1:9000
broadlink2.0	2020-06-22 20:58:19.777	debug	(10707) objectDB connected
broadlink2.0	2020-06-22 20:58:19.767	debug	(10707) Objects connected to redis: 127.0.0.1:9001
broadlink2.0	2020-06-22 20:58:19.707	debug	(10707) Objects client initialize lua scripts
broadlink2.0	2020-06-22 20:58:19.706	debug	(10707) Objects create User PubSub Client
broadlink2.0	2020-06-22 20:58:19.705	debug	(10707) Objects create System PubSub Client
broadlink2.0	2020-06-22 20:58:19.701	debug	(10707) Objects client ready ... initialize now
broadlink2.0	2020-06-22 20:58:19.648	debug	(10707) Redis Objects: Use Redis connection: 127.0.0.1:9001
broadlink2.0	2020-06-22 20:58:16.077	debug	(10481) system.adapter.admin.0: logging false

[joergeli]

@frankjoke
Hmmm, in diesem Beispiel hatte ich die Befehle via JavaScript direkt hintereinander gesendet, da kann es durchaus sein, daß da der vorherige Befehl noch nicht fertig war. Die Geräte wurde aber trotzdem einwandfrei geschaltet.

Andererseits hatte ich ja geschrieben, daß ich im Script auch mal testweise Verzögerungen von jeweils 5 Sekunden hinter jedem Befehl eingebaut hatte.
Die Befehle wurden auch dementsprechend zeitverzögert abgesetzt, es kamen aber trotzdem die Warnmeldungen, daß der vorige Befehl noch nicht fertig sei ???

Anyway, ich kann damit leben, bzw. setze den LogLevel des Adapters auf "Error" , denn die IR, bzw. 433MHz-Empfänger werden ja trotzdem geschaltet.

Gruß
Jörg

[frankjoke]

@Christoph1337

Schau mal in die Adapter-Konfig, dort findest du Listen für Szenen und States.

Kreiere einen neuen Eintrag in States mit deinen gewünschten Namen und Befehlen und dann starte den Adapter neu und du hast unter States den neuen Eintrag.

[frankjoke]

@Knallochse

Bitte letzte Version von git ziehen, dort sollte nicht null für den Fehler angezeigt werden.

Übrigens, Dein Gerät scheint öfter nicht am WLAN erreichbar zu sein!