Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.2k stars 1.6k forks source link

Tuya thermostatic valve #3821

Closed Romioyar closed 2 years ago

Romioyar commented 3 years ago

Bug Report

What happened

New Tuya thermostatic valve was auto discovered in Zigbee2Mqtt 1.14.0 as Tuya curtain motor. Valve reports model as TS0601 which is occupied already in devices.js by Tuya curtain motor. https://aliexpress.ru/item/4001043738901.html?spm=a2g0s.9042311.0.0.1b6033edHXNB4c&_ga=2.27185918.2138683156.1593276537-279917533.1590225196

info  2020-06-27 17:39:11: Device '0xbc33acfffe6d821c' joined
info  2020-06-27 17:39:11: Starting interview of '0xbc33acfffe6d821c'
info  2020-06-27 17:39:11: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_connected","message":{"friendly_name":"0xbc33acfffe6d821c"}}'
info  2020-06-27 17:39:11: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"interview_started","meta":{"friendly_name":"0xbc33acfffe6d821c"}}'
debug 2020-06-27 17:39:11: Device '0xbc33acfffe6d821c' announced itself
info  2020-06-27 17:39:11: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0xbc33acfffe6d821c"}}'
debug 2020-06-27 17:39:11: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"modelId":"TS0601"}' from endpoint 1 with groupID 0
info  2020-06-27 17:39:12: MQTT publish: topic 'homeassistant/cover/0xbc33acfffe6d821c/cover/config', payload '{"command_topic":"zigbee2mqtt/0xbc33acfffe6d821c/set","position_topic":"zigbee2mqtt/0xbc33acfffe6d821c","set_position_topic":"zigbee2mqtt/0xbc33acfffe6d821c/set","set_position_template":"{ \"position\": {{ position }} }","value_template":"{{ value_json.position }}","json_attributes_topic":"zigbee2mqtt/0xbc33acfffe6d821c","name":"0xbc33acfffe6d821c_cover","unique_id":"0xbc33acfffe6d821c_cover_zigbee2mqtt","device":{"identifiers":["zigbee2mqtt_0xbc33acfffe6d821c"],"name":"0xbc33acfffe6d821c","sw_version":"Zigbee2mqtt 1.14.0","model":"Curtain motor (TS0601)","manufacturer":"TuYa"},"availability_topic":"zigbee2mqtt/bridge/state"}'
info  2020-06-27 17:39:12: MQTT publish: topic 'homeassistant/sensor/0xbc33acfffe6d821c/linkquality/config', payload '{"icon":"mdi:signal","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}","state_topic":"zigbee2mqtt/0xbc33acfffe6d821c","json_attributes_topic":"zigbee2mqtt/0xbc33acfffe6d821c","name":"0xbc33acfffe6d821c_linkquality","unique_id":"0xbc33acfffe6d821c_linkquality_zigbee2mqtt","device":{"identifiers":["zigbee2mqtt_0xbc33acfffe6d821c"],"name":"0xbc33acfffe6d821c","sw_version":"Zigbee2mqtt 1.14.0","model":"Curtain motor (TS0601)","manufacturer":"TuYa"},"availability_topic":"zigbee2mqtt/bridge/state"}'
debug 2020-06-27 17:39:12: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"manufacturerName":"_TZE200_ckud7u2l"}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:12: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"powerSource":3}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:12: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"zclVersion":3}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:12: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"appVersion":83}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:12: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"stackVersion":0}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:12: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"hwVersion":1}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:13: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{"dateCode":""}' from endpoint 1 with groupID 0
debug 2020-06-27 17:39:13: Received Zigbee message from '0xbc33acfffe6d821c', type 'readResponse', cluster 'genBasic', data '{}' from endpoint 1 with groupID 0
info  2020-06-27 17:39:13: Successfully interviewed '0xbc33acfffe6d821c', device has successfully been paired
info  2020-06-27 17:39:13: Device '0xbc33acfffe6d821c' is supported, identified as: TuYa Curtain motor (TS0601)

I deleted TS0601 device in devices.js and repaired and got this:

warn  2020-06-27 19:05:57: Received message from unsupported device with Zigbee model 'TS0601'
warn  2020-06-27 19:05:57: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.

Then I changed devices.js and added TS0601 as Tuya thermostatic valve and deleted curtain part, also fixed homeassistant.js for autodiscovery :

    {
        zigbeeModel: ['TS0601'],
        model: 'TS0601',
        vendor: 'Moes',
        description: 'Radiator valve with thermostat',
        supports: 'thermostat, temperature',
        fromZigbee: [
            fz.tuya_thermostat,
            fz.tuya_thermostat_on_set_data,
            fz.ignore_basic_report,
        ],
        toZigbee: [
            tz.tuya_thermostat_child_lock,
            tz.tuya_thermostat_window_detection,
            tz.tuya_thermostat_valve_detection,
            tz.tuya_thermostat_current_heating_setpoint,
            tz.tuya_thermostat_system_mode,
            tz.tuya_thermostat_auto_lock,
            tz.tuya_thermostat_calibration,
            tz.tuya_thermostat_min_temp,
            tz.tuya_thermostat_max_temp,
            tz.tuya_thermostat_boost_time,
            tz.tuya_thermostat_comfort_temp,
            tz.tuya_thermostat_eco_temp,
            tz.tuya_thermostat_force,
        ],

    },

And thermostatic valve works correctly after this. I bought 4 of them so could you please fix so it is correctly recognized out of the box.

Thanks!

What did you expect to happen

Valve autodiscovered as Tuya thermostatic valve which is actually similar to Moes.

How to reproduce it (minimal and precise)

Start pairing thermostatic valve.

Debug Info

Zigbee2mqtt version: 1.14.0 Adapter hardware: CC2538 Adapter firmware version: zStack30x

Stoatwblr commented 3 years ago

You and me both on this journey :) Why do I always end up learning more than I ever want to know about the nuts and bolts?

https://github.com/TuyaInc might have useful content too

Sthopeless commented 3 years ago

So I'm running Zboss, initially I looked for my Tuya Gateway id which is 0x14 (20). Then I started wireshark and recorded only me changing the temp from Tuya app to 17 and 16.5 and stopped wireshark and looked for those values Here it's 17, AA Screenshot (63)

And here the 16.6 A5 Screenshot (62)

I also noticed the data is pretty much basic Tuya protocol we use on ESP8266's.

insipiens commented 3 years ago

A5 = 165 so 16.5 degrees multiplied by 10

0202 (big endian same in normal hex) = 514 decimal which was the DP mentioned above as change temperature target.

In the converters file fromZigbee.js this message is programmed as follows

tuya_thermostat_current_heating_setpoint: { key: ['current_heating_setpoint'], convertSet: async (entity, key, value, meta) => { const temp = Math.round(value * 10); const payloadValue = utils.convertDecimalValueTo2ByteHexArray(temp); sendTuyaCommand(entity, 514, 0, [4, 0, 0, ...payloadValue]); }, },

Unfortunately my look at the Moes Room Thermostat has completely different DP values for similarcommands - was hoping for some consistency....no luck there....

Sthopeless commented 3 years ago

thank you @insipiens. I been doing something like this for the device, i'll sort and fix it tomorrow Screenshot (67)

insipiens commented 3 years ago

@Sthopeless Nice work! 👍

A comment on the calibration results data you have there, and apologies if I'm explaining the bleeding obvious: for negative values e.g -10 it uses the binary compliment so -10 = 0b1111110110 = 0xfffffff6 (as it's dealing in 1/10 of a degree) .

I'm not fully up to speed on the programming of zigbee2mqtt yet so, like you finding my way....

Sthopeless commented 3 years ago

Here are the DP's from my printscreen

Window Parameter =104
Key Lock         =263
KeyLock          =372
Change Temp      =514
Temp Calibration =556
MaxTemp Limit    =615
Mode             =1028
Valve Setting    =1130
AutoMode Type    =1135

And here a link for my sheet https://docs.google.com/spreadsheets/d/e/2PACX-1vSN8czWM_IVTDJ6Ayr8SEU9u1bzMdTVxImeeZ0k6uXhzcOzW1Hc46KipJiObhhC8RD23kV7jr0cMzbh/pubhtml?gid=1315981890&single=true let me know if there's anything missing and i can have a look

mgrom commented 3 years ago

Guys you're inventing the wheel again https://github.com/Koenkk/zigbee-herdsman-converters/blob/8102114d8bde669342de577202e8ccefdb9fd281/converters/fromZigbee.js#L221

insipiens commented 3 years ago

@mgrom . understood! given all your hard work! I think trying to make more functionality available....this should be encouraged, if for nothing else but greater participation and understanding.

For me, the program setting aspect is still not fnctional across [any/all?] thermostats - I'm keen to engage further on that given my work on the Moes room thermostat (nearing minimal completion!)

All sent with great respect for everyones contributions

mgrom commented 3 years ago

@insipiens it wasn't me who made all this hard work. I've just added few fixes.

Anyway, my advise: check the code I've linked, then try to create new methods in toZigbee file in converters that will for example change week type (7, 6+1, 5+2). Command structure that have to be send to device is exaxtly the same as its report, it's quite easy. More difficult will be setting weekly schedule in HA, than coding it back to zigbee format :)

If you have any questions, I'll try to help.

shirou93 commented 3 years ago

I have error on mqtt when change mode Screenshot_20200904-204226

Showing windows sensor etc as switch is a bug? Why not binary sensor?

shirou93 commented 3 years ago

On Google home (home assistant expose thermostat) only show temperature inside. I can't change temperature on Google home (only text "other" in circle). Tap mode no working. Screenshot_20200906-135329

Moes Hy369rt

Bartekn86 commented 3 years ago

Sep 06 18:01:19 raspberrypi npm[6918]: Zigbee2MQTT:error 2020-09-06 18:01:19: No converter available for 'mode' (auto) Sep 06 18:02:17 raspberrypi npm[6918]: Zigbee2MQTT:error 2020-09-06 18:02:17: No converter available for 'mode' (eco)

Sep 06 18:11:48 raspberrypi npm[6918]: Zigbee2MQTT:info 2020-09-06 18:11:48: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'preset' to 'bn duzy glowica' failed: 'Error: Command 0xec1bbdfffe91c050/1 manuSpecificTuyaDimmer.setData({"status":0,"transid":205,"dp":1028,"fn":0,"data":[1,0]}, {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999))'","meta":{"friendly_name":"bn duzy glowica"},"type":"zigbee_publish_error"}'

ebyna commented 3 years ago

https://github.com/stas-demydiuk/domoticz-zigbee2mqtt-plugin/issues/383#issuecomment-687848489

Rossez commented 3 years ago

Hi all,

sorry if this is obvious or allready addressed. I have six of Moes branded Tuya thermostatic valves - model number HY368. Using latest zigbee2mqtt with HA. When I change the operating mode on the valve to manual I get an error in HA

[homeassistant.components.mqtt.climate] Invalid modes mode: manual

Same is with other modes axcept of auto.

But in fact it seems it works with HA ok. It only generates HA error logs. From the MQTT perspective it looks ok (no erorrs in zigbee2mqtt log, MQTT topic seems to update fine).

Are the errors in HA log problem of HA interpreting the mqtt messages or is there anything yet that should be corrected on the zigbee2mqtt or converters side? Thank you.

Bartekn86 commented 3 years ago

Sep 07 21:01:51 raspberrypi npm[11448]: Zigbee2MQTT:error 2020-09-07 21:01:51: Publish 'set' 'local_temperature_calibration' to 'bn duzy glowica' failed: 'Error: Command 0xec1bbdfffe91c050/1 manuSpecificTuyaDimmer.setData({"status":0,"transid":95,"dp":556,"fn":0,"data":[4,0,0,0,0]}, {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Data request failed with error: 'Timeout' (9999))' Sep 07 21:01:51 raspberrypi npm[11448]: Zigbee2MQTT:info 2020-09-07 21:01:51: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'local_temperature_calibration' to 'bn duzy glowica' failed: 'Error: Command 0xec1bbdfffe91c050/1 manuSpecificTuyaDimmer.setData({\"status\":0,\"transid\":95,\"dp\":556,\"fn\":0,\"data\":[4,0,0,0,0]}, {\"timeout\":10000,\"disableResponse\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null}) failed (Data request failed with error: 'Timeout' (9999))'","meta":{"friendly_name":"bn duzy glowica"},"type":"zigbee_publish_error"}'

insipiens commented 3 years ago

Hi all,

sorry if this is obvious or allready addressed. I have six of Moes branded Tuya thermostatic valves - model number HY368. Using latest zigbee2mqtt with HA. When I change the operating mode on the valve to manual I get an error in HA

[homeassistant.components.mqtt.climate] Invalid modes mode: manual

Same is with other modes axcept of auto.

But in fact it seems it works with HA ok. It only generates HA error logs. From the MQTT perspective it looks ok (no erorrs in zigbee2mqtt log, MQTT topic seems to update fine).

Are the errors in HA log problem of HA interpreting the mqtt messages or is there anything yet that should be corrected on the zigbee2mqtt or converters side? Thank you.

A couple of observations:

  1. Integration with HA isn’t a given, I haven’t seen a card in HA which mimics a radiator valve, it’s more an issue with HA in my opinion. When you select a mode in HA (standard thermostat card) it sends a value, either ‘auto’, ‘heat’, or ‘off’? None of these correspond to the radiator valve’s modes. Some programming would be required to make them do something, but what?

  2. You could create automations in HA which just adjust the temperature, such an automation would be in effect the same as a program...probably better actually.

Nothing is stopping anyone from developing this further if they feel the need to do so.

mgrom commented 3 years ago

Few facts:

  1. HA requires climate sensors to have modes
  2. First version of integration of this valbe was built on modes.
  3. HA allows only strict set of modes, they are predefined.
  4. HA have something called hold_modes (name is quite dumb because they appear as presets on UI). Preset are more flexible, you can just define own list
  5. I've made few fixes to be able to use presets instead of modes, but I had to keep backward compatibility. So everytime you change preset there is also mode change triggered.
Rossez commented 3 years ago

Thanks for the comments!

  1. I've made few fixes to be able to use presets instead of modes, but I had to keep backward compatibility. So everytime you change preset there is also mode change triggered.

Understood. Thanks very much. So the issue is HA problem and it doesn't affect the valve functionality. I am planning to use manual mode (preset) only and control the temp with automations.

Two more questions:

1) How the window detection switch is supposed to work? When I switch it on the valve fully opens. I thought that it is supposed to close the valve so that the heating is turned off while windows are temporarily opened (temp drops).

2) What valve detection switch should do?

Thank you.

Bartekn86 commented 3 years ago

1 the detection works so that a sudden drop in temperature closes the valve for a certain time, set by some parameter

shirou93 commented 3 years ago

1.14.4.1 still mqtt error when change modes.

Miguelin96 commented 3 years ago

How can I improve the update frequency since the center of the valve was touched and it turns on if it sends me information but if I don't do that, the refresh rate is very large or null

cadavre commented 3 years ago

@Miguelin96 you can use automation to trigger forced temperature measurements in your preferred time interval, as exampled here: https://github.com/Koenkk/zigbee2mqtt/issues/3821#issuecomment-672252658

Miguelin96 commented 3 years ago

@ Miguelin96 puede usar la automatización para activar mediciones de temperatura forzadas en su intervalo de tiempo preferido, como se muestra aquí: # 3821 (comentario)

The same thing still happens to me after I put the automation.....

If I modify the data from the thermostat, it is updated in home assistant but when I do it from home assistant, the valve does not change if I do not touch the valve

QBANIN commented 3 years ago

@ Miguelin96 puede usar la automatización para activar mediciones de temperatura forzadas en su intervalo de tiempo preferido, como se muestra aquí: # 3821 (comentario)

The same thing still happens to me after I put the automation.....

If I modify the data from the thermostat, it is updated in home assistant but when I do it from home assistant, the valve does not change if I do not touch the valve

Same problem here. Conbee II + z2m 1.14.4.1 + TZE200_ckud7u2l thermostat.

jul1an353 commented 3 years ago

@ Miguelin96 puede usar la automatización para activar mediciones de temperatura forzadas en su intervalo de tiempo preferido, como se muestra aquí: # 3821 (comentario)

The same thing still happens to me after I put the automation..... If I modify the data from the thermostat, it is updated in home assistant but when I do it from home assistant, the valve does not change if I do not touch the valve

Same problem here. Conbee II + z2m 1.14.4.1 + TZE200_ckud7u2l thermostat.

same here. i have three thermostats with different version numbers. only one works. it seems the other ones going in to sleep and have to wake up by touching them.

working working

not working not_working

not working not_working2

callahanharry commented 3 years ago

I have received my valve recently and similarly to QBANIN, Miguel96 and jul1an353, I am basically not able to set any command over Zigbee to it once it goes to sleep. I tried to use it with zStack 1.2 and 3.0 and it is the same. As long as the LEDs are on, it is accepting commands. When they goes off, it does not talk to me anymore. I tried for example to send local_temperature_calibration command with argument of 0 and no response.

Not working: manufId: 4098 manufName: _TZE200_ckud7u2l modelId: TS0601

IMG_1962

diabl0 commented 3 years ago

@callahanharry @Miguelin96

Once i received mine set, i connected heads to original zigbee gate and updated firmware to latest version, but forgot about one. When heads was was mounted i reconnected them to z2m CC2531 USB stick, and found same problem as mentioned - data seems to go only in one directions - head to z2m/ha. Reconnecting to original gate, updating to latest firmware via Smart Life app, and connecting back to z2m fixed issue.

misza-m commented 3 years ago

I also have the Moes TRV, and with the newest dev version of z2m I also have the same problems. I can see things that are set on the trv but when I change enything in Home Assistant, nothing happens.

@diabl0 - Can I update firmware without the Tuya gateway?

QBANIN commented 3 years ago

@callahanharry @Miguelin96

Once i received mine set, i connected heads to original zigbee gate and updated firmware to latest version, but forgot about one. When heads was was mounted i reconnected them to z2m CC2531 USB stick, and found same problem as mentioned - data seems to go only in one directions - head to z2m/ha. Reconnecting to original gate, updating to latest firmware via Smart Life app, and connecting back to z2m fixed issue.

Great! After firmware update valve works perfectly :) Thank you!

cadavre commented 3 years ago

I never used valves with original gateway, so firmware I received is the one I'm using. And it's working flawlessly!

It's a pitty we cannot check firmware from Z2Massistant – this way we could prepare a "Supported versions" matrix. Or is there any other way of getting FW info?

pirracas77 commented 3 years ago

I've just received two valves and they are running correct without the gateway. So happy. The only problem is that the battery status is completly missing. Any idea?

pirracas77 commented 3 years ago

Additionally, I discovered that the two valves received, it seems that they have diferent firmware between them. One of them doesn't have the value ""running":false" in the payload and also this valve aswer is faster than the other one to the "current_heating_setpoint" query.

callahanharry commented 3 years ago

@misza-m - Looking at z2m sources, there seems to be some support for OTA update of ZigBee devices. As the implementation for different devices differs basically just in way of version checking and obtaining newer images from vendor sites, updating ZigBee device could be standardized thing. Probably the only, but also major, problem would be obtaining firmware image for this valve. There are some projects on github allowing to use tuya cloud API, but they are mostly hacks, obtaining encryption keys hidden in pixels of pictures extracted from APKs, etc ...

fabicodes commented 3 years ago

I've received such a thermostat today, ordered also at moes. But it seems to be a different model - the HY368 IMG_20200923_142508 Otherwise it looks exactly the same, but isn't yet supported (log after re-powering it on):

Zigbee2MQTT:debug 2020-09-23 14:26:45: Device '0x842e14fffe5a314c' announced itself
Zigbee2MQTT:info  2020-09-23 14:26:45: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x842e14fffe5a314c"},"type":"device_announced"}'
Zigbee2MQTT:debug 2020-09-23 14:26:45: Device '0x842e14fffe5a314c' announced itself
Zigbee2MQTT:info  2020-09-23 14:26:45: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x842e14fffe5a314c"},"type":"device_announced"}'
Zigbee2MQTT:debug 2020-09-23 14:26:49: Received Zigbee message from '0x842e14fffe5a314c', type 'read', cluster 'genTime', data '["localTime"]' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:49: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:49: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:56: Received Zigbee message from '0x842e14fffe5a314c', type 'raw', cluster 'manuSpecificTuyaDimmer', data '{"data":[25,1,36,0,3],"type":"Buffer"}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:56: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:56: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:58: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,0,5],"type":"Buffer"},"dp":614,"fn":0,"status":0,"transid":1}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:58: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:58: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:58: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,0,35],"type":"Buffer"},"dp":615,"fn":0,"status":0,"transid":2}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:58: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:58: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:58: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,1,24],"type":"Buffer"},"dp":514,"fn":0,"status":0,"transid":3}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:58: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:58: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,1,14],"type":"Buffer"},"dp":515,"fn":0,"status":0,"transid":4}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,1,14],"type":"Buffer"},"dp":515,"fn":0,"status":0,"transid":5}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[2],"type":"Buffer"},"dp":1028,"fn":0,"status":0,"transid":6}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[2],"type":"Buffer"},"dp":1028,"fn":0,"status":0,"transid":7}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0],"type":"Buffer"},"dp":263,"fn":0,"status":0,"transid":8}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0],"type":"Buffer"},"dp":1293,"fn":0,"status":0,"transid":9}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:26:59: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[255,255,255,246],"type":"Buffer"},"dp":556,"fn":0,"status":0,"transid":10}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:26:59: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:26:59: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:27:00: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,5,10],"type":"Buffer"},"dp":104,"fn":0,"status":0,"transid":11}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:27:00: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:27:00: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:27:00: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,1,44],"type":"Buffer"},"dp":617,"fn":0,"status":0,"transid":12}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:27:00: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:27:00: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:27:00: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0],"type":"Buffer"},"dp":1130,"fn":0,"status":0,"transid":13}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:27:00: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:27:00: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:27:00: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,0,20],"type":"Buffer"},"dp":619,"fn":0,"status":0,"transid":14}' from endpoint 1 with groupID 0
Zigbee2MQTT:warn  2020-09-23 14:27:00: Received message from unsupported device with Zigbee model 'undefined'
Zigbee2MQTT:warn  2020-09-23 14:27:00: Please see: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html.
Zigbee2MQTT:debug 2020-09-23 14:27:00: Received Zigbee message from '0x842e14fffe5a314c', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"data":{"data":[0,0,0,15],"type":"Buffer"},"dp":620,"fn":0,"status":0,"transid":15}' from endpoint 1 with groupID 0

I also found commits for it at deconz, if that helps: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3110

slashbv commented 3 years ago

I have ordered one for testing from aliexpress. it arrived today. I have the same problem, I can only change something from HA while the leds are on. Once the leds turn off I cannot do anything.

insipiens commented 3 years ago

I have one and did some checking of the traffic and it is working fine, even with or without updating to latest firmware (I checked both).

The only major problem I found was in the smart life app it was asking for a password to access the advanced settings....it was not the App password oddly so I couldn't check those functions out. If someone could shed some light on that I'd appreciate it...I could then check out the other functions by sniffing to confirm any other functions.

Here attached is the analysis from my checks, it matches with the current Zigbee2mqtt configuration so no difference so far between the Moes valve HY368 and the Tuya family of valves....

Also, to mention...the calibration function only works for positive numbers, why? the library function in Z2M can't handle negative (complimentary) values. Is this a deal breaker? probably not :)

Moes HY368

pirracas77 commented 3 years ago

I have one and did some checking of the traffic and it is working fine, even with or without updating to latest firmware (I checked both).

The only major problem I found was in the smart life app it was asking for a password to access the advanced settings....it was not the App password oddly so I couldn't check those functions out. If someone could shed some light on that I'd appreciate it...I could then check out the other functions by sniffing to confirm any other functions.

Here attached is the analysis from my checks, it matches with the current Zigbee2mqtt configuration so no difference so far between the Moes valve HY368 and the Tuya family of valves....

Also, to mention...the calibration function only works for positive numbers, why? the library function in Z2M can't handle negative (complimentary) values. Is this a deal breaker? probably not :)

Moes HY368

Yes, I realise that only works with positive values. Do you see why battery status is not reported?

insipiens commented 3 years ago

Another comment:

In home assistant you are correct, clicking the icon on the climate control does nothing.

What you need to do is click the ellipses (3 vertical dots) in the upper right corner which takes you to the additional preset control (see attachment). There you will find the presets which do change settings.

HA only allows a limited selection of the control in normal view, hence why the presets was configured to provide the added functionality I assume.

Hope that helps :)

radiator control

insipiens commented 3 years ago

@pirracas77 Battery status. Yes, part of the reason I did the analysis was to check that,

I saw no Zigbee HA messages that contained the battery status.....it does clearly get transmitted but nothing obvious showed up.

When working on another Moes item, a thermostat I also noticed the time setup was sent in a different way - I think ZCL or IEEE, not one that Z2M would be able to pick up.

I wonder if this does it the same way?

pirracas77 commented 3 years ago

@pirracas77 Battery status. Yes, part of the reason I did the analysis was to check that,

I saw no Zigbee HA messages that contained the battery status.....it does clearly get transmitted but nothing obvious showed up.

When working on another Moes item, a thermostat I also noticed the time setup was sent in a different way - I think ZCL or IEEE, not one that Z2M would be able to pick up.

I wonder if this does it the same way?

Maybe. Or perhaps the device is only prepared to send the message "battery low"

Does anyone know what information sends to the official app?

slashbv commented 3 years ago

so I understand for you it's working fine even with the leds off?

pirracas77 commented 3 years ago

so I understand for you it's working fine even with the leds off?

Yes, it works very well.

insipiens commented 3 years ago

@pirracas77 For sure, could be something like that maybe...but on the Smart Life app it states the battery level so I would assume it is transmitted regularly.

Edit: scrub that - its valve position it reports.....

pirracas77 commented 3 years ago

Edit: scrub that - its valve position it reports.....

So maybe battery status is simply not reported regulary.

The valve has a "battery low" icon. Maybe this is the only information that could arrive.

could you put a run out battery and sniff the information reported?

shirou93 commented 3 years ago

After upgrade firmware also reacts after 4 minutes on change z2m?

raptor1989 commented 3 years ago

Hey, I have this device, but during pairing I get information that device is unsupported.

https://ibb.co/db5MYwJ

Zigbee2mqtt version: 1.14.4 Adapter hardware: CC2530 Adapter firmware version: zStack12

What should I do to make it work? Switch to the dev branch? Whether updating firmware is needed?

Rossez commented 3 years ago

@Bart-1992 Thanks for info. Window detection will work in next release.

I've made simple automation:

trv_automations:
  automation:
    - id: bedroom_trv_get_temp
      alias: Bedroom TRV get current temp
      trigger: 
        - platform: time_pattern
          minutes: "/2"
      action:
        - service: mqtt.publish
          data_template:
            topic: 'zigbee2mqtt/bedroom_moes_trv/set/local_temperature_calibration'
            payload: '0'

I tried above automation and I need to set local_temperature_calibration to -1 degree (asi it was set from factory). I send "-1.0" or "-1" as payload. However I get MQTT error:

(node:17) UnhandledPromiseRejectionWarning: RangeError [ERR_OUT_OF_RANGE]: The value of "value" is out of range. It must be >= 0 and <= 255. Received -10

Is there any way to put negative value to temp calibraton? Thank you.

pirracas77 commented 3 years ago

Is there any way to put negative value to temp calibraton? Thank you.

It was already stated, negative values doesn't work for the moment. You should set it by hand in the valve.

ramelito commented 3 years ago

Same issue for me, valve accepts commands only when it is not sleeping; i have bought it on the official Moes store;

rachffus commented 3 years ago

@Bart-1992 Thanks for info. Window detection will work in next release. I've made simple automation:

trv_automations:
  automation:
    - id: bedroom_trv_get_temp
      alias: Bedroom TRV get current temp
      trigger: 
        - platform: time_pattern
          minutes: "/2"
      action:
        - service: mqtt.publish
          data_template:
            topic: 'zigbee2mqtt/bedroom_moes_trv/set/local_temperature_calibration'
            payload: '0'

I tried above automation and I need to set local_temperature_calibration to -1 degree (asi it was set from factory). I send "-1.0" or "-1" as payload. However I get MQTT error:

(node:17) UnhandledPromiseRejectionWarning: RangeError [ERR_OUT_OF_RANGE]: The value of "value" is out of range. It must be >= 0 and <= 255. Received -10

Is there any way to put negative value to temp calibraton? Thank you.

I have found a way to set negative values: Values above 128 are negative for device, so for example if you send 129,5 it will be -1,5 for thermostat. Checked and tested in NodeRED.