Hive SLR1

[steveuk23]

Hi @Koenkk @robertalexa I'm trying to add a Unsupported device to zigbee2mqtt (i use the edge addon btw) The device is listed as SLR1 and i was hoping it was basically the same as the SLR1b that is supported. i found this hive.js and edited it to suit my device and added the below to my zigbee2mqtt configuration.yaml

external_converters:
  - hive.js

But every time i restart the add on it fails to reload until i delete the line again, I'm not great with all this so am just guessing as i go along but have read about adding it to devices.js but not sure how or where that file is. My hive.js code is like below

const exposes = require('../lib/exposes');
const fz = {...require('../converters/fromZigbee'), legacy: require('../lib/legacy').fromZigbee};
const tz = require('../converters/toZigbee');
const globalStore = require('../lib/store');
const constants = require('../lib/constants');
const reporting = require('../lib/reporting');
const extend = require('../lib/extend');
const e = exposes.presets;
const ea = exposes.access;

module.exports = [
    {
        zigbeeModel: ['SLR1'],
        model: 'SLR1',
        vendor: 'Hive',
        description: 'Heating thermostat',
        fromZigbee: [fz.legacy.thermostat_att_report, fz.legacy.thermostat_weekly_schedule_rsp],
        toZigbee: [tz.thermostat_local_temperature, tz.thermostat_system_mode, tz.thermostat_running_state,
            tz.thermostat_occupied_heating_setpoint, tz.thermostat_control_sequence_of_operation, tz.thermostat_weekly_schedule,
            tz.thermostat_clear_weekly_schedule, tz.thermostat_temperature_setpoint_hold, tz.thermostat_temperature_setpoint_hold_duration],
        exposes: [exposes.climate().withSetpoint('occupied_heating_setpoint', 7, 30, 1).withLocalTemperature()
            .withSystemMode(['off', 'auto', 'heat']).withRunningState(['idle', 'heat']).withPiHeatingDemand()],
        meta: {disableDefaultResponse: true},
        configure: async (device, coordinatorEndpoint, logger) => {
            const endpoint = device.getEndpoint(5);
            const binds = ['genBasic', 'genIdentify', 'genAlarms', 'genTime', 'hvacThermostat'];
            await reporting.bind(endpoint, coordinatorEndpoint, binds);
            await reporting.thermostatTemperature(endpoint, {min: 0, max: constants.repInterval.HOUR, change: 1});
            await reporting.thermostatRunningState(endpoint);
            await reporting.thermostatOccupiedHeatingSetpoint(endpoint);
            await reporting.thermostatTemperatureSetpointHold(endpoint);
            await reporting.thermostatTemperatureSetpointHoldDuration(endpoint);
        },
    },
];

[robertalexa]

So just to make sure i understand correctly, you have set reporting on both endpoint 5 and enpoint 6 and you have seen improvements right?

[peterguy04]

reporting works on both endpoints yes after manually adding it like you suggested. before that it did nothing. but i havent been able to properly use the hive stuff on z2m because it wont work with my home assistant properly . cant control it. i paired it back up to help you here

[robertalexa]

Auto means Scheduler, so the internal scheduler of the thermostat. There is kinda some support for it, but i feel that there are some bits missing. And also this would be done via commands only, not via interface. This would also make it impossible to expose to HA. But equally, people that plan on using a scheduler will do their own thing, and not rely on the internal one. See my comments above when talking to Steve about scheduling.

With regards to boost, yes, there is a 4th value called emergency_heating. But this is not supported by z2m. I can create support for it, but it might not be a good idea. The reason for it is cause it requires more than 1 call to action it, you need a temperature and a duration. When i do my PR i will discuss this with Koen and see what he suggests. Nonetheless, i plan on adding it to the documentation when i am done.

Once you put the receiver in emergency_heating (boost on the Thermostat), you have to send a new command to stop the boost. So that explains why you see them as unresponsive.

I have not tried to test my receiver in HA, i will handle that part of it once i finish changing these devices. Maybe I can help you with your device too.

I will send another message soon to test the battery reporting, though from what i can gather i am 99% sure it will work without testing.

[peterguy04]

@robertalexa sure, ye i do my boost and scheduling between HA and nodered anyway, aswell as my own automation for "heat on demand" for the TRVs as hives was very in-efficient

i helped create support in deconz and sniffed the hive hub . so theres some info here on the different modes that i got if its helpful for anything at the bottom of this issue. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2978

[robertalexa]

@robertalexa sure, ye i do my boost and scheduling between HA and nodered anyway, aswell as my own automation for "heat on demand" for the TRVs as hives was very in-efficient

THANK YOU!!! This is exactly how i ended up supporting these devices, cause i want to do my own thing precisely because of heat on demand! Maybe you can share with me your flow logic for heat on demand in node red? or even an export if it makes it easier?

Here is what to do to test the battery reporting:

1. stop the addon

2. edit your database.db file and change the model of your remote from SLT2 to SLT2A (this way it becomes unsupported) in my case with an SLT3 it looks like this

3. create a file called SLT2A.js in the same place as your configuration.yaml

   
   const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
   const exposes = require('zigbee-herdsman-converters/lib/exposes');
   const reporting = require('zigbee-herdsman-converters/lib/reporting');
   const e = exposes.presets;

const definition = { zigbeeModel: ['SLT2A'], model: 'SLT2A', vendor: 'Hive', description: 'Heating thermostat remote control', fromZigbee: [fz.battery], toZigbee: [], exposes: [e.battery()], configure: async (device, coordinatorEndpoint, logger) => { const endpoint = device.getEndpoint(9); await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg']); await reporting.batteryPercentageRemaining(endpoint, {min: 60, max: 120, change: 1}); }, };

module.exports = definition;

4. edit your configuration.yaml file and add

external_converters:

• SLT2A.js

  
  5. restart the addon and check the frontend. it should look like this
  ![image](https://user-images.githubusercontent.com/9019306/127910489-34b4c68f-8316-459a-8779-d209ca1694d8.png)

Thanks a lot!

[peterguy04]

so for some reason am having a hard time adding the line to the yaml, its either giving me invalid yaml OR when i restart the addon its deleting the line.... this is using the HA addon btw

also i notice EP6 has no function on SLR2 i already said that it has fixed values so acts more like a on/off switch. but changing from heat to off, or off to heat does nothing

[robertalexa]

Hi @peterguy04

That error is probably because you already have the external_converters: [] line in your configuration. Replace that with the one i sent you :)

I kinda expected exactly that about the EP6, but because i do not have it i find it impossible to understand how it operates on its own, let apart what should z2m have. So how would you go about turning water on and off from z2m on the water endpoint?

LE: can you take a screenshot of the device in z2m frontend please?

[peterguy04]

sorry for the delay, was having abit of a drama between my VM and my coordinator so the whole thing came crashing down. anyway ive fired it up in a docker container now rather than HA addon so its easier for me to work with. i have a few things to be on with today but ill try that battery reporting on the SLT when i get chance

so heres the image of the SLR2 endpoint, so focusing on water both the "occupied_heating_setpoint" and the "local_temperature" are hardcoded to the device at 21c and 22c . these are not settable by the user. it turns it into a ON/OFF switch based on the mode OFF/HEAT . so the running_state is reported from SLT in Z2M correctly but when we send the system_mode command from Z2M it does nothing.

i know when i sniffed the zigbee packets they needed multiple commands at once , but i dont know how this translates to z2m but should be similar to EP5 i would of thought

for "on - manual"

attribute 0x001C > 0x04 = "heat"
attribute 0x0023 > 0x01 = "Setpoint Hold On"

For "off"

attribute 0x001C > 0x00 = "off"
attribute 0x0023 > 0x00 = "Setpoint Hold Off"

[robertalexa]

@peterguy04

Thank you for the above information. I think i kinda understand.

You are saying that nothing is happening when you change system_mode OFF and HEAT. Does that mean the receiver doesn't do anything? Does the remote show that you did that action? What happens if you press the blue refresh button (for occupied, local, system and running state) after running this action (reporting currently is a bit wrong, so that could be why it wouldnt update without manually refreshing - but i have already changed this in my improvements)?

Now onto "improvements":

• I am correct in thinking that AUTO should be removed from the water endpoint?
• I am correct in thinking that the temperature slider should be lock to a range between 21 and 22 rather than the current 7 to 30?
• I am correct in thinking that pi_heating_demand is never showing a value for either of the endpoints and should be removed?

Because this has to act as a climate device, and it should link correctly in HA, as much as it is counter intuitive, we can't remove the occupied heating setpoint and local temperature, cause they all contribute to the climate entity. But i we restrict it to only correct values than that would make it work better generally.

Let me know about the above and I can make the relevant changes. Thanks

LE: maybe the water endpoint could be treated as a switch, but you would have to give me logs of you operating it from both z2m and the thermostat in order to understand exactly the commands. Then i can talk to Koen when i do the PR to see if we can handle the commands magically behind the scenes, while the expose in z2m and ha will be a simple toggle switch.

[robertalexa]

Can you also confirm if for the heating endpoint you can set the temperature on the physical thermostat in 0.5 degrees increments rather than 1 degree as z2m does? If that is the case, i can fix z2m steps

[peterguy04]

Can you also confirm if for the heating endpoint you can set the temperature on the physical thermostat in 0.5 degrees increments rather than 1 degree as z2m does? If that is the case, i can fix z2m steps

yes it goes up in .5 increments on the SLT , we can set that by manually typing the value but not on slider in z2m and setting a value with .5 this way does update to the SLT

[robertalexa]

@peterguy04 I can fix that slider, which will then expose it correctly to HA too.

PS: i have sent another message above - just in case it has gone unnoticed by you :)

Thanks again

[peterguy04]

i did miss that lol, but i need to pop out for a few hours so ill get back to ya when i am home on that one

[peterguy04]

You are saying that nothing is happening when you change system_mode OFF and HEAT. Does that mean the receiver doesn't do anything? Does the remote show that you did that action? What happens if you press the blue refresh button (for occupied, local, system and running state) after running this action (reporting currently is a bit wrong, so that could be why it wouldnt update without manually refreshing - but i have already changed this in my improvements)?

ok so ive looked abit more at this, and when i press HEAT in z2m, the thermostat display changes to heat BUT the SLR doesnt call for hot water - no response ... same with OFF , click OFF in z2m, thermostat changes to off, SLR does not turn off. This happened before when we were working on the support for deconz, this was due to the multiple commands not being sent at once

• I am correct in thinking that AUTO should be removed from the water endpoint?

Auto is used for scheduling in hive, useless to me personally as i schedule myself

• I am correct in thinking that the temperature slider should be lock to a range between 21 and 22 rather than the current 7 to 30?

the slider cant be changed from 22c , its fixed. Slider serves no purpose on this EP

• I am correct in thinking that pi_heating_demand is never showing a value for either of the endpoints and should be removed?

always showing N/A% for both EP5 and EP6

Because this has to act as a climate device, and it should link correctly in HA, as much as it is counter intuitive, we can't remove the occupied heating setpoint and local temperature, cause they all contribute to the climate entity. But i we restrict it to only correct values than that would make it work better generally.

agreed , as system_mode is the only usable function here we can work on a cleaner way in the frontend of our applications to hide the heating_setpoint if we need to, link the modes to a switch on the front end or something like if we need to.

LE: maybe the water endpoint could be treated as a switch, but you would have to give me logs of you operating it from both z2m and the thermostat in order to understand exactly the commands. Then i can talk to Koen when i do the PR to see if we can handle the commands magically behind the scenes, while the expose in z2m and ha will be a simple toggle switch.

i think if its easier we can do this in our front ends, maybe edit the readme for this device to explain. This way we could keep it as a climate device?

[robertalexa]

@peterguy04 Thanks for your feedback. My turn to go through your answers :)

ok so ive looked abit more at this, and when i press HEAT in z2m, the thermostat display changes to heat BUT the SLR doesnt call for hot water - no response ... same with OFF , click OFF in z2m, thermostat changes to off, SLR does not turn off. This happened before when we were working on the support for deconz, this was due to the multiple commands not being sent at once

I was kinda suspecting that. More on this further down.

Auto is used for scheduling in hive, useless to me personally as i schedule myself

Can you actually schedule the water too? Or is it only the heating?

the slider cant be changed from 22c , its fixed. Slider serves no purpose on this EP

You have previously mentioned that the value varies between 21 and 22 depending if on or off. Yes i understand that the slider is pointless, but having values less than 21 and more than 22 is even more pointless, probably also invalid.

always showing N/A% for both EP5 and EP6

I have removed them

i think if its easier we can do this in our front ends, maybe edit the readme for this device to explain. This way we could keep it as a climate device?

What i have in mind, that is if we can actually make it work, would be a very nice simple button. Water: On / Off

Toggling between the 2 values as a switch would then call multiple commands on the device to satisfy the device requirements. All of this behind the scenes. Then expose this switch to HA and again, that would also work great.

The end result is that people that are not able to code can still use the functionality easily. The switch can possibly even be an entity of the Heating climate, or sth like that.

But in order for me to discuss this with Koen I need to understand exactly what the commands are when you turn the water on and off from the thermostat.

Would you be able to do that? Turn the water on from the thermostat and send the logs that you see in z2m. I expect to be 3 maybe 4 commands in a row? And of course the same for turning the water off.

I really appreciate you taking the time to help me with this! Rob

[peterguy04]

Can you actually schedule the water too? Or is it only the heating?

in hive app, you can schedule water yes

You have previously mentioned that the value varies between 21 and 22 depending if on or off. Yes i understand that the slider is pointless, but having values less than 21 and more than 22 is even more pointless, probably also invalid.

so before i said that the local_temperature is fixed at 21c and occupied_heating_setpoint is fixed at 22c , neither of these can change, resulting in system_mode off and heat working like a switch with off / heat . you cant move the slider anywhere away from 22 as z2m throws a error, its all based on system_mode only.

ill look into getting logs

[robertalexa]

in hive app, you can schedule water yes

I do not trust the hive app, because i do not know what is actually device support and what is hub controlled. e.g. the schedule in software triggering commands when it needs to. Can you set the water schedule on the physical thermostat? Actually the answer probably lies on the system_mode AUTO, can that be selected? does system_mode go into AUTO if the scheduler turns the water on? Or is auto actually irrelevant and it should be removed from exposure?

so before i said that the local_temperature is fixed at 21c and occupied_heating_setpoint is fixed at 22c , neither of these can change, resulting in system_mode off and heat working like a switch with off / heat . you cant move the slider anywhere away from 22 as z2m throws a error, its all based on system_mode only.

sorry i must have misunderstood. thank you for clarifying. so they are both emulated basically just to act like a climate and allow operation. setpoint > local + system_mode heat, warm up the water.

ill look into getting logs

Thank you!

[peterguy04]

i dont think auto has much use to us tbh. we would need a way to set schedules to the device , which doesnt make alot of sense when theres so many other potential methods of doing so. but i dont know if the schedule is stored on device, reciever or cloud tbh. my personal choice would be to get rid of auto.

is this the right logs for you?

ON

Debug Received Zigbee message from 'SLR', type 'attributeReport', cluster 'hvacThermostat', data '{"tempSetpointHold":1,"tempSetpointHoldDuration":65535}' from endpoint 6 with groupID null

Info MQTT publish: topic 'zigbee2mqtt/SLR', payload '{"linkquality":255,"local_temperature_heat":30.22,"local_temperature_water":21,"occupied_heating_setpoint_heat":1,"occupied_heating_setpoint_water":22,"running_state_heat":"idle","running_state_water":"idle","system_mode_heat":"off","system_mode_water":"heat","temperature_setpoint_hold_duration_heat":0,"temperature_setpoint_hold_duration_water":65535,"temperature_setpoint_hold_heat":0,"temperature_setpoint_hold_water":1}'

Debug Received Zigbee message from 'SLR', type 'attributeReport', cluster 'hvacThermostat', data '{"runningState":1}' from endpoint 6 with groupID null

Info MQTT publish: topic 'zigbee2mqtt/SLR', payload '{"linkquality":255,"local_temperature_heat":30.22,"local_temperature_water":21,"occupied_heating_setpoint_heat":1,"occupied_heating_setpoint_water":22,"running_state_heat":"idle","running_state_water":"heat","system_mode_heat":"off","system_mode_water":"heat","temperature_setpoint_hold_duration_heat":0,"temperature_setpoint_hold_duration_water":65535,"temperature_setpoint_hold_heat":0,"temperature_setpoint_hold_water":1}'

OFF

Debug Received Zigbee message from 'SLR', type 'attributeReport', cluster 'hvacThermostat', data '{"tempSetpointHold":0,"tempSetpointHoldDuration":0}' from endpoint 6 with groupID null

Info MQTT publish: topic 'zigbee2mqtt/SLR', payload '{"linkquality":255,"local_temperature_heat":30.22,"local_temperature_water":21,"occupied_heating_setpoint_heat":1,"occupied_heating_setpoint_water":22,"running_state_heat":"idle","running_state_water":"heat","system_mode_heat":"off","system_mode_water":"heat","temperature_setpoint_hold_duration_heat":0,"temperature_setpoint_hold_duration_water":0,"temperature_setpoint_hold_heat":0,"temperature_setpoint_hold_water":0}'

Debug Received Zigbee message from 'SLR', type 'attributeReport', cluster 'hvacThermostat', data '{"runningState":0}' from endpoint 6 with groupID null

Info MQTT publish: topic 'zigbee2mqtt/SLR', payload '{"linkquality":255,"local_temperature_heat":30.22,"local_temperature_water":21,"occupied_heating_setpoint_heat":1,"occupied_heating_setpoint_water":22,"running_state_heat":"idle","running_state_water":"idle","system_mode_heat":"off","system_mode_water":"heat","temperature_setpoint_hold_duration_heat":0,"temperature_setpoint_hold_duration_water":0,"temperature_setpoint_hold_heat":0,"temperature_setpoint_hold_water":0}'

[peterguy04]

@robertalexa regarding battery on SLT2 its just showing 0%, i dont know what its real value is because theres no indicator on screen, but no sign its low battery as there is a low battery icon and it isnt on

[roadsnail]

Rob,

I can confirm @steveuk 's observation that the SLT2 does not display the battery status on the device. As I mentioned, I'm busy on a different project so I'll be watching your developments and look forward to incorporating them into my Pi-ve https://github.com/roadsnail/Pi-ve project at some time and let you guys get on with testing :)

From my experience playing with these SLR/SLT devices (I have 3 test setups as well as my live kit!), I decided to leave the 'AUTO' mode alone and control heating/hot-water using MANUAL/OFF modes and setting the CH setpoint. The HW setpoint doesn't do anything. My standalone Pi-ve solution achieves HW/CH on/off setpoint scheduling in node-red so Hive AUTO is not required.

[robertalexa]

@steveuk23 @roadsnail Just to clarify, you are using the SLT2, and you have followed my steps to fake the Model number and add an external converter for it? And the result it that battery is now showing in exposes tab but it is shown as 0%?

Unlike my SLT3?

Can i please make a suggestion, because since I do not have this device, I am kinda blindly guiding you?

• Can you revert to the original model number and let it be support by z2m itself.
• Go to the Frontend
• Go to Reporting tab
• Setup up a reporting with the following values

Can you also please see if the reporting is binded successfully or if there are any errors, can you then try to do some commands on the device itself, maybe even restart it, maybe even let it be for an hour, just to be absolutely sure that there is actually something wrong rather than a bad coincidence?

@roadsnail Just wanted to send you a big thanks for what you did with your project. I will be honest and say that i do not use it, but purely on the basis of I want HA as my dashboard rather than Node-Red, but your project is exactly what made me look into these devices further, because if we can provide some features through z2m, it will also mean that any other automations can be much simplier, leaving the handling to z2m and pressing buttons to something else. Hence my "vision" of having the water endpoint as a simple on/off switch.

With that in mind Chris, because you have already paved the work for me, and to save me some time and brain power (so i dont have to dig through your project), would you be kind to provide the exact calls that your software uses to handle native boost (even pause if you want, although that is the same), and heat and temperature settings. I have not finished my testing yet but i have a feeling that multiple commands in a row need to be send for example to change from OFF to MANUAL (changes to system_mode, occupied heating, and i also suspect setpoint_hold and setpoint_hold_duration?). I would truly appreciate this!

Rob

[robertalexa]

Actually, as a continuation of the above post, is the SLT2 a wireless device or wired? Looking at deconz it appears to be Mains Powered?? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2979

LE: but their manual mentions batteries.... https://assets.ctfassets.net/mijf9lz5yt3u/6erWY2L3W9Z5O9PBuFSFCD/d0d2c9b07638d2359d15c7750dd61a78/Hive_1_Thermostat_User_Guide.pdf

LE: oh actually

It might be the device only shows voltage and not percentage, so probably a conversion is needed. I shall look into it and then give you code to test? :)

LE: yes, that seems like it, can you please confirm what batteries and how many the SLT2 uses?

[peterguy04]

was gunna say its defo battery.

i followed your steps, ill try reverting back now to real model and do the reporting.

on a slightly different subject ive noticed that with SLR2 in HA what i mentioned earlier . we can set mode , set temp . BUT z2m doesnt seem to be reporting the states back to HA (or HA doesnt know what to do with it) so HA isnt reading the mode, temperature and current temp, so we can write but not read basically

[roadsnail]

As confirmed above, it's battery operated. Takes 2 AA batteries.

[robertalexa]

@peterguy04 I have already crossed some text in my comments, forget about that. it is deffo batteries, and it uses a different attribute and it will need a convertor. Can you please confirm what batteries and how many the SLT2 uses?

on a slightly different subject ive noticed that with SLR2 in HA what i mentioned earlier . we can set mode , set temp . BUT z2m doesnt seem to be reporting the states back to HA (or HA doesnt know what to do with it) so HA isnt reading the mode, temperature and current temp, so we can write but not read basically

Already fixed in my code changes. Now the devices reports to z2m when such changes occur. And then in turns HA will know too

LE: or at least in theory HA should work. I have not reached that far in my testing. Once I get the z2m side of things done, then i can move forward. No point in overcomplicating things

[robertalexa]

I think i got some view on that battery thing, just confirming with the big brains of the operation here https://github.com/Koenkk/zigbee-herdsman-converters/pull/2866#issuecomment-892164334

I might need to give you some code and ask you to test your thermostats with some brand new good batteries, maybe tomorrow if time permits me to do some more work on this

[roadsnail]

@robertalexa

With regard to the 'BOOST' function in my node-red flow, all it does is add 1 deg C to the existing thermostat (SLT) temp, makes that the new SP and then starts a timer (within N-R). A dedicated CH Boost button is not available on the SLT2. After the boost time has counted down (or BOOST CANCEL is actuated which additionally zeroes the BOOST timer), the flow restores the SP value before BOOST started (if that makes sense!).

Also, you ask about multiple commands to achieve switching. It may be worth you having a very quick read of my findings from playing with the SLR/SLT combo and zigbee2mqtt so that I could control HW/CH from my Domoticz scripts.

Take a quick look at the MQTT publishes in https://github.com/roadsnail/Hive-SLR2-SLT2-Zigbee2MQTT-with-node-RED especially the sections Relay Control (Heating) and Relay Control (Hot Water). My Domoticz scripts have always controlled the CH and HW relays by publishing the topics/payloads described. Those command sequences have worked well for me since last December without issues once I moved from the CC2531 to the much improved ZZH device.

BTW, I am also migrating to using Zigbee TRVs away from my older ZWave valves if you are interested. I am using the Zigbee 'Sandy Beach' TRV available at Amazon https://www.amazon.co.uk/gp/product/B093B4SCBT

They integrate nicely into recent versions of zigbee2mqtt and they are relatively cheap and appear to work well given that it is not possible to test them fully until Autumn arrives here in the UK and the heating goes on. (Probably tomorrow! Ha ha)

[roadsnail]

@robertalexa

I'll leave battery level change tests to @peterguy04 if that is okay... I don't have the time to experiment at the moment. Good luck with it :)

[robertalexa]

With regard to the 'BOOST' function in my node-red flow, all it does is add 1 deg C to the existing thermostat (SLT) temp, makes that the new SP and then starts a timer (within N-R). A dedicated CH Boost button is not available on the SLT2. After the boost time has counted down (or BOOST CANCEL is actuated which additionally zeroes the BOOST timer), the flow restores the SP value before BOOST started (if that makes sense!).

So you have not moved to the native boost, as suggested by one of your users. He did post the commands so i have a rough idea.

Take a quick look at the MQTT publishes in https://github.com/roadsnail/Hive-SLR2-SLT2-Zigbee2MQTT-with-node-RED especially the sections Relay Control (Heating) and Relay Control (Hot Water). My Domoticz scripts have always controlled the CH and HW relays by publishing the topics/payloads described. Those command sequences have worked well for me since last December without issues once I moved from the CC2531 to the much improved ZZH device.

I was planning on ready through it, was hoping that maybe you have them at hand and can copy and paste. But it's ok, i will get to it soon :)

BTW, I am also migrating to using Zigbee TRVs away from my older ZWave valves if you are interested. I am using the Zigbee 'Sandy Beach' TRV available at Amazon https://www.amazon.co.uk/gp/product/B093B4SCBT

I fitted my house with Hive TRVs before doing my own zigbee network, then soon sarted hating Hive baaadly, then did my own zigbee network, then properly supported the Hive TRVs and Danfoss Ally using spec documentation. So now i have TRVs that work very nice :)

I'll leave battery level change tests to @peterguy04 if that is okay... I don't have the time to experiment at the moment. Good luck with it :)

No problem, thanks for your input anyway :)

[roadsnail]

I was planning on ready through it, was hoping that maybe you have them at hand and can copy and paste. But it's ok, i will get to it soon :)

Here you go...... (Cut and paste follows...)

Relay Control - Hot Water Hot Water relay control is relatively simple. Just publish 3 MQTT messages in sequence for each state (Off/On). Although the controller publishes a 'water' temperature and thermostat value, these are not used. The HW Relay can be simply switched using the below sequence. (The 'get' message (second one below) is required):-

Switch off HW Relay MQTT message sequence (SLT2 displays 'Off'):- Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"system_mode_water": "off"}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/get Message {"system_mode_water": ""}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"temperature_setpoint_hold_water": "0"}

Switch on HW Relay MQTT message sequence (SLT2 displays 'On'):- Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"system_mode_water": "heat"}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/get Message {"system_mode_water": ""}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"temperature_setpoint_hold_water": "1"}

Note that the water thermostat occupied_heating_setpoint_water has no effect on this function.

Relay Control - Heating Heating relay control is slightly different to the simple on/off Hot Water relay control. As well as publishing 3 MQTT messages for each CH relay state (Off/On). (The 'get' message is once again required). Relay control is also affected by occupied_heating_setpoint (CH Thermostat SP). ie Setting this to a low value (less than thermostat temperature, will set the CH relay to 'off' OR setting this to a high value (greater than thermostat temperature, will set the CH relay to 'on'.

The message sequence to set up CH on/off mode is:-

Switch off CH Relay MQTT message sequence (SLT2 displays 'Off' and thermostat setting changes to 1deg C). Publish:- Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"system_mode_heat": "off"}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/get Message {"system_mode_heat": ""}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"temperature_setpoint_hold_heat": "0"}

Switch on CH Relay 'manual' mode MQTT message sequence (SLT2 displays 'Manual'). Publish:- Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"system_mode_heat": "heat"}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/get Message {"system_mode_heat": ""}

Topic zigbee2mqtt/FRIENDLY_NAME/heat/set Message {"temperature_setpoint_hold_heat": "1"}

Now that CH Relay 'Manual' mode is selected, the relay may be switched by changing the thermostat setpoint value. To achieve this, send a thermostat set value message:-

Topic zigbee2mqtt/FRIENDLY_NAME/heat/set/occupied_heating_setpoint Message VALUE where VALUE is Thermostat setpoint in degrees C (eg. 20.5)

Hope that helps...

[peterguy04]

for native boost on EP5 the commands were these, which the "0x0024" was the time to boost for , the same for EP6 but withno occupied_heating_setpoint

[roadsnail]

So you have not moved to the native boost, as suggested by one of your users. He did post the commands so i have a rough idea.

No, I didn't move to native boost as suggested by @russdan as the boost switch is not available on the older SLT2 device.

[robertalexa]

@roadsnail You are a good man :) Thank you for saving me some time in that investigation. And that you @peterguy04 for digging through your original sniffing. I guess you deserve all the credits for having these devices supported :1st_place_medal:

No, I didn't move to native boost as suggested by @russdan as the boost switch is not available on the older SLT2 device.

Yes, i was thinking exactly that, but had no way of proving it. I am guessing only SLT3 and SLT3b support it. Maybe even the WPT1 but i can't seem to find anyone to test. Anyway, boosting will never be implemented as an easy point and click thing. Because it will be hard to expose it to Frontend and HA as well. So the best I can do is document it and then at least people know how to create their automations.

I will call it a night for now, but I will continue most likely tomorrow. Need to get these woring before winter comes haha. Have a good night guys!

[robertalexa]

@roadsnail @russdan by the way, you won't need that extra get when i am done with my PR Topic zigbee2mqtt/FRIENDLY_NAME/heat/get Message {"system_mode_heat": ""}

I have made changes to the reporting so that can be just skipped :) (obviously they are not yet publishes, but you can find the link to the PR in this thread)

[steveuk23]

Looks like you're making good progress @robertalexa I noticed you mention the WPT1 before that's the model I have that's linked to the SLR1. I can test things on that if you need when I'm back home as well as anything else. I've briefly read about you not including the boost button does that mean if I press the heating boost on the thermostat it wouldn't sync to Z2M or HA.

[robertalexa]

@steveuk23 I forgot you for the WPT1 that would be great :)

With regards to the boost, the short answer is no, it won't sync. The long answer is I will see what i can do to make it user friendly but my hopes are very low for this.

In boost system_mode is emergency_heating. This is currently not allowed by z2m, but can be easily fixed. But it is not supported by HA, and that can't be fixed. HA uses presets for boost, and not the actual system_mode.

But not to worry about it now, I will be raising all these things with Koen and see if between myself and the core z2m team, and maybe their contacts at HA, we can come up with a workaround. We shall see. Enjoy the rest of your holiday :)

[steveuk23]

@robertalexa that's fine I'm happy with which ever way you go :) I'll just put tape over the button to stop my wife pressing it ha ha..

[robertalexa]

@steveuk23 @roadsnail Can one of you please follow these instructions again? https://github.com/Koenkk/zigbee2mqtt/issues/8184#issuecomment-891258303

But use this code for the device

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const e = exposes.presets;

const definition = {
    zigbeeModel: ['SLT2A'],
    model: 'SLT2A',
    vendor: 'Hive',
    description: 'Heating thermostat remote control',
    fromZigbee: [fz.battery],
    toZigbee: [],
    exposes: [e.battery_voltage()],
    configure: async (device, coordinatorEndpoint, logger) => {
        const endpoint = device.getEndpoint(9);
        await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg']);
        await reporting.batteryVoltage(endpoint, {min: 0, max: 60, change: 1});
    },
};

module.exports = definition;

This should now expose a different attribute called battery voltage. Could you please put in fresh brand new batteries, and tell me what is the highest value you are getting? The line from the log where it gets reported is also needed please, so i can see the exact format of the value (e.g. 2 digits, 4 digits etc).

This would allow me to understand what converter i need to put in place in order to convert volts to percentage.

Once i get this i can most likely get this fixed.

LE: fixed syntax error discussed in the post below

[peterguy04]

i tested the above @robertalexa but z2m fails to boot with that converter with this error in the log.

Zigbee2MQTT:info  2021-08-05 06:46:10: Disconnecting from MQTT server
Zigbee2MQTT:info  2021-08-05 06:46:10: Stopping zigbee-herdsman...
Zigbee2MQTT:info  2021-08-05 06:46:10: Stopped zigbee-herdsman
Zigbee2MQTT:info  2021-08-05 06:46:10: Stopped Zigbee2MQTT
Using '/app/data' as data directory
(node:7) UnhandledPromiseRejectionWarning: SyntaxError: Unexpected token ')'
(Use `node --trace-warnings ...` to show where the warning was created)

(node:7) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

EDIT: right i fixed the converter, was just missing a } on the line

await reporting.batteryVoltage(endpoint, {min: 0, max: 60, change: 1);

With brand new batteries

heres the log entries

Info MQTT publish: topic 'zigbee2mqtt/SLT', payload '{"battery":100,"linkquality":255,"voltage":3200}'
Info MQTT publish: topic 'zigbee2mqtt/SLT', payload '{"battery":100,"linkquality":255,"voltage":3100}'

it did seem to fluctuate a bit between 3100 and 3200 at first but now seems to of settled at 3200

[robertalexa]

@peterguy04 You are correct, i messed it up :)

To be honest i was expecting a value around there, just didn't know how many digits the device will have.

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const e = exposes.presets;

const definition = {
    zigbeeModel: ['SLT2A'],
    model: 'SLT2A',
    vendor: 'Hive',
    description: 'Heating thermostat remote control',
    meta: {battery: {voltageToPercentage: '3V_2100'}},
    fromZigbee: [fz.battery],
    toZigbee: [],
    exposes: [e.battery()],
    configure: async (device, coordinatorEndpoint, logger) => {
        const endpoint = device.getEndpoint(9);
        await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg']);
        await reporting.batteryVoltage(endpoint, {min: 0, max: 60, change: 1});
    },
};

module.exports = definition;

Could you try the above code please?

The battery_voltage attribute should now be replaced by battery attribute as percentage, but the source of it should be from converting the voltage into percentage.

Once you get that in place you should get 100% battery.

To test the theory, after doing that can you try to replace the batteries with some used ones and see if the value updates.

Let me know how it goes. Thanks

[peterguy04]

New batteries

Used batteries : payload '{"battery":16,"linkquality":255,"voltage":2700}'

[robertalexa]

@peterguy04 Thank you for confirming. Feels like it is working?

LE: i will however reduce the reporting time. It was set to every minute for testing purposes. If we reduce it, then the device will save more battery by not having to report the battery very often

[peterguy04]

i think so, getting NO RF error on SLT , but i think thats between the SLT and SLR so ill repair that to see if it fixes , its reporting to z2m fine so i dont think the issue is there .

what about report on 1.0% change? and retain previous value until new value is reported. i dont know if thats possible just a suggestion.

[robertalexa]

what about report on 1.0% change? and retain previous value until new value is reported. i dont know if thats possible just a suggestion.

It doesn't quite work that way, because you get a voltage result back, and you have to "guestimate" what percentage that is. That in itself can be inaccurate already, depending on the batteries used. For example a AA battery can stop working earlier in a device and much later in another.

if (voltage < 2100) {
    percentage = 0;
} else if (voltage < 2440) {
    percentage = 6 - ((2440 - voltage) * 6) / 340;
} else if (voltage < 2740) {
    percentage = 18 - ((2740 - voltage) * 12) / 300;
} else if (voltage < 2900) {
    percentage = 42 - ((2900 - voltage) * 24) / 160;
} else if (voltage < 3000) {
    percentage = 100 - ((3000 - voltage) * 58) / 100;
} else if (voltage >= 3000) {
    percentage = 100;
}
percentage = Math.round(percentage);

The default reporting period is every aprox 17 hours. Realistically your thermostat will lose less than 1% per day anyway, so you will be good.

In my case for example, i have put new batteries in my SLT3 in September, and 2 days ago they were on 56%.

[robertalexa]

@peterguy04

With regards to ES6, I have done the following:

• restricted occupied_heating_setpoint to ONLY 22 degrees based on your explanation above. this now looks like this

Can you please confrm what happens if you press the refresh icon for:

• occupied_heating_setpoint
• local_temperature I am wondering if the values are only presented in STATE by the device or if you can GET them manually. Depending on your answer I will change the access level.

Onto ES6 water scheduling and implicitly the heating_mode auto, I have an internal fight going on. I do believe that because of the lack of understanding of how it operates, little to no people will ever rely on using the internal scheduler, so maybe auto should be removed? But on the other side, because auto is a valid value, someone could try to make use of it, or they might set it via commands, or even the thermostat itself, and then the status will not show the mode the device is in. I know you are also a strong believer that it is probably better to just hide that value... This debate is valid for ES5 and the single channel receivers too. So based on the lack of understanding we should then remove it from all. But then that negates the point of having a device supported as best as possible.

Because of the above I feel that it should be left available, for all endpoints and all receivers, and it will be a case of not using it. I will raise this debate in my PR too and see what z2m guys think about it

[robertalexa]

Actually the occupied_heating_setpoint might not display as above. That is because there are some tests that will fail because occupied_heating_setpoint allows setting by definitions. So i can't really restrict them as it stands. I think it will be better to just accept it, and with the bug below fixed it will not be a real problem

It will still be a slider but with one individual value.

I have also discovered a bug with the Frontend which allows users to put in values that should not be supported. Follow it here: https://github.com/nurikk/z2m-frontend/issues/718

[roadsnail]

@robertalexa

Onto ES6 water scheduling and implicitly the heating_mode auto, I have an internal fight going on. I do believe that because of the lack of understanding of how it operates, little to no people will ever rely on using the internal scheduler, so maybe auto should be removed? But on the other side, because auto is a valid value, someone could try to make use of it, or they might set it via commands, or even the thermostat itself, and then the status will not show the mode the device is in. I know you are also a strong believer that it is probably better to just hide that value... This debate is valid for ES5 and the single channel receivers too. So based on the lack of understanding we should then remove it from all. But then that negates the point of having a device supported as best as possible.

Because of the above I feel that it should be left available, for all endpoints and all receivers, and it will be a case of not using it. I will raise this debate in my PR too and see what z2m guys think about it

You make very valid comments about the 'AUTO' scheduler built into the SLR/SLT firmware. My node-red flows (and MQTT snippets used in Domoticz) have always steered clear of AUTO as I have achieved CH/HW scheduling either in N-R or Domoticz. (I presume HA has similar scheduling functionality?). However, anyone playing with the menus on the SLT2/SLT3's remotes may easily enable AUTO (ie scheduled heat/hot water mode). Then the internal SLT/SLR firmware would take over with controlling the CH/HW relays on the SLR. This would screw with any external scheduling set up and controlled by N-R, HA, Domoticz, etc etc.

Maybe, the best way around this is to emulate what the British Gas cloud servers currently do.

ie The end user sets up or modifies CH/HW schedules in their App (or via Web interface) thus updating the British Gas cloud setup for the user which presumably gets written to their Hive Hub which then modifies the schedules stored in the SLR (via Zigbee). (I think the SLR stores this stuff, the SLT only provides a remote interface into the SLR and has a thermocouple installed to measure ambient temperature).

Also, the SLR/SLT devices can be used standalone (ie no Hive Hub/Cloud account). In that instance, all scheduled heat periods are set up via button presses/knob turning on the SLT remotes.

Either way, ideally we need to programme the SLR onboard CH/HW scheduler enabled via AUTO setting.

For this to happen, there needs to be some sort of MQTT topic publish function implemented in Z2M? I think that would be very bespoke for Hive so not covered by generic HVAC functions? Or, maybe it's already there? I don't know. What are your thoughts?

The same logic applies to the Hot water/Heating boost function buttons on the SLT3 remotes (not available on the SLT2). Because they exist, users may press them causing a boiler to fire up, which may screw up any control system that does not cater for them.

It's a tricky situation. In my view, we either work with the functionality built into the SLR/SLT firmware and embrace AUTO heating scheduling, BOOST on/off. Or end users are told not to use those features already provided on the remotes. Somebody mentioned putting tape over the BOOST button :)

In my situation, I have ignored Hive's AUTO and BOOST as we only use the SLT as a pretty thermometer in my home setup. Heat boost/on/off for CH and HW are all controlled by my RPi automation system

OR Alexa commands (via HA-Bridge/Domoticz to turn things on/off)

OR Zigbee push-button switches that cause a boost on/off , CH/HW on/off

OR HTTP REST commands (implemented using N-R on my Pi-ve system) from an App on my phone (Android HTTP Shortcuts) to switch on/off or set CH setpoint.

[peterguy04]

@robertalexa i think your right, keep auto for the purpose of identifying the state. my opinion was more of a selfish one in the fact that i wont use it, i would hide it. like i said though if its something i want hidden i can do that on the front end easily enough, atleast then everyone gets the choice.

so nothing visually happens when refreshing either values on EP6 as they are always at 21 and 22, but in the logs we get

occupied_heating_setpoint

Debug Received MQTT message on 'zigbee2mqtt/SLR/water/get' with data '{"occupied_heating_setpoint_water":""}'
Debug Publishing get 'get' 'occupied_heating_setpoint' to 'SLR'
Info MQTT publish: topic 'zigbee2mqtt/SLR', payload '{"linkquality":255,"local_temperature_heat":26.61,"local_temperature_water":21,"occupied_heating_setpoint_heat":12,"occupied_heating_setpoint_water":22,"running_state_heat":"idle","running_state_water":"idle","system_mode_heat":"off","system_mode_water":"heat","temperature_setpoint_hold_duration_heat":65535,"temperature_setpoint_hold_duration_water":0,"temperature_setpoint_hold_heat":1,"temperature_setpoint_hold_water":0}'

local_temperature

Debug Received MQTT message on 'zigbee2mqtt/SLR/water/get' with data '{"local_temperature_water":""}'
Debug Publishing get 'get' 'local_temperature' to 'SLR'
Info MQTT publish: topic 'zigbee2mqtt/SLR', payload '{"linkquality":255,"local_temperature_heat":26.61,"local_temperature_water":21,"occupied_heating_setpoint_heat":12,"occupied_heating_setpoint_water":22,"running_state_heat":"idle","running_state_water":"idle","system_mode_heat":"off","system_mode_water":"heat","temperature_setpoint_hold_duration_heat":65535,"temperature_setpoint_hold_duration_water":0,"temperature_setpoint_hold_heat":1,"temperature_setpoint_hold_water":0}'

also if its any use i can provide the logs for when i change system_mode on EP6?

[robertalexa]

@roadsnail Hi Chris and thanks for your feedback. This is exactly why i do not want to take stuff out. Someone in a household will press the wrong buttons and then all systems freak out because they do not understand what the device is doing.

So here is my leftover TODO list, with my thoughts attached.

Native Schedule Just like the TRV, nobody should use the internal ones, ever. Looking at my thermostat setting up the schedule is weird, convoluted and simply screw that. It would involve multiple commands, on endpoints that i feel i do not have, and i will not try to find them either. People move away from Hive so they can do their own thing, better. This is a dead end and will remain a dead end. I am not saying it might not be possible, but that I will not pursue it. But in case somebody actually puts the thermostat manually into the schedule, at least the system_mode AUTO exists, z2m and ha won't freak out, and happy days. And you can set an automation on system_mode change, if value is AUTO change it back to HEAT and bring it back into your 3rd party schedule. This way it can be "family-friendly". With regards to bespoke commands (you mentioned them), when one tries such an approach they need to be aware of where else these things get exposed. e.g. will this work or brake home assistant. Thoughts?

Water Endpoint As explained by @peterguy04 this basically acts by toggling system_mode between ON and HEAT. The local temp is faked at 21C, the desired is faked at 22C, the "thermostat" will never shut because the temp will never be reached. So you turn it OFF and ON yourself through the system_mode Because of this behaviour I would personally think that all of these attributes can be left as is and replaced by a simple ON/OFF switch in HA. HOWEVER, and I am now chaning what i said in previous posts above. Because this is a simple toggle like that, it is then simple to use from Z2M Frontend, z2m commands, and HA. Although in HA, for maybe a better user experience, users can set custom entity that acts as an ON/OFF switch. Using very simple HA automation you can change the climate entity system_mode based on that switch. And remove the climate cards for the water endpoint from the dashboard completely. This feels like the best and simple approach. That simple switch can also be exposed to Google Assistant nicely so you can have voice control. That would work really well. I feel this approach is "healthy" and doesn't require massive re-engineering of how z2m works. Share your thoughts pls. PS: i do not even have a dual channel receiver, so here I am just trying to provide ideas for others.

Boost This one will 100% be a major pain in the a**. And I will soon be looking at that. So more on this topic shortly.

Thank you both for your involvement so far, it proved to be really helpful having multiple brains to bounce ideas off, and obviously to test on your devices the things that i am trying to do

[peterguy04]

@robertalexa can i load up your work so far in a external converter for the SLR2 or is there more to it than just a converter? just because its not in a workable state with current support so be nice to test what your doing and how its going so far. be great if i could get EP6 working as currently have to put it back on hive hub for that and id rather not lol