Oh right that’s good to know…or maybe not good to know in my case as i’m not getting anything from plugging mine in.
Do you know what the differences are between your SLR1b and my SLR1 ? i’ve tried looking online but can’t find anything.
So did you pair yours to your zigbee in HA ? i wasn’t sure how things paired up do the receiver and thermostat pair to each other and then to HA or are they all paired individually to HA
EDIT…
So it turns out my fuse had blown in the plug ha ha.
it has now powered on any synced straight away to the thermostat and the thermostat turns on and off the receiver ok.
But when trying to pair it to zigbee2mqtt it tells me it’s a unsupported device (SLR1)
@Steveuk Re SLR1/1b, it does appear that the SLR1 is not listed as supported but it is hard to believe the differences are great. Worth examining the relevant log for MQTT messages, perhaps looking with the app “MQTT Explorer” perhaps re-pairing as you do so.
@vonagio At the time of my last post, I had only the boiler controller SLR2b (no thermostat) and so had the slow flashing orange LED but that did not stop the boiler controller functioning. If you get white (arguably a pale pink), then you can press the heating button then release to get the slow flashing orange, which is the boiler controller looking for the thermostat. Possibly you could publish an MQTT message from an imaginary thermostat to stop the flashing.
Now I have the thermostat as well as the boiler controller, I’ve got it all working under node-red and everything appears to be working fine, manual on/off, timers, override, replacing all the stuff that BG Hive servers provide. So, it can be done. In my case, I’ll be running it on the bench for a week or so, just to see whether it is reliable, before swapping over to my boiler for real use.
@Chiny Thanks, can I ask when you had just the receiver connected, how did you get the heating relay to toggle? Simply turn occupied heating setpoint up above the local temp, and have the mode on heat?
So on mine, via z2m, it reports a local_temperature of 21C, which never changes. (Not a huge deal as the receiver is in a daft location, I have other thermometers around to use)
It has modes: off, auto, heat.
Ans an option to set the occupied_heating_setpoint to a desired temp…
I’m struggling to find a way for the receiver to actually toggle the relay itself, rather than pushing the physical button… any ideas?!
I’m mostly interested in using this as a simple relay toggle, for now.
EDIT: for clarity if anyone comes to this post - I relented and bought a SLT3 on ebay (£10!). Since z2m has been updated, I’m not sure if I need this but its got high WAF so i’m keeping it. See my reply below for more
@vonagio Head over HERE where someone has been helping me getting my SLR1 supported.
But he is also re writing code for the other ones.
2 Likes
Thanks @Steveuk - as it happens Robert is also helping me! I’m following his progress on this PR…
2 Likes
Thanks to Robert Alexa’s work on the converter and readme over on z2m, I now have a perfectly working thermostat with some basic scheduling included. I tried Schedy but it did mad things with a whole range of entities I hadn’t asked it to (including spooky TV/music/light changes at random times!!) so I just deleted it and went with a more manual set up…
Thought I’d share my thermostat package file and lovelace cards in case anyone has similar case needs something similar:
EDITS: handful of edits to clarify some bits incase anyone comes down wanting to duplicate this in the future.
Config
I use packages, with this in configuration.yaml:
## /config/configuration.yaml
homeassistant:
packages: !include_dir_named packages
and the package:
## /config/packages/house_thermostat.yaml
## Hive Thermostat
# Switch for frontend to toggle heat/off - with both system_mode and heating_setpoint_hold
switch:
- platform: template
switches:
thermostat_mode:
value_template: "{{ is_state('climate.house_thermostat_receiver','heat') }}"
turn_on:
service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: '{ "system_mode":"heat", "temperature_setpoint_hold":"1" }'
turn_off:
service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: '{ "system_mode":"off", "temperature_setpoint_hold":"0" }'
icon_template: >
{% if is_state('climate.house_thermostat_receiver','heat') %}
mdi:fire
{% elif is_state('climate.house_thermostat_receiver','off') %}
mdi:power
{% else %}
mdi:alert
{% endif %}
# Adds a temperature sensor to HA from the thermostat temperature
template:
- sensor:
name: house_thermostat_temperature
icon: mdi:thermometer
state: "{{ state_attr('climate.house_thermostat_receiver','local_temperature') }}"
state_class: measurement
unit_of_measurement: °C
device_class: temperature
# Scheduling - input times to change temperature
input_datetime:
thermsched_01:
name: Thermostat Schedule 1
icon: mdi:numeric-1-circle-outline
has_time: true
initial: 06:00:00
thermsched_02:
name: Thermostat Schedule 2
icon: mdi:numeric-2-circle-outline
has_time: true
initial: 09:00:00
thermsched_03:
name: Thermostat Schedule 3
icon: mdi:numeric-3-circle-outline
has_time: true
initial: 16:00:00
thermsched_04:
name: Thermostat Schedule 4
icon: mdi:numeric-4-circle-outline
has_time: true
initial: 21:00:00
# Sheduling - corresponding input temperatures for each input time
input_number:
thermtemp_01:
name: Thermostat Temperature 1
icon: mdi:numeric-1-circle-outline
initial: 21
min: 5
max: 32
step: 1
thermtemp_02:
name: Thermostat Temperature 2
icon: mdi:numeric-2-circle-outline
initial: 18
min: 5
max: 32
step: 1
thermtemp_03:
name: Thermostat Temperature 3
icon: mdi:numeric-3-circle-outline
initial: 21
min: 5
max: 32
step: 1
thermtemp_04:
name: Thermostat Temperature 4
icon: mdi:numeric-4-circle-outline
initial: 15
min: 5
max: 32
step: 1
# Automations
automation:
# Scheduling automation - change temp at corresponding time
- id: house_thermostat_schedule
alias: House Thermostat Schedule
description: 'Sets house thermostat temperature based on input_datetimes and input_times'
trigger:
- platform: time
at: input_datetime.thermsched_01
id: '01'
- platform: time
id: '02'
at: input_datetime.thermsched_02
- platform: time
id: '03'
at: input_datetime.thermsched_03
- platform: time
id: '04'
at: input_datetime.thermsched_04
condition:
- condition: state
entity_id: climate.house_thermostat_receiver
state: heat
action:
- choose:
- conditions:
- condition: trigger
id: '01'
sequence:
- service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: >-
{"system_mode":"heat","temperature_setpoint_hold":"1","occupied_heating_setpoint":"{{ states('input_number.thermtemp_01') }}"}
- conditions:
- condition: trigger
id: '02'
sequence:
- service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: >-
{"system_mode":"heat","temperature_setpoint_hold":"1","occupied_heating_setpoint":"{{ states('input_number.thermtemp_02') }}"}
- conditions:
- condition: trigger
id: '03'
sequence:
- service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: >-
{"system_mode":"heat","temperature_setpoint_hold":"1","occupied_heating_setpoint":"{{ states('input_number.thermtemp_03') }}"}
- conditions:
- condition: trigger
id: '04'
sequence:
- service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: >-
{"system_mode":"heat","temperature_setpoint_hold":"1","occupied_heating_setpoint":"{{ states('input_number.thermtemp_04') }}"}
default: []
mode: single
# Fix accidental auto mode selection from the SLT - switch to heat mode.
# This makes sure the HA schedule is used instead of the SLT internal one.
- id: house_thermostat_auto_fix
alias: House Thermostat Auto Fix
description: 'Switches auto mode to heat mode. Maintains HA schedule rather than Hive schedule'
trigger:
- platform: state
entity_id: climate.house_thermostat_receiver
to: auto
condition: []
action:
- service: mqtt.publish
data:
topic: zigbee2mqtt/house_thermostat_receiver/set
payload: '{ "system_mode":"heat", "temperature_setpoint_hold":"1" }'
mode: single
Note: I have SLR1b and SLT3. The SLR1b has entity climate.house_thermostat_receiver.
Lovelace cards
I have a few custom cards included stack-in-card, simple-thermostat, mini-graph-card, and slider-entity-row
For basic thermostat control, on my wall tablets, I have this card:
type: custom:stack-in-card
mode: horizontal
cards:
- type: custom:stack-in-card
cards:
- type: button
entity: switch.thermostat_mode
tap_action:
action: toggle
hold_action:
action: more-info
show_name: false
show_icon: true
show_state: false
icon_height: 30px
- type: conditional
conditions:
- entity: climate.house_thermostat_receiver
state: heat
card:
type: custom:simple-thermostat
entity: climate.house_thermostat_receiver
header: false
layout:
mode:
names: false
headings: false
icons: true
step: column
step_size: '0.5'
decimals: '1'
control: false
sensors: false
- align_header: right
color_thresholds:
- color: '#4B88B0'
value: 16
- color: '#e7710f'
value: 20
- color: '#FC0E34'
value: 24
decimals: 1
entities:
- sensor.house_thermostat_temperature
font_size: 75
hours_to_show: 24
show:
icon: false
name: Lounge
type: custom:mini-graph-card
card_mod:
style: |
ha-card {
--ha-card-background: #04021C;
}
Which looks like this when on:
and like this when off:
To adjust the scheduling, I then have this card in a popup_card when long pressing the switch, and other dashboards I use on desktop:
type: entities
entities:
- entity: input_datetime.thermsched_01
- type: custom:slider-entity-row
entity: input_number.thermtemp_01
full_row: true
- entity: input_datetime.thermsched_02
- type: custom:slider-entity-row
entity: input_number.thermtemp_02
full_row: true
- entity: input_datetime.thermsched_03
- type: custom:slider-entity-row
entity: input_number.thermtemp_03
full_row: true
- entity: input_datetime.thermsched_04
- type: custom:slider-entity-row
entity: input_number.thermtemp_04
full_row: true
Which looks like this:
We find we don’t need any additional schedule changes, or different between weekday/weekend (joys of working from home!)… but extra schedule times should be simple enough to implement, and with a workday sensor, and/or additional input_datetime it should be fairly straightforward to make much more complex schedules.
Still to do:
- find a way to set temp based on current/last temperature when turning it on - as manually toggling the heating now reverts to 19C when turned on. I imagine we might never turn heating on/off, except at the end of winter - instead simply setting a lower temperature when away, for frost protection (Hive may automatically do this with its internal frost level? I need to investigate).
- lower the temperature when we leave the house/preheat when we’re coming home. to do this, I’m working on a granular home occupancy state based on our distance from home (eg going for a walk near home = only lower temp a little bit, going to visit friends for the night = lower temp completely, etc etc). Currently my basic away mode just turns the heating off - not ideal when we’re out for the day and its freezing when we arrive home…
Long post, I might have been better to start a new thread!
2 Likes
Great info all this.
You’ve done some great work, I’ve only had chance to skim through it as I’m at work but I’ll be looking at this later.
I still have not actually hard wired my SLR1 in place but it’s plugged into a socket running on a very simple schedule with Node Red.
I’ve been trying to get my head around boost as that’s what my family tend to use often.
So I’m wanting 3 independent buttons for 30/45/60 boost times and I’ve kind of managed it with Peters code in the GitHub link.
On your Hive wall thermostat are you leaving that set to manual all the time and letting your automation deal with it?
What happens if the boost button is pressed on the Hive SLT3 ? Does it actually sync with HA and perform the boost and if so what happens after the boost has ended.
Thanks
Yes, this is what I do. In my package file above, I included a small automation house_thermostat_auto_fix to automatically switch back to manual mode if auto is selected directly on the thermostat unit - eg by the wife/in-laws! This ensures the HA schedule is always used instead of one set on the SLT itself.
The boost mode works as it’s meant to, initially, but as soon as the next scheduled time comes around the boost is superseded by the HA schedule, ie if you boosted 25 mins before the next schedule time, it would only boost for those 25 mins… then revert to the previous scheduled time, which is not great!
I think you might add a condition to the schedule automation to make sure emergency heat mode isn’t on… then probably some way to revert back to the schedule after it ends, I’m not sure how this would work - maybe a template which could refer to the most recent last schedule time…?!
For us, I’ve not explained the SLT boost mode to my wife, so she doesn’t know it exists, solving that issue! I might make a HA boost button/switch if I get round to it this winter.
1 Like
Quick addition: @Steveuk, if you decide to use or follow my scheduling automation above - I have amended the package.yaml in my earlier post, to use mqtt.publish service rather than climate.set_temperature, as the first method was a bit finicky, sometimes it just doesn’t work, so directly controlling the device through mqtt (including the "temperature_setpoint_hold":"1" command) without HA translation from the climate entity works flawlessly.
1 Like
Thanks again.
I’m gonna go on the laptop later to try and set this method up looks great.
Is it easier using packages ? I’ve never used it before but I’ve heard of it, am I right in thinking it’s a way of grouping all different things into 1 Yaml file like automation, sensors etc.
So you have all this heating code in 1 file and not spread around ?
My HA automations stopped working a few months ago and I’ve not looked into why yet as I normally use Node Red.
With you scheduling does it set the heating to the desired temp at the set time no matter what is set to on the Hive thermostat ?
I’m just thinking of a situation like I had yesterday when the house was too warm so I just turned out off on the Hive thermostat.
So say on this set up if I turn the heating off say 30 mins before the schedule is about to kick in it would then turn it back on wouldn’t it ? Or is there a way where it can ask me if I want the schedule re activating if it’s off ?
Sorry I’m useless at the logic side… And the other side of things lol
I much prefer it, as I spend a lot of time tinkering with a few automations which need input helpers, and template sensors/binary sensors, etc, so when (regularly!!) my latest and greatest automation doesn’t work I can then just delete the package.yaml and all the different entities I’ve made for that are wiped together - I used to just write them in the relavent files but ended up with 100s of useless and out of date entities!
you have this right yes. All the entities and automations etc that I need for this schedule are in that single package yaml file. Now that I’m happy with it all, I will keep it there, but it allows the flexibility of removing it and doing things a different way - I also like the file structure way of organising things. Finally, I write with VS Code, which can search across whole directories so I can easily search for entities/automations without needing to know which package its in.
Not sure what this might be, my first guess is to check you have default_config: or automation: (just one of them) in your configuration.yaml… Might need to ask around if this isnt it…
I’ve just had a think about this, and one way to do this, which is a bit clunky, is to make a binary sensor which checks whether the SLR last_changed time is equal to the schedule automation’s last_triggered time, and then, use that to trigger an automation to disable the scheduling automation. You would then need to turn the automation back on again (either automated with a further automation to reset it at midnight for example, or perhaps with a button/entities card in the frontend).
## Binary sensor to check whether the SLR was last changed by the schedule automation
template:
## append this to the template: section in the package file above
- binary_sensor:
- name: climate_schedule_automated
state: >-
{% set last_changed = states.climate.house_thermostat_receiver.last_changed %}
{% set last_triggered = state_attr('automation.house_thermostat_schedule','last_triggered') %}
{% if last_changed == last_triggered %}
on
{% endif %}
## An extra automation to disable the scheduling automation when the binary_sensor.climate_schedule_automated is turned off - through a manual temp change
automation:
- id: auto_disable_house_thermostat_schedule
alias: Auto-disable House Thermostat Schedule
description: 'Disables the House Thermostat Schedule automatically with manual override of the heating_setpoint_temperature on the SLT or in frontend'
trigger:
- platform: state
entity_id: binary_sensor.climate_schedule_automated
to: 'off'
action:
- service: automation.turn_off
target:
entity_id: automation.house_thermostat_schedule
There are a few ways I can think of where you could have it ask you if you wanted to turn the schedule automation back on again when the next scheduled time comes around… Maybe, another automation, which runs at the scheduled times only if the main automation is off which sends an actionable notification to your phone asking if you want to set the temperature to X degrees… Happy to try to help with that if its something you wanted to do and don’t know where to start!
Edit: I modified and added an extra automation to allow the schedule to run again - glaring error previously!! & added another answer to the last post’s questions
Hi i think i’ve messed up already lol
so what i’ve done so far is…
-
Set my automations back to default ( no !include_dir_merge_list anymore)
-
Added packages: !include_dir_named packages to my configuration.yaml (under home assitant)
-
Created the yaml file called house_thermostat in the packages folder
-
Added your code from from above and replaced “climate.house_thermostat_receiver” with my “climate.hive_receiver” and your “zigbee2mqtt/house_thermostat_receiver/set” with my “zigbee2mqtt/hive_receiver/set”
So then i saved and restarted and it seems to have created all the sensors/switch and automations etc, But i get a error on startup saying unable to setup input_datetime & default_config.
From reading it seems i need to add something to my main config but i’m not sure if i do if i’m now using these packages.
And also a side note that i hope you might be be able to help with is the automations, so like i said i set back to default with just the automations.yaml file in my config folder and when i restarted your new automations do appear there but my existing ones are greyed out with me unable to toggle them lol
Sorry for waffling on heres some screenshots trying to explain.
Thanks
Also this has confused me how have you got a climate sensor for the SLT3 ?
It says on Here that it only creates battery and link sensors
Cheers
Also i’m in no rush for a reply whenever you are free lol
It could be this - you might not have unique ID’s for each of the automations in the automations.yaml file?
What do the logs say for these two errors?
Apols, mistake here, you’re right there isnt a climate entity for the thermostat (though the SLR local_temperature actually comes from the SLT). Only relevance is the climate.house_thermostat_receiver = climate.hive_receiver in your case.
Thanks it looks like the automation problem could be that i’ll have a go afterwards.
No worries just thought i was going mad looking for a extra climate 
They don’t really say much just this
2021-10-04 19:46:54 ERROR (MainThread) [homeassistant.setup] Unable to set up dependencies of default_config. Setup failed for dependencies: input_datetime
2021-10-04 19:46:54 ERROR (MainThread) [homeassistant.setup] Setup failed for default_config: Could not set up all dependencies.
@vonagio
Ok it seems I’m back on track everything is added and seems to be running ok.
My input_datetime issue was cause by the lack of quotes in the names.
Someone on GitHub pointed it out to me and when I changed it to this is worked straight away.
input_datetime:
thermsched_01:
name: "Thermostat Schedule 1"
icon: "mdi:numeric-1-circle-outline"
has_time: true
initial: "06:00:00"
thermsched_02:
name: "Thermostat Schedule 2"
icon: "mdi:numeric-2-circle-outline"
has_time: true
initial: "09:00:00"
thermsched_03:
name: "Thermostat Schedule 3"
icon: "mdi:numeric-3-circle-outline"
has_time: true
initial: "16:00:00"
thermsched_04:
name: "Thermostat Schedule 4"
icon: "mdi:numeric-4-circle-outline"
has_time: true
initial: "21:00:00"
I just want to try and style it so it fits into my working mobile dashboard and work my boost buttons.
I want 3 independent buttons for boost that will boost the heating for 30,45 or 60 mins as that’s what I have at the moment but I want the flame icon to change red when the boost is running but as all 3 buttons use the same sensor they all turn red lol
I’m hoping to hard wire my receiver this afternoon after work, just want to make sure I have the wiring correct as I’m going from a dual channel to a single channel
I never used the dual water side anyway as I have a combi boiler.
Thanks for help.
1 Like
@HarvsG Thanks! My Hive hub was stuck in the initialising phase and BG wanted me to purchase a replacement hub.
Using zHA I have cut over all my Hive accessories (lights, plugs. contact and motion sensors) and thanks to these instructions I now also have my thermostat in HA.
However, whilst it reports status (temp/state etc) I don’t seem to be able to control either the heating or the hotwater. Any ideas/suggestions?
Have you paired the thermostat to the receiver ?
So they both need adding into ZHA individually but they also need pairing to each other.
If not reset both so they start searching (the receiver needs to flash orange not light purple) then they should connect to each other.
1 Like
Glad you got this sorted - I just checked mine and I don’t have the speech marks… yet it still works!!! I won’t fiddle with it now, but will update the post above to include them just incase anyone else comes by.
Did you get it installed? How’s it working for you?
Really interested to see how you integrate this - it feels a bit complicated to me, might need to find a way (template?) to see the last/current input_datetime so HA knows the original temperature to return to after boost is over…
1 Like
Thanks I messaged you not been great so far since hard wiring but I think that’s another issue.
Can I ask you’ve done these input_datetimes and I’ve added the sliders like you have with the initial numbers.
If I change the numbers in that card from the initial number it works bit after time it defaults back to the initial number is that how it’s meant to work or once I change the number in the card it should stay that value ?