MOES Zigbee Radiator Actuator HY368

[schoven]

See #3024, similar device

Was told to create a new issue, so here we go:

Device

• Product name: MOES Zigbee Radiator Actuator.
  - specs on package:
  

• Manufacturer: _TZE200_ckud7u2l

• Model identifier: TS0601

• Device type :

  • Sensor
  • Thermostat

Screenshots

[GuillaumeP01]

hello I am also interested to have this trv in deconz because I have 10 to install. I am available for testing if needed.

[GuillaumeP01]

zigbee2mqtt side, they have already successfully integrated [https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html]
if that helps.

[Smanar]

But this device is already in deconz ?
I m seing it in the code ATM, It will be in version 80 I think.

Have you tried to compile the last code ?

Edit:

Sorry we have missed it, not the same mac adress.

Can you try with this code ?

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

[GuillaumeP01]

@Smanar
hello thank you for your feedback. I'm starting with homeassistant. is your fork usable with homeassistant? if so how to put it? Thanks for your help.

[Smanar]

You can do nothing with HA, except if you are engineer ^^.
You haven't another machine with a real Unix OS to make test ?

[GuillaumeP01]

for testing I can mount a virtual machine with debian. once tested will this be added to the HA plugin?

[Smanar]

I don't think you can replace yourself the file in HA, when you compile it, the result file is hardware/software specific.

But If you can validate the modification, it will be added in next deconz version and too in next HA plugin version. Unfortunately for you the version 80 will be out soon, so I think the modification will be on version 81.

[GuillaumeP01]

thank you for this clarification I can wait for a new version it's not a problem.

[Smanar]

You have the procedure on github homepage https://github.com/dresden-elektronik/deconz-rest-plugin at "Install deCONZ development package (optional, Linux only)"

Just replace the step 1 by
git clone --branch tuya2 https://github.com/Smanar/deconz-rest-plugin.git

[GuillaumeP01]

great, thank you.
you anticipated my request
do you have to install a debian with a display server or a simple debian netinst is OK?

[Smanar]

Ha good question, never tried netinst.
As you want, the desktop is realy usefull to use deconz, but I think your device will work itself, for me it s same device just with different mac adress, so the faster/easyer way will be the better.

[GuillaumeP01]

it's good i installed everything you asked for.
what should i check now?

[Smanar]

If you have finished all the procedure, the last thing is a file replacement.

So you can remove the conbee from your production network for some time, plug it on the machine where you have the custom deconz version, and try to include the device.

For information IDK wich one devices you have on your production network, but some of them like xiaomi don't like to be out of network too long time. So if it take too long time, better to use the backup/restore feature in phoscon to make a "network clone" when you make your tries.

[GuillaumeP01]

indeed I noticed that the xiaomi sensors disconnect quickly.
i have included the TRV from phoscon from the sensor page. inclusion OK and TRV recognized in deconz as TS0601

do you need anything else?

[Smanar]

Yep, just use it ^^, to check if you miss something.
If all is working, I will make the PR

for this device you have at least.

• low battery
• mode
• actual temperature
• setpoint
• preset (but complicated to use)

[GuillaumeP01]

Thank you for guiding me through all of these steps.

How do I check the information I receive from the TRV in deconz because it is not visible in phoscon?
Obviously there must be information:
child lock
window detection
valve detection
% battery
fashions
local temperature
current heating setpoint

And how do you send, for example, a new temperature setpoint?

[GuillaumeP01]

I did an integration in jeedom and here is the result:

Control of the setpoint: OK
on the other hand, the possible range is 5 to 35 ° C and the piloting generates an error beyond 32 ° C
Switch on / off: OK

I continue my tests but it seems super promising to me

[GuillaumeP01]

this is missing:

• child lock (info and action)
• window detection (info and action)
• % battery

is it possible to add them?

[Smanar]

Ha you are from jeedom ? first time I see some one testing a thermostat on it ^^
BTW, if the plugin don't support all feature yet, you have a button to display node (noeud), inside you will see all fields, even the one the plugin don't use yet.

You have a "lowbattery" filed , this device don't provide a battery level (or haven't see it yet).
For the 2 other I can add them, but are you sure you need them ?

[GuillaumeP01]

Do you have a screenshot to display the nodes and see all the fields?
For the 2 missing fields I think so.
For children it's pretty good and the detection of window opening I think it's useful too.

[GuillaumeP01]

by the way, is it possible to rename the devices in deconz to find them more easily when they are not displayed in phoscon?

[Smanar]

I think they called that "informations brutes" > https://community.jeedom.com/t/deconz-sondes-aqara-recuperer-des-informations-brutes/22467

The children protection was already in the Json, have added the window open state
Children protection > config/locked
Windows > state/windowopen

You need te include the device again to enable the window, no need to delete it.

[GuillaumeP01]

yes indeed I found the raw information in jeedom. I was thinking more of the raw deconz info.
in the raw jeedom info the child lock goes back up after adding a new info command and 2 action commands
On the other hand, I do not see the window detection?

[Smanar]

the child lock goes back up after adding a new info command and 2 action commands

It mean it works or not ?

And no, the windows detection is not here, you have tried to re-include the device ?
And the lowbattery is blocked at "null" ? After some time you need to have true or false.

[GuillaumeP01]

Sorry that was not clear but yes the child lock works with the addition of commands.

I tried to re-include the valve but it didn't change anything.

The low battery is still stuck at null despite more than 3 hours of testing.

[Smanar]

Ok there is something strange, the fileld "state/windowopen" is created in same time than the "config/preset", I don't see why it s not displayed, there is a mistake in the code (bool / string mistake) but even with that, the field need to be displayed.

For battery, it s device dependent, I will enable the battery level tomorrow for your to check if this one have it.

[GuillaumeP01]

OK fine

For information there is a parameter which is not very explicit and which has 2 possible actions (on / off) is it maybe this but which is badly recorded? see screenshot


I do not see any refresh or update possible, is this normal?

by the way, is it possible to rename the devices in deconz to find them more easily when they are not displayed in phoscon?

[ebaauw]

As with any Zigbee sensor, the state attributes are read-only. on is derived from valve >0.

To change the name, use the API. Do a PUT to /sensors/21 with a body of {"name": "Cool New Name"}.

[Smanar]

@andye2801 rememebr you need to make 2 inclusion/pairing without deleting the device to correclty include it.
Can you share some screenshoot if you still have problem (from the VNC map or check the model id)

[andye2801]

This is the device in the VNC map. I do believe I paired it twice, do I need to reset the TRV between pairing or reboot?

[Smanar]

All is fine in deconz.
And you can't see the device in HA ?
You need to see it as plug > bad inclusion (need a second inclusion), or as ZHAthermostat > good inclusion.

But you can too have a new model, it s something starting by TYST11 or TZE200

To include it 2 time, just set phosocn in permit join (add new sensor) then reset the device 2 times, with a little space time between both.

[andye2801]

I'll give that a go then, by reset do you mean the factory reset through the menus?

[Smanar]

nope, the device (the TRV) reset (it s the procedure to include it in the zigbee network)

[andye2801]

Stupid question, how do I actually reset the TRV? I'm trying the AA reset option from below but this seems to be having little success.
https://drive.google.com/file/d/116rj8RwvsLJHDkL9Y6XwAXmZ3JiX6Pnb/view

[Smanar]

IDK I haven't tuya device ^^
But yes I think it s the part that start by "after the actuactor has completed self test ...."

[andye2801]

Is there anything needed on the HA side of things or should the TRV show up as a TRV with all attributes showing?

[Smanar]

From my memory HA support ZHAthermostat, you can have issue for the "mode" but all is working.
You need to see it, at least as plug if you have bad inclusion.

[Guus-H]

I also still have issues with this TRV. It used to work in te beginning, but after an update of Phoscon it stopped working. I recently installed the new version hoping it would fix it, but unfortunately it doesn't :(
I have tried repairing (many times, no success)
It still reads the TRV, and actually updates its temperature when this is changed on the TRV, but it fails to actually set target temperatures and it doesn't report valve positions etc.
I'm guessing I might get it all to work if I can unpair it from Phoscon and start from scratch, but I can't seem to pull this off.

If you have any suggestions of something I could try that would be awesome or if you get it to work please let me know how exactly, that would be much appreciated!

For reference:
This is what it looks like in Phoscon:

This is what it looks like in HA:

[andye2801]

All I get in Home Assistant is:

Am I missing something? I have gone through the connect to zigbee network steps at least 10 times now.

[Smanar]

Yep #4417
But it only impact "mode" and "preset" are you sure the "setheatpoint" is not working ?
If yes can you show log when making the command ? deconz/help/log with "info", tuya log are easy to reconize.

@andye2801, try this trick

• Set phoscon in permit jojn (add new sensor)
• Read again the basic attribute in deconz (2 time if needed)

Then try to check direclty in the API
http://IP:PORT/api/KEY/sensors

IP and PORT are the same than for Phoscon
KEY is an api key, you can use the same than in HA else you can create one with
curl http://127.0.0.1:80/api/ -X POST -d '{"devicetype": "TestKey"}'

[Paul-DS]

I can't find any log concerning my device when using the command /usr/bin/deCONZ -platform minimal --http-port=80 --dbg-info=2 --dbg-zdp=1 --dbg-zcl=1 --db-aps=1. Am I using the right command ?
I tried updating my device config using Jeedom and also directly using the Deconz API.

---

I did some testing to have an exhaustive list of non-working features:

{
    "9": {
        "config": {
            "heatsetpoint": 2200, 			// GET OK, SET KO
            "offset": -100,				// GET OK, SET KO
            "on": true,
            "reachable": true,
            "schedule": {...},
            "schedule_on": false			// GET KO, SET KO
        },
        "ep": 1,
        "etag": "...",
        "lastseen": "2021-02-16T07:15Z",
        "manufacturername": "Heiman",
        "modelid": "TS0601",
        "name": "Thermostat 9",
        "state": {
            "lastupdated": "none",	
            "on": true,					// GET OK
            "temperature": 2100				// GET OK
        },
        "type": "ZHAThermostat",
        "uniqueid": "..."
    }
}

(GET means I can get updated values from the device, SET means I can update the value through deconz)

---

By the way, it's probably another problem, but it seems I missing some properties:

• Locked state
• Valve state
• Boost mode

Thanks

[Smanar]

@Paul-DS Wich one deconz version are you using ?

"manufacturername": "Heiman"

Is a bug from older version, and on the next one, the device will be not reconized at all.

If you have the GUI, you can use this method to have the correct manufacture name #3110 (comment)
Else you realy need to delete the device first.

Tuya need 2 inclusions, the first one to memorise the good manufacture name used for the second one.
So if somewhere in the database you have writted "heiman" for this device, it will never work, because deconz will use it instead the good one.

[Paul-DS]

@Paul-DS Wich one deconz version are you using ?

I'm using the version 2.09.03, but I did the inclusion for this device few months ago, with an older version.

If you have the GUI, you can use this method to have the correct manufacture name #3110 (comment)
Else you realy need to delete the device first.

I removed the device via the deconz API. I tried to pair it again, but it doesn't work.
I tried the following:

• I set phoscon in permit join.
• I put my device in pairing mode.
• I repeated the previous steps ~20 times.
• I also tried to reset the device multiple time, waiting sometime 1-2 hours before turning it on again.

Should I downgrade deconz to a previous version to make the pairing work ?

You mention a method to update manually the manufacture name, but I can't find it anywhere. This would be interesting for me as I have other "Heiman" devices that I didn't removed yet.

Don't hesitate if you need any log or additional information.

Thanks

[Smanar]

So you still have "heiman" as manufacture name ? Even with 2.09.3 ?

Should I downgrade deconz to a previous version to make the pairing work ?

No it s the reverse, it s old version that use "heiman".

You mention a method to update manually the manufacture name, but I can't find it anywhere. This would be interesting for me as I have other "Heiman" devices that I didn't removed yet.

Yes, it s using the GUI.

- Set phoscon in permit jojn (add new sensor)
- Read again the basic attribute in deconz (2 time if needed)

When you will read the basic attribute (cluster "basic" 0x0000, button "read") you will have the real manufacture name displayed, and the code can use it too.

[GuillaumeP01]

Hello,
Everything had been working fine so far and for some time, notably after restarting my deconz gateway, there was no way to change mode (heat, on, off). Locking and unlocking works correctly.
@Smanar what do you need?

[Smanar]

Yep, can you try a more recent version ?
The problem that disable "mode" and "preset" is corrected on recent one.

[GuillaumeP01]

Ok I update and I do a test

[GuillaumeP01]

I updated to the latest version and everything looks OK.
Thank you again for all the work you do.

[swieprecht]

Hi everyone,

So, I've purchased 7 TRV's after I thought getting my test one working fine.

Initially I had issues with them staying on heat, even when they were well over the Target Temperature, then I did a reboot on Deconz and they all went from having basic options to having loads (including the presets, auto mode, valve position etc...)

Ideal I thought... but then they all went unavailable. I tried everything but the only way I could get them to reconnect was to repair each one in Phoscon app.

All working great....

Then I needed to do another reboot on Deconz to get the thermostat working... All now gone to unavailable again.

Is this a known flaw, and is there a way to fix it so I don't have to repair every time I need to reboot Deconz? I don't often reboot Deconz, but it will be really annoying if I have to do this every single time.

[GuillaumeP01]

Yes I too am encountering the same type of problem.
Looking at the json, I noticed a difference on my 9 TRVs:

5/9
{ "21": { "config": { "heatsetpoint": 1950, "locked": true, "mode": "auto", "offset": -100, "on": true, "preset": "manual", "reachable": true, "schedule": { "W124": [ { "heatsetpoint": 20, "localtime": "T134:00" }, { "heatsetpoint": 15, "localtime": "T08:00" }, { "heatsetpoint": 15, "localtime": "T11:30" }, { "heatsetpoint": 15, "localtime": "T12:30" }, { "heatsetpoint": 20, "localtime": "T17:30" }, { "heatsetpoint": 15, "localtime": "T22:00" } ], "W3": [ { "heatsetpoint": 20, "localtime": "T06:00" }, { "heatsetpoint": 15, "localtime": "T08:00" }, { "heatsetpoint": 15, "localtime": "T11:30" }, { "heatsetpoint": 15, "localtime": "T12:30" }, { "heatsetpoint": 20, "localtime": "T17:30" }, { "heatsetpoint": 15, "localtime": "T22:00" } ] }, "schedule_on": false, "setvalve": false, "windowopen_set": false }, "ep": 1, "etag": "xxxxxx", "lastseen": "2021-03-03T12:38Z", "manufacturername": "_TZE200_ckud7u2l", "modelid": "TS0601", "name": "Vanne", "state": { "lastupdated": "none", "lowbattery": null, "on": false, "temperature": 2150, "valve": 0 }, "type": "ZHAThermostat", "uniqueid": "xxxxx-01-0201" } }

3/9
{ "24": { "config": { "heatsetpoint": 2100, "locked": true, "mode": "auto", "offset": -100, "on": true, "preset": "manual", "reachable": true, "schedule": { "W127": [ { "heatsetpoint": 20, "localtime": "T06:00" }, { "heatsetpoint": 15, "localtime": "T08:00" }, { "heatsetpoint": 15, "localtime": "T11:30" }, { "heatsetpoint": 15, "localtime": "T12:30" }, { "heatsetpoint": 20, "localtime": "T17:30" }, { "heatsetpoint": 15, "localtime": "T22:00" } ] }, "schedule_on": false, "setvalve": false, "windowopen_set": false }, "ep": 1, "etag": "xxxxxxxxxx", "lastseen": "2021-03-03T12:30Z", "manufacturername": "_TZE200_ckud7u2l", "modelid": "TS0601", "name": "Vanne", "state": { "lastupdated": "none", "lowbattery": null, "on": true, "temperature": 2000, "valve": 40 }, "type": "ZHAThermostat", "uniqueid": "xxxx-01-0201" } }

1/9
{ "36": { "config": { "heatsetpoint": 2400, "locked": true, "mode": "heat", "offset": -100, "on": true, "preset": "manual", "reachable": true, "schedule": [], "schedule_on": false, "setvalve": false, "windowopen_set": false }, "ep": 1, "etag": "xxxxx", "lastseen": "2021-03-03T12:47Z", "manufacturername": "_TZE200_ckud7u2l", "modelid": "TS0601", "name": "Vanne", "state": { "lastupdated": "none", "lowbattery": null, "on": null, "temperature": null, "valve": null }, "type": "ZHAThermostat", "uniqueid": "xxxxxx-01-0201" } }

[Smanar]

@swieprecht I have answer on your other issue.
@GuillaumeP01 I m seing same information on the 3 TRV, except the third (1/9) seem not working correctly, still no temperature.

[GuillaumeP01]

the information is not identical there is an extra part for 5 of my valves:
"W124": [ { "heatsetpoint": 20, "localtime": "T134:00" }, { "heatsetpoint": 15, "localtime": "T08:00" }, { "heatsetpoint": 15, "localtime": "T11:30" }, { "heatsetpoint": 15, "localtime": "T12:30" }, { "heatsetpoint": 20, "localtime": "T17:30" }, { "heatsetpoint": 15, "localtime": "T22:00" } ],

and the part is the same but named differently W3 in the first case and W127 in the second :
"W3": [ { "heatsetpoint": 20, "localtime": "T06:00" }, { "heatsetpoint": 15, "localtime": "T08:00" }, { "heatsetpoint": 15, "localtime": "T11:30" }, { "heatsetpoint": 15, "localtime": "T12:30" }, { "heatsetpoint": 20, "localtime": "T17:30" }, { "heatsetpoint": 15, "localtime": "T22:00" } ] }, "schedule_on": false, "setvalve": false, "windowopen_set": false },

is this normal?

[Smanar]

Yep, this is shedule, nothing to see with the normal working mode, you have set a schedule W124 = workday on one and W3 = Saturday and Sunday on the second one.

[GuillaumeP01]

Ok merci

[bchhabra]

Hello Guys,

I am looking to buy a new trv which supports deconz/zigbee with my home assistant installation.
@GuillaumeP01 @swieprecht @Smanar Are you happy with these trvs?
Can you please share your feedback?

Best Regards
B

[Smanar]

I don't have tuya TRV ^^. And there is at least 30/40 models, so you can found the better like the worst.

[bchhabra]

From my memory HA support ZHAthermostat, you can have issue for the "mode" but all is working. You need to see it, at least as plug if you have bad inclusion.

Sorry about the stupid question.
What are the recommended steps to get this TRV visible in phoscon? I just got one to try out.
I should add as a Lights or Switches or Sensor ?

[Smanar]

I should add as a Lights or Switches or Sensor ?

Sensor, but it will work same.
And if it will not work, forced to use the GUI to see the modelID+Manufacture name, the inclusion in the zigbee network will work even if the integration in te API not. (to see if the device is supported, there is so much clones on tuya)