NEWS
tuya Adapter stateChange von node-red geht nicht
-
Hi,
ich nutze den Tuya Adpter v3.15.0 und kann meinen Ladeziegel fürs E-Auto auslesen.
Es gibt einen Datenpunkt, der 3 Werte annehmen kann: 0 (Laden),1 (Ladestopp) oder 2 (Warten).
Das Objekt sieht so aus:
Die Objektdaten sehen so aus:
{
"type": "state",
"common": {
"type": "number",
"states": {
"0": "OpenCharging",
"1": "CloseCharging",
"2": "WaitOperation"
},
"read": true,
"write": true,
"name": "ChargingOperation",
"role": "level"
},
"native": {
"code": "ChargingOperation",
"defaultValue": "OpenCharging",
"canTrigger": true,
"type": "obj",
"executable": true,
"mode": "rw",
"defaultRecommend": false,
"name": "充电操作",
"property": {
"range": [
"OpenCharging",
"CloseCharging",
"WaitOperation"
],
"type": "enum"
},
"id": 124,
"editPermission": false
},
"from": "system.adapter.tuya.0",
"user": "system.user.admin",
"ts": 1719915722916,
"_id": "tuya.0.bf7b77d8a1f50ad987nrek.124",
"acl": {
"object": 1636,
"state": 1636,
"owner": "system.user.admin",
"ownerGroup": "system.group.administrator"
}
}Wenn ich über den Iobroker den Datenpunkt manuell ändere, startet oder stoppt das Laden des Fahrzeugs problemlos.
Das Log sieht dann so aus:tuya.0 2024-07-02 17:56:54.584 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.101 {"val":2,"ack":true,"ts":1719935814581,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935814581} tuya.0 2024-07-02 17:56:54.577 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"101":"charing"},"t":1719935814} tuya.0 2024-07-02 17:56:54.311 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":1,"ack":true,"ts":1719935814307,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935814307} tuya.0 2024-07-02 17:56:54.301 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"124":"CloseCharging"},"t":1719935813} tuya.0 2024-07-02 17:56:51.573 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":2,"ack":true,"ts":1719935811570,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935811570} tuya.0 2024-07-02 17:56:51.566 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"124":"WaitOperation"},"t":1719935811} tuya.0 2024-07-02 17:56:51.028 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.101 {"val":1,"ack":true,"ts":1719935811024,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935811024} tuya.0 2024-07-02 17:56:51.020 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"101":"connect"},"t":1719935810} tuya.0 2024-07-02 17:56:50.913 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":0,"ack":true,"ts":1719935810909,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935810781} tuya.0 2024-07-02 17:56:50.904 debug bf7b77d8a1f50ad987nrek.124: set value "OpenCharging" via bf7b77d8a1f50ad987nrek (Local): res={"dps":{"124":"OpenCharging"},"t":1719935810} tuya.0 2024-07-02 17:56:50.904 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"124":"OpenCharging"},"t":1719935810} tuya.0 2024-07-02 17:56:50.785 debug bf7b77d8a1f50ad987nrek onChange triggered for 124 and value 0 tuya.0 2024-07-02 17:56:50.784 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":0,"ack":false,"ts":1719935810781,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1719935810781} **Wenn ich den Ladevorgang aus node-red starte, sieht das Log so aus und der Ladevorgang startet nicht:** tuya.0 2024-07-02 17:59:48.489 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.102 {"val":399,"ack":true,"ts":1719935988484,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935988484} tuya.0 2024-07-02 17:59:48.473 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"102":399},"t":1719935986} tuya.0 2024-07-02 17:59:44.402 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.102 {"val":398,"ack":true,"ts":1719935984399,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935984399} tuya.0 2024-07-02 17:59:44.394 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"102":398},"t":1719935982} tuya.0 2024-07-02 17:59:36.240 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.102 {"val":399,"ack":true,"ts":1719935976238,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935976238} tuya.0 2024-07-02 17:59:36.234 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"102":399},"t":1719935975} tuya.0 2024-07-02 17:59:32.164 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.102 {"val":400,"ack":true,"ts":1719935972161,"q":0,"from":"system.adapter.tuya.0","user":"system.user.admin","lc":1719935972161} tuya.0 2024-07-02 17:59:32.157 debug bf7b77d8a1f50ad987nrek: Received data: {"dps":{"102":400},"t":1719935971} tuya.0 2024-07-02 17:59:15.167 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {**"val":2,**"ack":true,"ts":1719935955165,"q":0,"from":"system.adapter.node-red.0","user":"system.user.admin","lc":1719935955165} tuya.0 2024-07-02 17:59:14.167 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {**"val":0,"**ack":true,"ts":1719935954164,"q":0,"from":"system.adapter.node-red.0","user":"system.user.admin","lc":1719935954164}
Um den Wert 0 = laden an das IOBroker-Objekt aus Node-red zu senden verwende ich den Node: "IOBroker out"
Mir scheint, dass das auslösen des Ladevorgangs in IOBroker selber mehr als nur die "0" gesendet wird, daher schicke ich auch die "2" hinterher, aber da passiert noch mehr aus IoBroker raus, was ich nicht verstehe.
Frage: wie finde ich heraus, welche Routine ausgeführt wird, wenn ich im IOBroker das Objekt ändere? Oder hat jemand eine Lösung wie ich das Objekt so anstossen kann, dass der Ladziegel anfängt zu laden?MOD-Edit: Log in Code-Tags gesetzt
-
@mik77 Wenn Du es in Objekten schalten kannst, dann geht es auch mit NodeRed. Du musst es in der iobroker-out als command und nicht als value schicken. Ausserdem ggf. prüfen, ob Du den richtigen Datentyp also eine Zahl schickst.
-
@mik77
Du nutzt die falsche Methode um zu schalten. Wenn du dir jeweils den ersten (zeitlich) Eintrag der beiden log files anschaust solltest du den Unterschied sehen.2024-07-02 17:56:50.784 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":0,"ack":false,"ts":1719935810781,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1719935810781}
2024-07-02 17:59:14.167 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":0,"ack":true,"ts":1719935954164,"q":0,"from":"system.adapter.node-red.0","user":"system.user.admin","lc":1719935954164}
Ich nutze Node-red nicht, bin aber sicher das dir einer der Spezis sagen kann was du ändern musst, damit du von Node-red mit
ack=false
steuerst.A.
-
@asgothian sagte in tuya Adapter stateChange von node-red geht nicht:
@mik77
Du nutzt die falsche Methode um zu schalten. Wenn du dir jeweils den ersten (zeitlich) Eintrag der beiden log files anschaust solltest du den Unterschied sehen.2024-07-02 17:56:50.784 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":0,"ack":false,"ts":1719935810781,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1719935810781}
2024-07-02 17:59:14.167 debug stateChange tuya.0.bf7b77d8a1f50ad987nrek.124 {"val":0,"ack":true,"ts":1719935954164,"q":0,"from":"system.adapter.node-red.0","user":"system.user.admin","lc":1719935954164}
Ich nutze Node-red nicht, bin aber sicher das dir einer der Spezis sagen kann was du ändern musst, damit du von Node-red mit
ack=false
steuerst.A.
Habe ich ja geschrieben:
Type: command = ACK = false
Type: value = ACK = trueUnd deshalb habe ich geschrieben man muss es als command und nicht als value schicken.
Siehe auch: https://forum.iobroker.net/post/1175552
-
@mickym , das Leben kann so einfach sein
Vielen Dank für den Tipp mit dem Command, ich habe es umgestellt und direkt funktioniert es!
Kannst du kurz erklären wass der Command anders macht als das Value? -
@mik77 sagte in tuya Adapter stateChange von node-red geht nicht:
@mickym , das Leben kann so einfach sein
Vielen Dank für den Tipp mit dem Command, ich habe es umgestellt und direkt funktioniert es!
Kannst du kurz erklären wass der Command anders macht als das Value?Nun ich dachte - ich habe es schon erklärt.
command = setzt das ACK (acknowledged Flag nicht, also false), also nicht bestätigt und
value = setzt das ACK (acknowledged Flag, also true) also bestätigtDas ist das Gleiche, wenn Du das Objekt im iobroker schreibst.
Wenn Du den Datenpunkt beschreibst und keinen Haken bei "Bestätigt" setzt, dann wird dieser unbestätigt geschrieben und der Adapter, weiß er muss etwas machen.
Umgekehrt wenn Du einen Datenpunkt beschreibst und diesen "Bestätigt" setzt, dann geht der Adapter davon aus, dass Du schon weißt was Du tust und er macht nichts.Sprich Du kannst das Verhalten der iobroker-out node eines Objekts mit dem Type value direkt mit dem direkten Beschreiben im iobroker mit "bestätigt" nachvollziehen.
Was hat es nun allgemein mit dem ACK- Flag auf sich bzw. wann verwendet man das Beschreiben eines Objekts mit Bestätigung (also als Type value in iobroker-out node) und wann ohne Bestätigung (also als Type command in iobroker-out node) ?
Grundsätzlich, wenn Du etwas in irgendeinem Adapter steuern willst, also zu einer Aktion veranlassen willst, dann schreibst Du einen Wert UNBESTÄTIGT.
Jeder Adapter, der eine Hardware steuert, reagiert grundsätzlich NUR auf unbestätigte Objekte, führt dann den Befehl hardwareseitig aus und BESTÄTIGT selbst den Wert, nachdem er die Aktion durchgeführt hat.
Sprich in der Regel setzt NUR ein ADAPTER selbst bestätigte Werte, da er diese direkt von der Hardware erhält.
Du kannst Dir auch vorstellen, dass BESTÄTIGT heißt, wurde vom Adapter oder der Hardware bestätigt.Wann setzt Du also selbst ein Objekt bestätigt?
Im Allgemeinen nur dann, wenn hinter einem iobroker Objekt KEIN Adapter bzw. Hardware steckt, die Dir diesen Wert bestätigen kann. Das ist in der Regel also nur bei selbsterstellten Datenpunkten und die liegen ja alle unter 0_userdata.0.
Hier schreibst Du also in der Regel mit "value" rein.Du kannst aber auch selbst Adapter spielen mit einem 0_userdata.0 Datenpunkt. Grundsätzlich (aus eben genannten Gründen) werden Visualisierungen wie VIS etc. Datenpunkte nur UNBESTÄTIGT schreiben, damit der Adapter oder Du weißt, dass etwas gemacht werden muss.
Deshalb gibt es in der iobroker-IN Node auch ein Flag in dem Du filtern kannst, ob ein Wert unbstätigt oder bestätigt geschrieben wurde.
Beschreibst Du also mit VIS einen Datenpunkt unter 0_userdata.0 einen unbestätigte Wert, dann kannst Du den mit einer iobroker-in Node entsprechend filtern:
In den iobroker-Objekten erscheint ein "unbestätigter Wert" auch erst rot.
Dann führst Du Deinen Flow aus - und da Du selbst Adapter spielst, setzt Du den gleichen Wert nochmal "bestätigt" als value, um die Ausführung zu bestätigen. Da Dein Flow aber nur durch unbestätigte Werte getriggert wird, erzeugst Du KEINE Endlosschleife.Den Wechsel von rot zu grün, siehst Du beim direkten Beschreiben oft nicht, weil die Kommunikation im ms Bereich stattfindet.
Falls noch Fragen offen sind, einfach melden.
Nachtrag: Bin ja froh, dass nicht jeder puzzelt und NodeRed als Logikmaschine und nicht dieses Blockly nutzt. Zu diesem Entschluß möchte ich Dir nachträglich gratulieren. Trotzdem noch ein Nachtrag. Bei dem Puzzeln entspricht dem Type command der iobroker-out Node in NodeRed, das Puzzleteil "steuere" und dem Type value der iobroker-out Node in Node-Red, das Puzzleteil "aktualisiere".
-
@mickym sagte in tuya Adapter stateChange von node-red geht nicht:
Cool, danke für die Ausführliche Antwort!