[New device support]: TCP Thermostatic Radiator Valve

james-fry commented 1 year ago

Link

Database entry

{"id":45,"type":"EndDevice","ieeeAddr":"0xec1bbdfffec28c49","nwkAddr":52001,"manufId":0,"manufName":"_TYST11_czk78ptr","powerSource":"Battery","modelId":"zk78ptr\u0000","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":0,"inClusterList":[0,3],"outClusterList":[3,25],"clusters":{"genBasic":{"attributes":{"modelId":"zk78ptr\u0000","manufacturerName":"_TYST11_czk78ptr","stackVersion":0}}},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":72,"stackVersion":0,"hwVersion":1,"dateCode":"20180727","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1662134252760,"defaultSendRequestWhen":"immediate"}

Comments

I seached the zigbee-herdsman-converters repo for the model ID and mfrs ID and couldnt find any entries.

The device appears physically identical to these supported tuya devices: https://www.zigbee2mqtt.io/devices/SMART-HEAT10.html https://www.zigbee2mqtt.io/devices/GS361A-H04.html

How can I check which (if either) of these could be a good starting template to add this new device with? I'm not a JS coder, but might be able to hack together an external converter to check it with some support...

Below is a log extract for join/interview/pairing and some messages sent by the device. Filtered by the ieee address of the device:

Info 2022-09-02 17:09:31MQTT publish: topic 'zigbee2mqtt_cc1352p/bridge/event', payload '{"data":{"friendly_name":"0xec1bbdfffec28c49","ieee_address":"0xec1bbdfffec28c49","status":"started"},"type":"device_interview"}' Info 2022-09-02 17:09:31MQTT publish: topic 'zigbee2mqtt_cc1352p/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0xec1bbdfffec28c49"},"type":"pairing"}' Info 2022-09-02 17:09:31MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:30+01:00","linkquality":78}' Debug 2022-09-02 17:09:31Device '0xec1bbdfffec28c49' announced itself Info 2022-09-02 17:09:31MQTT publish: topic 'zigbee2mqtt_cc1352p/bridge/event', payload '{"data":{"friendly_name":"0xec1bbdfffec28c49","ieee_address":"0xec1bbdfffec28c49"},"type":"device_announce"}' Info 2022-09-02 17:09:31MQTT publish: topic 'zigbee2mqtt_cc1352p/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0xec1bbdfffec28c49"},"type":"device_announced"}' Debug 2022-09-02 17:09:32Received Zigbee message from '0xec1bbdfffec28c49', type 'readResponse', cluster 'genBasic', data '{"manufacturerName":"_TYST11_czk78ptr","modelId":"zk78ptr\u0000"}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:32MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:31+01:00","linkquality":81}' Debug 2022-09-02 17:09:35Received Zigbee message from '0xec1bbdfffec28c49', type 'readResponse', cluster 'genBasic', data '{"stackVersion":0}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:35MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:34+01:00","linkquality":78}' Debug 2022-09-02 17:09:36Received Zigbee message from '0xec1bbdfffec28c49', type 'readResponse', cluster 'genBasic', data '{}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:36MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:35+01:00","linkquality":78}' Info 2022-09-02 17:09:36Successfully interviewed '0xec1bbdfffec28c49', device has successfully been paired Warning 2022-09-02 17:09:36Device '0xec1bbdfffec28c49' with Zigbee model 'zk78ptr' and manufacturer name '_TYST11_czk78ptr' is NOT supported, please follow https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html Info 2022-09-02 17:09:36MQTT publish: topic 'zigbee2mqtt_cc1352p/bridge/event', payload '{"data":{"definition":null,"friendly_name":"0xec1bbdfffec28c49","ieee_address":"0xec1bbdfffec28c49","status":"successful","supported":false},"type":"device_interview"}' Info 2022-09-02 17:09:36MQTT publish: topic 'zigbee2mqtt_cc1352p/bridge/log', payload '{"message":"interview_successful","meta":{"friendly_name":"0xec1bbdfffec28c49","supported":false},"type":"pairing"}' Debug 2022-09-02 17:09:39Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":10240}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:39MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:38+01:00","linkquality":78}' Debug 2022-09-02 17:09:39Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":5,"dp":13}],"seq":10496}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:39MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:38+01:00","linkquality":75}' Debug 2022-09-02 17:09:40Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":4,"dp":14}],"seq":10752}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:40MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:39+01:00","linkquality":75}' Debug 2022-09-02 17:09:41Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":4,"dp":4}],"seq":11008}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:41MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:40+01:00","linkquality":78}' Debug 2022-09-02 17:09:42Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":4,"dp":4}],"seq":11008}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:42MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:41+01:00","linkquality":75}' Debug 2022-09-02 17:09:43Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":4,"dp":4}],"seq":11008}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:43MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:42+01:00","linkquality":78}' Debug 2022-09-02 17:09:44Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,210],"type":"Buffer"},"datatype":2,"dp":2}],"seq":11264}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:44MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:43+01:00","linkquality":78}' Debug 2022-09-02 17:09:45Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":18}],"seq":11520}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:45MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:44+01:00","linkquality":75}' Debug 2022-09-02 17:09:46Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":18}],"seq":11520}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:46MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:45+01:00","linkquality":72}' Debug 2022-09-02 17:09:47Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":18}],"seq":11520}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:47MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:46+01:00","linkquality":75}' Debug 2022-09-02 17:09:48Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":1,"dp":7}],"seq":11776}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:48MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:47+01:00","linkquality":75}' Debug 2022-09-02 17:09:51Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":4,"dp":17}],"seq":12032}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:51MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:50+01:00","linkquality":75}' Debug 2022-09-02 17:09:54Received Zigbee message from '0xec1bbdfffec28c49', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,241],"type":"Buffer"},"datatype":2,"dp":3}],"seq":12288}' from endpoint 1 with groupID 0 Info 2022-09-02 17:09:54MQTT publish: topic 'zigbee2mqtt_cc1352p/0xec1bbdfffec28c49', payload '{"device":{"applicationVersion":72,"dateCode":"20180727","friendlyName":"0xec1bbdfffec28c49","hardwareVersion":1,"ieeeAddr":"0xec1bbdfffec28c49","manufacturerID":0,"manufacturerName":"_TYST11_czk78ptr","model":"unknown","networkAddress":2538,"powerSource":"Battery","stackVersion":0,"type":"EndDevice","zclVersion":3},"last_seen":"2022-09-02T17:09:53+01:00","linkquality":78}'

External converter

No response

Supported color modes

No response

Color temperature range

No response

james-fry commented 1 year ago

I created an external converter based on the siterwell version as a template as it seems to support more features.

Currently it seems that the following are working:

Reporting current temperature
link quality

Noting else seems working...

How would I go about debugging what needs to be done to fix this?

External converter code:

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;
const tuya = require("zigbee-herdsman-converters/lib/tuya");

module.exports = [
    {
        zigbeeModel: ['zk78ptr'],
        fingerprint: [
            {modelID: 'zk78ptr', manufacturerName: '_TYST11_czk78ptr'}
        ],
        model: 'WTRV',
        vendor: 'TCP',
        description: 'Radiator valve with thermostat',
        fromZigbee: [fz.tuya_thermostat, fz.ignore_basic_report],
        meta: {tuyaThermostatSystemMode: tuya.thermostatSystemModes4, tuyaThermostatPreset: tuya.thermostatPresets,
            tuyaThermostatPresetToSystemMode: tuya.thermostatSystemModes4},
        toZigbee: [tz.tuya_thermostat_child_lock, tz.siterwell_thermostat_window_detection, tz.tuya_thermostat_valve_detection,
            tz.tuya_thermostat_current_heating_setpoint, tz.tuya_thermostat_system_mode, tz.tuya_thermostat_auto_lock,
            tz.tuya_thermostat_calibration, tz.tuya_thermostat_min_temp, tz.tuya_thermostat_max_temp, tz.tuya_thermostat_boost_time,
            tz.tuya_thermostat_comfort_temp, tz.tuya_thermostat_eco_temp, tz.tuya_thermostat_force, tz.tuya_thermostat_preset],
        whiteLabel: [{vendor: 'Essentials', description: 'Smart home heizkörperthermostat premium', model: '120112'},
            {vendor: 'TuYa', description: 'Głowica termostatyczna', model: 'GTZ02'},
            {vendor: 'Revolt', description: 'Thermostatic Radiator Valve Controller', model: 'NX-4911'},
            {vendor: 'Unitec', description: 'Thermostatic Radiator Valve Controller', model: '30946'},
            {vendor: 'Tesla', description: 'Thermostatic Radiator Valve Controller', model: 'TSL-TRV-GS361A'},
            {vendor: 'Nedis', description: 'Thermostatic Radiator Valve Controller', model: 'ZBHTR10WT'}],
        exposes: [e.child_lock(), e.window_detection(), e.battery(), e.valve_detection(), e.position(), exposes.climate()
            .withSetpoint('current_heating_setpoint', 5, 30, 0.5, ea.STATE_SET).withLocalTemperature(ea.STATE)
            .withSystemMode(['off', 'auto', 'heat'], ea.STATE_SET)
            .withRunningState(['idle', 'heat'], ea.STATE)],
    },
];

Note that I can see zigpy/ZHA has added support:

https://github.com/zigpy/zha-device-handlers/issues/1180 https://github.com/accessiblepixel/TCP-Smart-TRV/blob/master/ts0601_trv.py

james-fry commented 1 year ago

Below is status:

What is not working is:

1) Battery is showing Null 2) States showing as off / auto / heat. Really states should be manual / away / auto - in that order (see https://github.com/zigpy/zigpy/discussions/653)

jcxldn commented 1 year ago

@james-fry

Regarding system_mode it seems to me that the mode names are chosen as they are rather standard. ie. if we used the manual's manual/away/auto it could cause compatibility issues with eg. homeassistant.

From herdsman-converter's source code the allowed modes (for thermostat system_mode) are: off, heat, auto, dry, fan_only, sleep, and emergency_heating.

Given this, would it be worth mapping the TRV's modes into these definitions?

Prehaps off: away, auto: auto and manual: heat?

On another note, when the valve is moving, do your units make a buzzing noise? It's rather loud for me!

Thanks, James

P.S. I have now setup a zigbee sniffer so I can see each datapoint, there are some interesting values but I'm not sure what they relate to just yet.

james-fry commented 1 year ago

@james-fry

Regarding system_mode it seems to me that the mode names are chosen as they are rather standard. ie. if we used the manual's manual/away/auto it could cause compatibility issues with eg. homeassistant.

I've playing around a bit and I think that the most appropriate way to align state to the device operation is to use presets. There is are presets already defined in herdsman tuya thermostat for "away", "schedule" and "manual", but adding auto instead of schedule should be possible.

Trouble is Im learning everything (JS, herdsman code structure, zigbee clusters, tuya DPs, HA MQTT HVAC etc) from scratch :) so progress is slow. Ive been using the DP dump converter and I see many expected DPs and some unexpected/unmapped ones too. I too have also flashed an old zigbee stick as a sniffer, so learning wireshark too :)

BTW in a github issue for ZHA support for this TRV someone just posted that removing and reinstalling the battery will cause the TRV to send all its DPs.

From herdsman-converter's source code the allowed modes (for thermostat system_mode) are: off, heat, auto, dry, fan_only, sleep, and emergency_heating.

Given this, would it be worth mapping the TRV's modes into these definitions?

Prehaps off: away, auto: auto and manual: heat?

I think that the problem with this model TRV is that we set a temperature and the TRV does its thing to keep the rad at that temperature. Since valve state (open/closed or %) is not reported then we dont really know if its heating or not without doing some algorithm. Static mapping of manual to heat will mean that in HA the rad will show as heating even when the valve is closed. Although this might be a case of "who cares" :) Maybe just leave it on auto since I think from our perspective (not using tuya app) they do the same thing - regulate to the set temperature.

On another note, when the valve is moving, do your units make a buzzing noise? It's rather loud for me!

Yes they do buzz. When not installed on a rad they are quite quiet, but when on a rad it amplifies their sound. Especially on my older rads that are not so well hung on the wall. I have another brand of TRV too and they also buzz. They are also supported by Z2M.

Thanks, James

P.S. I have now setup a zigbee sniffer so I can see each datapoint, there are some interesting values but I'm not sure what they relate to just yet.

joejoyce commented 1 year ago

I got some of these a few days ago and did some testing. I think the tuya data points used are as follows (thanks for the power-cycle suggestion James, I got a few more that way):

1 : state - on/off
2 : heating set point
3 : local temperature
4 : mode (0 = manual, 1 = eco, 2 = auto)
7 : child-lock
13 : error flags (16 = low battery, not sure of the rest)
14 : run state (0 = not headting, 1 = heating)
17 : window state (0 = window open, 1 = window not open)
18 : window detection enable

These looked very similar to the etop_thermostat so I've copied and modified the code for that. The handling of the modes is also inspired by how it was handled there:

off : mode = off
manual : away_mode = false, mode = heat
eco: away_mode = true, mode = heat
automatic : away_mode = false, mode = auto

This is the output on the dashboard: Screen Shot 2022-09-26 at 18 29 55

There are still a few issues with the implementation:

Not all data requests seem to be processed and often the device changes state but doesn't appear to send back a response so the UI state doesn't update.
Some of the interactions between on/off and mode aren't right. I know of at least one where if you turn the TRV from off to eco mode it doesn't update the device mode correctly.
Initially on pairing or restarting the battery shows up in the device list but not later - I wonder if there's some info that's only sent on start.

Have you had any luck getting reliable state updates out of the device following changes in zb2mqtt?

Thanks Joseph

james-fry commented 1 year ago

Thanks for the input, @joejoyce

Would you mind sharing your local converter code please? I would be happy to try it. TBH I've been distracted from working on these TRVs for a while but its starting to get cold now and I'll need to use them very soon!

A point to note: similar DPs just been reported in this comment: https://github.com/Koenkk/zigbee2mqtt/issues/12870#issuecomment-1258074994

Looks like no-one got this TRV family fully working yet...

Some questions:

Did you ever see the battery low change? (e.g. by put in old flat batteries)
I dont think there is an away mode. "Away" is mutually exclusive with the manual and auto modes, so should not be an independent toggle
Does running state change if the valve opens?
Wow that link quality is high! is your TRV right next to your coordinator?

joejoyce commented 1 year ago

Yep, I've put the code here: https://github.com/joejoyce/zigbee-herdsman-converters/tree/add-tcp-trv. It'd be great if you could try it out.

I have seen the low battery flag set (along with the icon on the device). I had the battery contacts hooked up to a power supply, lowered the voltage and waited for a bit. Raising the voltage didn't clear the flag so it's probably programmed not to clear as a battery wouldn't! (or I didn't wait sufficiently long).

I agree that an independent toggle complicates things however I think it was that way in the etop_thermostat for use with Homeassistant. I'm new to zb2mqtt and HA so I don't know the best way to expose these features. It looks like the etop_thermostat was probably setup to allow away mode t be a preset in HA - https://developers.home-assistant.io/docs/core/entity/climate/.

The run state changes from idle to heat to match the local temperature relative to the target temperature. It looks like it's set to heat if the target temperature is above the local temperature. The valve appears to move to close immediately if the local temperature is equal or above the target temperature and this matches the idle state. If heating is required, the state changes to heat but the valve only moves immediately if the difference in local to target temperature is 1 C or more and seems to move in proportion to the delta. It appears to be possible for the run_state to be heat but the valve to be closed. Presumably this would only persist for a short time until the room temperature fell sufficiently for the valve to be opened or perhaps the TRV, detecting no increase in temperature, opens the valve more.

I might be wrong about what happens when the actual and target temperatures are equal as the converters do everything in 0.5C increments but the device measures to 0.1C

Yes- there's a router device next to the coordinator which has a link quality of 255, the TRV is connected via that. Perhaps zb2mqtt reports the quality of the first link?

joejoyce commented 1 year ago

Increasing the delay between the on/off state and the mode commands appeared to resolve most of the state update issues. I guess they don't handle multiple updates well.

jcxldn commented 1 year ago

Hi, I've been doing some packet capture and for datapoint 4 (mode) I've seen values 0-3, as opposed to the documented 0-2 seen earlier. Thanks, James

james-fry commented 1 year ago

Hi, I've been doing some packet capture and for datapoint 4 (mode) I've seen values 0-3, as opposed to the documented 0-2 seen earlier. Thanks, James

I saw in the ZHA support for the siterwell/ TCP TRVs that the 4th state is the "F1" setup mode. (with the other three being zero frost, manual and auto)

MattWestb commented 1 year ago

I have some of the clones in ZHA and if getting the valve jammed is the FI mode great getting it back working OK without taking the battery out.

The away mode (from the original documentation linked in ZHA tuya TRV matrix) is frost protection mode then the valve dont have one off mode (i think its regulations in some countries that is doing it one must) and auto mode is software so the host system is sending updated set points and is not any shudder in the device.

Nice looking little simple TRV that works great.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

jcxldn commented 1 year ago

not stale

joejoyce commented 1 year ago

Sorry have been a bit busy the last couple of weeks. Thanks for pointing out the F1 setup mode state. I'll have a look at making sure it's handled in the next couple of days. On the valves I have, OFF is displayed when the temperature is turned below 5C in away mode, I haven't tested to see what this does but the value in datapoint 1 changes.

joejoyce commented 1 year ago

There's support now for entering setup mode. It's a separate switch to the other mode components so as not to change the mode behviour for HA. It seems to work OK though the behaviour is a bit funky when toggling it off, it looks like if you switch it to setup, then off it gets stuck in a mode where it doesn't do much. Toggling setup mode on completes the setup sequence and goes back to normally operational.

skleeschulte commented 1 year ago

I have this TRV (branded Nedis model ZBHTR10WT). In Nedis marketing material I read, that it can work with an external temperature sensor and multiple thermostats in one room can be grouped. How would this be done when using zigbee2mqtt?

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

hoggerz commented 1 year ago

Hi,

I’ve had some of these TCP TRVs for a while, but they seem to have absolutely terrible battery life. When installed with brand new Duracell or energiser batteries they immediately show a low battery symbol on them & last maybe 1-2 days before completely dying. Has anyone else noticed this?

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

hoggerz commented 1 year ago

Nobody else had any luck with these? They’re a bit unusable at the moment for me.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

Koenkk / zigbee2mqtt