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

[ebaauw]

What version of the API plugin are you using? config.schedule should be {} in v2.05.80 instead of [].

[GuillaumeP01]

What version of the API plugin are you using? config.schedule should be {} in v2.05.80 instead of [].

yes this is the version

On the other hand, I didn't understand to change the name, do you have screenshots to guide me?

[Smanar]

Ok So I have corrected the "window open" setting. It seem on your device, you haven't return, it s just a setting that you can enable or not, so I have moved this field from state to config.

I have add too the battery field for test, but we have never see this value on logs on other tuya device, so just make test for at least 24h.

To change name you can use Curl with curl -H 'Content-Type: application/json' -X PUT -d '{"name": "Cool New Name"}' http://PORT:IP/api/API_KEY/sensors/ID/

[GuillaumeP01]

Perfect thank you do I need to update?

Thank you very much for the name change command line its worked nickel

[Smanar]

Yep, pls, and re-include the device, BTW I m a little busy atm so I don't test on my side, so if you have error during compliation, you can stop all the procedure.

[GuillaumeP01]

The update went well and after reintegrating the valve the windowopen_set parameter appeared as well as battery. I added the commands to activate windowopen and it seems to work but I don't see any change on the valve. more testing needs to be done.

I will leave 24 hours to see if the battery status changes

What is the schedule_on parameter?

[GuillaumeP01]

[Smanar]

For schedule you have an exemple here : https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2393

I will ask for battery on the other issue, but if we don't find it, I think the only one solution is putting deconz in debug mode, to find the good vlaue.

[SwoopX]

What's config/windowopen_set? We already have windowopen as state...

[Smanar]

There is 2 "windows open"

• One that return value > State/windowopen (only readable)
• One that you can only set to on or off > config/windowopen_set (readable and writable)

But can be wrong, It from that I m reading, I haven't the device to test.

[GuillaumeP01]

After almost 24 hours I still have no feedback for the battery.

The doc indicates a low battery indicator suddenly I think there is no battery recovery.

[Smanar]

Yep I think it's normal, I have an aswer just ATM

yes, on one of my valves sometimes the bootstrapping message about lowbattery is caught, on the other never. If the battery is ok the lowbattery=false message is sent only once when you insert new batteries. If batteries are ok, no message will be sent until the batteries go empty. However, when the batteries go empty/dead, the lowbattery status start flapping. So, it would be great if the default value for the lowbattery status could be "false" instead of "null" at beginning for this kind of devices. But I'm not sure is possible nor it's correct.

So you will have "Battery" = "false", on the future version (Already online on my fork but better to wait for some days, big change ATM)

[GuillaumeP01]

do you have an example code for the schedule [] ? And preset? For the test

what do you correspond "on"? and "reachable"?

[Smanar]

Reachable = online. For "on" , there is 2 one ?

For preset, if you want to test on your device, if it support them

                    if (presetSet == "holiday") { data = QByteArray("\x00",1); }
                    else if (presetSet == "auto") { data = QByteArray("\x01",1); }
                    else if (presetSet == "manual") { data = QByteArray("\x02",1); }
                    else if (presetSet == "confort") { data = QByteArray("\x03",1); }
                    else if (presetSet == "eco") { data = QByteArray("\x04",1); }
                    else if (presetSet == "boost") { data = QByteArray("\x05",1); }
                    else if (presetSet == "complex") { data = QByteArray("\x06",1); }

[GuillaumeP01]

Yes that's it for "On" I have 2 actions and the state

I will do some tests for preset tests thanks for the codes

Do you have the same for schedule?

[Smanar]

Schedule have be never tested on tuya. and the code not permit that yet, so it s not on top of the TODO list ^^.

config/on is a setting : with his one you can enable or not the device (to prevent it trigger event for exemple) I think you have t on all sensor

state/on is a state : like have said Ebaawn it reflect the valve state (it is "on" when valve status > 3)

BTW, you confirm me too, battery level is not working for your device (and not low battery) ? (To disable it in the code)

[GuillaumeP01]

on a screenshot taken from the internet we see that there are 2 additional parameters for the opening command window how do we add them?

I added the 7 presets and change of course on the trv : "holiday" "auto" "manual" "confort" "eco" "boost" "complex"

[GuillaumeP01]

low battery I think it works but I have no hs battery to test

[Smanar]

I have find for windows parameter, the information is visible on the device ? I m trying to find a way to don't overload the JSON.

[GuillaumeP01]

Yes the informations for Windows parameter is visible on the device.

[Smanar]

Ok so I can made an hidden command to change this setting. So with that you will see the values on the device instead of in the API, and no more field in the JSON.

[GuillaumeP01]

ok tell me when i can test it