Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Mik77]

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

[mickym]

@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.

[Asgothian]

@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.

[mickym]

@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 = true

Und deshalb habe ich geschrieben man muss es als command und nicht als value schicken.

Siehe auch: https://forum.iobroker.net/post/1175552

[Mik77]

@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?

[mickym]

@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ätigt

Das 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".

[Mik77]

@mickym sagte in tuya Adapter stateChange von node-red geht nicht:
Cool, danke für die Ausführliche Antwort!