Closed Romioyar closed 2 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
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
And here the 16.6 A5
I also noticed the data
is pretty much basic Tuya protocol we use on ESP8266's.
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....
thank you @insipiens. I been doing something like this for the device, i'll sort and fix it tomorrow
@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....
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
Guys you're inventing the wheel again https://github.com/Koenkk/zigbee-herdsman-converters/blob/8102114d8bde669342de577202e8ccefdb9fd281/converters/fromZigbee.js#L221
@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
@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.
I have error on mqtt when change mode
Showing windows sensor etc as switch is a bug? Why not binary sensor?
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.
Moes Hy369rt
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"}'
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.
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"}'
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:
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?
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.
Few facts:
Thanks for the comments!
- 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.
1 the detection works so that a sudden drop in temperature closes the valve for a certain time, set by some parameter
1.14.4.1 still mqtt error when change modes.
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
@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 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
@ 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.
@ 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
not working
not working
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
@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.
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?
@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!
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?
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?
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.
@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 ...
I've received such a thermostat today, ordered also at moes. But it seems to be a different model - the HY368 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
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.
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 :)
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 :)
Yes, I realise that only works with positive values. Do you see why battery status is not reported?
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 :)
@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 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?
so I understand for you it's working fine even with the leds off?
so I understand for you it's working fine even with the leds off?
Yes, it works very well.
@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.....
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?
After upgrade firmware also reacts after 4 minutes on change z2m?
Hey, I have this device, but during pairing I get information that device is unsupported.
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?
@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.
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.
Same issue for me, valve accepts commands only when it is not sleeping; i have bought it on the official Moes store;
@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.
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
I deleted TS0601 device in devices.js and repaired and got this:
Then I changed devices.js and added TS0601 as Tuya thermostatic valve and deleted curtain part, also fixed homeassistant.js for autodiscovery :
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