search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.74k stars 1.64k forks source link

Add Drayton Wiser TRV #2521

Closed arcanefoam closed 4 years ago

arcanefoam commented 4 years ago

Current Status

Valve correctly reports local temp, occupied heating setpoint, pi heating demand, and boost (i.e. user request temp change at valve).

Allowed settings are occupied heating set point and keypad lock.

Errors

Keypad lockout setting not working.

Device information

Manufacturer

This is the Drayton Wiser TRV: https://wiser.draytoncontrols.co.uk/radiator-thermostat

DB Information

{ 
  "id": 2,
  "type": "EndDevice",
  "ieeeAddr": "0x086bd7fffe7ed5e4",
  "nwkAddr": 63976,
  "manufId": 4190,
  "manufName": "Schneider Electric",
  "powerSource": "Battery",
  "modelId": "iTRV",
  "epList": [ 1,  2 ],
  "endpoints": {
    "1": {
    "profId": 260,
      "epId": 1,
      "devId": 769,
      "inClusterList": [ 0, 1, 3, 32, 513, 516, 2821, 65027 ],
      "outClusterList": [ 0, 25 ],
      "clusters": {
        ...
      },
      "binds": [
        {
          "cluster": 0,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        },
        {
          "cluster": 1,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        },
        {
          "cluster": 3,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        },
        {
          "cluster": 32,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        },
        {
          "cluster": 513,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        },
        {
          "cluster": 516,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        },
        {
          "cluster": 2821,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b000be8a0ed",
          "endpointID": 1
        }
      ]
    },
    "2": {
      "profId": 260,
      "epId": 2,
      "devId": 7,
      "inClusterList": [],
      "outClusterList": [ 513 ],
      "clusters": {},
      "binds": []
    }
  },
  ...
}

Additions to Converters and Herdsman

Current device configuration (devices.js)

{
        zigbeeModel: ['iTRV'],
        model: 'iTRV',
        vendor: 'Dryton Wiser',
        description: 'Smart heating thermostat',
        supports: 'temperature, battery, keypad lock, heating demand',
        fromZigbee: [
            fz.ignore_basic_report,
            fz.ignore_haDiagnostic,
            fz.ignore_genOta,
            fz.ignore_zclversion_read,
            fz.thermostat_att_report,
            fz.drayton_itrv_battery,
            fz.drayton_user_interface,
            fz.drayton_device_info,
        ],
        toZigbee: [
            tz.thermostat_occupied_heating_setpoint,
            tz.thermostat_keypad_lockout,
        ],
        meta: {configureKey: 2},
        configure: async (device, coordinatorEndpoint) => {
            let endpoint = device.getEndpoint(1);
            const binds = [
                'genBasic', 'genPowerCfg', 'genIdentify', 'genPollCtrl',
                'hvacThermostat', 'hvacUserInterfaceCfg', 'haDiagnostic'
            ];
            await bind(endpoint, coordinatorEndpoint, binds);
            await configureReporting.batteryVoltage(endpoint);
            await configureReporting.thermostatTemperature(endpoint);
            await configureReporting.thermostatOccupiedHeatingSetpoint(endpoint);
            await configureReporting.thermostatPIHeatingDemand(endpoint);
            const userInterfaceConfig = [
                {
                    attribute: 'keypadLockout',
                    minimumReportInterval: repInterval.MINUTE,
                    maximumReportInterval: repInterval.MAX,
                    reportableChange: 0,
                }
            ];
            await endpoint.configureReporting('hvacUserInterfaceCfg', userInterfaceConfig);
            const draytonDeviceConfig = [
                {
                    attribute: 'ALG',
                    minimumReportInterval: repInterval.MINUTE,
                    maximumReportInterval: repInterval.MAX,
                    reportableChange: 0,
                },
                {
                    attribute: 'ADC',
                    minimumReportInterval: repInterval.MINUTE,
                    maximumReportInterval: repInterval.MAX,
                    reportableChange: 0,
                },
                {
                    attribute: 'boost',
                    minimumReportInterval: repInterval.MINUTE,
                    maximumReportInterval: repInterval.MAX,
                    reportableChange: 0,
                }
            ];
            await endpoint.configureReporting('draytonDeviceInfo', draytonDeviceConfig);
        },
    },

Added fromZigbee

    // Dryton Wiser
    drayton_device_info: {
        cluster: 'draytonDeviceInfo',
        type: 'attributeReport',
        convert: (model, msg, publish, options) => {
            const result = {};
            const data =  msg.data['deviceInfo'].split(',');
            if (data[0] == 'ALG') {
                // TODO What is ALG
                result['ALG'] = data.slice(1).join(',');
            }
            else if (data[0] == 'ADC') {
                // TODO What is ADC
                result['ADC'] = data.slice(1).join(',');
            }
            else if (data[0] == 'UI') {
                if (data[1] == 'BoostUp') {
                    result['boost'] = 1;
                }
                else if (data[1] == 'BoostDown') {
                    result['boost'] = -1;
                }
                else {
                    result['boost'] = 0;
                }
            }
           return result;
        },
    },
    drayton_itrv_battery: {
        cluster: 'genPowerCfg',
        type: ['attributeReport', 'readResponse'],
        convert: (model, msg, publish, options) => {
            const result = {};
            if (typeof msg.data['batteryVoltage'] == 'number') {
                const battery = {max: 30, min: 22};
                const voltage = msg.data['batteryVoltage'] ;
                result.battery = toPercentage(voltage, battery.min, battery.max);
                result.voltage = voltage / 10;
            }
            if (typeof msg.data['batteryAlarmState'] == 'number') {
                const battLow = msg.data['batteryAlarmState'] ;
                if (battLow) {
                    results['battery_low'] = true;
                } else {
                    results['battery_low'] = false;
                }
            }
            return result;
        },
    },
    drayton_user_interface: {
        cluster: 'hvacUserInterfaceCfg',
        type: 'attributeReport',
        convert: (model, msg, publish, options) => {
            const result = {};
            if (typeof msg.data['keypadLockout'] == 'number') {
                const kLock = msg.data['keypadLockout'] ;
                if (kLock) {
                    result['keypad_lockout'] = true;
                } else {
                    result['keypad_lockout'] = false;
                }
            }
            return result;
        }
    },

    // Dryton ignores
    ignore_genOta: {
        cluster: 'genOta',
        type: ['attributeReport', 'readResponse'],
        convert: (model, msg, publish, options) => null,
    },
    ignore_haDiagnostic: {
        cluster: 'haDiagnostic',
        type: ['attributeReport', 'readResponse'],
        convert: (model, msg, publish, options) => null,
    },
    ignore_zclversion_read: {
        cluster: 'genBasic',
        type: 'read',
        convert: (model, msg, publish, options) => null,
    },

Added to clusters

Required to get boost messages

    // Drayton Wiser
    draytonDeviceInfo: {
        ID: 0xFE03, // 65027
        attributes: {
        deviceInfo: { ID: 32, type: dataType_1.default.charStr },
    },
        commands: {},
        commandsResponse: {}
    }

Debug Info

zigbee2mqtt version: 1.7.1 CC253X firmware version: latest

sand3rk commented 4 years ago

https://raw.githubusercontent.com/Koenkk/zigbee-herdsman-converters/8afbb59b7c71c3d8488de7c735645c3e92ed40e8/devices.js

The one from dev is still broken, I fixed the error... but I got a new one now on configuring one of the reporting endpoints. (But at least the device shows up now)

Thanks, is this link the fixed one?

sand3rk commented 4 years ago

I now get the follow error:

zigbee2mqtt:error 2020-01-25 17:32:41: Failed to configure '0x086bd7fffedfee28', attempt 1 (Error: AREQ - ZDO - bindRsp after 10000ms at Timeout._onTimeout (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7))

zigbee2mqtt:error 2020-01-25 17:33:16: Failed to configure '0x086bd7fffedfee28', attempt 2 (Error: Data request failed with error: 'MAC transaction expired' (240) at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:578:27) at Generator.next (<anonymous>) at fulfilled (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:5:58))

zigbee2mqtt:error 2020-01-25 17:34:15: Failed to configure '0x086bd7fffedfee28', attempt 3 (Error: Cluster with key 'draytonDeviceInfo' does not exist at Object.getCluster (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/zcl/utils.js:59:15) at Endpoint.<anonymous> (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:215:39) at Generator.next (<anonymous>) at /zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:8:71 at new Promise (<anonymous>) at __awaiter (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:4:12) at Endpoint.configureReporting (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:213:16) at Object.configure (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman-converters/devices.js:7044:28) at async DeviceConfigure.configure (/zigbee2mqtt-1.9.0/lib/extension/deviceConfigure.js:99:13)) zigbee2mqtt:error 2020-01-25 17:34:28: No converter available for 'system_mode' (off) zigbee2mqtt:error 2020-01-25 17:34:29: No converter available for 'system_mode' (heat)

But the error from before is gone

sjorge commented 4 years ago

Yes, it should get you past the error you are having. But you might hit another one after I haven't been able to fix yet.

sjorge commented 4 years ago

@sand3rk did you remove and rejoin the device? It looks like zigbee2mqtt could not reach it to do the configure step.

sand3rk commented 4 years ago

@sjorge , no not yet. I will try that.

arcanefoam commented 4 years ago

My valves do not report any configuration errors. I might get the timeout on one attempt, but then it succeeeds.

Regarding the boost I have tried adding toZigbee functions to send data to the deviceInfo and tried sending BoostOff, BoostNone and others but still no luck. I also tried sending system_state but it does not change the valves behavior.

I still feel that some other configuration/command is needed to tell the valve that it is part of a system. Looking at my Home Assistant graphs it seems that every two hours that I get a occupied_heating_setpoint spike to 20 degrees the valve opens (pi_heating_demand =100) so it kind of ovverides the setpoint I am sending it. It seems it might be something in the deviceInfo cluster but with no information from the manufacturer we are blind. Unless someone has a wiser hub and does some sniffing.

On Sat, 25 Jan 2020, 16:35 sand3rk, notifications@github.com wrote:

@sjorge https://github.com/sjorge , no not yet. I will try that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521?email_source=notifications&email_token=AAQOU3LUB7UZ4AL4BPHRN33Q7RS43A5CNFSM4J2QFNAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5ABPY#issuecomment-578420927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOU3PBR6ONJJTPMFWYJW3Q7RS43ANCNFSM4J2QFNAA .

arcanefoam commented 4 years ago

I am also getting timeouts occasionally when sending setpoint changes. I really don't understand much of the zigbee protocol or how herdsman work or else I would do some more debugging.

On Sat, 25 Jan 2020, 17:22 arcanefoam@gmail.com, arcanefoam@gmail.com wrote:

My valves do not report any configuration errors. I might get the timeout on one attempt, but then it succeeeds.

Regarding the boost I have tried adding toZigbee functions to send data to the deviceInfo and tried sending BoostOff, BoostNone and others but still no luck. I also tried sending system_state but it does not change the valves behavior.

I still feel that some other configuration/command is needed to tell the valve that it is part of a system. Looking at my Home Assistant graphs it seems that every two hours that I get a occupied_heating_setpoint spike to 20 degrees the valve opens (pi_heating_demand =100) so it kind of ovverides the setpoint I am sending it. It seems it might be something in the deviceInfo cluster but with no information from the manufacturer we are blind. Unless someone has a wiser hub and does some sniffing.

On Sat, 25 Jan 2020, 16:35 sand3rk, notifications@github.com wrote:

@sjorge https://github.com/sjorge , no not yet. I will try that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521?email_source=notifications&email_token=AAQOU3LUB7UZ4AL4BPHRN33Q7RS43A5CNFSM4J2QFNAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5ABPY#issuecomment-578420927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOU3PBR6ONJJTPMFWYJW3Q7RS43ANCNFSM4J2QFNAA .

arcanefoam commented 4 years ago

This are the setpoint spikes and the heating demand.

image

On Sat, 25 Jan 2020, 17:25 arcanefoam@gmail.com, arcanefoam@gmail.com wrote:

I am also getting timeouts occasionally when sending setpoint changes. I really don't understand much of the zigbee protocol or how herdsman work or else I would do some more debugging.

On Sat, 25 Jan 2020, 17:22 arcanefoam@gmail.com, arcanefoam@gmail.com wrote:

My valves do not report any configuration errors. I might get the timeout on one attempt, but then it succeeeds.

Regarding the boost I have tried adding toZigbee functions to send data to the deviceInfo and tried sending BoostOff, BoostNone and others but still no luck. I also tried sending system_state but it does not change the valves behavior.

I still feel that some other configuration/command is needed to tell the valve that it is part of a system. Looking at my Home Assistant graphs it seems that every two hours that I get a occupied_heating_setpoint spike to 20 degrees the valve opens (pi_heating_demand =100) so it kind of ovverides the setpoint I am sending it. It seems it might be something in the deviceInfo cluster but with no information from the manufacturer we are blind. Unless someone has a wiser hub and does some sniffing.

On Sat, 25 Jan 2020, 16:35 sand3rk, notifications@github.com wrote:

@sjorge https://github.com/sjorge , no not yet. I will try that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521?email_source=notifications&email_token=AAQOU3LUB7UZ4AL4BPHRN33Q7RS43A5CNFSM4J2QFNAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5ABPY#issuecomment-578420927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOU3PBR6ONJJTPMFWYJW3Q7RS43ANCNFSM4J2QFNAA .

sand3rk commented 4 years ago

I re-paired, but still got this error: zigbee2mqtt:error 2020-01-26 13:52:03: Failed to configure '0x086bd7fffedfee28', attempt 3 (Error: Cluster with key 'draytonDeviceInfo' does not exist at Object.getCluster (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/zcl/utils.js:59:15) at Endpoint.<anonymous> (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:215:39) at Generator.next (<anonymous>) at /zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:8:71 at new Promise (<anonymous>) at __awaiter (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:4:12) at Endpoint.configureReporting (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:213:16) at Object.configure (/zigbee2mqtt-1.9.0/node_modules/zigbee-herdsman-converters/devices.js:7044:28) at async DeviceConfigure.configure (/zigbee2mqtt-1.9.0/lib/extension/deviceConfigure.js:99:13))

But climate card is still grey, it does not respond to the card, but it does not say: No converter available.

arcanefoam commented 4 years ago

I guess the zigbee-herdsman changes haven't been merged to zigbee2mqtt 1.9.0 . So you need to modify: /zigbee2mqtt-1.9.0/node_modules\zigbee-herdsman\dist\zcl\definition\clister.js and add

wiserDeviceInfo: {
        ID: 0xFE03, // 65027
        attributes: {
            deviceInfo: { ID: 32, type: dataType_1.default.charStr },
        },
        commands: {},
        commandsResponse: {}
    }

At the end of the file before the final }; which closes the Cluster const.

sjorge commented 4 years ago

I’m in dev though, and it’s there?

~ sjorge

On 27 Jan 2020, at 18:34, Horacio Hoyos notifications@github.com wrote:

 I guess the zigbee-herdsman changes haven't been merged to zigbee2mqtt 1.9.0 . So you need to modify: /zigbee2mqtt-1.9.0/node_modules\zigbee-herdsman\dist\zcl\definition\clister.js and add

wiserDeviceInfo: { ID: 0xFE03, // 65027 attributes: { deviceInfo: { ID: 32, type: dataType_1.default.charStr }, }, commands: {}, commandsResponse: {} } At the end of the file before the final }; which closes the Cluster const.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

arcanefoam commented 4 years ago

On a closer look, it seems that the cluster has been added, but the issues is that the reporting is using the wrong name. Line 7047 of devices.js should be

await endpoint.configureReporting('wiserDeviceInfo', draytonDeviceConfig);

It currently uses 'draytonDeviceInfo' which is an undefined cluster.

On Mon, 27 Jan 2020, 17:52 Jorge Schrauwen, notifications@github.com wrote:

I’m in dev though, and it’s there?

~ sjorge

On 27 Jan 2020, at 18:34, Horacio Hoyos notifications@github.com wrote:

 I guess the zigbee-herdsman changes haven't been merged to zigbee2mqtt 1.9.0 . So you need to modify: /zigbee2mqtt-1.9.0/node_modules\zigbee-herdsman\dist\zcl\definition\clister.js and add

wiserDeviceInfo: { ID: 0xFE03, // 65027 attributes: { deviceInfo: { ID: 32, type: dataType_1.default.charStr }, }, commands: {}, commandsResponse: {} } At the end of the file before the final }; which closes the Cluster const.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521?email_source=notifications&email_token=AAQOU3LO6BGZVWX75TVSRTDQ74NNFA5CNFSM4J2QFNAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKANZXA#issuecomment-578870492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOU3LRWQ2ZRHBDNIHCDRDQ74NNFANCNFSM4J2QFNAA .

sjorge commented 4 years ago

I have https://github.com/Koenkk/zigbee-herdsman-converters/pull/939/files open to fix that, but i hit another issue. See koenkk's comment on the PR

sourbrambles commented 4 years ago

I'm also experiencing this issue, looking forward to the PR being pushed through. Is there a reason some users have been unaffected and others are seeing this issue?

sjorge commented 4 years ago

I bumbed the PR, there is still an issue a I am hitting that I haven't been able to fix.

arcanefoam commented 4 years ago

Hi all, after some more testing the only way I can manage to keep the babies happy is with constant attention. That is, I will send my desired set-point (from a schedule) every-time the valve sends a report. The peaks I mentioned earlier are gone and everything is working nicely. I am working on a custom wiser component and card for home assistant. Its work in progress but this is what it looks so far (its based on the Wiser phone app): image

The wiser component lets you define rooms and specify what valves are in each room, and lets you define a schedule. The card shows the information for each room, which room needs heat and will eventually let you control stuff like away mode and "boost all". Ideally it will allow you to change the schedule too.

davidscottparker commented 4 years ago

Great work Horacio, thank you - I am following your progress with interest.

Kind regards

Dave Parker dave@daveparker.co.uk 07971 807853 01726 813557

On 15 Feb 2020, at 07:47, Horacio Hoyos notifications@github.com wrote:

Hi all, after some more testing the only way I can manage to keep the babies happy is with constant attention. That is, I will send my desired set-point (from a schedule) every-time the valve sends a report. The peaks I mentioned earlier are gone and everything is working nicely. I am working on a custom wiser component and card for home assistant. Its work in progress but this is what it looks so far (its based on the Wiser phone app): https://user-images.githubusercontent.com/2157165/74584159-0a699800-4fc7-11ea-9b99-9a8c81cc37d3.png The wiser component lets you define rooms and specify what valves are in each room, and lets you define a schedule. The card shows the information for each room, which room needs heat and will eventually let you control stuff like away mode and "boost all". Ideally it will allow you to change the schedule too.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521?email_source=notifications&email_token=AGADFSJDIXWDGLKI2ALD3YDRC6MYLA5CNFSM4J2QFNAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3EKVA#issuecomment-586564948, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGADFSPDR62H4Y36FOIEULDRC6MYLANCNFSM4J2QFNAA.

mgrom commented 4 years ago

Hi all, after some more testing the only way I can manage to keep the babies happy is with constant attention. That is, I will send my desired set-point (from a schedule) every-time the valve sends a report. The peaks I mentioned earlier are gone and everything is working nicely. I am working on a custom wiser component and card for home assistant. Its work in progress but this is what it looks so far (its based on the Wiser phone app): image

The wiser component lets you define rooms and specify what valves are in each room, and lets you define a schedule. The card shows the information for each room, which room needs heat and will eventually let you control stuff like away mode and "boost all". Ideally it will allow you to change the schedule too.

Are you using wall thermostat together with TRV's? I'm trying to figure out working standalone TRV. I've got issue here: sending occupied_heating_setpoint sometimes has no impact on occupied_heating_setpoint (Status message), but instead it keeps apearing nicely in ADC and ALG

I've read that ADC is Analog to Digital Converter - so maybe that's the key. ALG is Application Layer Gateway, so maybe this is something that needs to be used when communicating with TRV. Messages sent using occupied_heating_setpoint have impact on ALG somehow, correct temp apears in 3rd place, but occupied_heating_setpoint status value can be still old.

arcanefoam commented 3 years ago

Hey. Sorry for the late reply but since the ticket is closed, seem to not send notifications. Nice finding and I saw you made a PR to fix this! Excellent.

I am using standalone setting, with a switch to control to boiler so no need for the thermostat. The card and related component are still WIP, but if you are interested you can follow progress here https://github.com/arcanefoam/wiser-home-assistant/tree/develop

GSzabados commented 2 years ago

Hi,

@arcanefoam, @sjorge

I would like to resurrect this topic for a short time as the heating season starts again.

First of all, I don't know why but in HA the device's target_temp_step is 1, but this device supports 0.5 step. Where is the place for fixing it?

I've previously worked on the SmartThings integration about that time when this Z2M integration was made, and I think we reached the same result regarding features and details.

My findings were the following:

And last, but not least, @arcanefoam is your project still working with the latest version of Z2M and HA?

Best Regards,

Gábor

arcanefoam commented 2 years ago

Hi Gábor,

I have moved to sunny Mexico so, sadly, I have no longer an active interest in the valves. That being said, here are my thoughts:

The device is chatty. It reports every minute and floods the network with it. It is. From what I understand, I think it is chatty because it is not happy with the initial configuration, i.e. I think the messages it sends are announce messages (“I am here, config me”). This is probably due to the fact that they are not zigbee compliant, hence the Drayton hub may be sending additional config instructions.

I also think this is the reason the valve is not completely responsive when you want to change the set point. You sometimes need 2 or 3 retries to make it stick. What has worked for me is to send the set command as soon as the valve communicates. It would be good if someone with a hub could do some reverse engineering of the communication.

BoostUp and BoostDown are just like button press states. And actually that's how it should be handled. The device itself, by default, changes the setpoint to current temperature +2 or -2. It does not count for the Boost time. The Wiser Hub should do that. They are buttons, but although they are momentary on the valve, the state on the valve is persistence. As such, it is very hard to track the button state on the driver. Perhaps the ALG messages have information about the button state, but I was not able to find out. As @mgrom https://github.com/mgrom noted, the correct way of communication with the iTRV should be the ALG messages. The Wiser Hub does that probably, as I have been in contact with a guy who ran into problems with newer firmwares, where the device was not changing setpoint anymore, and he confirmed with Wiser that the firmware change was causing that. If you have noticed, in none of the Wiser documentation is stated that these iTRVs or any other Wiser product from the line is a Zigbee Certified device. At least at the time when I purchased the first few iTRVs there wasn't. It was only saying that it uses a 2.4Ghz communication protocol. As if the device is not Zigbee Certified, it is not bind to follow the Zigbee documentation, but it can still use the protocol. ADC is again what @mgrom https://github.com/mgrom said before, basically a few temperature measurements and maybe forecasts plus voltage values as I can recall. MOT is motor state, but not really useful. Stale=reached the closing position (or not), unfortunately the motor is not too powerful to close the valve on the radiator sometimes. Motor state is useful to track the valve state, i.e. you can know if the valve is “active” or in “setup mode”. This can be important as some might put the valve in “setup mode” by error and you can get notified.

Cheers,

On 24 Oct 2021, at 10:08, GSzabados @.***> wrote:

Hi,

@arcanefoam https://github.com/arcanefoam, @sjorge https://github.com/sjorge I would like to resurrect this topic for a short time as the heating season starts again.

First of all, I don't know why but in HA the device's target_temp_step is 1, but this device supports 0.5 step. Where is the place for fixing it?

I've previously worked on the SmartThings integration about that time when this Z2M integration was made, and I think we reached the same result regarding features and details.

My findings were the following:

The device is chatty. It reports every minute and floods the network with it. BoostUp and BoostDown are just like button press states. And actually that's how it should be handled. The device itself, by default, changes the setpoint to current temperature +2 or -2. It does not count for the Boost time. The Wiser Hub should do that. As @mgrom https://github.com/mgrom noted, the correct way of communication with the iTRV should be the ALG messages. The Wiser Hub does that probably, as I have been in contact with a guy who ran into problems with newer firmwares, where the device was not changing setpoint anymore, and he confirmed with Wiser that the firmware change was causing that. If you have noticed, in none of the Wiser documentation is stated that these iTRVs or any other Wiser product from the line is a Zigbee Certified device. At least at the time when I purchased the first few iTRVs there wasn't. It was only saying that it uses a 2.4Ghz communication protocol. As if the device is not Zigbee Certified, it is not bind to follow the Zigbee documentation, but it can still use the protocol. ADC is again what @mgrom https://github.com/mgrom said before, basically a few temperature measurements and maybe forecasts plus voltage values as I can recall. MOT is motor state, but not really useful. Stale=reached the closing position (or not), unfortunately the motor is not too powerful to close the valve on the radiator sometimes. And last, but not least, @arcanefoam https://github.com/arcanefoam is your project still working with the latest version of Z2M and HA?

Best Regards,

Gábor

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521#issuecomment-950341482, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOU3NJM6IBCR47SWBSRX3UIQOQNANCNFSM4J2QFNAA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Arcanefoam

https://bitbucket.org/arcanefoam/ https://github.com/arcanefoam

GSzabados commented 2 years ago

I have moved to sunny Mexico so, sadly, I have no longer an active interest in the valves.

That is good for you. Now you need to worry about a working AC, I guess. ;)

Being chatty is a general thing, both Z2M and SmartThings can see the devices behave the same. Send reports every 60 seconds. The iTRV sends another message at the beginning and it is being commissioned correctly as it announces itself. Something like this:

NWK,WiserHeatUserRejoin,561300026,0000

The Heat hub does the heavy lifting (schedule, smart learning, window detection, etc.) and that is why it reports so often I guess.

They are buttons, but although they are momentary on the valve, the state on the valve is persistence.

Have you ever seen the valve go back to the previous state after 1 hour of the twisting? Because I have never. It stays at current temperature +/- 2 Celsius, and stays that way indefinitely. As I said the Heat Hub does the smart stuff and that tells one hour later to the valve to go back to previous state. That's the reason why it just reports the state change like a button and no way to set it back to previous state. The Hub is the brain, the iTRV is just an actuator.

Motor state is useful to track the valve state, i.e. you can know if the valve is “active” or in “setup mode”.

If you put the valve to "setup mode", it does close fully after some time, so there is no reason to worry about that. So either moving or stalled.

arcanefoam commented 2 years ago

Have you ever seen the valve go back to the previous state after 1 hour of the twisting? Because I have never. It stays at current temperature +/- 2 Celsius, and stays that way indefinitely. As I said the Heat Hub does the smart stuff and that tells one hour later to the valve to go back to previous state. That's the reason why it just reports the state change like a button and no way to set it back to previous state. The Hub is the brain, the iTRV is just an actuator.

Yes I have, the valves work perfectly fine on their own (if you are happy with the 20C default setpoint).

On 26 Oct 2021, at 10:21, GSzabados @.***> wrote:

I have moved to sunny Mexico so, sadly, I have no longer an active interest in the valves.

That is good for you. Now you need to worry about a working AC, I guess. ;)

Being chatty is a general thing, both Z2M and SmartThings can see the devices behave the same. Send reports every 60 seconds. The iTRV sends another message at the beginning and it is being commissioned correctly as it announces itself. Something like this:

NWK,WiserHeatUserRejoin,561300026,0000

The Heat hub does the heavy lifting (schedule, smart learning, window detection, etc.) and that is why it reports so often I guess.

They are buttons, but although they are momentary on the valve, the state on the valve is persistence.

Have you ever seen the valve go back to the previous state after 1 hour of the twisting? Because I have never. It stays at current temperature +/- 2 Celsius, and stays that way indefinitely. As I said the Heat Hub does the smart stuff and that tells one hour later to the valve to go back to previous state. That's the reason why it just reports the state change like a button and no way to set it back to previous state. The Hub is the brain, the iTRV is just an actuator.

Motor state is useful to track the valve state, i.e. you can know if the valve is “active” or in “setup mode”.

If you put the valve to "setup mode", it does close fully after some time, so there is no reason to worry about that. So either moving or stalled.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2521#issuecomment-952048445, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOU3LJU323CPUDEX4DF7LUI3IQDANCNFSM4J2QFNAA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Arcanefoam

https://bitbucket.org/arcanefoam/ https://github.com/arcanefoam

2m commented 2 years ago

... You sometimes need 2 or 3 retries to make it stick.

I am running zigbee2mqtt with Home Assistant integration and I also noticed that. When I am trying to manually change the set point using https://github.com/nervetattoo/simple-thermostat card I can retry myself if the new value does not stick.

However with https://github.com/nielsfaber/scheduler-card its a bit more tricky as that attempts to set the value only once and therefore some of the scheduled temperature changes are missed.

Would it be possible to make it retry on the zigbee2mqtt side until it is successfully set?

2m commented 2 years ago

I tried connecting this TRV via ZHA to see how it is handled using zigby stack.

Setpoint changes are very stable. I have not had it miss a setpoint change from HA to TRV once.

However two ours after the initial setup the TRV seems to reset (heating mode, setpoint) and stops receiving setpoint changes from HA. Described in more detail here: https://community.home-assistant.io/t/drayton-wiser-schneider-electric-itrv-issues/268728/9?u=2.m

Hope this is helpful to someone knowing a bit more to possibly solve these problems on one stack of another. :)