update the code and you will have the ability to set sensitivity. After the update, issue a full refresh to force update the internally cached state before attempting to change. It won't break anything if you don't, but the setting for sensitivity is linked to the app's cached state, so if it is outdated, it may show the wrong value.
2 Likes
Thanks - to confirm - 0 - low, 1 - medium, 2 - high?
Honestly, I don’t really know. I would assume 0 is les than 2, and since the at tribe is sensitive, that would mean 0 is less sensitive than 2, nothing would surprise me with software.
What I do is ask the device for its config, and if reports back that it’s sensitivitymax = 2 and sensitivity is what ever the current value is. I use whatever I get back in as the max value for the range max. And if for some reason no current value is reported, i set the default to the max value — because all my sensors were set to max value, and I don’t mess with them.
I also plan to add light level setting for day/night attribute from hue but want to plan that out more.
Thanks @armand, for this app. Worked right away for me with my first Hue hub connected to 8 Lily spots. I have two questions though...
- Does this app support two Hue hubs? That first Hue hub was for my front yard landscape lights. I have a project I am planning for my backyard landscape lights with another Hue hub and 12 Lily spots. Can I just select the hub button in the app to add another Hue hub?
- Why does the app (or all the apps) require to scan the network to find the Hue hub(s)? They appear to be scanning UDP for Hue traffic to find the hub. Then once the Hue hub IP is found and established authentication, don't need UDP anymore. This can be inconvenient when your Hue hub is on the client side of a wireless bridge which doesn't pass that traffic. Couldn't we just supply the app with the IP address of the Hue hub? The workaround is to bring the Hue hub onto the same network as Hubitat, establish the connection, then move the Hue hub back to the intended network.
Thank You
Troy
You can run more than one hub by installing more than one instance of the app. In my version 2 code, I create the hubs as child apps of the main app that just locates the hubs, and pairs them. But that code is on hold because the the V2 API has not very helpful as a full replacement to the v1 API. I have been tinkering with the idea of moving forward the the new logical layout of parent app, and child apps per hub. Maybe I will move forward with that plan and release a pre-v2 update that does a lot of the heavy lifting work now, before full v2 API implementation. gif meme a couple weeks to work through it all. In the mean time, you can just install the app multiple times, and pair each instance to a different hub.
The Hue protocol uses SSDP (as do many smart devices) which is a simple service discovery protocol. It does use UDP, more specifically, it uses a specific multi-cast IP address (239.255.255.250). Multi-cast should work on every LAN, regardless of bridging. In fact, SSDP is part of the UPnP protocol, so every router and access point should support it, and all network switches support it. The only time it wouldn't, is if the device being discovered is on the other side of a NATing device. Even if the router has UPnP turned off, SSDP will still work. In a multi-subnet LAN configuration multi-cast should propagate across all the subnets as well, as the router should forward the packets to any device subscribed to them. In rare cases, IGMP Snooping may be required on some routers, and managed switches before multi-cast traffic is handled correctly.
As such, we all rely on SSDP for discovering devices, because it is a protocol that was built for that very purpose, and which works on almost all networks. I don't know which wireless bridge you are using, but I have used more than a dozen different ones, and none of them had issues with SSDP packets, provided they were in bridging mode, and as stated above, if it doesn't work you should have an IGMP snooping setting or multicast setting that you can turn on.
What I can do is to work on the user interface more, so that some of the newer options available to hue can be used. Reviewing their updated discovery documentation, I see I can use SSDP, mDNS (also multi-cast, but a different protocol, and not supported on the HE platform), or a service discovery web site.
So I think what I will do is provide 3 modes of discovery that you can pick from, Simple Discovery (LAN based), discovery web portal (https://discovery.meethue.com), or manual IP address. This will have to wait a few days as I have other tasks to address.
1 Like
That was all very helpful @armand. Thank You !
@armand When I compare to the app it does appear that my original assumption was correct regarding the sensitivity levels.
However, since installing this latest update the motion sensor is not apparently firing. I am in the process of moving all devices from my legacy homeseer. So I have the hue plugin in homeseer and it is working fine. Also in the app I see the motion sensor activating. Yet in Hubitat I get nothing - log below - during this time it triggered multiple times in Homeseer. Incidentally I did try testing with Homeseer disabled in case that was causing an issue.
I only just installed this integration two days ago, before updating to the version with the sensitivity adjustment yesterday. I initially moved the sensitivity to 0 - but when I noticed it wasn't working this morning I returned it to 1 - the default.
Happy to do more testing? Thanks.
Please go to your bridge device and issue a refresh, then press the connect button. it may have lost connection with the event stream.
@armand When you say press the connect button. Are you referring to the setup button on the back for the motion sensor or the button on the top of the hue hub? Thanks.
Got it. That solved my problem. Thanks.
Hi there -
I've found this integration really excellent but I'm running into a particular issue. I'm using Maker API to communicate the state of my hue groups to another application. This integration seems to update group state faster than the native hue integration which is great. However, when a group is turned off, the events sent via Maker API cause the group to show as off and then immediately back on. I think the issue is that after an Off, a level is sent even though the group is off. That comes across as the device being on, so in my receiving app, the device turns back on immediately.
If you look at the events, you can see that when the device is turned off, it reports a level of zero, but then follows that with a level of 65 - which was the level when it was on. I think this is the reason the device appears to go back on.
What is commanding the group to turn off? In Hubitat, setting a level to any value other than 0 turns on the device, so I follow this logic to be compliant with capture/restore state actions and the mirror me apps.
Certainly possible there is a bug in my code, but this would be a huge issue and I have not heard anyone complaining, and I don’t have this behavior for any of my groups. As such, I suspect the issue is in whatever’s turning off the group is also sending a level set command which is why my code turns the group back on.
If anyone else is experiencing this behavior, please speak up.
I know it's been a few weeks but everything worked great for awhile there and had no reason to go back and look.
I've got a light that occasionally fails to turn on, or fails to turn off. From the device page I can turn it on an off several times and re-create it. Rebooted the hub too just to see but didn't make a difference. It's definitely a breakdown between HE and Hue. I can toggle it all day long from the hue app without any failure.
When I go back to the parent app, it's showing offline. If I hit connect, it's shows connected. Auto refresh is still set to 1hr.
Not sure if that connected state matters or not. I ran out of time and didn't get to retest the light after connecting it in the parent device.
Thank you for the feedback. The connected state has always been a bit of a challenge. I have to use a Hubitat provided method to subscribe to the event stream. Coupled with this is a support method that informs me when the stream state changes. There is no way for me to query if the stream is connected or not. What happens if that the event stream interface falsely reports many times over that the connection stopped, and if I reconnect it, Inwill have two connections open. When a refresh is issued, the stream does a best effort attempt at trying to determine if the stream is online or not, and reconnect it if offline.
This would have nothing to do with being able to turn lights on or off from the app, it only has to do with detecting the state of light changes when issued outside the hue system.
As for the app not sending the on/off event to the light, is this a light that is a member of a group that you are commanding on/off or Mia the on/off command sent directly to the light?
There are hard limits to how many commands can be sent to the hub. I do not have any code to regulate this and forcefully pace them out over time. I can look some more into the issue, but I need to know if it is a light in a group in/off command that fails, or an per light command that fails to know where to look.
Ah gotcha. I wasn't sure if the connected state mattered or not. In this case it does not. I only have 3 hue bulbs on the bridge and they only get controlled via hubitat.
Not using any groups, just individual devices. This is a weird thing that I've been chasing on and off for awhile now. I'll go weeks with no issues, then suddenly I'll have issues again. I just mostly wanted to make sure the event stream wasn't part of the problem.
The hue hub cannot handle more than 10 bulbs state changes per second. Are you sure you are not exceeding this limit?
If the command being sent is not to turn the light on, nor to activate a scene, then I just queue up the action until the light is in the on state:
// If device state does not contain the value on, then determine if we must queue the state for a future call
if (!deviceState.on && !deviceState.scene) {
if ((currentValue(child, 'switch') ?: 'on') == 'off') {
return
}
}
You can try removing this block of code inside the setDeviceState() method of the app, and see if that clears up your issues. The purpose of this is to limit the number of calls to the hue hub, to only those that affect the visible state of the light, and the reason for this is to keep hub load down.
2 Likes
Yeah it shouldn't be. I'm usually able to recreate it by turning it on and off a few times from the device page. I'll try that this weekend and see if it changes anything.
@armand Yesterday I had an issue with my network - one device, an old hub, was flooding the network. I had to go down the switch unplugging devices until I isolated it and pulled it. Once I figured it out everything was running again.
But then this morning I realized that the Hue hub had not reconnected. Since I didn't reboot the hubitat I assume it gave up connecting while I was messing with the network?
How often or for how long does it attempt to reconnect? I thought to add a rule that checks the status and attempt a reconnect. But I thought it best to understand the events that lead to it remaining offline first. Thanks.
1 Like
I do not auto-reconnect because there is no way to test if the connection is up or not, and reconnecting it while it is already online causes issues. This is a problem with the Hubitat EventStream code. It has a facility to notify me when the connection ends, it it falsely reports I’m the connection has ended after nearly every event sent, even though the connection is still up. I will see if I can learn any thing new in regards to this. It is annoying and should be fixed by HE.
