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.
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!
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
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.:
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)
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.
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.
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)
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]
