Hue motion sensor supported

Don't know, don't own any HUE sensor yet.

But probably it's possible, in last case by using the HUE api and pooling the sensor, and therefore creating your logic.

I'm using the HUE api for other things that don't appear to the common user, and I'm pretty sure I've seen info about the sensor presence data somewhere.

So, yeah, probably it's doable

Hi Ricardo, 

Thanks for your answer, so it's not available in the HUE connection (only Lamps as I can see in the docs?), but we should be able to use the API using web commands? I'm guessing there will be a serious lag between the detection and the trigger? 

Do you have any API docs on the motion sensors? 

Best, 

Michiel

Hi,

Well, as I referred I don't own any sensor from Philips Hue, only several lights, so I can't answer you that. But if you can add a sensor to bOS, you'll be able to confirm us that.

As for the lag, I don't think that's a problem. You can create a logic that queries the Hue Hub on a second or less. Please note that the queries are going to be over the Hub, and not over the Sensor, so any concerns about the battery of the sensor are not a problem, because the sensor sends any changes to the hub. And the logic will act over the hub in this case.

As for the API for the sensors, it's available under the following link:

https://developers.meethue.com/develop/hue-api/5-sensors-api/

You need to create a developer account, but it's free.

I use the API for some cool features, as described on one of my other posts:

https://support.comfortclick.com/en/communities/4/topics/4007-blinking-hue-lights-new-feature-for-your-projects

I saw some examples on the web, but none is for bOS. But the logic to have something working with the hue sensor seems pretty straightforward. One thing that's pretty cool, is that you can also get the battery level from the sensor, which is great for visualization purposes.

It's really great to see Philips Hue to have open API with lot's of functionalities. Hopefully other manufacturers could do the same.

Best regards

Hi Ricardo, 

Yes, thanks for your elaboration. I do believe what I want is the other way around. You push something to HUE, while I want to get it from HUE. But if I can believe you, you state this is perfectly possible?

I did see a thing called "Rules", so I believe my key is here, in combination with the IFTTT or RCP  automations. 

If I ever get this RCP, IFTTT and HUE combination at work that is. Everything is broken in the beta and I cannot downgrade :( 

Hi,

I got your point, you want to use the HUE sensor to trigger something that's not HUE. A KNX light for example...

As I said, I think it's possible. You just need to create a task to pool the sensor cyclically.

Your task needs to pool the API, and extract the json values, for the sensor state and the battery if needed.

In this case you're not going to poll the sensor, but the HUB instead. The sensor is battery based, and it sends the status changes to the HUB. In bOS, your task will poll the HUB to get the sensor status. And therefore use that to trigger what you want. Of course that probably you'll have to fine tune the task until you get the desired result.

It's always better to use local resources, than rely on external services.

I don't own any hue sensor yet, otherwise I would help you further.

Best regards

Hi Ricardo, 

Thanks for your thoughts. Am very close to get this to work using the API, all I need to do is make a PUT request to the bridge. In your other "blinking" example you stated to add an HTTP device and change to PUT; however; I cannot see any options you mention there:

Once this works, I'll try to document this as good as you did ;-) 

Best, 

Michiel

Nevermind; found the "Command" option :-) Getting closer!

Hi Ricardo, 

I'm close to finishing this integration, but my HTTP device triggers uncontrollably. I've it all set; integration with HUE, the API and also my KNX devices and switches, but the HTTP device in charge of setting all scenes does trigger out of control... 

It's like it sends a periodically "health checks" to the lights to check if the device is still responding. Of course it does, which turns on all lights. It's in our hallway connected to our sensors, so everything this happens, we think someone is in the hallway... Pretty spooky :-)

As it has nothing to do with motion sensors, can you confirm you (don't) have this behaviour? 

Best, 

Michiel

Hi,

You're probably doing something wrong. I have lot's of http devices pooling stuff, and none of them is triggering anything unusual.

Your http device / command, needs to pool the HUE API to get the sensor state, not the lights. And if the sensor state is active, you trigger the light. And the command keeps pooling the sensor...as soon as the sensor sets to false state, then you turn off the light. Someone on the internet said, that the sensor might send a false right it stops detecting motion, which I can't confirm. If it does, then I suggest you to add the light to a timer, and adapt your example to ignore the first false, or something like that.

This is something you need to fiddle around...

I would help, but I don't own any sensor, so I can't create an example...

Best regards

Hi Ricardo, 

The motion thing is all worked out, so no questions there. It's about controlling the lights with the information I get from this sensors... 

Let me show you: 

And it looks like the HTTP driver lives on his own and controlling the lights. I have logging on each level (bOS, KNX, HUE,...) and none of them triggers this behaviour. When I disable the HTTP device, the uncontrollably triggering of the lights stops..; 

I do run the bèta (33), so maybe this is related? 

Best, 

Michiel

Why are you sending cyclically the command for running the scene? It's set to 300, and set to true...

I be dammed... Ofcourse :-) That's just stupid of me. Thanks for pointing this out. 

I'll continue working on this!

Best, 

Michiel