Hi all,
I saw that Hue Automations were added as channels to the Hue Bridge and it’s possible to enable and disable these automations.
In Hue you can however also manually trigger/run automations that do not run on a schedule. Is there a way to run automations in Openhab and if not, will this be added in a future update?
Thanks,
Florian
I will look into it. For the avoidance of doubt can you please illustrate what you want to achieve by showing an example screen shot of doing it in the Hue app?
Sure thing. Here’s the screenshot.
As for the use case, Hue automation is super limited. I can only select the time and repeat on certain week days. Since I am using the sunrise lights in my kids’ room, I want to contextually disable it. In OH I can easily us ephemeris to configure the rule so it does not run during holidays for example.
I can achieve the same thing with a workaround currently, i.e. running a cron job every day 1 min past midnight and disable/enable the rule.
A trigger would be more convenient though.
Ok. Let me see what I can do. The api for that is not obvious, so we may need to reverse engineer it.
I looked at this but unfortunately I hit a dead end.
In technical parlance an ‘automation’ is called a ‘behaviour instance’. The API v2 DTO to command those is described HERE
The “enable” command is already implemented quite easily because the DTO field enabled is simple and clear (a plain boolean). I guess that if we would implement a “run” command, then it would use either the trigger or the configuration DTO field whose contents are JSON complex types that follow a specific but opaque JSON schema. Hue / Signify does not provide any documentation of that schema – neither officially nor on their developer forum.
Therefore if we would try to implement such a “run” command then we will need to observe some actual commands over the wire between the Hue App and the Hue Bridge.
Normally it would be simple enough to use Wireshark to sniff the traffic. However API v2 is only supported via HTTPS so such an approach will not work. And instead we would need to figure out a way of interposing an HTTPS proxy between the App and the Bridge to observe that traffic; which in turn requires a knowledge of the keys.
Currently I cannot think of a way to hack this. => So I wonder if anyone reading this thread has any suggestions? (e.g. @laursen ??)
EDIT: I suppose it is possible that sending the run command from the App to the Bridge might cause an SSE event to OH which would show up in the logs which might give some clue towards reverse engineering the command. I will make some tests.
EDIT 2: a command from the App to the Bridge does cause an SSE event to OH … however the event contains a new value of the state field, and does not contain any hint about the content of the original command.
EDIT 3: in the meantime I was able to set up Charles proxy to sniff the commands that the Hue App sends out. And (obviously) it did not help. The reason is that the Hue App sends uplink commands to the Hue remote cloud server which in turn pushes a downlink command to the Hue bridge. And neither the uplink nor the downlink commands are encoded according to API v2. => So @Ltty the answer to your question is: No.
