Tuya Aiibot Air Purifier via tuyapi und tuya-mqtt

Begonnen von tschimi, 17 Dezember 2020, 09:10:38

Vorheriges Thema - Nächstes Thema

Beta-User

...das geht ja wild durcheinander...

Bleib bei MQTT2_DEVICE, der Versuch mit MQTT_DEVICE ist "Banane".

Die ClientID ändert sich bei diesen "paho"-Devices ständig. Falls man es nicht per yaml einstellen kann: in der readingsList die CID-Präfixe (mqttjs_9f56ab04:)  löschen (siehe "Praxisbeispiele zu MQTT2_DEVICE im Wiki" (unten)).

Ansonsten: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt
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

brain666

hmm ich verstehe es irgendwie nicht :/


ich habe den tuya-mqtt mit meinen lokalen mqtt server verbunden
habe fhem als client auf dem mqtt verbunden

dieser erstellt dann auch das device


Internals:
   CFGFN     
   CID        FHEM
   DEF        FHEM
   DEVICETOPIC MQTT2_FHEM
   FUUID      6227397d-f33f-078c-a4c7-495c86eadaedf19d
   IODev      meinMQTT2Client
   LASTInputDev meinMQTT2Client
   MSGCNT     53
   NAME       MQTT2_FHEM
   NR         1637
   STATE      off
   TYPE       MQTT2_DEVICE
   meinMQTT2Client_MSGCNT 53
   meinMQTT2Client_TIME 2022-03-08 12:26:16
   .attraggr:
   .attrminint:
   READINGS:
     2022-03-08 12:09:49   IODev           meinMQTT2Client
     2022-03-08 12:14:31   dps_10_state    0
     2022-03-08 12:14:31   dps_14_state    off
     2022-03-08 12:14:31   dps_15_state    relay
     2022-03-08 12:14:31   dps_16_state    false
     2022-03-08 12:14:31   dps_17_state   
     2022-03-08 12:14:31   dps_18_state   
     2022-03-08 12:14:31   dps_19_state    BwACBQACAgACAQAC
     2022-03-08 12:14:31   dps_1_state     false
     2022-03-08 12:14:31   dps_2_state     false
     2022-03-08 12:26:16   dps_3_state     false
     2022-03-08 12:14:31   dps_4_state     false
     2022-03-08 12:14:31   dps_7_state     0
     2022-03-08 12:14:31   dps_8_state     0
     2022-03-08 12:14:31   dps_9_state     0
     2022-03-08 12:26:16   state           off
     2022-03-08 12:12:32   state_          true
     2022-03-08 12:14:31   state_1         false
     2022-03-08 12:14:31   state_10        0
     2022-03-08 12:14:31   state_14        off
     2022-03-08 12:14:31   state_15        relay
     2022-03-08 12:14:31   state_16        false
     2022-03-08 12:14:31   state_17       
     2022-03-08 12:14:31   state_18       
     2022-03-08 12:14:31   state_19        BwACBQACAgACAQAC
     2022-03-08 12:14:31   state_2         false
     2022-03-08 12:14:31   state_3         false
     2022-03-08 12:14:31   state_4         false
     2022-03-08 12:14:31   state_7         0
     2022-03-08 12:14:31   state_8         0
     2022-03-08 12:14:31   state_9         0
     2022-03-08 12:14:31   status          online
Attributes:
   readingList FHEM:tuya/4ch/status:.* status
FHEM:tuya/2ch/status:.* status
FHEM:tuya/4ch/dps/state:.* { json2nameValue($EVENT, 'state_', $JSONMAP) }
FHEM:tuya/4ch/dps/1/state:.* dps_1_state
FHEM:tuya/4ch/dps/2/state:.* dps_2_state
FHEM:tuya/4ch/dps/3/state:.* dps_3_state
FHEM:tuya/4ch/dps/4/state:.* dps_4_state
FHEM:tuya/4ch/dps/7/state:.* dps_7_state
FHEM:tuya/4ch/dps/8/state:.* dps_8_state
FHEM:tuya/4ch/dps/9/state:.* dps_9_state
FHEM:tuya/4ch/dps/10/state:.* dps_10_state
FHEM:tuya/4ch/dps/14/state:.* dps_14_state
FHEM:tuya/4ch/dps/15/state:.* dps_15_state
FHEM:tuya/4ch/dps/16/state:.* dps_16_state
FHEM:tuya/4ch/dps/17/state:.* dps_17_state
FHEM:tuya/4ch/dps/18/state:.* dps_18_state
FHEM:tuya/4ch/dps/19/state:.* dps_19_state
FHEM:tuya/2ch/dps/state:.* { json2nameValue($EVENT, 'state_', $JSONMAP) }
FHEM:tuya/2ch/dps/1/state:.* dps_1_state
FHEM:tuya/2ch/dps/2/state:.* dps_2_state
FHEM:tuya/2ch/dps/7/state:.* dps_7_state
FHEM:tuya/2ch/dps/8/state:.* dps_8_state
FHEM:tuya/2ch/dps/14/state:.* dps_14_state
FHEM:tuya/2ch/dps/16/state:.* dps_16_state
FHEM:tuya/2ch/dps/17/state:.* dps_17_state
FHEM:tuya/2ch/dps/18/state:.* dps_18_state
FHEM:FHEM_tuya/4ch/dps/3/state:.* dps_3_state
   room       MQTT2_DEVICE



laut tuya-mqtt ist das  tuya/4ch/dps/3/state das relais welches ich schalten möchte


tuya-mqtt:state MQTT DPS JSON: tuya/4ch/dps/state ->  {"3":true} +17s
  tuya-mqtt:state MQTT DPS3: tuya/4ch/dps/3/state ->  true +1ms
  tuya-mqtt:tuyapi Received JSON data from device bfff20fd3305acf489ybm9 -> {"3":false} +804ms
  tuya-mqtt:state MQTT DPS JSON: tuya/4ch/dps/state ->  {"3":false} +804ms
  tuya-mqtt:state MQTT DPS3: tuya/4ch/dps/3/state ->  false +0ms



ich habe verstanden das ich über das setlist Kommandos senden kann
also habe ich das hinzugefügt.

   setList    on tuya/4ch/dps/3/state true
off tuya/4ch/dps/3/state false


wenn ich dann auf on / off klicke sieht man bei den readings das sich

dps_3_state   true     2022-03-08 12:50:37

dem entsprechend auf true / false ändert

ich verstehe aber nicht wieso nichts beim tuya-mqtt ankommt, es wird lediglich in FHEM die reading geändert

sendet der tuya-mqtt erneut seine daten und die werte werden überschrieben

wenn es auf true steht überschriebt er es mit false

also sieht es für mich so aus als würde garnichts an den mqtt server übergeben.


Beta-User

Na ja, immerhin hast du die CleintId schon mal "fixiert" bekommen...

Grundsätzlich sollten bei MQTT die Sende- und Empfangsrichtung immer (!!!) unterschiedlich sein! In der readingList steht die Empfangsrichtung, und es wird aus diesem Grund auch (normalerweise, bei MQTT2_SERVER) nichts wieder empfangen, was aus FHEM versendet wurde.

Klingt danach, als würde der Gerät ohne die Kanal-Angabe im Topic auf einen JSON warten, von daher würde ich mal folgendes ins Rennen werfen:
setList    on tuya/4ch/dps/state {"3":true}
off tuya/4ch/dps/state {"3":false}
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

Nachtrag noch: Zum einen wäre das wieder so ein Fall, wo eine zentrale Instanz mit bridgeRegexp angebracht wäre (analog zigbee2mqtt usw.), und zum anderen könnte man noch true/false in was "lesbares" übersetzen. Zumindest der 2. Teil sollte auch in "Schritt für Schritt" zu finden sein.
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

brain666

Zitat von: Beta-User am 08 März 2022, 13:02:12
Na ja, immerhin hast du die CleintId schon mal "fixiert" bekommen...

Grundsätzlich sollten bei MQTT die Sende- und Empfangsrichtung immer (!!!) unterschiedlich sein! In der readingList steht die Empfangsrichtung, und es wird aus diesem Grund auch (normalerweise, bei MQTT2_SERVER) nichts wieder empfangen, was aus FHEM versendet wurde.

Klingt danach, als würde der Gerät ohne die Kanal-Angabe im Topic auf einen JSON warten, von daher würde ich mal folgendes ins Rennen werfen:
setList    on tuya/4ch/dps/state {"3":true}
off tuya/4ch/dps/state {"3":false}


Danke das habe ich auch bereits versucht da ich mir dachte das er den Kanal benötigt.
hat aber leider auch nichts gebracht.

aber dafür der Tip mit den bridgeRegexp

die devices sehen nun wie folgt aus.


define MQTT2_FHEM MQTT2_DEVICE FHEM
setuuid MQTT2_FHEM 6227397d-f33f-078c-a4c7-495c86eadaedf19d
attr MQTT2_FHEM bridgeRegexp FHEM:tuya/([A-Za-z0-9]*)[/]?.*:.* "tuya_$1"
attr MQTT2_FHEM room MQTT2_DEVICE
define MQTT2_tuya_4ch MQTT2_DEVICE tuya_4ch
setuuid MQTT2_tuya_4ch 62275282-f33f-078c-0794-e025dbda07bb02cd
attr MQTT2_tuya_4ch readingList tuya/4ch/status:.* status\
tuya/4ch/dps/state:.* { json2nameValue($EVENT, 'state_', $JSONMAP) }\
tuya/4ch/dps/1/state:.* dps_1_state\
tuya/4ch/dps/2/state:.* dps_2_state\
tuya/4ch/dps/3/state:.* dps_3_state\
tuya/4ch/dps/4/state:.* dps_4_state\
tuya/4ch/dps/7/state:.* dps_7_state\
tuya/4ch/dps/8/state:.* dps_8_state\
tuya/4ch/dps/9/state:.* dps_9_state\
tuya/4ch/dps/10/state:.* dps_10_state\
tuya/4ch/dps/14/state:.* dps_14_state\
tuya/4ch/dps/15/state:.* dps_15_state\
tuya/4ch/dps/16/state:.* dps_16_state\
tuya/4ch/dps/17/state:.* dps_17_state\
tuya/4ch/dps/18/state:.* dps_18_state\
tuya/4ch/dps/19/state:.* dps_19_state
attr MQTT2_tuya_4ch room MQTT2_DEVICE
attr MQTT2_tuya_4ch setList on tuya/4ch/dps/state {"3":true}\\
off tuya/4ch/dps/state {"3":false}

define MQTT2_tuya_2ch MQTT2_DEVICE tuya_2ch
setuuid MQTT2_tuya_2ch 62275282-f33f-078c-0d45-a11132db56d3fc6e
attr MQTT2_tuya_2ch readingList tuya/2ch/status:.* status\
tuya/2ch/dps/state:.* { json2nameValue($EVENT, 'state_', $JSONMAP) }\
tuya/2ch/dps/1/state:.* dps_1_state\
tuya/2ch/dps/2/state:.* dps_2_state\
tuya/2ch/dps/7/state:.* dps_7_state\
tuya/2ch/dps/8/state:.* dps_8_state\
tuya/2ch/dps/14/state:.* dps_14_state\
tuya/2ch/dps/16/state:.* dps_16_state\
tuya/2ch/dps/17/state:.* dps_17_state\
tuya/2ch/dps/18/state:.* dps_18_state
attr MQTT2_tuya_2ch room MQTT2_DEVICE
[code]

Beta-User

Bei deinem "on" ist ein doppelter Backslash drin! Nicht, dass der das Problem ist.

Ansonsten werde ich aus https://github.com/TheAgentK/tuya-mqtt#dps-topics auch nicht so richtig schlau...

Und dass nach der Doku derselbe Topic für Kommandos und Zustände genutzt zu werden scheint (?), ist imo ein Bug.
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

brain666

Danke am doppelten "\" lag es nicht war nur ein copy&paste fehler :/

genau das DPS JSON topic hatte ich mir auch gerade angeschaut bringt mich aber auch nicht weiter :(

schade

naja zumindest habe ich schonmal die aktuellen werte der einzelnen relais


Ich danke dir

Beta-User

Zitat von: brain666 am 08 März 2022, 14:46:20
schade
...irgendwie schon...

Wobei diese Variante eh' ein "totes Pferd" zu sein scheint, der Maintainer hat ja angekündigt, dass es keine Weiterentwicklung geben wird (weil im diese Tuya Cloud prinzipiell nicht gefällt).

Vielleicht ist es mittelfristig der einfachere Weg, die Lösung von dominik zu nehmen: https://forum.fhem.de/index.php/topic,122288.0.html
(oder eben ganz von Tuya-Cloud wegzugehen).
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

brain666

Ja Dominik seine Lösung hatte ich auch erwähnt

Ich wollte es halt über mqtt und mit der tuya-mqtt sah es nicht schlecht aus

Auf iobroker / openhab läuft es auch über tuya-mqtt

Ich recherchiere nochmal ein bissel

Von tuya weg wäre mir auch die liebste Lösung aber ich habe keine Idee wie ich die relaisboards dafür modden muss
Geschweige von löten habe ich keine Ahnung:(

Beta-User

Ohne info zur konkreten Hardware ist es schwierig... Am ehesten tasmota.
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

brain666

#25
Hardware ist das als 4 Kanal und als 2 Kanal relais

Ich nutze es für meine Garagen und Hoftore
433 mhz wegen der Fernbedienung
Tuya wegen alexa
Alexa habe ich auch auf meinen Server debian

https://www.amazon.de/Wireless-Selbstverriegelung-Garagentor-Fernbedienung-kompatibel/dp/B08NPTCQDB/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=8IXG25NDVFAF&keywords=4+kanal+relais+alexa&qid=1646736023&sprefix=4+kanal+relais+alexa%2Caps%2C104&sr=8-


Im Moment sieht es so bei mir aus auf dem Tablet sieht es anständiger aus
Ich bediene zurzeit die Garagen und hoftore über den Umweg Alexa Routine




define Hoftor_alexa dummy
setuuid Hoftor_alexa 61eea386-f33f-078c-db12-606efcbec4b23272
attr Hoftor_alexa alias Hoftor
attr Hoftor_alexa devStateIcon off:secur_locked@green:on on:secur_open@red:off
attr Hoftor_alexa devStateStyle style="text-align:left;;;;font-weight:bold;;;;"
attr Hoftor_alexa group Steckdosen
attr Hoftor_alexa icon fts_sliding_gate@grey
attr Hoftor_alexa room 0.1_Amazon
attr Hoftor_alexa webCmd :

define Hoftor_alexa_noti notify Hoftor_alexa:on set ECHO_G0916D10046500MS speak " Hoftor ist auf";; set ECHO_G0916D10046500MS routine_play hoftor_öffnen@amzn1.alexa.automation.36447688-e9d5-4bdd-882e-1327cfb412bb
setuuid Hoftor_alexa_noti 61eea59d-f33f-078c-f42d-b7c5e6c51a6d6f65
attr Hoftor_alexa_noti room 0.4_Telegramm

Beta-User

Ah, sieht speziell aus, und hat wohl neuerdings auch einen Tuya-Chip statt des ESP8266, der in https://templates.blakadder.com/eachen_ST-DC4.html zu finden ist. Die Anleitung dort liest sich so, als wäre da ein weiterer Controller verbaut, der den 433MHz-RF-Teil macht, und der Tuya-Chip sollte flashbar sein, aber im Zweifel würde ich das auch erst mal mit einem Duplikat testen...
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


brain666

Ich habe diese bei mir einfach an den Schlüsselschalter geklemmt.