Huh, you're getting a null value there. I don't get that here:
Are you definitely choosing "Thermostat heat setpoint"? Mine's reporting back "20", which is correct.
Yes, my settings look exactly like your screenshot, but mine is still pulling a (null) result. I've reset and re-paired the devices a couple times and no change. We'll make do with the functionality we have - thanks again for all the help!
Very odd. I'm on HE v2.3.5.152 in case there's been some bug fixed in Rule Machine. If you're able to get by I'll keep tinkering with the driver and hopefully some update that happens in the future irons things out! 
I get a null value there too
I dont use this value as part of my use in my home (I have independent thermostats in each room in the house) but I thought I would share.
Let me know if I can help you to test this further or help with testing of any future tinkering you might do
Are you definitely choosing the receiver and not the thermostat there? The thermostat, counterintuitively, doesn't report the set point. It only talks to the receiver, which is the real brains of the operation.
The only thing the thermostat itself reports to Hubitat are its own battery voltage and the current temperature. The set point is sent to and retrieved from the receiver on the boiler. When you wake up the thermostat you'll see it can tell you the current temperature immediately, but it takes a couple of seconds to retrieve the rest of the information from the receiver.
I think so, but here is the approach I am taking.
In my setup the parent device is called 'Hive Receiver SLR1b' and the child is called 'Hive Thermostat'
The device page for the parent is
and the device page for the child is
When I create the dummy rule in RM and create a new trigger event and use Custom Attribute the Parent Device only has these options
The child device has
Is my approach incorrect?
The child device is however capturing the temperature within the logs
If I go to create a new trigger in the rule and just use 'Temperature' from within the drop down it gives the same null
Might have* stuffed something up with the temperature and heating setpoint reporting.
Fixed.
*definitely did
1 Like
Just checked... Works for me!
Thank you!!!!
1 Like
These drivers have now been updated to support the healthStatus custom attribute, so will no longer misuse presence as a means of reporting device connectivity.
Use @kkossev's Device Health Status to give yourself a nice system overview.
2 Likes
I just noticed there are 3 devices/drivers mentioned in the HPM section. I've only ever had two devices referenced in my Device page. Is that correct? I don't see any reference to a Thermostat?
When you were pairing either the hub dropped out of pairing mode when you got to the thermostat step, or it missed it for some other reason. This is what see on the test setup:
It's actually not important, it only gives you the temperature which the thermostat sees, which is sent to the receiver and reported back to you on that device anyway, and the battery level of the thermostat itself.
So unless you're desperate to have the thermostat battery level reported in Hubitat, I wouldn't bother going through the reset and re-pairing. Though of course you could and the receiver should hook back up to the existing device just fine so long as you don't delete it.
Updated the Receiver parent and child drivers to v0.69. There are some breaking changes here regarding the removal of the heatingMode custom attribute (which was unreliable) and the renaming of heatingBoostRemaining to overrideMinutes with an eye on hot water being added.
The other big reason for these changes is to better support HomeKit, which can now be used reliably with it's slightly US-centric "Off", "Cool", "Heat" and "Auto" modes, which don't account for the override capabilities of the Active Heating system.
If the system is in "Auto" mode, it is running to a schedule. Adjusting the target temperature with "Heat" or "Cool" in HomeKit configures a temporary override to that temperature until the next schedule change, at which point the system will revert to running its scheduled programming. This way people tinkering with HomeKit can't instantly mess up the operation of your heating.
The way to set a permanent override through HomeKit is to first set the system to "Off". This drops it into frost-protect mode (you can set this temperature to between 7 and 12 degrees on the thermostat). If you then choose a "Heat" or "Cool" temperature it will run this new setting permanently. Flick it to "Auto" and the programmed schedule will resume. The bracketed temperatures in "Auto" mode do nothing as this is a heat-only system, and will always revert to being the same value if set separately.
As always, thanks for your ongoing work on this. Its functionality that brings a lot of value!
I've updated to the latest version, all seems good.
I upgraded to a C8 Hub recently and had to go through the pairing again, it took a few goes and resulted in the same devices as it did on the previous Hub. I noticed that the website with instructions looked a bit different to before and the "Step 6" referred to didn't exist?
I thought I would go through the pairing steps here for you to check and amend?
-
Reset the Hive thermostat by pressing the back and menu buttons at the same time, wait for the count down and for it to restart and ask which language you would like. At this point remove the batteries to turn it off
-
Turn off the boiler and the boiler controller and wait for 5 seconds before turning back on. Press and hold the top button until the light on the controller is flashing pink. Press and hold the top button again until it flashes double amber.
-
Turn the thermostat by putting the batteries back in and choose a language, it will begin to seach.
-
Begin the search for new devices in Hubitat by searching for new Zigbee devices
-
As Hubitat detects the devices the lights on the controller will turn constant green the thermostat will complete its searching and begin the setup tutorial. Skip this.
-
Name the devices found by Hubitat to complete the setup.
If you could check the above? I think the sequence might not quite be right and my terminology of the devices might be unhelpful?
Also could you confirm what needs to be done with the Hub? Does this need to be completely removed from the home network and powered off in the new setup?
Huh, looks like they mangled their website a bit. I'll... recreate the instructions in the first post.
From what I can see you've pretty much got the process, though I always start by powering off the boiler and receiver first so there's no chance of the thermostat talking back to the receiver without pairing again.
The Hive hub? If you have no other devices using it just unplug it and consign it to the drawer of Interesting Things. It may become useful again if there's some shockingly important firmware update to be installed one day, but I find that highly unlikely after all this time.
1 Like
Done. Spent a bit too long on that to be honest, but at least it's clear!
1 Like
I've been giving this driver a good kicking on the test system over the past few days and it's performing well enough that I've added the controls for our real heating system to HomeKit (via Homebridge) now.
Even flinging the settings around in the Home app doesn't appear to break anything; if you set something which is unsupported (cooling, either specifically or via the "keep between" temperatures) the driver simply takes the upper (or only) requested set point temperature and uses that as both the upper and lower value, so within a few seconds the system reports the correct auto (schedule) set point and HomeKit gets updated.
It works, basically.
Please report back any successes or failures! 
2 Likes
Hi there,
Thanks for this driver, had a day off work today so this was one of my projects on the list to move the Hive Thermostat over to HE direct after the HE > API fell apart last year.
All is working well, but I wanted to check what the behaviour is after the system is boosted. Does it revert back to the schedule if the system is on Auto at the time of boosting (e.g. does the driver store the current state and then restore it, or always revert to “off” after boosting) please?
Best wishes
Guy
The driver mimics the instruction sent by the Thermostat when requesting boost, which doesn't change the underlying operating mode. It will return to whichever mode it was in previously once the boost time has completed, and this behaviour is fixed in the Receiver's firmware. So far as I can tell there's no way to tinker with it, other than explicitly changing the mode before requesting the boost.
Answering your question in a less roundabout way; yes, if you trigger a boost from either the Thermostat or Hubitat while in schedule mode, the system will revert to schedule mode once the boost is completed.
Fantastic
1 Like
