PI Heating Demand on Sinope TH1223ZB incorrectly controlling running state
See original GitHub issueI have a Sinopé TH1223ZB thermostat which is currently reporting state:
{
"current": 6962,
"keypad_lockout": 0,
"linkquality": 255,
"local_temperature": 18,
"occupied_heating_setpoint": 19,
"operation": "heating",
"pi_heating_demand": 16,
"running_mode": "heat",
"running_state": "heat",
"system_mode": "heat",
"voltage": 1206
}
However the heater is not running. Seems like running_state
is calculated from pi_heating_demand >= 10
which does not appear to be correct for at least this model. I’m watching to see exactly what it should be.
I tested using Docker image tagged latest-dev
and have legacy: false
on the device settings.
Issue Analytics
- State:
- Created 2 years ago
- Comments:26 (9 by maintainers)
Top Results From Across the Web
No results found
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
#2738 fixed 2 things.
@crbn60 , My findings on this issue are:
Problem with MQTT state->pi_heating_demand When investigating this issue with my TH1124ZB, I discovered that when Zigbee hvacThermostat->piHeatingDemand = 100 the MQTT state->pi_heating_demand = 39 . It seems that Zigbee hvacThermostat->piHeatingDemand is scaled from 256 to 100 when it shouldn’t. There is a problem here.
Need to adjust MQTT state->running_state based on support of Zigbee hvacThermostat->runningState reporting. The main reason MQTT state->running_state is based on Zigbee hvacThermostat->piHeatingDemand is because older firmware didn’t support the Zigbee hvacThermostat->runningState reporting. If possible, a fix will be required to differentiate between those that have it and others that don’t. Fixing the previous problem will also improve this. BTW, there is no relation with the Zigbee2mqtt legacy configuration option
Instability of Sinope Zigbee _hvacThermostat->runningState During testing I notice a lot of change (instability between polling) of Zigbee _hvacThermostat->runningState , Such instability could generate a lot of traffic on the Zigbee network. The actual reporting has a minimum interval set to 0 seconds. On a network with 10-15 thermostats like mine, this means a lot of traffic when trottling home temperature in the winter. A fix will be required to reduce the occurrence of those reports. A minimum of 10 seconds between updates should do it. In sinope.js , replacing all occurence: await reporting.thermostatRunningState(endpoint); by: await reporting.thermostatRunningState(endpoint , {min: 10, max: 302, change: 1});
@Koenkk, my developement setup is not operational. Can-you help on this ? Also, how can I activate the loging of incoming Zigbee packets (I really miss this feature) ?
PR #3551 will fix the current and voltage scaling problem you have with TH1123ZB.