Drayton Wiser / Schneider Electric iTRV Issues

[GSzabados (Gábor Szabados)]

@10100011

I’ve got 3 x WV704R0A0902 TRVs bought as a pack running firmware f60f643; no Wiser Hub. These have worked well for about two months but, after a hard reset, 1 x TRV has started automatically changing its setpoint to 20°C. The other two TRVs still work as expected. I’m therefore in a privileged position to be able to compare TRVs with and without issues.

This looks quite interesting!

Can you please check that all the TRVs are reported as the same kind of device. I mean they are all reported as WV704R0A0902 in Z2M?

As for debugging the issue, can you try the following, a bit different than what you have done before with an extra step.

Reset the device and force remove from Z2M as before, but as a twist, please restart Z2M before trying to pair it again. You don’t need to leave the batteries out for 2+ days.

After the restart, try to pair it again, and let’s see how it goes.

You can add the bindings manually if you want, and probably you are right regarding the “some artefact” statement.

Also, if the above does not fixes the TRV’s reporting, then you can try to use the “Reconfigure device” button. You know the yellow one on the device’s page with the “refresh icon” in Z2M. But I hope the first one will solve the issue.

[10100011]

@GSzabados

Can you please check that all the TRVs are reported as the same kind of device. I mean they are all reported as WV704R0A0902 in Z2M?

Confirmed as being 3 x WV704R0A0902 TRVs. FWIW, the IEEE Address of the problem device is within 0x5085 = 20,645 of the other two, which are themselves consecutive - but, as I say, even the TRV with the issue worked fine until it was hard reset.

Good idea to make sure the reset is complete. I followed these steps:

• Force removed device
• Hard reset (turned to ‘-’ until 8 x red flashes)
• Restarted Z2M
• Attempted to pair again
• Tried to reconfigure once it was clear pairing was only partially successful; same result.

Device is accepted and is available, but an error occurs in the logs and there are some interesting entries: the frequent skipping of what appear to be useful messages from the device may be a red flag. I’ve also tried looking through zigbee-herdsman/deconzAdapter.ts but that doesn’t seem to point to what error 140 means (or I just haven’t found it):

info  2022-11-28 20:30:25: Zigbee: allowing new devices to join.
info  2022-11-28 20:30:51: Device '0x50325ffffxxxxxxx' joined
info  2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x50325ffffxxxxxxx","ieee_address":"0x50325ffffxxxxxxx"},"type":"device_joined"}'
info  2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x50325ffffxxxxxxx"},"type":"device_connected"}'
info  2022-11-28 20:30:51: Starting interview of '0x50325ffffxxxxxxx'
info  2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x50325ffffxxxxxxx","ieee_address":"0x50325ffffxxxxxxx","status":"started"},"type":"device_interview"}'
info  2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x50325ffffxxxxxxx"},"type":"pairing"}'
debug 2022-11-28 20:30:51: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
debug 2022-11-28 20:30:51: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:52: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"modelId":"iTRV"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:52: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:52: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"manufacturerName":"Schneider Electric"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:52: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:52: Received Zigbee message from 'Thermostat-Hallway', type 'commandCheckIn', cluster 'genPollCtrl', data '{}' from endpoint 9 with groupID null
debug 2022-11-28 20:30:52: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"powerSource":3}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:52: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genOta', data '{"currentFileVersion":56000,"currentZigbeeStackVersion":2,"fileOffset":4294967295,"imageTypeId":513,"imageUpgradeStatus":0,"manufacturerId":4190}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'hvacUserInterfaceCfg', data '{"keypadLockout":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genPowerCfg', data '{"256":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"BAT,2.90,Full"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genBasic', data '{"57345":"0201000000056000","57346":"0","57348":"50325FFFFE496716"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"zclVersion":2}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:54: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"appVersion":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:54: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:54: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:54: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"hwVersion":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:55: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:55: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:56: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"swBuildId":"f60f643"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:56: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:57: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genPollCtrl', data '{"checkinInterval":14400}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:57: Skipping message, definition is undefined and still interviewing
info  2022-11-28 20:30:57: Successfully interviewed '0x50325ffffxxxxxxx', device has successfully been paired
info  2022-11-28 20:30:57: Device '0x50325ffffxxxxxxx' is supported, identified as: Schneider Electric Wiser radiator thermostat (WV704R0A0902)
info  2022-11-28 20:30:57: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Wiser radiator thermostat","exposes":[{"features":[{"access":7,"description":"Temperature setpoint","name":"occupied_heating_setpoint","property":"occupied_heating_setpoint","type":"numeric","unit":"°C","value_max":30,"value_min":7,"value_step":1},{"access":1,"description":"Current temperature measured on the device","name":"local_temperature","property":"local_temperature","type":"numeric","unit":"°C"},{"access":1,"description":"The current running state","name":"running_state","property":"running_state","type":"enum","values":["idle","heat"]},{"access":1,"description":"Position of the valve (= demanded heat) where 0% is fully closed and 100% is fully open","name":"pi_heating_demand","property":"pi_heating_demand","type":"numeric","unit":"%","value_max":100,"value_min":0}],"type":"climate"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"WV704R0A0902","options":[{"access":2,"description":"Controls the temperature unit of the thermostat (default celsius).","name":"thermostat_unit","property":"thermostat_unit","type":"enum","values":["celsius","fahrenheit"]},{"access":2,"description":"Set to false to disable the legacy integration (highly recommended), will change structure of the published payload (default true).","name":"legacy","property":"legacy","type":"binary","value_off":false,"value_on":true}],"supports_ota":false,"vendor":"Schneider Electric"},"friendly_name":"0x50325ffffxxxxxxx","ieee_address":"0x50325ffffxxxxxxx","status":"successful","supported":true},"type":"device_interview"}'
info  2022-11-28 20:30:57: Configuring '0x50325ffffxxxxxxx'
info  2022-11-28 20:30:57: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_successful","meta":{"description":"Wiser radiator thermostat","friendly_name":"0x50325ffffxxxxxxx","model":"WV704R0A0902","supported":true,"vendor":"Schneider Electric"},"type":"pairing"}'
info  2022-11-28 20:30:57: MQTT publish: topic 'homeassistant/sensor/0x50325ffffxxxxxxx/pi_heating_demand/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"entity_category":"diagnostic","icon":"mdi:radiator","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx pi heating demand","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_pi_heating_demand_zigbee2mqtt","unit_of_measurement":"%","value_template":"{{ value_json.pi_heating_demand }}"}'
info  2022-11-28 20:30:57: MQTT publish: topic 'homeassistant/climate/0x50325ffffxxxxxxx/climate/config', payload '{"action_template":"{% set values = {None:None,'idle':'off','heat':'heating','cool':'cooling','fan_only':'fan'} %}{{ values[value_json.running_state] }}","action_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","availability":[{"topic":"zigbee2mqtt/bridge/state"}],"current_temperature_template":"{{ value_json.local_temperature }}","current_temperature_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","max_temp":"30","min_temp":"7","name":"0x50325ffffxxxxxxx","temp_step":1,"temperature_command_topic":"zigbee2mqtt/0x50325ffffxxxxxxx/set/occupied_heating_setpoint","temperature_state_template":"{{ value_json.occupied_heating_setpoint }}","temperature_state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","temperature_unit":"C","unique_id":"0x50325ffffxxxxxxx_climate_zigbee2mqtt"}'
info  2022-11-28 20:30:57: MQTT publish: topic 'homeassistant/sensor/0x50325ffffxxxxxxx/linkquality/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"enabled_by_default":false,"entity_category":"diagnostic","icon":"mdi:signal","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx linkquality","state_class":"measurement","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_linkquality_zigbee2mqtt","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}"}'
debug 2022-11-28 20:30:57: Received MQTT message on 'homeassistant/sensor/0x50325ffffxxxxxxx/pi_heating_demand/config' with data '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"entity_category":"diagnostic","icon":"mdi:radiator","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx pi heating demand","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_pi_heating_demand_zigbee2mqtt","unit_of_measurement":"%","value_template":"{{ value_json.pi_heating_demand }}"}'
debug 2022-11-28 20:30:57: Received MQTT message on 'homeassistant/climate/0x50325ffffxxxxxxx/climate/config' with data '{"action_template":"{% set values = {None:None,'idle':'off','heat':'heating','cool':'cooling','fan_only':'fan'} %}{{ values[value_json.running_state] }}","action_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","availability":[{"topic":"zigbee2mqtt/bridge/state"}],"current_temperature_template":"{{ value_json.local_temperature }}","current_temperature_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","max_temp":"30","min_temp":"7","name":"0x50325ffffxxxxxxx","temp_step":1,"temperature_command_topic":"zigbee2mqtt/0x50325ffffxxxxxxx/set/occupied_heating_setpoint","temperature_state_template":"{{ value_json.occupied_heating_setpoint }}","temperature_state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","temperature_unit":"C","unique_id":"0x50325ffffxxxxxxx_climate_zigbee2mqtt"}'
debug 2022-11-28 20:30:57: Received MQTT message on 'homeassistant/sensor/0x50325ffffxxxxxxx/linkquality/config' with data '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"enabled_by_default":false,"entity_category":"diagnostic","icon":"mdi:signal","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx linkquality","state_class":"measurement","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_linkquality_zigbee2mqtt","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}"}'
error 2022-11-28 20:30:58: Failed to configure '0x50325ffffxxxxxxx', attempt 1 (Error: Bind 0x50325ffffxxxxxxx/1 genPowerCfg from '0x00212effff05b9fb/1' failed (Error: status: 140)
    at DeconzAdapter.bind (/app/node_modules/zigbee-herdsman/src/adapter/deconz/adapter/deconzAdapter.ts:768:19)
    at Endpoint.bind (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:567:13)
    at Object.bind (/app/node_modules/zigbee-herdsman-converters/lib/reporting.js:40:9)
    at Object.configure (/app/node_modules/zigbee-herdsman-converters/devices/schneider_electric.js:220:13)
    at Configure.configure (/app/lib/extension/configure.ts:115:13))
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1412,1371,1,204,-32768,2000,0,0,100,212,227,237"}' from endpoint 1 with groupID null
info  2022-11-28 20:31:05: Configuring '0x50325ffffxxxxxxx'
info  2022-11-28 20:31:05: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1412,1371,1,204,-32768,2000,0,0,100,212,227,237","linkquality":255,"local_temperature":20.4,"occupied_heating_setpoint":20,"pi_heating_demand":null,"running_state":null}'
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ALG,1,1,200,204,-4,0,0,0,0,0,100"}' from endpoint 1 with groupID null
info  2022-11-28 20:31:05: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1412,1371,1,204,-32768,2000,0,0,100,212,227,237","ALG":"1,1,200,204,-4,0,0,0,0,0,100","linkquality":255,"local_temperature":20.4,"occupied_heating_setpoint":20,"pi_heating_demand":0,"running_state":null}'
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":148,"lastMessageRssi":-63}' from endpoint 1 with groupID null
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"57345":65534}' from endpoint 1 with groupID null
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"RST,06,0601,346951ms ago."}' from endpoint 1 with groupID null

Finally, worth mentioning that the device is removed entirely from /config/zibee2mqtt/database.db and state.json once it is removed from the UI - which is what you’d expect - so if there’s an artefact somewhere it might be elsewhere. After re-pairing, the device appears in both files but its entry in database.db is notably smaller than those of the other two identical TRVs. Which, if it’s ignoring messages from the device, may also be what you’d expect.

[GSzabados (Gábor Szabados)]

@10100011

Tried to reconfigure once it was clear pairing was only partially successful; same result.

Has it fulfilled all the bindings as the others?

If the interview/configuration is non-successful then you can try during the interview/configuration to twist the head to keep the device “awake”.

Also, as a test, you can try to reset the device twice.

At the end in the log the configuration finished with or without an error? Do you see the Failed to configure '0x50325ffffxxxxxxx', attempt 1 (Error: Bind 0x50325ffffxxxxxxx/1 genPowerCfg from '0x00212effff05b9fb/1' failed (Error: status: 140) multiple times or only once?

[10100011]

@GSzabados

Has it fulfilled all the bindings as the others?

It had not fulfilled the bindings. The error was also repeated multiple times (at least 3, possibly 4).

However, there’s some hopeful news this morning. Inspired by your suggestions to “try to reset the device twice” and also to “restart Z2M”, I have now got Bind, Reporting, and State tabs which are consistent with the other two TRVs. And no errors in the logs.

I’ve had the TRV batteries out overnight. It may not be necessary to wait that long: think I read a suggestion to try that with a different Wiser device. Maybe a minute or two is required, if at all?

Starting with the TRV force removed from Z2M and the TRV with batteries out, detailed steps:

1. Insert batteries and let the TRV boot
2. Twist to ‘-’ to reset. Repeat this step until only 5 x red flashes occurred before lights off (usually expect 8 x flashes)
3. TRV is now flashing red-yellow-blue
4. Enable device joining in Z2M. Twist to ‘+’ to pair:
   a. Pairing appeared successful with no errors
   b. State appeared more complete / consistent with the other devices
   c. Bind and Report entries did not appear complete
5. TRV is now flashing red-green-blue
6. Restart Z2M
7. Seemed to continue pairing:
   a. Green pop-up in Z2M indicated further pairing was occurring
   b. Bind and Reporting entries in Z2M now appear complete

So the TRV, which used to work fine and has only experienced this issue over the past week, now appears to be in a state consistent with the other two identical TRVs, which have continued to work correctly.

Will this fix the 20°C issue? I’ll let you know in a few hours…

[GSzabados (Gábor Szabados)]

@10100011

Restart Z2M

I experienced that with Z2M, if the device was forced removed and the paired back, Z2M was not doing a full interview and configuration. That’s why I suggested that step, before pairing.

For the missing binding, if the device failed on the power configuration binding, that means the whole binding part hasn’t finished of the code as it exited with and error message.
If the device stops doing the 20C resets, then it means, it needs to have these bindings for correct operation.

{
        zigbeeModel: ['iTRV'],
        model: 'WV704R0A0902',
        vendor: 'Schneider Electric',
        description: 'Wiser radiator thermostat',
        fromZigbee: [fz.ignore_basic_report, fz.ignore_haDiagnostic, fz.ignore_genOta, fz.ignore_zclversion_read,
            fz.legacy.wiser_thermostat, fz.legacy.wiser_itrv_battery, fz.hvac_user_interface, fz.wiser_device_info],
        toZigbee: [tz.thermostat_occupied_heating_setpoint, tz.thermostat_keypad_lockout],
        exposes: [exposes.climate().withSetpoint('occupied_heating_setpoint', 7, 30, 1).withLocalTemperature(ea.STATE)
            .withRunningState(['idle', 'heat'], ea.STATE).withPiHeatingDemand()],
        configure: async (device, coordinatorEndpoint, logger) => {
            const endpoint = device.getEndpoint(1);
            const binds = ['genBasic', 'genPowerCfg', 'hvacThermostat', 'haDiagnostic'];
            await reporting.bind(endpoint, coordinatorEndpoint, binds);
            await reporting.batteryVoltage(endpoint);
            await reporting.thermostatTemperature(endpoint);
            await reporting.thermostatOccupiedHeatingSetpoint(endpoint);
            await reporting.thermostatPIHeatingDemand(endpoint);
            // bind of hvacUserInterfaceCfg fails with 'Table Full', does this have any effect?
            await endpoint.configureReporting('hvacUserInterfaceCfg', [{attribute: 'keypadLockout', reportableChange: 1,
                minimumReportInterval: constants.repInterval.MINUTE, maximumReportInterval: constants.repInterval.HOUR}]);
        },
    },

For getting the device “depleted”, it is enough to twist the head a few times after you removed the battery.

[10100011]

It has reset to 20°C.

I noticed, just before it changed, that three lights flashed: red-???-blue (??? = presumably green or yellow - can’t remember which)

See what you think of the logs. It appears to me that something external to the TRV is making the change to 20°, based on an entry at 10:59:58, unless the TRV itself is publishing to the topic? Is there a way to trace the source of a message? I’ve enabled debug logging on the MQTT broker

Zigbee2MQTT:debug 2022-11-29 10:58:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1485,1487,3,185,-32768,1500,0,0,100,185,185,189"}' from endpoint 1 with groupID null
Zigbee2MQTT:info  2022-11-29 10:58:44: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:58:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ALG,1b,1,150,185,-35,0,0,0,0,0,100"}' from endpoint 1 with groupID null
Zigbee2MQTT:info  2022-11-29 10:58:44: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:58:45: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":172,"lastMessageRssi":-57}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genOta', data '{"currentFileVersion":56000,"currentZigbeeStackVersion":2,"fileOffset":4294967295,"imageTypeId":513,"imageUpgradeStatus":0,"manufacturerId":4190}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3874,4240"}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'hvacUserInterfaceCfg', data '{"keypadLockout":0}' from endpoint 1 with groupID null
Zigbee2MQTT:info  2022-11-29 10:59:46: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genPowerCfg', data '{"batteryVoltage":29}' from endpoint 1 with groupID null
Zigbee2MQTT:info  2022-11-29 10:59:46: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genPowerCfg', data '{"256":0}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:48: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:48: Received Zigbee message from '0x50325ffffxxxxxxx', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":56000,"imageType":513,"manufacturerCode":4190}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:48: Device '0x50325ffffxxxxxxx' requested OTA
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1486,1483,1,185,-32768,2000,0,435,100,185,186,190"}' from endpoint 1 with groupID null
Zigbee2MQTT:info  2022-11-29 10:59:58: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1486,1483,1,185,-32768,2000,0,435,100,185,186,190","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":20,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ALG,1,1,200,185,15,435,435,1,435,81,100"}' from endpoint 1 with groupID null
Zigbee2MQTT:info  2022-11-29 10:59:58: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1486,1483,1,185,-32768,2000,0,435,100,185,186,190","ALG":"1,1,200,185,15,435,435,1,435,81,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":20,"pi_heating_demand":81,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":172,"lastMessageRssi":-57}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"57345":65534}' from endpoint 1 with groupID null

FWIW, the request for OTA looks like it might be relevant, but a working TRV logged the same activity a few seconds earlier:

Zigbee2MQTT:debug 2022-11-29 10:59:36: Received Zigbee message from 'WorkingTRV', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":192,"lastMessageRssi":-52}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:36: Received Zigbee message from 'WorkingTRV', type 'attributeReport', cluster 'haDiagnostic', data '{"57345":59735}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:36: Received Zigbee message from 'WorkingTRV', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":56000,"imageType":513,"manufacturerCode":4190}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:36: Device 'WorkingTRV' requested OTA
Zigbee2MQTT:debug 2022-11-29 10:59:38: Received Zigbee message from 'WorkingTRV', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1634,1634,2,130,-32768,1100,0,0,100,130,130,130"}' from endpoint 1 with groupID null

Finally, these entries frequently appear in the MQTT broker logs:

2022-11-29 10:59:46: New connection from 172.30.32.2:43098 on port 1883.
2022-11-29 10:59:46: Client <unknown> closed its connection.
2022-11-29 11:01:46: New connection from 172.30.32.2:44750 on port 1883.

I’m assuming 172.x.x.x is the Docker subnet?

[10100011]

20°C issue 'hack’

There is a fix workaround hack which seems to stop the TRV resetting to 20°C. It has so far remained constant for five days, and I have been able to replicate it multiple times.

I use Zigbee2MQTT but maybe it can be adapted for ZHA.

---

Step 1: Clean out.

• Remove / delete TRV from Home Assistant.
• Force remove from Z2M.
• Reset TRV by holding it towards minus.
• Reset again until the TRV flashes red exactly 5 times (not 8; not 3)
• Restart Z2M (HA: Settings -> Add-Ons -> Zigbee2MQTT).

Step 2: Pair TRV. This may appear to work but check whether there are multiple bindings under Z2M: [device] -> Reporting. There should be five but frequently there are none: this means it has only partially paired. You are likely also to see errors in the logs.

If bindings are missing:

• Restart Z2M
• Check for errors / bindings
• If errors and / or missing bindings, reset the TRV again without removing it from HA or Z2M. The number of red flashes is unimportant at this stage.
• Pair again
• Restart Z2M again
• Repeat until bindings are complete.

In short: restart / reset / re-pair / repeat.

I have found this process has a good chance of success but it’s not an exact science and YMMV.

Step 3: Disable the TRV in Home Assistant between 1h 45m and 2h 15m after successful pairing.

HA: Settings -> Devices & Services -> MQTT (n devices) -> [TRV] -> Edit Settings (pencil icon) -> Toggle 'Enable device'.

It’s a good idea to change the setpoint to something other than 20°C before disabling it, just to prove that it hadn’t changed when you re-enable it. Don’t disable it too early: at around 1h 30m the TRV whirrs and adjusts itself, but if it’s disabled at this time then the hack fails.

At 2h 15m, re-enable the device. It should now stop resetting to 20°C.

---

Good luck. Feedback welcome.

[GSzabados (Gábor Szabados)]

@10100011

Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3874,4240"}' from endpoint 1 with groupID null

Can you try to set up an automation to react to the aforementioned message with a heating setpoint publish to the TRV?

Just a blind guess, but this seems to be really suspicious to me…

[10100011]

It seems a reasonable blind guess. WiserHeatUserRejoin consistently appears in the logs about 12 seconds before the TRV reports a new setpoint of 20°C.

Do you know of a way to get the automation to trigger only when the payload includes that string? The following automation trigger triggers on every message but the condition also seems to block every message, and obviously I want to react only to messages that include WiserHeatUserRejoin:

  - platform: mqtt
    topic: zigbee2mqtt/0x50325ffffxxxxxxx
condition:
  - condition: template
    value_template: "{{ \"WiserHeatUserRejoin\" in trigger.payload }}"

Incidentally, the ‘hack’ I wrote above held successfully for five days, until I reset the TRV to continue experimenting.

[GSzabados (Gábor Szabados)]

@10100011

Do you know of a way to get the automation to trigger only when the payload includes that string?

You need to write an external converter to get that wiserDeviceInfo published as well. As I see that data does not get published. It is actually only in the log.

But you can write the converter that way, if the Rejoin message received, then publish the target temperature.

By the way, do the other devices have the same Rejoin messages?

[10100011]

@GSzabados

You need to write an external converter to get that wiserDeviceInfo published as well. As I see that data does not get published. It is actually only in the log.

This is pushing my knowledge a little so, to be clear, is it the case that Zigbee messages are sent directly from the device to Z2M but Z2M-to-device are buffered via the MQ broker? In which case, that means the WiserHeatUserRejoin message is definitely coming from the TRV.

@GSzabados

By the way, do the other devices have the same Rejoin messages?

They do not. Looking at the log files in ~/config/zigbee2mqtt/log, the string WiserHeatUserRejoin only appears yesterday (after I’d reset the TRV) and five days prior (when it was last reset). The other two TRVs have never had that message, and the TRV I’m working on did not have it after the ‘hack’ was implemented.

FWIW, with the bindings missing I disabled the TRV overnight to see if it would reset to 20°C: it did reset. That could be because disabling it didn’t block the very first message, or because the bindings are essential to the ‘hack’. TBC.

[GSzabados (Gábor Szabados)]

@10100011

Zigbee messages are sent directly from the device to Z2M but Z2M-to-device are buffered via the MQ broker? In which case, that means the WiserHeatUserRejoin message is definitely coming from the TRV.

Z2M is a gateway software. As the name suggests Zigbee to MQTT. The device communicates through the Zigbee protocol with Z2M. Z2M translates the Zigbee messages (or not, it depends that is it implemented or not). And then it publishes the MQTT topics as separate devices/entities what HA handles. ZHA does the same thing, but without the MQTT step.

What you see in your log, is what Z2M decodes from the Zigbee protocol. And where you see the MQTT Publish, that is the place where it publishes the results to the MQTT broker.

Those rejoins are coming from the device itself. It is not Z2M which causes it, or actually something is missing and that’s probably the reason why the device rejoins and resets the setpoint.

[10100011]

I’ve looked around, but I’m not sure how to scrape the Z2M log for the WiserHeatUserRejoin string. It’s possible to scrape the system log but logs for add-on seems more difficult.

But let’s just take a step back here: what are we trying to do / prove?

Demonstrate a link between WiserHeatUserRejoin and resetting to 20°C
I think we’ve done that. Here are the logs from the past eight days. Remember that the TRV had the ‘hack’ in place between the first and second entries (five days) and was working normally. As soon as it was reset, the messages appeared again and the setpoint kept changing back to 20°C:

[core-ssh ~]$ cd config/zigbee2mqtt/log/
[core-ssh log]$ grep "WiserHeatUser" * -r -h
debug 2022-12-01 16:56:50: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,23162940,4240"}' from endpoint 1 with groupID null
debug 2022-12-06 10:32:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserJoin,30936,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 13:01:38: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserJoin,39517,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 13:02:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserJoin,25110,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 15:14:21: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3874,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 17:25:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 19:37:03: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3875,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 21:48:22: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3870,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 23:59:43: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 02:11:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3878,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 04:22:28: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3878,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 06:33:48: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 08:45:07: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 10:56:30: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3877,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 13:07:51: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3873,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 15:19:13: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 19:41:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 21:53:13: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 02:15:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3877,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 04:27:18: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3878,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 06:38:37: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 08:49:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 11:01:20: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3877,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 13:12:43: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3873,9063"}' from endpoint 1 with groupID null

I haven’t always changed the temperature from 20°C every time, but when I have it has always changed back around the time that WiserHeatUserRejoin is logged.

(Incidentally, I’ve also noticed that the TRV motor has been running around that time - even when the setpoint was still 20° and no change was necessary)

We want to find a workaround
So far we have two:

• @madbobmcjim’s workaround, which maintains the desired setpoint by repeatedly setting it
• The hack I put together with your help, @GSzabados, which seems reliable but doesn’t explain the behaviour

It will help with further research into the underlying cause
In which case I’m happy to keep going, although I’m not sure how to proceed from here

[RolandLT]

Hello. My firmware is abe98a2 and I’ve followed your guide, but after enabling device I can’t set temperature anymore. It just keeps jumping between 16C and 18C

Empty block in chart is when I’ve disabled device in HA. bind and reporting has all the entries as per guide so I assume it has paired correctly.
Also my TRV always flashes 8 times while I hold dial turned to minus - should I release dial after 5 flashes instead?

[RolandLT]

I’ve given it another go yesterday, but this time TRV dropped from MQTT network completely before midnight and doesn’t appear in dashboard anymore.

[christatt]

Hi…

From my experience it seems that there is a polling issue when ZHA or Z2M are used which causes the iTRV to fall back to a default mode I.e resets to 20deg.

I have 8 iTRV’s and some of them hold the occupied_heating_setpoint and others that reset to 20deg after several hours.

I think that there is some merit in the “20deg hack” but it doesn’t always work.

I have noticed that the iTRV’s which reset to 20deg show their leds as disconnected, I.e when the head is twisted, the led flashes. Which means the iTRV is not connected.

Maybe the ZHA, Z2M protocol isn’t polling the iTRV as it is expecting therefore It falls back to its default mode of 20deg.

I now have a wiser hub and I’ll try and trace some logs re the polling…

[RolandLT]

As far as I’ve found from testing, it seems that iTRV “listening interval” gets shorter and shorter until it is impossible to update occupied_heating_setpoint. I have schedule which is increasing temperature by 1 degree every hour and iTRV seems to stop responding after about 4 hours or so.
It could be that iTRV need acknowledgment within some intervals or maybe even after each message it publishes - I’ve noticed that “ADC” and “ALG” changes though there is no change to other parameters.

[10100011]

@RolandLT

Also my TRV always flashes 8 times while I hold dial turned to minus - should I release dial after 5 flashes instead?

In my experience (firmware f60f643), repeating the initial reset until it flashes red 5 times is important. Once you’ve started the pairing process and are repeating Step 2 (restart / reset / re-pair), the number of reset flashes doesn’t matter.

FWIW, I’ve just had to rebuild my entire Zigbee network and had to go through the hack again x 3. I tried doing them in parallel but that definitely doesn’t work! Do them one-by-one. But they are all working again.

The disclaimer is that I have no special insight: those steps have been defined through trial and error until they were reproduceable so it’s possible different firmware behaves differently…

@RolandLT

As far as I’ve found from testing, it seems that iTRV “listening interval” gets shorter and shorter until it is impossible to update occupied_heating_setpoint.

…because this, for instance, does not match what I’ve been seeing. I’m not aware of reading about that anywhere else either.

Your chart where the TRV came online at around 14:20 looks good. It’s possible it was reconnected five minutes early but I think what you’re saying is that it had already reset to 20°C even before reconnection?

@christatt

Maybe the ZHA, Z2M protocol isn’t polling the iTRV as it is expecting therefore It falls back to its default mode of 20deg.

This would seem to be a logical explanation.

[hazymat (Mat Smith)]

I have my Drayton Wiser TRV connected to a Sonoff Zigbee wifi hub with Tasmota flashed, and I am simply trying to do two things:

• read the current temperature (no issues here)
• be able to set the target temperature (OMG - what a hassle)

(Bonus: just control the stupid motor directly!)

I’m actually wanting to control it from Node-RED not HA, and through Sonoff Zigbee bridge not Zigbee2MQTT but I’m having the same problems as everyone else above. I gather from these many posts above that my aims are not actually that easy to do!

Thanks to the excellent @10100011 for all the testing you did.

@10100011

At 2h 15m, re-enable the device. It should now stop resetting to 20°C.

That’s absolute nuts. I’m going to give it a try.

[christatt]

Ive been using the wiser hub for a few weeks now and the integration to HA is flawless so far.
I don’t think home assistant will be able to mimic the operating modes and energy saving functions in the near future directly with the valves…
I highly recommend investing in the hub, at approx the price of a couple of valves it’s worth it.