New binding for Centrica Hive / British Gas Hive with Multizone Heating and Radiator Valve support

Tags: #<Tag:0x00007f6171aba048>

I recently started playing with openHAB and found that the current binding for Hive only supports a single thermostat.

In my home I have a more complex setup so I have created a new binding that supports:

  • Hot water control
  • Multizone heating (thermostat)
  • Smart radiator valves

Now I have got the hang of the Hive API it would probably not be too difficult to add smart plug / bulb support with help from someone who owns them (I only own the Hive heating products).

This is my first attempt at an openHAB binding and I have not extensively tested it so it may be a bit buggy.

Get the binding

Binding README

Releases (including jar)

Initial Pull Request

Setup

N.B. Make sure you do not have Chris Foot’s binding installed as I also use the org.openhab.binding.hive package which will probably break things.

  1. Put the addon jar file in <openhab home>/addons
  2. Manually add a “Hive Account” thing in the Paper UI (use the username/password you would use in the mobile app)
  3. If everything has worked all the supported things should be auto-discovered and show up in the Paper UI Inbox after a few seconds.
1 Like

Great job! Is this specifically for OH2.5+?

It is based on the 2.5.x branch of openhab/openhab-addons if that is what you mean.

Thanks Ross … that means I’m going to have to upgrade, which I’ve been putting off :slight_smile:

You might want to give it a test run on a separate copy of openHAB first if upgrading is a lot of effort. I’ve just been playing with it on my laptop so far, not using it day-to-day. I would hate for you to put a load of work into upgrading only to find my binding does not work correctly with your setup!

Hi Ross; I need to take the plunge anyway … your project has given me the kick that I needed :slight_smile:

Thanks for your work and I will get testing soon as I also have multi-zone Hive.

Just to let you know I’ve done a minor update.

If you have already started trying out my binding you probably want to upgrade before you do too much as this will break any existing channel→item links

Details are on the github releases page.

Please tell me what you think when you get around to trying the binding. I hope you find it useful :slight_smile:

I’ve posted another little update today (again see the github releases page for details).

For now the binding seems to be good enough for me.
Unless I notice problems with bugs / instability I’m probably not going to release any more changes until I get other people’s feedback about how it is working for them.

If other people do not have any significant issues running my binding here are some ways I may be able to improve the binding if people want it:

  • Fahrenheit support (at the moment I assume Celsius)
  • Socket, Bulb, Leak sensor etc. support (with a little help from someone who owns them)
  • Exposing more “features” of devices to openHAB e.g.:
    • frost protect
    • heat-on-demand
    • optimum start
    • zigbee info

EDIT: This bug was fixed in v0.4.2

N.B. I just discovered an issue when @evansnp tried out the binding.

If you have never used the “heating boost” feature before my binding will fail to discover any things (an exception will be thrown in the discovery process).

Until I release a fix this can be worked around by simply starting a heating boost in each of your heating zones using the Hive app before using my binding. (Does not need to be boosting while discovery is running, just needs to have boosted at least once since the Hive system was installed)

Hi Ross. Just an update to say that your binding is working a treat, and has been stable for several days.

Nice one :slight_smile:

1 Like

Yes, been meaning to post here to echo Nigel’s experience. Have been running v0.4.0 for about a week now and it has been rock solid. Just upgraded to v0.4.1, which will hopefully have no impact because “boost” has been previously used on my system.

Thanks for all the work you have put into this. If only I could find a way to talk locally to the hub via MQTT, without the need for all the cloud services, I would then be truly happy.

1 Like

Tantalisingly v6.6.0 of the API is MQTT based (I’m using v6.5.0) and from what they say on their website the Hive Hub 360 may allow it to work offline.

Unfortunately it looks like they are using client certificate authentication because I cannot get the endpoints to complete the TLS handshake. It may be possible to extract a working certificate by digging into the app or the firmware of the Hive View but that is a project for another day.

I decided to go for the REST API for now because it was so much easier to get something up and running.

I’m afraid v0.4.1 will have an unwanted impact after all. I just noticed I made a mistake while refactoring that effectively made all channels read only.

It is a simple fix but I have been making some extensive changes as part of my pull request code review that I have not had a chance to test much yet. I’m hesitant to push the fix in case I have introduced some worse problems elsewhere.

You probably should roll back to v0.4.0 until I have a chance to test my “fixed” version.

1 Like

Thanks Ross, you spotted the error in v0.4.1 before I even noticed! As recommended I have rolled back to v0.4.0 for the moment.

Also good news that MQTT is getting a mention in the Hive APIs. I have a feeling I read an article suggesting that was how the hub communicates with the cloud infrastructure. Would be great if we could get local access to it at some stage so that I can take back ownership of my home!

It looks like with v6.6.0 they went all-in on MQTT. The REST API seems to become just a lookup service for all the devices registerd to your account.
In earlier versions of the API when you looked up a node (device) it would give you a list of attributes / features of that node which you can read from / write to.
In v6.6.0 all that is gone. It just gives you basic info like the node’s ID and name then a local MQTT broker (<hub_serial>._mqtt._tcp.local) and a remote MQTT broker (<jibberish>.iot.eu-west-1.amazonaws.com) along with the corresponding MQTT topics for that node.

I’ve noticed even my standard Hive Hub (NANO2) has an open secure MQTT port. As I cannot complete the TLS handshake I don’t know if that port allows for local control without internet or if it just proxies everything to a cloud service.

Interestingly the Hive website advertises this about the Hub 360:

If your internet goes down, keep your home up and running

Hive Hub 360 has its own internal memory so if your broadband ever goes down your Hive devices and any Hive Actions you’ve set up keep working.

Which may mean full local control if someone can figure out how to get that MQTT port talking.

I’ve been running my fixed version for a couple of days now and nothing seems to have gone terribly wrong. I’ve released it as v0.4.2 if you want to give it a go.

From a user point of view the only changes since the “stable” release v0.4.0 are:

  • Fix bug which broke the binding if the user has never used Heating Boost before.
  • Fix bug in easy-mode-operating channel for Hot Water (would display SCHEDULE instead of OFF)
1 Like

v0.4.2 just installed, so will keep an eye on it for the next few days also. Busy playing with VLANs and switch configurations, so once I settle on something I like I’ll have a look at my Hive Hub (also NANO2) and see if I can see any interesting traffic to/from it.

Yesterday I did have a go at doing a MITM attack on the mobile app. Sadly it turns out the app does not use MQTT. It uses the “BeeKeeper” API (same as the website) which I think is just a facade over the “Omnia” API that I have been using in the binding.

I suspect all the communication from the hub will be encrypted which will make getting anything useful from it challenging. If we are lucky you might be able to spot the mystery location where it looks for firmware updates.

I am becoming quite tempted to get my hands on a second hand hub, solder on some JTAG headers and have my first go at firmware reverse engineering.

Not sure if I am doing something wrong (I am pretty new to openHAB so pretty good chance it is just me) but when I setup the account thing with 0.4.2 i consistantly get nothing. I enabled debug logging from the command line and got the following output upon creation and at every scheduled poll. I got a similar result with 0.4.0 albeit with different line numbers. Any thoughts what I am screwing up?

12:15:07.959 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'hive:account:3ba1ac2a' has been updated.
12:15:07.961 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'hive:account:3ba1ac2a' changed from ONLINE to UNKNOWN (CONFIGURATION_PENDING)
12:15:07.963 [INFO ] [smarthome.event.ItemStateChangedEvent] - hive_account_3ba1ac2a_dump_nodes changed from NULL to OFF
12:15:08.246 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'hive:account:3ba1ac2a' changed from UNKNOWN (CONFIGURATION_PENDING) to ONLINE
12:15:08.361 [DEBUG] [nal.handler.DefaultHiveAccountHandler] - Polling failed with exception
org.openhab.binding.hive.internal.client.exception.HiveClientResponseException: Report Changed Time is unexpectedly null.
        at org.openhab.binding.hive.internal.client.FeatureAttributeFactory.buildFeatureAttribute(FeatureAttributeFactory.java:61) ~[?:?]
        at org.openhab.binding.hive.internal.client.FeatureAttributeFactory.getReadOnlyFromDtoWithAdapter(FeatureAttributeFactory.java:85) ~[?:?]
        at org.openhab.binding.hive.internal.client.FeatureAttributeFactory.getReadOnlyFromDto(FeatureAttributeFactory.java:72) ~[?:?]
        at org.openhab.binding.hive.internal.client.repository.DefaultNodeRepository.getPhysicalDeviceFeatureFromDto(DefaultNodeRepository.java:207) ~[?:?]
        at org.openhab.binding.hive.internal.client.repository.DefaultNodeRepository.parseNodesDto(DefaultNodeRepository.java:551) ~[?:?]
        at org.openhab.binding.hive.internal.client.repository.DefaultNodeRepository.getAllNodes(DefaultNodeRepository.java:603) ~[?:?]
        at org.openhab.binding.hive.internal.client.DefaultHiveClient.makeAuthenticatedApiCall(DefaultHiveClient.java:112) ~[?:?]
        at org.openhab.binding.hive.internal.client.DefaultHiveClient.getAllNodes(DefaultHiveClient.java:144) ~[?:?]
        at org.openhab.binding.hive.internal.handler.DefaultHiveAccountHandler.poll(DefaultHiveAccountHandler.java:281) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_252]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_252]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]