Saswell SEA801-Zigbee TRV

[rotragit]

Device

• Product name: SEA801-ZIGBEE TRV
• Manufacturer: SASWELL.
• Model identifier: SEA801-ZIGBEE.
• Device type : Please remove all unrelated device types.
  • Thermostat (TRV)

This is a TRV valve from Saswell. Joined deconz using Phoscon -> Sensors. Attached is the screenshot, no useful information seem to be present in other clusters.

Attached SEA801.zip with sniffing the operations when connected to a Tuya Zigbee Gateway. Room temperature was 28°C. Temperature in the filenames are without the comma (200 = 20.0°C, 165 = 16.5°C).

At the moment I have a Tuya Zigbee Gateway, but it's not mine. I was unable to find the Netwok key while sniffing. Could it be it's not encrypted?

SEA801.zip

[Smanar]

Your device seem exactly like this one https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3024 Just another model + brand, do you have the manufacture code ?

[rotragit]

I don't know why/how I closed the issue :-)

No, I don't have the manufacturer code. Ok, I'll give a try with

git clone --branch tuya https://github.com/Smanar/deconz-rest-plugin.git

Found the transport key, anyway :-)

[Smanar]

Wait need to add your model id at code first. And just to be sure,if we can have the manafacture code, on "node info" panel.

[rotragit]

0x0000 ?

Same as Tuya Smart TRV HY369.

[Smanar]

Ok so yes it s exactly the same device. I have updated the code for your device, you can try it.

For issue (for exemple loosing the device after a restart) I think you will find information on the main issue https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3024

[rotragit]

I use a docker image. Anyway I complied the plugin and I've moved on the docker image. Restarted the container but with the new plugin the device doesn't pair anymore. I've revert to the original plugin and the device pair again.

It's enough I sniff the traffic to detect the problem o you prefer I setup a fresh installation (not in docker) and give you also the debug logs?

[Smanar]

Not possible the code block the device integration ... it make the inclusion in the API possible, but can't prevent the device be added in deconz itself. I can be wrong for the inclusion in the API, but strange it don't appear in deconz.

You are using this branch ?

git clone --branch tuya https://github.com/Smanar/deconz-rest-plugin.git

And yes if you realy have a problem, I think log will be more usefull than sniff. The inclusion is not easy , for exemple > https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3024#issuecomment-658291972 I think he make 2 inclusions, without deleting the first one.

[rotragit]

Yes, I'm using that branch. With the plugin included with the docker image the pairing it's easy. The device shows a wireless icon when it's paired, so there is no doubt about that, and Phoscon ends with "Ready". The device is then present in the deconz interface. No difference if the device was already paired. Using the compiled branch the device do not turn with the wireless icon on, Phoscon ends with "Scan failed" and the device is not in deconz. Tomorrow I'll setup a local installation of deconz and I will check if the behavior is the same. And I'll post logs if the case :-) Thank you.

[vegetate7]

Did you replaced "general.xml' file as well? I'm not sure, is it necessary, btw..

[rotragit]

Ok, it was a version problem between the pc where I compile and the vesion in the docke image. Deconz is 2.05.79 in docker and the running linux is Debian 9. My local instalation was 2.05.78 on a Ubuntu installation. I've recompiled in the docker image anyway, and the pairing is now ok. Anyway in HA the temperature is not read and no command seems to operate the device. But I go back to sleep for the moment :-)

[Smanar]

Can you show me the JSON generated for this device pls ?

If you have "temperature" field in the Json, If you enable deconz log, you will find in it

Tuya debug 4 :xxxxxxxxxxxxxxxx Tuya debug 5 : xxxxxxxxxxxxxxxx

With information SEND by the device, so if the temperature is still not displayed, can you give me those line, pls ?

[rotragit]

"20": { "config": { "heatsetpoint": 2250, "offset": 0, "on": true, "reachable": true, "scheduler": null, "scheduleron": null }, "ep": 1, "etag": "b8b4c8adfa218158842329843daf689c", "lastseen": "2020-08-04T19:01:57.956", "manufacturername": "_TYST11_KGbxAXL2", "modelid": "GbxAXL2", "name": "GbxAXL2", "state": { "lastupdated": "none", "on": null, "temperature": null }, "swversion": "20180727", "type": "ZHAThermostat", "uniqueid": "ec:1b:bd:ff:fe:2c:60:5b-01-0201" }

But the messages seem ok:

18:14:07:159 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000aa 18:14:07:159 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 170 18:15:21:152 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:15:21:152 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:15:42:908 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000aa 18:15:42:908 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 170 18:15:46:670 Tuya : debug 218:15:46:686 DB save zll database items 0x00000001 18:16:30:343 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00076c01000101 18:16:30:343 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 Fn: 0 Data 1 18:16:31:238 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000266020004000000f7 18:16:31:238 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 247 18:16:32:250 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:16:32:250 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:17:37:148 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:17:37:148 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:18:06:849 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00076c01000100 18:18:06:849 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 Fn: 0 Data 0 18:18:07:856 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:18:07:856 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:18:16:223 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00016501000100 18:18:16:223 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 Fn: 0 Data 0 18:18:17:233 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:18:17:233 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:18:28:828 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00016501000101 18:18:28:828 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 Fn: 0 Data 1 18:18:29:836 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:18:29:836 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:18:30:848 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00026602000400000101 18:18:30:848 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 257 18:18:38:660 Tuya debug 77 18:18:43:134 Tuya debug 77 18:18:48:741 Tuya debug 77 18:18:53:741 Tuya debug 77 18:18:58:534 Tuya debug 77 18:19:04:126 Tuya debug 77 18:20:01:387 Tuya : debug 218:20:01:709 poll node 00:04:74:00:00:a1:32:f0-01 18:20:31:198 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00026602000400000107 18:20:31:198 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 263 18:22:51:187 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 0002660200040000010d 18:22:51:187 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 269 18:27:51:191 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00026602000400000107 18:27:51:191 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 263 18:31:11:214 Tuya : data length excess 18:31:11:214 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000973000018191818181818181718000000000000000000000000000000 18:31:11:214 Tuya debug 5 : Status: 0 Transid: 9 Dp: 115 Fn: 0 Data 421009432 18:31:12:232 Tuya : data length excess 18:31:12:232 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000d6e000018101010101010101010000000000000000000000000000000 18:31:12:232 Tuya debug 5 : Status: 0 Transid: 13 Dp: 110 Fn: 0 Data 269488144 18:31:13:239 Tuya : data length excess 18:31:13:239 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 001177000018000000000000000000000000000000000000000000000000 18:31:13:239 Tuya debug 5 : Status: 0 Transid: 17 Dp: 119 Fn: 0 Data 0 18:32:51:198 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00026602000400000101 18:32:51:198 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 257 18:36:06:260 Tuya debug 77 18:39:50:213 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 0002660200040000010b 18:39:50:213 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 267 18:44:51:190 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00026602000400000105 18:44:51:190 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 261 18:50:31:200 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000266020004000000ff 18:50:31:200 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 255

"debug 77" is when I try to on/off or set temperature in HA.

[Smanar]

I don't see temperature return from the device, Temperature => dp = 515 On your you have : 614 > Unknow 615 > Unknow 115 > Unknow t 110 > Unknow 119 > Unknow

So I think your device don't use same value ^^.

I think the 614 is the heatpoint temperature (514 on the code ATM) 615 is the temperature mesured, 17 degre can be possible as value ? 364 or 357 the mode ?

Seriously ok to use non standard cluster/value, but they can use same value for all their devices ...

[vegetate7]

From my code converted from Z2M

    case 614 { #// 0x6602 min temperature limit
        return {'0x6602 min_temperature' => dataAsDec($data_)};
      }
    case 615 { #// 0x6702 max temperature limit
        return {'0x6702 max_temperature' => dataAsDec($data_)};
      }

But it usually quite 'round' values. Can it be manufacturer trick? To force to buy they gateway?

[rotragit]

18:39:50:213 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 0002660200040000010b 18:39:50:213 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 267

That is the room temperature: 26.7*C. This data is sent fom the device when it changes.

18:14:07:159 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000aa 18:14:07:159 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 170 18:15:21:152 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000a0 18:15:21:152 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 160 18:15:42:908 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000aa 18:15:42:908 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 170

That is the temperature I set on the device and the device send to the gateway (after 2 seconds).

From the z2m group, and confirmed when I sniffed some time ago:

0) ?? -> one more byte before your payload shoud be message type: 36 = heartbeat, 2 = anything else, 1 = ? 1) 00 -> ? 2) 03 -> if message type = 2: 1=turn on / turn off, 2=attReport, 3=devChange (temp), 7=mode change (mode), 9=program mode, 3) 13=program mode, 17=program mode 4) 67 -> subtype message 5) 02 -> 0 = program, 1 = heating mode, 2 = all the rest 6) 00 -> ? 7) 04 -> 1 = change on device, 4 = report 8) 00 -> 0 = manual, 1= auto 9) 00 -> ? 10) 00 -> 0 = tempeature message 11) aa -> temperatue*10

Dp value in your decode are bytes 4 and 5 read as a single number. Not caring the semantic too much I think there is no operational difference. And I don't know if other Tuya TRV use the same schema or not, so....

On the z2m group somebody posted a google sheet with some decodes. It's fair to link here?

[Smanar]

Sure it s open source project too ^^ On my side I m using https://medium.com/@dzegarra/zigbee2mqtt-how-to-add-support-for-a-new-tuya-based-device-part-2-5492707e882d

But I m not understand why you haven't same value ! On this device it seem Dp: 614 > temperature Dp: 615 > setpoint And not min/max max temperature limit. There is something wrong on Z2m or it s device depend ? I can add both, but need to be sure.

And BTW 000367020004000000aa 00 > status 03 > transid 6702 > dp (reversed) 00 > fn 04 > data lenght 000000aa > data

[vegetate7]

And BTW 000367020004000000aa 00 > status 03 > transid

Look, in @rotragit logs lot of records with same 'transid'. While in #3024 the 'transid' incrementing.

[Smanar]

I don't think the incrementation is forced, we don't do it with deconz,

transid: Seems to have the same purpose as the Transaction Sequence Number. Its purpose is to relate two or more frames as participants of the same sequence. e.g., A command 0x02 emitted by the ZED in response to a command 0x00 received from the ZC will have the same transid number.

If the device send itself response from it s own initiative, for me he can use the same value, up the next command.

On his log, it's 3 time the same DP, perhaps the device keep the same transid, up to a different Dp, ...

But yes, right, there are all < 10, and always the same, even on 2 diffrent logs strange, so 2 different protocols ? I have find the protol https://docs.google.com/spreadsheets/d/1BaKJdkmumf3S8rP4JfhNATyeryAGX9wh416llWWFACQ/edit#gid=0 but not sure it s right because the payload is compatible too with the one we are already using.

He said for exemple

04 -> 1 = change on device, 4 = report

But it s strange, this value is exactly the data size, and nothing to see with report or change. For me his interpretation is not good.

[rotragit]

@Smanar thank you for the article.

For me his interpretation is not good.

Yes, I agree after reading the article. Anyway, the semantic of the payload is device dependent?

[rotragit]

Looking at the tuya documentation https://docs.tuya.com/en/iot/configure-in-platform/function-definition/define-product-features?id=K97vug7wgxpoq I understand the device can implement standard functions, custom functions or cloud functions.

So yes, even if two devices are TRV they could implement different custom functions (or one use standard functions and the other not).

Looking very fast at the documentation I don't find standard functions examples for TRV anyway. So it's possible that every manufacturer define its own set of functions.

[vegetate7]

So perhaps there will be a full Zoo of Tuya devices.

[rotragit]

I guess that for most devices (switches, bulbs, ...) they use standard functions. But yes.... Anyway we have an explanation of why the messages are not the same...

[Smanar]

So perhaps there will be a full Zoo of Tuya devices.

Harrr nooo, a nightmare ......

But what to do ? @vegetate7 you have the basic device, do you have ever see a dp = 614 or 615 ? z2m can be wrong here too.

I will add dp from @rotragit device (realy fast modification) , if you are using them too, I will add a model id check

But we need to know which one is the "mode" dp ? for me its 364 or 357.

[rotragit]

@Smanar this device is not yet implemented in z2m......

[vegetate7]

But what to do ? @vegetate7 you have the basic device, do you have ever see a dp = 614 or 615 ? z2m can be wrong here too.

Yes. In my case those are 'min' and 'max' temperature limits

$ grep -e 'Dp: 614' -e 'Dp: 615' deconz.first_start.log 
20:37:27:481 Tuya debug 5 : Status: 47 Transid: 128 Dp: 614 Fn: 0 Data 5
20:37:28:485 Tuya debug 5 : Status: 47 Transid: 129 Dp: 615 Fn: 0 Data 35
20:39:16:663 Tuya debug 5 : Status: 8 Transid: 141 Dp: 614 Fn: 0 Data 5
20:39:17:111 Tuya debug 5 : Status: 8 Transid: 141 Dp: 614 Fn: 0 Data 5
20:39:17:566 Tuya debug 5 : Status: 8 Transid: 141 Dp: 614 Fn: 0 Data 5
20:39:18:475 Tuya debug 5 : Status: 8 Transid: 142 Dp: 615 Fn: 0 Data 35

[Smanar]

pffff

Ok so I have updated the code if you can try @rotragit , you will have temperature and setpoint

I take the first tuya device as "standard base" all other will be "special one" and will need specific checks.

Can you see the deconz log when using "mode" manualy ? if possible ?

[rotragit]

From manual to auto: 19:30:41:574 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00076c01000101 19:30:41:574 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 Fn: 0 Data 1

I guess these are programmed time: 19:31:12:083 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000973000018171617171717171717170000000000000000000000000000 19:31:12:083 Tuya debug 5 : Status: 0 Transid: 9 Dp: 115 Fn: 0 Data 387323671 19:31:13:095 Tuya : data length excess 19:31:13:095 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000d6e000018101010101010101010100000000000000000000000000000 19:31:13:095 Tuya debug 5 : Status: 0 Transid: 13 Dp: 110 Fn: 0 Data 269488144 19:31:15:117 Tuya : data length excess 19:31:15:117 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 001177000018000000000000000000000000000000000000000000000000 19:31:15:117 Tuya debug 5 : Status: 0 Transid: 17 Dp: 119 Fn: 0 Data 0

From auto to manu: 19:32:40:791 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00076c01000100 19:32:40:791 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 Fn: 0 Data 0

From on to off: 19:33:30:914 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00016501000100 19:33:30:914 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 Fn: 0 Data 0

From off to on: 19:34:06:483 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00016501000101 19:34:06:483 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 Fn: 0 Data 1

In HA I see now room temp and set temp. But I cannot change set temp.

[Smanar]

Ok so have updated the code again (can set temperature and mode), but I have a problem, from HA and for other device the mode can be "auto", "heat" and "off".

So if you set your device from "off" to "on", it mean "heat" ? and the other state is automaticaly switch to "manual" if it was on "auto" previously ?

You are sure it s not valve state, instead of "mode" ?

[rotragit]

If I set from off to on it returns to the last state "auto" or "manual".

I try your code today. Thank you :-)

On Fri, Aug 7, 2020 at 7:59 PM Smanar notifications@github.com wrote:

Ok so have updated the code again, but I have a problem, from HA and for other device the mode can be "auto", "heat" and "off".

So if you set your device from "off" to "on", it mean "heat" ? and the other state is automaticaly switch to "manual" if it was on "auto" previously ?

You are sure it s not valve state, instead of "mode" ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3109#issuecomment-670638659, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSG4VVNJYLOTVGEMR3KHYTR7Q6HNANCNFSM4PR5ZCMQ .

[rotragit]

Runs ok! The only problem is that there is no way to go from "auto" mode to "manu" mode, When it's on "auto" mode, pressing the middle icon has no effect. When it's "off", pressing the middle icon turns on and the valve is in the previous state (auto or manu).

EDIT: and the mode is always "spento" inthe UI. I get an error when operating the valve from HA:

/sensors/20/config/mode parameter, mode, not available 07:23:30 – Home Assistant WebSocket API (ERROR) - il messaggio si è verificato per la prima volta alle 07:03:35 e compare 35 volte

the error if shown every time I change temp of switch to off/on, even if the valve receives the message.

[Smanar]

Ha yep you miss some information (the field "mode "in the json for exemple), perhaps it can be solved with including again the device without deleting it. Else I have add something in the code to help you with this field, but not sure it will work.

If I set from off to on it returns to the last state "auto" or "manual".

So we will have a problem, I think I will set myself the device to "auto" after manipulation.

[rotragit]

I have already joined again. But I can delete the node and join.... again :-)

[Smanar]

I think it s better to not delete it, I don't think deconz clear the data, so the second inclusion can use the previous one.

[rotragit]

I cleaned zll.db, cleaned from HA, deleted the node, reset the device, repaired and now it's working. Except that I'm unable to switch to manu anyway. I think a good solution is to set manu when the "heat" icon is pressed (so if coming from off it goes on and manu). There is also a "on" status when setpoint is grater tham room temperature. But as far as I can see from the logs there is not any message sent by the device.

[vegetate7]

I think a good solution is to set manu when the "heat" icon is pressed

Look at the #3024 discussion about modes. The device (at least HY369 and HY369RT, and perhaps HY368) have two kind of "modes". One we named "preset" - is what you switch on device: "manual", "auto", "holiday", "eco", "conffort".. Those modes operating on setHeatPoint. and can not be set from HA gui, only from REST API.

And second we named "mode" but device named it as "forced", which are "Forced on", "Forced off" and "Auto". Those modes operating on valve directly ("Forced On" and "Forced Off") or passing valve control to presets ("Auto"). And those modes CAN be set from HA Thermostat Lovelace card.

[Smanar]

But there isn't "manu" mode in your capture. The mode avaiblable in the widget are "auto" "heat" and "off" so for me

auto > regulation by temperature => tuya mode = 'auto' heat > valve on off > valve off AND tuya mode "off" (the second part is not yet in code)

[rotragit]

Looking at the behavior with the tuya gateway, in auto mode the valve works with the programming timers (preset setpoints at given time in the day). When in manu mode it works only with the temperature setpoint. If I press the leftmost icon in the widget the valve switch to auto. But there is no way to switch back to manu. When the valve is using the timers, it will revert to the setpoint programmed temperature when the corresponding time is reached.

heat -> valve on means the valve is fully open? If you mean that my valve doesn't act like that. The "on" in that sense is set on the valve incrementing the setpoint over 30°C and the display show "on". But there is not a specific message sent by the device:

01:11:54:100 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000266020004000000fc 01:11:54:100 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 Fn: 0 Data 252 01:12:09:649 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 000367020004000000c8 01:12:09:649 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 200 01:12:59:098 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 0003670200040000012c 01:12:59:098 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 300 01:13:04:097 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 0003670200040000012c 01:13:04:097 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 Fn: 0 Data 300

The before last message is I set the setpoint to 30°C, the last message when I press one more time to increment the setpoint and the valve writes "on" on the display.

So, at the moment, with the rightmost icon the valve goes off (the valve pin is fully out so the radiator is closed). The "heat" icon switch the valve "on" but not in the sense that the pin is fully in and the radiator is fully open but in the sense that the valve is operating in the last state (that is auto or manu as it was before the "off" command). And the leftmost icon switch to "auto" mode (timers are used). No way to switch to "manu" mode.

Buttons layout on the valve are very different from the HY369:

[rotragit]

Also this device has min_temp 5 and max_temp 30 instead of 7 and 35.

[vegetate7]

Try long press on "+" or "-" buttons. on HY369 it is direct valve control (open or close)

[Smanar]

heat -> valve on means the valve is fully open? If you mean that my valve doesn't act like that. The "on" in that sense is set on the valve incrementing the setpoint over 30°C and the display show "on". But there is not a specific message sent by the device:

Yep "heat" is a forced working mode, lot of device just set the heatpoint at temperature > 30. But they came back at previous temperature after a timer itself, else this feature is useless and need to be managed by HA. direclty, because deconz don't memorise previous value, and don't use timer.

So, at the moment, with the rightmost icon the valve goes off (the valve pin is fully out so the radiator is closed). The "heat" icon switch the valve "on" but not in the sense that the pin is fully in and the radiator is fully open but in the sense that the valve is operating in the last state (that is auto or manu as it was before the "off" command). And the leftmost icon switch to "auto" mode (timers are used). No way to switch to "manu" mode.

So "heat" make the setpoint to 30, and the mode to "auto" ?

So to resume your devive have

• auto mode > use preset
• manu mode > use setpoint temperature
• off > ? , mode =auto or manu ? valve = off ?
• Heat > ?

I realy don't understand how work your device, but in HA you have 3 mode "auto" "off" heat, I just need to know which one command you want deconz send to device when you use this mode.

Or I can just ignore this setting, you have a filed "valve" too (but not enabled yet), and a field "preset" like have said @vegetate7 that can use "auto" and "manu". So I can remove the "mode" and you can use "valve" and "preset" but not managed by HA ATM, so you will need to use "custom command"

[rotragit]

Yep "heat" is a forced working mode, lot of device just set the heatpoint at temperature > 30.

That is "boost mode". This device doesn't have a boost mode. Anyway I have never seen the "heat" icon in HA to act as "boost mode". In air conditioning not for sure (doesn't exists boost mode in air conditioning) and I have several EQ3 Max! valves and with the integration in HA the "heat" icon is to set manual operating mode.

So "heat" make the setpoint to 30, and the mode to "auto" ?

No, "heat" just turn the valve in a operating mode (on, but not in the meaning the valve is fully open. The valve remember the previous state and setpoint temperature and if coming from "off" state it will restore it). Mode is not affected, it's restored the previous operating mode.

The device works this way:

auto mode -> use presets manu mode -> use setpoint temperature off -> doesn't affect mode, turn off the valve, when back the valve restores the pervious mode and setpoint

So in HA I think the best should be:

off -> like it's now, that's ok and it turns off the valve Heat -> send two messages (if possible), turn on and set manu mode:

10:01:10:435 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00016501000101 10:01:10:435 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 Fn: 0 Data 1 10:01:12:557 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00076c01000100 10:01:12:557 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 Fn: 0 Data 0

auto -> send two messages (if possible), turn on and set auto mode:

10:04:03:798 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00016501000101 10:04:03:798 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 Fn: 0 Data 1 10:04:08:744 Tuya debug 4 : Address 0xEC1BBDFFFE2C605B Payload 00076c01000101 10:04:08:744 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 Fn: 0 Data 1

Is that possible?

@vegetate7 no, if I log press "+" or "-" the setpoint seek up or down. The only way to go to "on" is to go over 30°C, and then the valve stay there, it is not a boost mode....

This device is not the HY369 device repackaged in a different format. It's completely different and they share only the tuya protocol (but not the function definition in messages, as we have seen).

I'm not sure it's the right way to derivate all Tuya TRV on the HY369, because the devices are very different. Ina object oriented programming view I probably write an abstract Tuya class, a TRV interface and every device should derive from the abstract class and implement the given interface. Java speaking ;-) But that is only my (questionable) opinion.

[Smanar]

Done, you can try

                        if (mode_set == "auto")
                        {
                            ok = SendTuyaRequest(task, TaskThermostat , 0x0165 , QByteArray("\x01",1) ) // turn valve on
                            ok = ok && (SendTuyaRequest(task, TaskThermostat , 0x016c , QByteArray("\x01",1) )) // Set mode to auto
                        }
                        else if (mode_set == "heat")
                        {
                            ok = SendTuyaRequest(task, TaskThermostat , 0x0165 , QByteArray("\x01",1) ) // turn valve on
                            ok = ok && (SendTuyaRequest(task, TaskThermostat , 0x016c , QByteArray("\x01",0) )) // Set mode to manu
                        }
                        else if (mode_set == "off")
                        {
                            ok = SendTuyaRequest(task, TaskThermostat , 0x0165 , QByteArray("\x01",0) ) // turn valve off
                        }

[rotragit]

@Smanar missing some ';' at the end of your lines before the comments

[Smanar]

missed, ..., thx

You have corrected them on your side too ?

[rotragit]

Yes, but I test this night when back at home :-)

[rotragit]

@Smanar ok, just some little corrections:

in tuya.cpp, lines 149,150, to reflect auto/manu state in HA:

                   if (data == 0) { mode = "heat"; } // was "manu"
                    if (data == 1) { mode = "auto"; } // back to "auto"

in rest_sensors.cpp, lines from 1180 (QByteArray inverted arguments):

else if (sensor->modelId().startsWith(QLatin1String("GbxAXL2")))
                    {
                        QString mode_set = map[pi.key()].toString();
                        bool ok = false;

                        if (mode_set == "auto")
                        {
                            ok = SendTuyaRequest(task, TaskThermostat , 0x016c , QByteArray("\x01",1) ); // Set mode to auto
                            ok = ok && (SendTuyaRequest(task, TaskThermostat , 0x0165 , QByteArray("\x01",1) )); // turn valve on
                        }
else if (mode_set == "heat")
                        {
                            ok = SendTuyaRequest(task, TaskThermostat , 0x016c , QByteArray("\x00",1) ); // Set mode to manu
                            ok = ok && (SendTuyaRequest(task, TaskThermostat , 0x0165 , QByteArray("\x01",1) )); // turn valve on
                        }
                        else if (mode_set == "off")
                        {
                            ok = SendTuyaRequest(task, TaskThermostat , 0x0165 , QByteArray("\x00",1) ); // turn valve off
                        }
                        else
                        {
                            rspItemState[QString("error unknow mode for %1").arg(sensor->modelId())] = map[pi.key()];
                        }

                        if ( ok )
                        {
                            updated = true;
                        }
                    }

Now the device is working great!!! There is a short delay when coming from off state and switching to manu/auto due to the two messages sent to the device. But there is no solution and it's just 1 second. If you update your code I can clone again it just to be sure all is ok.

EDIT: inverted order of messages, first set auto or manu and then on

[Smanar]

As you want I can make correction my self, or you can make a PR on my fork, like this the modification will be on your Username ?

And yes, the device is on battery so less reactive than powered device, I don't think it s possible to do better.

[rotragit]

Well, you've done 99.99999999999999% of the job. For me it's ok if you make the corrections. I don't need to have my name anywhere :-)

And I really would like to pay a beer for you, if you have a way to give me a paypal address or any other way :-)

[Smanar]

But my name is already in the project ^^. Even you do 0.1%, you do something (the multiples compilations/tries for exemple), some other realy do nothing.

And thx, but no link for beer yet ^^.

Code updated.

[rotragit]

thank you @Smanar ^^