Oh yeah. DUH! That works a lot better. I'll go back in my corner now... 
4 Likes
Job done. I had 20 wc pistons to edit and that took some time but hey it's what it is, it's cool, it's fun and it's a hobby that any other family member doesn't seem to understand. 
"Why the hell kitchen lights are not turning on.." that is one of the things that I heard yesterday.
Anyway.
At first I somehow thought that push 1 turns scene on and push 4 off but that was not the case So push 1 for turning scene on and to turn scene of user need to choose that particular "hue group" and just turn device off. Everything seems to be working ok.
I had to do some changes to those pistons which included turning scene on, waiting x minute to turn scene off. Those kind of webcore rules needs to be changed to two different sections where first one pushes 1 for the scene and then wait the needed time (whatever that is) and then start completely new WITH-section where hue group device is turned off.
3 Likes
@bertabcd1234, I've got a fun one for you. Updated to 5.1 with no problems. Everything works including my LightScenes as before; though, I had to manually select button 1 in Room Lighting again for all my instances that used Hue scenes. Minor but not actually the fun part of this post.
Upgrading to 5.1, my Hubitat Logs were no longer registering any of my individual lights or groups/zones. They were controllable via Hubitat, but not logging. I had to use the Hue app to push data through the eventstream in order to get them to trigger and show up in the logs. I know I did this for one of the 5.0.x upgrades, but was surprised to have to do it again. Not sure if it is from my end of CoCoHue, but though you should know.
In doing some more testing this morning, when Hubitat turns on an individual light or group/zone, it's not showing up in the logs. It shows up in the device's events page, but the logs themselves do not show them.
Do you just mean descriptionText logging? If you re-save the preferences, it should set the specified value. New upgrades are not affected, but you would be if you used earlier 5.x versions.
I see it now. It was a note in the 5.0.3 upgrade. Who reads or backs up their hub before upgrading? 
2 Likes
Hi, I have 4 outdoor motion sensors and until yesterday they were all working ok. But they all stopped reporting their status at 19:46 last night. They work okay in the Hue app, I have tried rebooting the Hubitat hub, cycled through the app and pressed refresh on each device. But all are stuck.
Any ideas?
1 Like
When troubleshooting an app or driver, the one of the first things you can do is check Logs. So, that is my first suggestion here as well. Do you see any errors or other concerning entries (more likely to be on the Bridge device than the sensor, but possible there or in the app as well)? If you enable debug logging on the sensor and bridge, do you see any debug logs generated for either when a motion event or something else happens on the sensor?
Running the "Initialize" command on the bridge device might also fix things if the eventstream (which is required to be connected for the hub to receive these updates) got disconnected, but that should automatically reconnect on its own.
EDIT: Also, are other Hue devices working as expected? E.g., do you get instant status updates on the hub if you turn on/off a light or group using the Hue app?
Hi, thanks for the quick response I have just enabled logging and I don't see anything concerning. I have reinitialised the motion sensors in the app. They are still not reporting status. I'll let the debug log run for the 30 mins and see if anything pops up.
I'll report back later.
I have an app that is designed (hopefully) to turn on all my lights. For the Hue bulbs, I use the group “All Hue Lights” through CoCoHue. It looks like that reports ON if any 1 of the Hue bulbs is already on and the app won’t therefore send a command to that group to turn on. I’m guessing that might be true of the smaller Hue groups too so just switching to them might not work either. It works perfectly if all the Hue bulbs are off, just not all if one of the bulbs is on. Is this by design?
Not exactly sure what "this" is, but the reporting is by design -- the Hue API (in V2, though this is also the option I chose in V1) reports "on" for a group if any light is on. So, that would be by design.
However, the group device on Hubitat does not care if the device is on or off when sending a command. If you're sending an "Off" to a group that is already partially off, it should still send the command. Debug logging on the Bridge and group device should verify what is happening. There is no "on/off optimization"-type thing happening in the driver or app (if your app is doing this, it won't work that way with groups, so you'd have to re-think the approach).
Nothing suspicious in there, but unfortunately, also nothing helpful. Are other devices working OK, including the evenstream (V2 API) data? Debug logs will say what it is using.
Also, I only see logs from the app there. As I mentioned above, bridge logs are the most likely to be helpful in case you weren't also looking at devices.
Thanks!
Okay I have enabled bridge logs...sorry I missed that request. I'll see if anything pops up
Do you have the option to use the V2 API enabled (in the app)? this is necessary for motion sensors starting with version 5.0.
Does the "Select Sensors" page match up the existing devices in the list?
