[Bug] Thermostat not detected yet exposes thermostat values about homebridge-z2m HOT 23 CLOSED

@itavero I thank you very much for your support. I manually updated the package.json on the zigbee2mqtt repo to point to the latest converters and restarted it and everything works. I have radiator thermostats in Apple Home now. Huge thanks !!!

from homebridge-z2m.

+1 this is exactly my problem, too, with Tuya TV02: TS0601_TZE200_hue3yfsn

from homebridge-z2m.

The documentation is generated automatically, so it is actually showing what the plugin will do. It clearly states this in the documentation as well.

It's still weird that it doesn't work though. Can you supply me with the debug logs of when Zigbee2MQTT starts (and it tries to create the services)?
I imagine that it might log some error/warning about this device.

Also, the status update you provided in your report can't really be from this device, as it doesn't have a state property defined in its exposes information.

from homebridge-z2m.

Just had a look at the code, the code currently expects the device to publish its setpoint (e.g. current_heating_setpoint), but according to the access level in the exposes information this is not published.

Can you confirm if the device actually does publish its setpoint?
E.g. if you change the setpoint on the device, do you see a state update messages from the device in MQTT with the updated setpoint?

from homebridge-z2m.

Thanks for your help @itavero.

Here is what I see in the logs following a restart with debug logging enabled:

info  2023-02-03 15:56:38: Guest room nr kitchen: Thermostat (0x84fd27fffe0cf20f): TV02-Zigbee - TuYa Thermostat radiator valve (EndDevice)
debug 2023-02-03 15:56:38: Passive device 'Guest room nr kitchen: Thermostat' was last seen '0.44' hours ago.
info  2023-02-03 15:56:38: MQTT publish: topic 'zigbee2mqtt/Guest room nr kitchen: Thermostat/availability', payload '{"state":"online"}'
info  2023-02-03 15:56:38: MQTT publish: topic 'zigbee2mqtt/Guest room nr kitchen: Thermostat', payload '{"battery_low":false,"boost_timeset_countdown":0,"child_lock":"UNLOCK","comfort_temperature":21,"current_heating_setpoint":21,"eco_temperature":17,"error_status":0,"frost_protection":"OFF","heating_stop":"OFF","holiday_start_stop":"2021/01/01 01:01 | 2021/01/01 01:01","holiday_temperature":17,"linkquality":69,"local_temperature":21.8,"local_temperature_calibration":0,"online":"ON","open_window":"OFF","open_window_temperature":21,"preset":"auto","schedule_friday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_monday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_saturday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_sunday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_thursday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_tuesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_wednesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","system_mode":"heat","working_day":"mon_sun"}'
debug 2023-02-03 16:00:00: Received Zigbee message from 'Guest room nr kitchen: Thermostat', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,217],"type":"Buffer"},"datatype":2,"dp":24}],"seq":1}' from endpoint 1 with groupID 0
info  2023-02-03 16:00:00: MQTT publish: topic 'zigbee2mqtt/Guest room nr kitchen: Thermostat', payload '{"battery_low":false,"boost_timeset_countdown":0,"child_lock":"UNLOCK","comfort_temperature":21,"current_heating_setpoint":21,"eco_temperature":17,"error_status":0,"frost_protection":"OFF","heating_stop":"OFF","holiday_start_stop":"2021/01/01 01:01 | 2021/01/01 01:01","holiday_temperature":17,"linkquality":75,"local_temperature":21.7,"local_temperature_calibration":0,"online":"ON","open_window":"OFF","open_window_temperature":21,"preset":"auto","schedule_friday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_monday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_saturday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_sunday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_thursday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_tuesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_wednesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","system_mode":"heat","working_day":"mon_sun"}'

I made an explicit update through from Zigbee2MQTT and captured two messages in MQTT, but I can't be sure if these came from the MQTT device, or from Zigbee2MQTT. Fortunately one came through 25 minutes later, which I assume must be from the device.

Here they are:

16:05:08

{"battery_low":false,"boost_timeset_countdown":0,"child_lock":"UNLOCK","comfort_temperature":21,"current_heating_setpoint":22,"eco_temperature":17,"error_status":0,"frost_protection":"OFF","heating_stop":"OFF","holiday_start_stop":"2021/01/01 01:01 | 2021/01/01 01:01","holiday_temperature":17,"linkquality":75,"local_temperature":21.7,"local_temperature_calibration":0,"online":"ON","open_window":"OFF","open_window_temperature":21,"preset":"auto","schedule_friday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_monday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_saturday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_sunday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_thursday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_tuesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_wednesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","system_mode":"heat","working_day":"mon_sun"}

16:05:10 (I assume response)

{"battery_low":false,"boost_timeset_countdown":0,"child_lock":"UNLOCK","comfort_temperature":21,"current_heating_setpoint":22,"eco_temperature":17,"error_status":0,"frost_protection":"OFF","heating_stop":"OFF","holiday_start_stop":"2021/01/01 01:01 | 2021/01/01 01:01","holiday_temperature":17,"linkquality":69,"local_temperature":21.7,"local_temperature_calibration":0,"online":"ON","open_window":"OFF","open_window_temperature":21,"preset":"auto","schedule_friday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_monday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_saturday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_sunday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_thursday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_tuesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_wednesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","system_mode":"heat","working_day":"mon_sun"}

16:30:00

{"battery_low":false,"boost_timeset_countdown":0,"child_lock":"UNLOCK","comfort_temperature":21,"current_heating_setpoint":22,"eco_temperature":17,"error_status":0,"frost_protection":"OFF","heating_stop":"OFF","holiday_start_stop":"2021/01/01 01:01 | 2021/01/01 01:01","holiday_temperature":17,"linkquality":72,"local_temperature":21.6,"local_temperature_calibration":0,"online":"ON","open_window":"OFF","open_window_temperature":21,"preset":"auto","schedule_friday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_monday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_saturday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_sunday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_thursday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_tuesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_wednesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","system_mode":"heat","working_day":"mon_sun"}

from homebridge-z2m.

I do see current_heating_setpoint, but I reckon you have caching turned on in Zigbee2MQTT as well?

Not sure if you understood my previous message correctly. I meant changing the setpoint by using the interface on the device (e.g., not via Zigbee2MQTT, but physically doing something on the device).
If you do that, do you immediately see the updated current_heating_setpoint in MQTT?

If so, it seems that the device actually does publish this data actively and the exposes information might be incorrect.

I could remove the requirement for the value being published, but that could mean that, when the setpoint is changed on the device, this does not end up in HomeKit.

from homebridge-z2m.

Not sure if you understood my previous message correctly. I meant changing the setpoint by using the interface on the device (e.g., not via Zigbee2MQTT, but physically doing something on the device).

Ah, sorry, I did misunderstand. I am afraid I am away from home for a few days, so will try again on the weekend and share the details.

it seems that the device actually does publish this data actively and the exposes information might be incorrect.

I am not sure I follow, it seems the MQTT raw data matches the exposes data. What am I missing?

I could remove the requirement for the value being published, but that could mean that, when the setpoint is changed on the device, this does not end up in HomeKit.

Which value are you referring to? I'm happy to play around with the code too if it helps.

Let me send you the info when I get back home this weekend and we can take it from there.

Thanks for your help 👏

from homebridge-z2m.

I am not sure I follow, it seems the MQTT raw data matches the exposes data. What am I missing?

Yeah, but you probably have caching turned on in Zigbee2MQTT (it's the default configuration). So the presence of data members doesn't tell us that much.

The access level for current_heating_setpoint does not have the bit set that indicates that this property is published (more or less meaning that you get informed by Zigbee2MQTT when it changes rather than actively having to request it).
Currently the code requires this bit to be set (see the PREDICATE_SETPOINT in src/converters/climate.ts, which includes the exposesIsPublished check).

from homebridge-z2m.

I'm not very technical, so please disregard if not relevant, but I think I see the exact same thing with my thermostat also. According to the Thermostat Documentation, it exposes attributes that should cause it to show up as a thermostat in HomeKit, but it just says "Not Supported" with a generic Home icon.

My Thermostat is the Centralite Pearl 3-Series, Model 3157100.

According to the Zigbee2MQTT database (and also according to what I see in Zigbee2MQTT front end) it exposes:

• battery
• temperature_setpoint_hold
• linkquality
• climate, including:
  • occupied_heating_setpoint
  • local_temperature
  • system_mode
  • running_state
  • fan_mode
  • occupied_cooling_setpoint
  • local_temperature_calibration

But in the Z2M database, it just lists as exposed:

• battery
  • Battery Level
  • Charging State
  • Status Low Battery

I can use the thermostat just fine in the front end, everything works right, just not in HomeKit.

Apologies if this is not relevant, but it seemed like the same kind of issue on the same type of device.

from homebridge-z2m.

My Thermostat is the Centralite Pearl 3-Series, Model 3157100.

@keness521 This is a different device which is not exposed as a Thermostat in HomeKit as it also exposes an occupied_cooling_setpoint. This currently is expected behavior for homebridge-z2m, as is also mentioned/explained in the documentation for the Thermostat handler. This is not related to the issue being discussed here.

from homebridge-z2m.

Got it. Sorry, not sure how I missed that note at the bottom. I think because I use mine exclusively as a heater, there’s no air conditioner connected to my thermostat, I wasn’t paying enough attention to that point once I saw it talking about cooling.

Thanks for everything Z2M does! Everything works incredibly well for me, and I’ve just been using the thermostat in the Zigbee2MQTT front end which is not bad.

from homebridge-z2m.

I think because I use mine exclusively as a heater, there’s no air conditioner connected to my thermostat, I wasn’t paying enough attention to that point once I saw it talking about cooling.

In your case, you can probably try to add occupied_cooling_setpoint to the excluded properties for that device in the plugin configuration. It might still show up as a thermostat in that case (I haven't checked all the other exposes information, so not 100% sure, but maybe it's worth a shot).

from homebridge-z2m.

In your case, you can probably try to add occupied_cooling_setpoint to the excluded properties for that device in the plugin configuration. It might still show up as a thermostat in that case (I haven't checked all the other exposes information, so not 100% sure, but maybe it's worth a shot).

That worked, thank you very much! That thermostat was the only device I had which wasn't making it into HomeKit. It works perfectly now. I have a followup question, but I'll start a new thread to avoid hijacking this one. Thanks again!

from homebridge-z2m.

@itavero thanks for your help.

I disabled all cacheing, and did the following:

1. Changed the heating setting and received the following messages:

{"current_heating_setpoint":17.0,"linkquality":42}

{"current_heating_setpoint":17.5,"linkquality":42}

(i.e. one message for each 0.5 degree temp increment)

2. Restarted the device

It streams a bunch of settings after reboot (apologies for the screenshot, I was unable to get this copied & pasted from the MQTT client. Clearly it sends one setting at a time, and the Zigbee2MQTT cacheing helps is build up the state from each setting.

3. I changed the temp from Zigbee2MQTT and got the following:

{"current_heating_setpoint":17,"linkquality":48}

Does any of that help? Is there anything I can do on my end to test a code change perhaps? Shout if I can help in any way.

Thanks again

from homebridge-z2m.

@mattheworiordan Thanks for the feedback. Based on your message I would say that the device does publish the current_heating_setpoint, so the exposes information provided by Zigbee2MQTT is incorrect.
I would suggest opening an issue/PR on Koenkk/zigbee-herdsman-converters to get this corrected.

I believe that, if the access level for this property is set correctly, homebridge-z2m should pick up the device as a Thermostat.

from homebridge-z2m.

Thanks for your response @itavero.

I am more than happy to raise an issue in the zigbee-herdsmand-converters project, however I am not clear on what I am meant to report as I am unclear on the problem due to the following:

1. We know that the device does publish current_heating_setpoint.
2. I can see that my device is identified as _TZE200_hue3yfsn, which has a mapping/converter defined correctly at https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices/tuya.js#L2226, which identifies the device as a TV02-Zigbee
3. The code exposes temperature using current_heating_setpoint.
4. The state exposed by Zigbee2MQTT follows a structure that I understood is expected from homebridge-z2m (see https://github.com/itavero/homebridge-z2m/blob/master/docs/climate.md):

{
    "battery_low": false,
    ...
    "current_heating_setpoint": 17,
    ....
    "error_status": 0,
    ...
    "linkquality": 21,
    "local_temperature": 21.4,
    "local_temperature_calibration": 0,
    "online": "ON",
    ...
    "system_mode": "heat", ...
}

So specifically:

Based on your message I would say that the device does publish the current_heating_setpoint, so the exposes information provided by Zigbee2MQTT is incorrect

I'm happy to confirm that, but is there a way to confirm the exposes information is incorrect. As above, I can only see evidence it is correct. Every 30 minutes I see a complete payload published on the local MQTT server with what appears to be the correct information:

{"battery_low":false,"boost_timeset_countdown":0,"child_lock":"UNLOCK","comfort_temperature":21,"current_heating_setpoint":17,"eco_temperature":17,"error_status":0,"frost_protection":"OFF","heating_stop":"OFF","holiday_start_stop":"2021/01/01 01:01 | 2021/01/01 01:01","holiday_temperature":17,"linkquality":21,"local_temperature":21.4,"local_temperature_calibration":0,"online":"ON","open_window":"OFF","open_window_temperature":21,"preset":"auto","schedule_friday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_monday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_saturday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_sunday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_thursday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_tuesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","schedule_wednesday":"06:00/17 12:00/21 14:00/17 17:00/21 24:00/17","system_mode":"heat","working_day":"mon_sun"}

I believe that, if the access level for this property is set correctly, homebridge-z2m should pick up the device as a Thermostat.

Can you elaborate what you mean by the access level being correct? The exposes information in herdsman looks correct to me.

Thanks again for your help with this.

from homebridge-z2m.

The access level in the exposes informatie for this property indicates that it is not published.

https://www.zigbee2mqtt.io/guide/usage/exposes.html#access

from homebridge-z2m.

Ok @itavero I think I understand now, sorry it took me a while.

When I look at the state of the thermostat I see the following:

So that access should be 3 or 7, but not 2 as that indicates a lack of "The property can be found in the published state of this device".

I will raise an issue now in that repo. Thanks

from homebridge-z2m.

@itavero I have created a PR Koenkk/zigbee-herdsman-converters#5473.
Can I ask a favour that you take a quick look (it's only one line) to see if you think this is what is needed?

I have tried to run this locally by modifying the file in node_modules, but I am still getting access 2. I am not sure if perhaps I am not following the right workflow, or if my change is not sufficient. Any advice very welcome!

from homebridge-z2m.

I think that is it, indeed. I would expect that changing this locally would result in the exposes information to be updated as well.
Silly question perhaps but you did restart Zigbee2MQTT after making this change?

from homebridge-z2m.

Silly question perhaps but you did restart Zigbee2MQTT after making this change?

Yes, but I used the web restart. Thinking about that, and not knowing how the restart works, it's possible the app did not reload, but just restarted inline. I should have restarted the service at an OS level.

I'll keep you posted, thanks for your help.

from homebridge-z2m.

Koenkk/zigbee-herdsman-converters#5473 has now been merged.
How do you typically update downstream dependencies, and should I expect this to be merged and released at some point?
Thanks.

from homebridge-z2m.

Koen typically makes a release of Zigbee2MQTT (and zigbee-herdsman-converters) at the beginning of every month including everything that has been merged up to that point.

I believe there's also some information on the Zigbee2MQTT website about how to already run the current master branch version.

The homebridge-z2m plugin will not need an update in this case as it is decoupled from Zigbee2MQTT itself. It simply uses the information published to MQTT by Zigbee2MQTT.

from homebridge-z2m.