Custom Hue API

[hansmbakker]

Cool mod!

Besides pushing the button with software, does this root allow you to modify, extend or replace the Hue API with a better one that works with, say, MQTT or webhooks?

Lots of people want this to respond to events happening in their hue system without having to poll: https://developers.meethue.com/content/reacting-tap-switches https://developers.meethue.com/content/asynchronous-event-notification

[Tristan79]

Well there is the ttyZigbee interface in /dev. If you know the ZigBee Light Link protocol and can find/write any code that does ZLL. And there is something called /usr/sbin/ipbridge which seems to translate zigbee into ip, and the output of ps shows the portalkey and the eui-64 used... since they are passed as arguments, so that's a start... of writing your own wrapper/interface

An easier solution could be that you could write little poller in python and run it on the bridge for the stuff you want to monitor, with an event push interface or a link to mqtt, you can even run mosquitto on the bridge itself... :-)

Experiment and play!

On Thu, Feb 16, 2017 at 9:56 PM, wind-rider [email protected] wrote:

Besides pushing the button with software, does this root allow you to modify, extend or replace the Hue API with a better one that works with, say, MQTT or webhooks?

Lots of people want this to respond to events happening in their hue system without having to poll: https://developers.meethue.com/content/reacting-tap-switches https://developers.meethue.com/content/asynchronous-event-notification

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Tristan79/HUEHack/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AEwE4BxsTFe2kPvN2OzF1U9V5SyNVz45ks5rdLfigaJpZM4MDiET .

[MaxValue]

I got into this topic like 2 months ago. All philips hue logic is in a single executable, /usr/sbin/ipbridge as Tristan79 said. It's a C++ program and decrypted at boot time. It hosts the REST API, issues the zigbee commands and manages the persistent databases, which, unfortunately, are in some .dat format. I wanted to implement hooks on the event that a light becomes reachable again (e.g. turning the light switch on). The options are:

• waiting for philips to implement this
• have a file system watchdog which monitors those persistent files (highly unstable, because no one knows the format)
• have a secondary program running on the bridge which polls every, like, 2 seconds for changes (tip: IP 0.0.0.0).
• build your own hue bridge and emulate the hue api while extending it.

I am currently doing no. 3 and 4. As soon as my code is working i make a repo.

[Tristan79]

The hue brigde uses a CC2530 on i think is a serial port(?) isn't it possible with a clever bash/pipe command to monitor what it sends and receive to from it? (http://www.ti.com/lit/an/swra444/swra444.pdf)

https://peeveeone.com, i ordered two mesh bees... :-)

[JoshMcguigan]

@MaxValue @Tristan79 Is the source available for the /usr/sbin/ipbridge executable? I'm wondering how much effort it would take to extend/modify the Hue API.

[MaxValue]

I am most definitely sure that it is not :D Philips wrote it themselves probably. There are known URLs where you can download the binaries (i saw a reddit thread about that once). Another thing is that Philips encrypts the binaries somehow. I am not sure if they decrypt it at boot or only at software update time. You can guess a little bit what's inside: If you go just to your bridges' IP address in the browser, it shows you a long list of open source projects it uses. Several of those projects are C++ only. That is another hint which is reinforced by the structure of the download-URLs for the update binaries: somewhere in the path is "cpp" mentioned if i remember correctly. Meaning that it's definitely C++ what they use.

This is all from memory, otherwise i would've provided you with links and screenshots.

[darconeous]

How do you know ipbridge is encrypted/obfuscated? Did you run strings on it?

I'm really curious to get a string list. This could allow us to infer the presence of any undocumented features. This could be accomplished in one of the following ways:

1. Simply running strings /usr/sbin/ipbridge, but if ipbridge is obfuscated then this might not be useful.
2. Attempt to extract the memory from the running process, as described here. This should bypass any code obfuscation. However, this seems like it would need GDB.
3. Run strings on the entire memory space of the device: strings /dev/mem This will also likely bypass any code obfuscation, but the memory space might also be fragmented.

Option three is likely the easiest, but it is also the most heavy-handed. Both options two and three may contain keys and passwords, so would need to be sanitized before being shared. But a sanitized strings dump would still be incredibly useful for determining the presence of undocumented features.

[darconeous]

I checked and ipbridge doesn't seem obfuscated or encrypted at all. Strings ran fine,.

[dersimn]

An easier solution could be that you could write little poller in python and run it on the bridge for the stuff you want to monitor, with an event push interface or a link to mqtt, you can even run mosquitto on the bridge itself... :-)

^this

I don't have a Hue Bridge 2 myself, but you could build a Hue-REST-API to MQTT adapter script (using NodeJS or Python if it's available via opkg) and let it run on the bridge itself.

Polling on localhost rather than over a latency-affected network connection will give you latencies of less than <10ms.

@darconeous: If you really consider reverse engineering the Hue binary and stuff.. there are probably easier solutions on the market by now, e.g.: zigbee2mqtt

[SnakyJake]

With the current firmware 1938112040 you can do the following to trigger the link button:

rc.local: #mosquitto iptables -I INPUT -p tcp --dport 1883 --syn -j ACCEPT

download mosquitto (also available for windows, you need mosquitto_pub.exe and mosquitto.dll) issue command: mosquitto_pub -h <IP_OF_HUE_BRIDGE> -t button/link -m pressed mosquitto_pub -h <IP_OF_HUE_BRIDGE> -t button/link -m released like mosquitto_pub -h 192.168.0.53 -t button/link -m pressed mosquitto_pub -h 192.168.0.53 -t button/link -m released

[hansmbakker]

@SnakyJake Are you saying that the hue hub firmware already contains a mqtt server? Is there anything written about that online? This is the first place I saw someone mention it. Also: did you mean that the hue hub firmware needs to be modified to open the 1883 port on the hub’s firewall?

[levihb]

@hansmbakker Yes it does. It uses mosquitto. It's for a version 2 of the API. If you look in /etc/nginx there's plenty of information on the v2 API.

There are plenty of endpoints related to events. So it seems very clear that they're adding MQTT. Or at minimum some sort of event subscription.