Tuya - Smart Life: LED Lampen und Schalter

Begonnen von area2051, 27 November 2018, 07:31:06

Vorheriges Thema - Nächstes Thema

area2051

Hallo zusammen,

ich habe versucht etwas über die Steuerung von LED Lampen und Schalter mit FHEM zu finden, die momentan mittels Tuya Cloud gesteuert werden. Leider bisher nicht fündig geworden.
Kann mir zufällig jemand sagen, wie der Status der Unterstützung mittles FHEM ist? Bisher hab ich leider nichts im Forum gefunden.

Besitze folgende Produkte:

  • Smart WLAN LED Lampe Glühbirne TECKIN E27 Birne RGB Bulb mit mehreren Farben Wifi Glühbirne 800LM, steuerbar via App dimmbare, kompatibel mit Alexa (Echo, Echo Dot) Google Home Fernbedienung 4Packs
  • Opard Wlan Steckdose Alexa Steckdose Wifi Steckdose Smart Plug Kompatibel mit Alexa für Ihres Smart Home Systems (2 Pack)
https://www.amazon.de/gp/product/B07GVJFBN5
https://www.amazon.de/gp/product/B078N4964P

Soweit ich bisher gelesen habe, gibt es eine API, über die man die Geräte über Umwege per Cloud zugreifen kann:
https://docs.tuya.com/en/cloudapi/device_access.html#http-https-connection-method

Falls noch keine Unterstützung existiert:
a) Was ist besser für die Umsetzung in Fhem geeignet: HTTPS Calls oder MQTT?
b) Habt ihr zufällig ein Modul was ich als Copy&Paste&Adapt nutzen kann?

Danke euch!

Gruß

-M-

dmq

Zitat von: area2051 am 27 November 2018, 07:31:06

Kann mir zufällig jemand sagen, wie der Status der Unterstützung mittles FHEM ist? Bisher hab ich leider nichts im Forum gefunden.


Das sieht aus wie ein AI-Light - darauf läuft ein ESP8266. Genauer könnte ich Dir das aber sagen, wenn Du den Deckel abmachst und ein Foto postest.

Falls es das besagte Licht ist, kannst Du ESPurna oder auch Tasmota flashen.

Anleitung:

http://tinkerman.cat/ailight-hackable-rgbw-light-bulb/
https://github.com/xoseperez/espurna/wiki/Hardware-AI-Thinker-AI-Light

Anschließend kannst Du dann mqtt machen oder auch per WEB-API. Ich habe Konfig-Beispiele für ESPurna + FHEM + mqtt hier. Werde die dann falls hilfreich posten.



area2051

Danke für die Info!

Gibt es auch eine Möglichkeit, diese einfach per fhem einzubinden? ... Ich will sie nur betreiben, weder auseinander nehmen, noch löten oder flashen. Dafür fehlt mir leider die Zeit 🕰...

Vielen Dank vorab.

dmq

Das hatte ich mir gedacht. Leider ist mir nur diese Lösung bekannt. Ich habe bezüglich einen Großteil von Diensten und Anbietern eine nicht-Cloud-Strategie - bin aber nicht hier um dich zu bekehren. Dann viel Erfolg u. Spaß.

Beta-User

Da die Teile irgendwie auch MQTT zu sprechen scheinen, würde ich mal nachsehen, wie das konkret implementiert ist und dann die MQTT2-Varianten testen.

Du müßtest dazu aber als erstes direkt in der Weboberfläche der Devices nachsehen, was man da zu MQTT einstellen kann. Kann man einen lokalen Server (aka Broker) angeben, kannst du in FHEM einen MQTT2_SERVER definieren, (ggf. ein passendes allowed konfigurieren,) den Server auf autocreate stellen und dessen Adresse (und Zugangsdaten wie in allowed angegeben) für jedes Device einstellen.

Mußt du einen externen Server nutzen, ginge das ähnlich mit MQTT2_CLIENT.

Bitte dazu die letzten Threads mit diesen Themen mal durchforsten (und natürlich die commandref), dann wird das hoffentlich etwas klarer. Konfiguration z.B. für RGB-Devices (und ggf. erforderlicher Zusatzcode) findet sich uU. im zigbee2mqtt-Thread.

Viel Erfolg,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dmq

Falls Du noch mit diesem System unterwegs sein solltest - schau doch bitte mal kurz hier rein:

35C3 Smart Hacks. Ich denke genau diese Plattform ist auch bei Dir im Einsatz. Wie gesagt, will dich nicht bekehren, aber hier wird voll und ganz das Risiko mit "einem" Cloud-Dienst veranschaulicht.

https://www.youtube.com/watch?v=urnNfS6tWAY

mwllgr

Hallo,

nur als Ergänzung: Bei mir funktioniert eine Tuya Glühbirne mit Tasmota über Tuya-Convert der c't.
Siehe https://github.com/ct-Open-Source/tuya-convert.

Die Anbindung funktioniert dann über MQTT in FHEM mit MQTT2_SERVER und MQTT2_DEVICE.

Beta-User

Für MQTT2_DEVICE gibt's zwischenzeitlich auch passende attTemplates...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mwllgr

Welche meinst du? tuyaMCU_dimmer? Bei mir funktionierten die nicht, musste selbst Attribute dazu schreiben - oder ich habe einfach eine falsche Konfiguration in Tasmota...

Beta-User

Die rgb- bzw. rgbw-Varianten. Ggf. update machen, sind noch nicht lange drin.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Vielleicht nochmal die Langfassung:

"Tuya" bzw. "TuyaMCU" sind (jedenfalls teilweise) zwei Paar Stiefel.
TuyaMCU ist ein spezielles Transceiversystem, das von Tasmota auch unterstützt wird (https://github.com/arendst/Tasmota/wiki/TuyaMCU). Da hat man afaik eine Art Gateway, das dann wieder andere (non-WLAN-) Geräte steuern kann, die ihrerseits aber wieder spezielle Codes benötigen (irritierenderweise ist das in dem attrTemplate nicht so richtig reflektiert; würde mal tippen, dass das mit den eigentlichen Zieldevices gar nicht so ohne weiteres funktioniert, sondern das sieht eher aus wie ein "normales" rgb-Device... (Sorry, ich kann häufig nur in Teilen verifizieren, was mir jemand zuruft; das sehe ich leider jetzt etwas anders, nachdem ich selbst mit einem rgbw-Device rumgespielt habe, vorher wäre es zu viel Raterei auf Basis der Tasmota-Doku gewesen.)).

"Tuya" ist einfach nur eine Art Cloud-API-Anbieter, den man direkt wieder vergessen kann, wenn die Tasmota-firmware erst mal auf dem ESP werkelt. Dann ist es einfach eines der "normalen" tasmota-attrTemplates, das zu wählen ist. Davon gibt es derzeit 3:rgb (=> attrTemplate: tasmota_rgb_led_controller);rgw+Weißkanal-Dimmer (tasmota_rgbw_led) und
rgbw+Weiß-Farbtemperatur (tasmota_rgbwct_led).

Es darf sich gerne jemand die Mühe machen, die Doku zu verbessern (in den Prayisbeispielen und im attrTemplate-File selbst), wenn das nicht als "selbsterklärend" empfunden wird ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mwllgr

Aaah, alles klar, vielen Dank!
Gibt's irgendwo eine Doku wie welche GPIOs in Tasmota auszuwählen sind oder geht das attrTemplate einfach, sobald 3 belegt sind? Habe später dann einfach selbst herumprobiert und drei für R, G und B gefunden.

Beta-User

Für den einzigen von mir genutzten Devic-Typ gab es ein (innoffizielles) "template" (Tasmonta-intern): https://templates.blakadder.com/maxcio-YX-DE04.html
Da gibt es noch viel mehr, allerdings sind die nicht immer perfekt...
Z.B. gibt es auch eines für das "eigentliche" Zieldevice (https://templates.blakadder.com/maxcio_YX-DE02.html) mit etwas anderer PIN-Belegung, das zwar auch "irgendwie" funktioniert hat, aber eben nicht so problemfrei. Außerdem behaupten die beiden tamplates (mMn.) fälschlicherweise, dass irgendwas analoges gemessen wird; das habe ich dann schlicht ("FLAG":0) ausgeschaltet.

Kurzfassung: vermutlich gibt es viele Überschneidungen und Fehlinfos da, aber es kann nicht schaden da reinzusehen, damit hat man schon mal eine Basis...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mwllgr

#13
Habe das Template tasmota_rgb_led_controller jetzt bei mir getestet und es scheint gut zu funktionieren.
Anbei ein Screenshot meiner Konfiguration in Tasmota. Ist eine normale E27-Glühbirne.

Lediglich gibt es bei mir kein POWER1 sondern nur POWER, also musste ich das im stateFormat etc. ändern.
Könnte man vllt. "LWT" einbauen, dass bei der Lampe ein unreachable-devStateIcon ist, wenn sie "Offline" ist?

Beta-User

#14
Hmm, fast alle E27-Sockel-Bulbs scheinen RGBW-Varianten zu sein.

Vielleicht machst du einen Test mit https://templates.blakadder.com/al_above_lights_9W_E26_rgbw.html?

Was POWERx angeht: Wenn du das mit "set ... attrTemplate ..." angewendet hattest, sollte das umgestellt sein. Oder hast du den attrTemplate-Code manuell übertragen und den ersten Schritt ausgelassen? (Sollte man "richtig" machen, dann paßt das auch besser mit Klein-/und Großschreibung).

Ansonsten würde ich raten, die jsonMap-Variante auszutesten. Geht am einfachsten, wenn du das rgbw-Template nimmst ("notfalls" den Weiß-Setter manuell rausnehmen, wenn der nach vollständiger Tasmota-Konfiguration wirklich nicht geht ;) ). (stateFormat muß dann raus! Ggf. zum Experimentieren einfach eine Kopie erstellen und alles außer readingList löschen).

EDIT: bitte wenn möglich auch die konkrete Type mitteilen, dann kann ich das in die desc mit aufnehmen, damit andere das wiederfinden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files