Closed llugo closed 1 year ago
Apparently this is a dupe of https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6381#issue-1393857813
@Smanar still not possible
Can try this DDF
{
"schema": "devcap1.schema.json",
"manufacturername": ["_TZE200_7fqkphoq", "_TZE200_xby0s3ta", "_TZE200_cpmgn2cf"],
"modelid": ["TS0601", "TS0601", "TS0601"],
"vendor": "Tuya",
"product": "Tuya TRV (MOES)",
"sleeper": false,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_THERMOSTAT",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0xef00"
],
"meta": {
"values": {
"config/mode": {"auto": 0, "heat": 1, "off": 2}
}
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "state/lowbattery",
"parse": {"fn": "tuya", "dpid": 110, "eval": "Item.val = Attr.val != 0"},
"read": {"fn": "none"}
},
{
"name": "config/battery",
"parse": {"fn": "tuya", "dpid": 21, "eval": "Item.val = Attr.val;"},
"read": {"fn": "none"}
},
{
"name": "config/heatsetpoint",
"parse": {"fn": "tuya", "dpid": 2, "eval": "Item.val = Attr.val * 10;"},
"write": {"fn": "tuya", "dpid": 2, "dt": "0x2b", "eval": "Item.val / 10;"},
"read": {"fn": "tuya"}
},
{
"name": "config/locked",
"parse": {"fn": "tuya", "dpid": 7, "eval": "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 7, "dt": "0x10", "eval": "Item.val;"},
"read": {"fn": "none"}
},
{
"name": "config/windowopen_set",
"parse": {"fn": "tuya", "dpid": 18, "eval": "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 18, "dt": "0x10", "eval": "Item.val;"},
"read": {"fn": "none"}
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "config/mode",
"values": [
["auto", 0], ["heat", 1], ["off", 2]
],
"parse": {"fn": "tuya", "dpid": 4, "eval": "if (Attr.val == 0) { Item.val = 'auto' } else if (Attr.val == 1) { Item.val = 'heat' } else { Item.val = 'off' }"},
"write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "eval": "if (Item.val == 'auto') { 0 } else if (Item.val == 'heat') { 1 } else { 2 }"},
"read": {"fn": "none"}
},
{
"name": "state/lastupdated"
},
{
"name": "state/temperature",
"parse": {"fn": "tuya", "dpid": 3, "eval": "Item.val = Attr.val * 10;"},
"read": {"fn": "none"}
}
]
}
]
}
The dpid for mode can be 106 instead of 4.
Can try this DDF
This is what i get from the API after loading the DDF, tried both dpid values (106 and 4) in "parse" and "write" lines in config/mode section... It somehow got the name somewhat right...
"19": {
"config": {
"heatsetpoint": null,
"locked": true,
"mode": "off",
"offset": 0,
"on": true,
"reachable": true
},
"etag": "b58befe403f8cda28fe96dc5b8a54867",
"lastannounced": null,
"lastseen": "2023-08-03T18:37Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat 19",
"state": {
"lastupdated": "2023-08-03T16:23:11.232",
"lowbattery": null,
"on": false,
"reachable": null,
"temperature": 0
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
},
Lol ok, so it seem the DDF is working bu I have wrong for ALL dpid ?
Can you enable log in deconz / help / debug view with flag "info" Then try to change the heatpoint manualy, you will have a return in log, something like
TY_DATA_%s: seq %u, dpid: 0x%02X, type: 0x%02X, length: %u, val: %d\n",
Can you enable log in deconz / help / debug view with flag "info"
13:42:25:373 TY_DATA_RESPONSE: seq 271, dpid: 0x03, type: 0x02, length: 4, val: 230
13:42:25:578 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:25:579 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:25:580 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:25:581 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:25:581 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:25:582 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:25:582 TY_DATA_RESPONSE: seq 272, dpid: 0x04, type: 0x04, length: 1, val: 2
13:42:29:306 TY_DATA_RESPONSE: seq 273, dpid: 0x02, type: 0x02, length: 4, val: 205
13:42:29:306 TY_DATA_RESPONSE: seq 273, dpid: 0x02, type: 0x02, length: 4, val: 205
This one need to be setheatpoint, and I m using same
"parse": {"fn": "tuya", "dpid": 2, "eval": "Item.val = Attr.val * 10;"},
It need to work ....
Nothing special in logs using "DDF" and "info" ? You are not using HA or docker ?
You are not using HA or docker ?
no just deconz v2.22.2.
Somehow the device seems to pick up a wrong ddf when connecting... Loading and hot reloading the DDF posted above doesn't seem to work. Whenever i close the editor and open it again there are wrong DPID entries.
Screenshot after connecting the node:
Screenshot after hot reloading
Sreenshot after closing the DDF editor an opening it again
DDF location ist /home/[USER]/.local/share/dresden-elektronik/deCONZ/devices/tuya/
Ok, I think you have more than 1 DDF for the same device.
You have one called tuya_ts601.json and one called _TZE200_cpmgn2cf.json
Oh good point. After restarting deconz it's picking the right DDF! I thought just deleting the 'wrong' file was sufficient.
This is the API response now. Heatsetpoint looks good. But temperature should be nonzero.
"20": {
"config": {
"battery": 0,
"heatsetpoint": 2000,
"locked": true,
"mode": "off",
"on": true,
"reachable": true,
"windowopen_set": false
},
"etag": "f3c5ce323d00fb21d47b5212f5f86085",
"lastannounced": null,
"lastseen": "2023-08-05T16:48Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat 20",
"state": {
"lastupdated": "2023-08-05T16:30:44.783",
"lowbattery": null,
"temperature": 0
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
},
EDIT: From the logs after changing the heat point
18:54:06:465 TY_DATA_RESPONSE: seq 355, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:06:466 TY_DATA_RESPONSE: seq 355, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:06:467 TY_DATA_RESPONSE: seq 355, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:07:582 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:584 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:585 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:586 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:587 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:588 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:590 TY_DATA_RESPONSE: seq 356, dpid: 0x02, type: 0x02, length: 4, val: 230
18:54:07:818 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:07:819 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:07:820 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:07:820 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:07:821 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:07:822 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:07:823 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
18:54:08:018 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:08:019 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:08:020 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:08:021 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:08:022 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:08:022 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:08:023 TY_DATA_RESPONSE: seq 358, dpid: 0x04, type: 0x04, length: 1, val: 2
18:54:24:981 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:24:983 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:24:984 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:24:985 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:24:986 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:24:988 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:24:989 TY_DATA_RESPONSE: seq 359, dpid: 0x03, type: 0x02, length: 4, val: 265
18:54:25:188 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:25:189 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:25:190 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:25:191 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:25:191 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:25:192 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:25:193 TY_DATA_RESPONSE: seq 360, dpid: 0x6D, type: 0x02, length: 4, val: 0
18:54:07:820 TY_DATA_RESPONSE: seq 357, dpid: 0x03, type: 0x02, length: 4, val: 260
{
"name": "state/temperature",
"parse": {"fn": "tuya", "dpid": 3, "eval": "Item.val = Attr.val * 10;"},
"read": {"fn": "none"}
}
So 260 * 10 give 2600, nothing strange ! Still no value for temperature ? if not you can enable the flag "DDF" in same time.
Still no value for temperature ?
After doing some more API requests, it's reporting temperature correctly now!
"20": {
"config": {
"battery": 0,
"heatsetpoint": 2350,
"locked": true,
"mode": "off",
"on": true,
"reachable": true,
"windowopen_set": false
},
"etag": "ec61d6dfe51d6299b394b7e477f01928",
"lastannounced": null,
"lastseen": "2023-08-05T17:13Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat 20",
"state": {
"lastupdated": "2023-08-05T17:12:08.825",
"lowbattery": null,
"temperature": 2650
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
},
Great! Finally this device is going to be used as intented!
@Smanar Thanks a thousand once again!
I m just seing this device have native support in c++ code
{"_TZE200_cpmgn2cf", "TS0601", "MOES", "Tuya_THD HY368 TRV"},
IDK why it haven't worked ... Perhaps because device detection is harder without DDF.
And this device haven't battery support, so bad you have "lowbattery": null,
you haven't used battery to test this field ?
Edit: Have found why this device is not working with native code https://forum.phoscon.de/t/tuya-trv-tze200-cpmgn2cf-not-pairing-correctly/2698/5
1) I changed batteries, API response now looks like that:
"19": {
"config": {
"battery": 0,
"heatsetpoint": 1500,
"locked": false,
"mode": "off",
"on": true,
"reachable": true,
"windowopen_set": false
},
"etag": "d806a25c45a93b11cc05562c9b2b9fdc",
"lastannounced": null,
"lastseen": "2023-08-07T18:41Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat 19",
"state": {
"lastupdated": "2023-08-07T18:41:30.298",
"lowbattery": false,
"temperature": 2550
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
},
2) Just to double check for "integral" deCONZ support I removed the DDF file then deleted the node then restarted deCONZ and reconnected the node. It wasn't detected as a TRV. So i deleted the node. Then i moved the DDF back, restarted deconz and reconnected the node again. It was then recognized as a TRV like before.
EDIT: just saw you edited your comment... EDIT2: if there's anything i can do make this work without a DDF i'd be happy to help!
I changed batteries, API response now looks like that [...]
Interestingly, altough "lowbattery" is reported as false deCONZ shows a low battery symbol:
deconz can't get battery level, this device is a tuya one, nothing standard.
"lowbattery": false,
Ha nice the value was updated (it's no more "null'), it was good or bad battery ?
deconz can't get battery level, this device is a tuya one, nothing standard.
Oh, I see.
Ha nice the value was updated (it's no more "null'), it was good or bad battery ?
I'm not sure what you mean with good or bad battery?
The device is using 2 AA alkaline batteries.
When it was showing "lowbattery": null,
there was also a blinking battery symbol on the devices display so the battery was indeed drained.
After changing batteries with a new pair, blinking stopped and now API shows "lowbattery": false,
.
I'm not sure what you mean with good or bad battery?
If you have used full battery it's ok (because we had `"lowbattery": false,) but if you have used empty battery (to simulate a low battery), the value is reversed ^^.
Sorry but apparantly the case isn't closed i'm afraid. When setting the heatsetpoint through API the device for some reason returns the value to the factory default after about 5 seconds. Also the device isn't doing anything anymore when i change the heatsetpoint.
Besides connecting it, and changing battereies i never changed anything on the device itself. Any idea what could cause that behaviour?
command:
curl -X PUT -H "Content-Type: application/json" -d '{"heatsetpoint":'3100'}' http://localhost:8080/APIKEY/sensors/19/config
API response after 1s:
{
"config": {
"battery": 0,
"heatsetpoint": 3100,
"locked": false,
"mode": "off",
"on": true,
"reachable": true,
"windowopen_set": false
},
"etag": "35718a8ed5289073f25bf58c3e7d8e69",
"lastannounced": null,
"lastseen": "2023-08-16T18:56Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat_Bad",
"state": {
"lastupdated": "2023-08-16T18:27:47.669",
"lowbattery": false,
"temperature": 2850
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
}
API respone after 5s:
{
"config": {
"battery": 0,
"heatsetpoint": 1500,
"locked": false,
"mode": "off",
"on": true,
"reachable": true,
"windowopen_set": false
},
"etag": "34afd4accc31ec731f9b1421980aa6ee",
"lastannounced": null,
"lastseen": "2023-08-16T18:56Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat_Bad",
"state": {
"lastupdated": "2023-08-16T18:57:11.039",
"lowbattery": false,
"temperature": 2800
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
}
edit: I didn't change anything in deconz nor the ddfs after my last post, when it was working and the device audibly turned the valve after changing heatsetpoint
Wasn't the max 2700?
Wasn't the max 2700?
Yeah i can only say that when I initially tested it temps where about 2400 or so, so that would explain it. From the docs delivered with the device it says factory default max temp would be 35°C.
edit: when setting it to 2650 it also jumps back to 1500 quickly. But this might be because measured temp is above heatsetpoint? edit2: i will test again when measured temp is lower and report back
"mode": "off",
You haven"t other mode to try ? Something you can try is set it manually on the device, you will see if it work or if the device don't change the mode in same time.
And BTW, note for later : remove the "config/battery".
And this device probably support "preset"
{
"name": "config/preset",
"parse": {"fn": "tuya", "dpid": 4, "script": "tuya_trv_preset.js"},
"write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "script": "tuya_trv_preset_set.js"},
"read": {"fn": "none"}
},
The DDF need to be in the same folder than "tuya_trv_preset_set.js"
"mode": "off",
You haven"t other mode to try ? Something you can try is set it manually on the device, you will see if it work or if the device don't change the mode in same time.
Ok, i tried to change things on the rather complicated UX of the device itself. After doing that i was able to set heatsetpoint without it jumping back, but no changes in 'mode' were observed.
And this device probably support "preset"
{ "name": "config/preset", "parse": {"fn": "tuya", "dpid": 4, "script": "tuya_trv_preset.js"}, "write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "script": "tuya_trv_preset_set.js"}, "read": {"fn": "none"} },
The DDF need to be in the same folder than "tuya_trv_preset_set.js"
After having a look at tuya_trv_preset_set.js
I think maybe it sets itself from manual to auto (with 'auto' maybe not accepting heatsetpoint changes) after a hardcoded time?
I'll try adding the preset lines to the DDF.
I'll try adding the preset lines to the DDF.
Looks like this worked! I get the following API response now:
{
"config": {
"heatsetpoint": 1500,
"locked": false,
"mode": "off",
"on": true,
"preset": "eco",
"reachable": true,
"windowopen_set": false
},
"etag": "3b4532bbd46d39a3e6ce8182e909c1ff",
"lastannounced": null,
"lastseen": "2023-08-17T19:06Z",
"manufacturername": "_TZE200_cpmgn2cf",
"modelid": "TS0601",
"name": "Thermostat 19",
"state": {
"lastupdated": "2023-08-17T19:06:25.881",
"lowbattery": false,
"temperature": 2700
},
"type": "ZHAThermostat",
"uniqueid": "8c:f6:81:ff:fe:a8:86:34-01-ef00"
}
It is possible to change the preset to 'manual' via an API request. So if my hypothesis about 'auto' mode, which i hereby expand to 'eco' mode, is correct it should work now. We'll see!
I will be happy if you can describe the working mode for next time ^^, not something evident for tuya.
In my mind you need to have mode=auto (for the device auto regulate the temperature) and preset=auto too ? But why this device have mode and preset working ? There is not one of them useless ?
So, after waiting for a day just to see if anything changed, the preset 'manual' is still set and i can set the desired heatsetpoint. I'll now use a basic bash script with api requests and some cron entries to do weekday/weekend/day/night 'presets'.
But why this device have mode and preset working ? There is not one of them useless ?
'Mode' seems useless yes. While trying different things on the device again I still didn't get any other value for 'mode' than 'off'. So config/mode can be pruned from the DDF just like config/battery?
So config/mode can be pruned from the DDF just like config/battery?
Yes, surely, so the actual DDF need to be
{
"schema": "devcap1.schema.json",
"manufacturername": ["_TZE200_7fqkphoq", "_TZE200_xby0s3ta", "_TZE200_cpmgn2cf"],
"modelid": ["TS0601", "TS0601", "TS0601"],
"vendor": "Tuya",
"product": "Tuya TRV (MOES)",
"sleeper": false,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_THERMOSTAT",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0xef00"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "state/lowbattery",
"parse": {"fn": "tuya", "dpid": 110, "eval": "Item.val = Attr.val != 0"},
"read": {"fn": "none"}
},
{
"name": "config/heatsetpoint",
"parse": {"fn": "tuya", "dpid": 2, "eval": "Item.val = Attr.val * 10;"},
"write": {"fn": "tuya", "dpid": 2, "dt": "0x2b", "eval": "Item.val / 10;"},
"read": {"fn": "tuya"}
},
{
"name": "config/locked",
"parse": {"fn": "tuya", "dpid": 7, "eval": "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 7, "dt": "0x10", "eval": "Item.val;"},
"read": {"fn": "none"}
},
{
"name": "config/windowopen_set",
"parse": {"fn": "tuya", "dpid": 18, "eval": "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 18, "dt": "0x10", "eval": "Item.val;"},
"read": {"fn": "none"}
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "config/preset",
"parse": {"fn": "tuya", "dpid": 4, "script": "tuya_trv_preset.js"},
"write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "script": "tuya_trv_preset_set.js"},
"read": {"fn": "none"}
},
{
"name": "state/lastupdated"
},
{
"name": "state/temperature",
"parse": {"fn": "tuya", "dpid": 3, "eval": "Item.val = Attr.val * 10;"},
"read": {"fn": "none"}
}
]
}
]
}
It's probably bad since it's my first attemp at writing a bash script with more than 5 lines, but anyways: I published a script you can use to control this devices (and probably other TRVs) settings. Currently there is support for
It was only tested with OPs device on Raspian buster. Needs curl and jq. You can find the script here: https://gist.github.com/llugo/562e080c8ff9e051e67f4fc510f64f56
edit: I'd be glad if someone had a look at it or even could suggest improvements. edit2: i personally have cronjob running this script every morning/evening to set room temp for a specified duration
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
@Smanar my bad all the time i was using above json only, sorry for the confusion. I modified the above json to use the DPID 109 for valve now I see the value in the valve as 1. However on the trv itself I check the valve and it says 50 which is 50% open. According to the manual value of valve could go from 0 to 99 (0 = fully closed and 99 = fully open) On reducing the expected temperature (forcing valve to close) it become 0 in API response.
{ "name": "state/valve", "parse": {"fn": "tuya", "dpid": 109, "eval": "Item.val = Attr.val != 0"}, "read": {"fn": "none"} },
State/valve is a bool, so it can be only true or false, the DPID 109 is a bool too. From z2m for the _TZE200_cpmgn2cf
e.binary('valve', ea.STATE, 'CLOSED', 'OPEN'),
@Smanar is there any way to get this Information? I am happy to do some tests if you want to try out something
But you need to have it using
{
"name": "state/valve",
"parse": {"fn": "tuya", "dpid": 109, "eval": "Item.val = Attr.val != 0"},
"read": {"fn": "none"}
},
This value don't move from true to false ?
This works fine as you described, it is 0 when closed and 1 when open.
I just checked the zigee2mqtt docs and found that valve open percentage is not readable. They have 3 values for this as described below
If all you need is to control on and off, you can set "force" with topic zigbee2mqtt/FRIENDLY_NAME/set.
The payload values are: open -> fully opens valve and stays there close -> fully closes valve and stays there normal -> normal valve operation
Can we achieve something similar?
You have the z2m doc page ? (so much clone with tuya) I m checking again, and I m seing only 2 thing about valve, the valve return, and a "valve detection" request, but this one is a bool too.
@Smanar Here I read about this, Please check Valve detection (switch). https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html
On the other thread I also found that the %valve is being read and displayed in HomeAssistant, I was quite amazed to see that. I have asked for details on the used integration, but I haven't got any response yet. https://community.home-assistant.io/t/zigbee-thermostatic-valve-hy368-weird-behaviour/359358/8
So on your page I can read there is a valve detection but it don't mean "valve position" ? The valve position is the dpid 109 too, it seem we are just checking if this value is 0 or other value. And good new I was wrong again, this field is not a bool but an int so can try
{
"name": "state/valve",
"parse": {"fn": "tuya", "dpid": 109, "eval": "Item.val = Attr.val"},
"read": {"fn": "none"}
},
Perfect, See what i got in the response. Thank you @Smanar
@Smanar I tried a few more tests.
for both config/locked and config/windowopen_set
Do you have the GUI ? If yes, just enable log in deconz (help/debug view with flag info and info_l2 )set the feature manualy on the device, and look in log the dpid used by the device, because I m cheking again and dpid are good 7 and 18 .
for windowopen_set
via api 11:53:06:923 writeTuyaData, dpid: 0x12, type: 0x10, expr: Item.val; 11:53:06:931 Tuya write expression: Item.val; --> true 11:53:17:249 SC state change failed: a4:6d:d4:ff:fe:1f:99:18-01-ef00 11:53:35:537 0x0017880106278811 found group 0x0004 11:53:35:540 0x0017880106278811 found group 0xFFF0 11:53:43:046 sensor 8 (TRADFRI motion sensor): disable presence 11:53:43:446 Set sensor check interval to 1000 milliseconds
change on trv 11:54:05:376 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:05:379 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:05:381 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:05:385 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:05:388 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:05:392 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:17:798 TY_DATA_RESPONSE: seq 692, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:17:800 TY_DATA_RESPONSE: seq 692, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:17:803 TY_DATA_RESPONSE: seq 692, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:17:805 TY_DATA_RESPONSE: seq 692, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:17:808 TY_DATA_RESPONSE: seq 692, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:17:811 TY_DATA_RESPONSE: seq 692, dpid: 0x03, type: 0x02, length: 4, val: 190 11:54:18:817 0x0017880106278811 error APSDE-DATA.confirm: 0xE9 on task 11:54:50:199 0x0017880106278811 error APSDE-DATA.confirm: 0xE9 on task 11:54:56:175 ZCL attribute report 0xEC1BBDFFFEAB7C09 for cluster: 0x0006, ep: 0x0B, frame control: 0x18, mfcode: 0x0000
When you have changed it on the TRV, nothing was returned, dpid 0x03 is only temperature report. And when you have set it using the API, all seem fine, but you have an error message
11:53:06:923 writeTuyaData, dpid: 0x12, type: 0x10, expr: Item.val;
11:53:06:931 Tuya write expression: Item.val; --> true
11:53:17:249 SC state change failed: a4:6d:d4:ff:fe:1f:99:18-01-ef00
You can enable APS log (need APS+APS_l2), you will see something
17:52:56:269 asdu (length: 5): 10C8000000
Will be the raw request, but I m almost sure it will finish by 00 01 12 01 00/01
Your device probably don't support it, or use a different dpid.
I shared here the logs, not sure if this helps. logs.txt
To be honest, if this does not work, its ok. However, I wanted to know if there is any way to open/close the valve from API, without using preset?
Something like force operation is described here. message from francisp https://community.home-assistant.io/t/zigbee-thermostatic-valve-hy368-weird-behaviour/359358/5?u=bchh
https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html
Other set operations are also useful like set schedule set comfort and eco temperature and boost time.
Those TRV are not designed to work like that, to prevent battery drain, it's lazy device. You set a heatpoint and the device work alone and you don't touch it, if you don't like it's regulation, try another TRV.
To know if this device support for exemple the "lock" feature, You need to see it in logs when you use it manualy.
11:54:05:376 TY_DATA_RESPONSE: seq 691, dpid: 0x03, type: 0x02, length: 4, val: 190
It's the dpid 0x12 for the "lock"
We can use too the 'config/unoccupiedheatsetpoint' to set a second heatpoint, but IDK how work this device. Do you want to use comfort or eco ? it work with preset ?
In the post above for z2m it is the same trv being used and they have implemented the force opening/closing the valve. How do you conclude that trv is not designed to work like that?
I used preset (set via API )and they work as expected, no issues there. Setting a schedule is something I was looking for, and setting a temperature for eco/comfort.
Anyways the main question here is to control the valve forcefully, sample below from z2m.
If all you need is to control on and off, you can set "force" with topic zigbee2mqtt/FRIENDLY_NAME/set.
The payload values are:
open -> fully opens valve and stays there
close -> fully closes valve and stays there
normal -> normal valve operation
{
"force": "open"
}
How do you conclude that trv is not designed to work like that?
Just make a try yourself.
The "force" mode is the dpid 106, type enum, value 0 - normal, 1 - open, 2 - close So for test can try
{
"name": "config/interfacemode",
"parse": {"fn": "tuya", "dpid": 106, "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 106, "dt": "0x30", "eval": "Item.val;"},
"read": {"fn": "none"}
},
I m agree "config/interfacemode" is ugly, but mode and preset are already used, and the one resting are not famous, make a test, create a new field will be easier after, on last DDF version you can create "custom" field.
But it 's just a mode, like 0 - auto, 1- heat, 2 - off
Edit Ha, I have see you miss the config/mode in this DDF. Can mimic this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/tuya/_TZE200_TS0601_trv.json
I'm also interested to get the _TZE200_cpmgn2cf working with deconz. I also have the Tuya Zigbee hub running with the tuya adapter on iobroker. If relevant for support I can share data points generated by the tuya dapter in iobroker...
Hello can try this DDF It''s an updated one, with the "mode" feature to enable auto/manu/off
{
"schema": "devcap1.schema.json",
"manufacturername": ["_TZE200_7fqkphoq", "_TZE200_xby0s3ta", "_TZE200_cpmgn2cf"],
"modelid": ["TS0601", "TS0601", "TS0601"],
"vendor": "Tuya",
"product": "Tuya TRV (MOES)",
"sleeper": false,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_THERMOSTAT",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0xef00"
],
"meta": {
"values": {
"config/mode": {"auto": 0, "heat": 1, "off": 2}
}
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "state/lowbattery",
"parse": {"fn": "tuya", "dpid": 110, "eval": "Item.val = Attr.val != 0"},
"read": {"fn": "none"}
},
{
"name": "config/heatsetpoint",
"parse": {"fn": "tuya", "dpid": 2, "eval": "Item.val = Attr.val * 10;"},
"write": {"fn": "tuya", "dpid": 2, "dt": "0x2b", "eval": "Item.val / 10;"},
"read": {"fn": "tuya"}
},
{
"name": "config/locked",
"parse": {"fn": "tuya", "dpid": 7, "eval": "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 7, "dt": "0x10", "eval": "Item.val;"},
"read": {"fn": "none"}
},
{
"name": "config/windowopen_set",
"parse": {"fn": "tuya", "dpid": 18, "eval": "Item.val = Attr.val;"},
"write": {"fn": "tuya", "dpid": 18, "dt": "0x10", "eval": "Item.val;"},
"read": {"fn": "none"}
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "config/preset",
"parse": {"fn": "tuya", "dpid": 4, "script": "tuya_trv_preset.js"},
"write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "script": "tuya_trv_preset_set.js"},
"read": {"fn": "none"}
},
{
"name": "config/mode",
"values": [
["auto", 0], ["heat", 1], ["off", 2]
],
"parse": {"fn": "tuya", "dpid": 106, "eval": "if (Attr.val == 0) { Item.val = 'auto' } else if (Attr.val == 1) { Item.val = 'heat' } else { Item.val = 'off' }"},
"write": {"fn": "tuya", "dpid": 106, "dt": "0x30", "eval": "if (Item.val == 'auto') { 0 } else if (Item.val == 'heat') { 1 } else { 2 }"},
"read": {"fn": "none"}
},
{
"name": "state/valve",
"parse": {"fn": "tuya", "dpid": 109, "eval": "Item.val = Attr.val"},
"read": {"fn": "none"}
},
{
"name": "state/lastupdated"
},
{
"name": "state/temperature",
"parse": {"fn": "tuya", "dpid": 3, "eval": "Item.val = Attr.val * 10;"},
"read": {"fn": "none"}
}
]
}
]
}
Device
Screenshots
Endpoints and clusters of the node
Node Info panel
Additional Notes
Since there is a "Generic Tuya TRV DDF" (https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6829) which I unsuccessfully tried to load on the device, I thought I'd give it another chance here.
It was bought here: https://www.aliexpress.com/item/1005002212605653.html?spm=a2g0o.order_list.order_list_main.5.54a85c5fRUkOms&gatewayAdapt=glo2deu