Sorry I haven’t been active over the last month and you had to waste a lot of time when I could of fixed it, I’m not the original developer and wouldn’t know how to change the ID looks like it uses the ID of the device ST creates for the hub.
No worries, I realized that the bug is pretty bizarre. I was hoping to patch the code to allow discovery to work correctly, but I do not believe that it can be made to be reliable.
Patching the code to allow someone to just enter the hubs’ addresses is the only way I believe to make it work.
The problem is ( in part ) how multicast functions, which gets into how someone’s network switch is configured.
If IGMP is enabled, and functioning correctly, the SmartThings Hub should be registering its interest in listening for specific multicast; when IGMP is not enabled the UPNP traffic should be set to broadcast to all known addresses within the subnet ( which,… some wireless AP will drop this sort of traffic, so if the SmartThings Hub is bridged then it will only see some of the traffic ).
On top of all of this, the Hue Hub does not seem to broadcast UPNP traffic as it is strictly supposed to ( I think… I might not be aware of some part of the standard that is supposed to keep one UPnP device from creating broadcast storms ).
I’ve just “upgraded” from the OOTB hue integrations to this, and I must say it’s amazing. Having a group of lights turn on/off in perfect sync is beautiful. I do have a couple of questions though I’m hoping someone get help me out with.
- Is there any way to update the level (brightness) whilst a bulb/group is off, so that the new brightness takes effect the next time the bulb is turned on. For example, if I turn off a bulb at 10% brightness, I want to be able to run a command while it is off, and the next time it turns on I want it to be at 100%.
- Reset - when looking at a group from Hue, I have the option to Reset it. This turns the lights green. Is there anyway for me to specify what the reset hue/brightness can be?
Thanks in advance.
Regarding the reset I have no idea.
As for setting the level with the bulb off and I had no luck.
The solution I found was to have it change the level the next time the light turns on using webcore. You can have a piston subscribed to that light that when the light turns on sets its level.
Or you could also use the custom app Circadian Daylight Coordinator, depending on what you need it for
Is there any way to receive bi-directional communication between Hue B Smart and SmartThings?
For example if I use Alexa, the Hue app, a wall switch, or any other means to turn on a Hue light, SmartThings still shows that the light is off. If I turn on the light within SmartThings, then it gets in sync again.
I need SmartThings to update it’s status for the Hue lights as I have a WebCoRE piston that checks if the light is on or off and right now it always says the light is off even though it’s on.
Hue B Smart refreshes the light status every 5 minutes. If you are turning them off using something not going through SmartThings, it indeed could take up to 5 minutes to be detected as on.
I edited the code on mine to refresh every 1 minute, but that also could not be enough.
Something you could try is to add a Refresh command to the lights on webcore some seconds before you need to know if they are on or off. A refresh in any of the lights refreshes all the others as well.
1 Like
Great idea! I have a motion sensor right next to my Hue dimmer switch so I added a section to my piston to do a “refresh” when the motion sensor detects motion. It then waits a few seconds and does another refresh just in case I don’t turn on the light right away and the motion sensor already captured my motion. This causes it to update that my light was turned on so the rest of my piston works the way I want it.
Thanks for your help!
Edit: here is a visual in case anyone else stumbles across this and is trying to do something similar:
1 Like
Great to know its working!
I would remove that second refresh command, though, it seems redundant and just adds extra work on your hub.
The challenge I ran into is that the motion sensor may detect motion and send the refresh before I’ve used the physical switch to turn on the light. I supposed I could remove the first refresh and only have the second one, as the 3 second delay wouldn’t be an issue for me.
Same thing happens here. Bridge is unlinked, I hit the link button, and the app crashes/closes
Only took me forever to figure out that I didn’t have ALL the Hue devices removed from SmartThings. After I got the all removed I could link the bridge with no problem.
So the problem i’m having now is that with I add the Hue lights and groups to Webcore to automate them there, it fails a lot. I have a piston to turn on a light when a door is open and off when closed. I will maybe turn on when the contact is open, or maybe turn off when the contact to closed, or just time out altogether.
When I remove Hue B Smart and add Hue back through “Add Things” the piston runs perfectly… I have no clue why with Hue B Smart it doesn’t act right.
Are you using the classic app, I’m not sure install is possible with new app
would need to see the piston as sounds like something was wrong with it
Yes, I am using the Classic
I think webcore checks to see the state of the ‘Thing’ before executing it, if the ‘Thing’ is already in the state the piston would have made it doesn’t execute, since this solution doesn’t update as fast as the native Smartthings Hue integration, it is possible it still saw the light group as off and didn’t turn it off?
Granted you think if the piston was turning it on, it would update the state in smartthings as well?
This is what I get from the piston using the light when added through Hue B Smart.
9/16/2019, 10:29:41 PM +412ms
+1ms ╔Received event [Contact Sensor 3].contact = closed with a delay of 124ms
+2129ms ║RunTime Analysis CS > 24ms > PS > 2059ms > PE > 46ms > CE
+2130ms ║Piston waited at a semaphore for 2005ms
+2132ms ║Runtime (37785 bytes) successfully initialized in 2059ms (v0.3.10f.20190822) (2130ms)
+2133ms ║╔Execution stage started
+2141ms ║║Comparison (enum) closed is (string) open = false (2ms)
+2142ms ║║Condition #7 evaluated false (5ms)
+2143ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+2145ms ║║Cancelling statement #2’s schedules…
+2151ms ║║Skipped execution of physical command [Dimmer 4].off([]) because it would make no change to the device. (2ms)
+2152ms ║║Executed [Dimmer 4].off (4ms)
+2154ms ║╚Execution stage complete. (21ms)
+2155ms ╚Event processed successfully (2155ms)
9/16/2019, 10:26:49 PM +129ms
+0ms ╔Received event [Home].time/recovery = 1568690809128 with a delay of 0ms
+138ms ║RunTime Analysis CS > 34ms > PS > 60ms > PE > 44ms > CE
+140ms ║Runtime (37699 bytes) successfully initialized in 60ms (v0.3.10f.20190822) (139ms)
+141ms ║╔Execution stage started
+142ms ║╚Execution stage complete. (1ms)
+143ms ╚Event processed successfully (143ms)
9/16/2019, 10:26:29 PM +137ms
+0ms ╔Received event [Home].time/recovery = 1568690789136 with a delay of 0ms
+128ms ║RunTime Analysis CS > 22ms > PS > 60ms > PE > 47ms > CE
+131ms ║Runtime (37699 bytes) successfully initialized in 60ms (v0.3.10f.20190822) (130ms)
+132ms ║╔Execution stage started
+133ms ║╚Execution stage complete. (1ms)
+134ms ╚Event processed successfully (134ms)
9/16/2019, 10:26:23 PM +369ms
+2ms ╔Received event [Contact Sensor 3].contact = closed with a delay of 142ms
+2877ms ║RunTime Analysis CS > 19ms > PS > 2811ms > PE > 46ms > CE
+2878ms ║Piston waited at a semaphore for 2756ms
+2880ms ║Runtime (37778 bytes) successfully initialized in 2811ms (v0.3.10f.20190822) (2877ms)
+2881ms ║╔Execution stage started
+2888ms ║║Comparison (enum) closed is (string) open = false (1ms)
+2890ms ║║Cancelling condition #7’s schedules…
+2891ms ║║Condition #7 evaluated false (5ms)
+2891ms ║║Cancelling condition #1’s schedules…
+2892ms ║║Condition group #1 evaluated false (state changed) (8ms)
+2894ms ║║Cancelling statement #2’s schedules…
+2956ms ║║Executed physical command [Dimmer 4].off() (58ms)
+2957ms ║║Executed [Dimmer 4].off (60ms)
+2959ms ║╚Execution stage complete. (79ms)
+2960ms ╚Event processed successfully (2960ms)
9/16/2019, 10:26:19 PM +825ms
+1ms ╔Received event [Contact Sensor 3].contact = open with a delay of 144ms
+6401ms ║RunTime Analysis CS > 18ms > PS > 6318ms > PE > 65ms > CE
+6403ms ║Piston waited at a semaphore for 6261ms
+6405ms ║Runtime (37776 bytes) successfully initialized in 6318ms (v0.3.10f.20190822) (6403ms)
+6406ms ║╔Execution stage started
+6415ms ║║Comparison (enum) open is (string) open = true (1ms)
+6417ms ║║Condition #7 evaluated true (6ms)
+6418ms ║║Condition group #1 evaluated true (state did not change) (7ms)
+6421ms ║║Cancelling statement #4’s schedules…
+6427ms ║║Skipped execution of physical command [Dimmer 4].on([]) because it would make no change to the device. (2ms)
+6428ms ║║Executed [Dimmer 4].on (4ms)
+6436ms ║║Skipped execution of physical command [Dimmer 4].setLevel([100]) because it would make no change to the device. (3ms)
+6437ms ║║Executed [Dimmer 4].setLevel (5ms)
+6439ms ║╚Execution stage complete. (33ms)
+6441ms ╚Event processed successfully (6440ms)
9/16/2019, 10:26:12 PM +98ms
+0ms ╔Received event [Home].time/recovery = 1568690772097 with a delay of 1ms
+129ms ║RunTime Analysis CS > 20ms > PS > 58ms > PE > 50ms > CE
+131ms ║Runtime (37692 bytes) successfully initialized in 58ms (v0.3.10f.20190822) (130ms)
+132ms ║╔Execution stage started
+133ms ║╚Execution stage complete. (1ms)
+134ms ╚Event processed successfully (134ms)
9/16/2019, 10:26:03 PM +491ms
+2ms ╔Received event [Contact Sensor 3].contact = open with a delay of 156ms
+2634ms ║RunTime Analysis CS > 21ms > PS > 2562ms > PE > 51ms > CE
+2635ms ║Piston waited at a semaphore for 2506ms
+2638ms ║Runtime (37776 bytes) successfully initialized in 2562ms (v0.3.10f.20190822) (2635ms)
+2638ms ║╔Execution stage started
+2646ms ║║Comparison (enum) open is (string) open = true (1ms)
+2648ms ║║Condition #7 evaluated true (4ms)
+2649ms ║║Condition group #1 evaluated true (state did not change) (6ms)
+2651ms ║║Cancelling statement #4’s schedules…
+2657ms ║║Skipped execution of physical command [Dimmer 4].on([]) because it would make no change to the device. (2ms)
+2658ms ║║Executed [Dimmer 4].on (4ms)
+2666ms ║║Skipped execution of physical command [Dimmer 4].setLevel([100]) because it would make no change to the device. (5ms)
+2667ms ║║Executed [Dimmer 4].setLevel (6ms)
+2669ms ║╚Execution stage complete. (31ms)
+2670ms ╚Event processed successfully (2670ms)
And this is what happened when I went back to the native integration.
9/17/2019, 8:11:37 AM +365ms
+2ms ╔Received event [Contact Sensor 3].contact = closed with a delay of 985ms
+145ms ║RunTime Analysis CS > 30ms > PS > 61ms > PE > 53ms > CE
+147ms ║Runtime (37704 bytes) successfully initialized in 61ms (v0.3.10f.20190822) (145ms)
+148ms ║╔Execution stage started
+156ms ║║Comparison (enum) closed is (string) open = false (1ms)
+158ms ║║Cancelling condition #7’s schedules…
+158ms ║║Condition #7 evaluated false (5ms)
+159ms ║║Cancelling condition #1’s schedules…
+160ms ║║Condition group #1 evaluated false (state changed) (8ms)
+163ms ║║Cancelling statement #2’s schedules…
+178ms ║║Executed physical command [Dimmer 4].off() (12ms)
+179ms ║║Executed [Dimmer 4].off (14ms)
+181ms ║╚Execution stage complete. (33ms)
+182ms ╚Event processed successfully (182ms)
9/17/2019, 8:11:34 AM +971ms
+1ms ╔Received event [Contact Sensor 3].contact = open with a delay of 891ms
+128ms ║RunTime Analysis CS > 26ms > PS > 57ms > PE > 45ms > CE
+131ms ║Runtime (37709 bytes) successfully initialized in 57ms (v0.3.10f.20190822) (128ms)
+132ms ║╔Execution stage started
+139ms ║║Comparison (enum) open is (string) open = true (1ms)
+141ms ║║Cancelling condition #7’s schedules…
+142ms ║║Condition #7 evaluated true (5ms)
+143ms ║║Cancelling condition #1’s schedules…
+143ms ║║Condition group #1 evaluated true (state changed) (8ms)
+145ms ║║Cancelling statement #4’s schedules…
+159ms ║║Executed physical command [Dimmer 4].on() (10ms)
+160ms ║║Executed [Dimmer 4].on (12ms)
+173ms ║║Executed physical command [Dimmer 4].setLevel([100]) (9ms)
+173ms ║║Executed [Dimmer 4].setLevel (10ms)
+176ms ║╚Execution stage complete. (44ms)
+177ms ╚Event processed successfully (176ms)
9/17/2019, 8:11:32 AM +704ms
+1ms ╔Received event [Contact Sensor 3].contact = closed with a delay of 885ms
+118ms ║RunTime Analysis CS > 17ms > PS > 54ms > PE > 46ms > CE
+120ms ║Runtime (37704 bytes) successfully initialized in 54ms (v0.3.10f.20190822) (118ms)
+121ms ║╔Execution stage started
+128ms ║║Comparison (enum) closed is (string) open = false (1ms)
+129ms ║║Cancelling condition #7’s schedules…
+130ms ║║Condition #7 evaluated false (5ms)
+131ms ║║Cancelling condition #1’s schedules…
+132ms ║║Condition group #1 evaluated false (state changed) (8ms)
+134ms ║║Cancelling statement #2’s schedules…
+149ms ║║Executed physical command [Dimmer 4].off() (11ms)
+150ms ║║Executed [Dimmer 4].off (13ms)
+152ms ║╚Execution stage complete. (32ms)
+153ms ╚Event processed successfully (153ms)
9/17/2019, 8:11:29 AM +961ms
+2ms ╔Received event [Contact Sensor 3].contact = open with a delay of 895ms
+131ms ║RunTime Analysis CS > 21ms > PS > 56ms > PE > 53ms > CE
+133ms ║Runtime (37709 bytes) successfully initialized in 56ms (v0.3.10f.20190822) (131ms)
+134ms ║╔Execution stage started
+141ms ║║Comparison (enum) open is (string) open = true (1ms)
+143ms ║║Cancelling condition #7’s schedules…
+144ms ║║Condition #7 evaluated true (6ms)
+145ms ║║Cancelling condition #1’s schedules…
+146ms ║║Condition group #1 evaluated true (state changed) (7ms)
+148ms ║║Cancelling statement #4’s schedules…
+163ms ║║Executed physical command [Dimmer 4].on() (11ms)
+163ms ║║Executed [Dimmer 4].on (13ms)
+175ms ║║Executed physical command [Dimmer 4].setLevel([100]) (9ms)
+176ms ║║Executed [Dimmer 4].setLevel (10ms)
+178ms ║╚Execution stage complete. (44ms)
+179ms ╚Event processed successfully (179ms)
In the log with Hue B Smart there is a Received event [Home].time/recovery I don’t see that with the native integration, and the piston completes in less than 200ms. With Hue B Smart it takes over 2000ms for the piston to complete.
Just seems weird to me. Maybe I can try to force a refresh to the device at the end of the piston, but I don’t know how that would help with a 2000ms completion time.
On webcore, on the piston settings disable command optimization, that way even if it thinks it’s on it will still send the command.
I think this would fix it.
Been using this for a couple of years now and its done everything I needed (thanks for all your hard work @tmleafs). Now I have a lot more Hue lights I wanted to simplify scene setting.
I changed my lighting pistons to uses a handful of scenes for different location modes. I used the scene push buttons created by Hue B smart.
e.g.
With Bright
Do
Settogroup(1)
Turn On
I pass in the parameter 1 as an integer.
Bright scene is by default groupid 2 when I look at the button in SmartThings.
I can see in the ST logs that the settogroup runs and says it’s setting the scene to group 1, but the piston still toggles the scene to run for the original group 2?
I thought I could change say a living room scene to run in the office, on the fly in Webcore? If this is possible, can someone please tell me what silly mistake I’m making.
Sorry if this has been asked and answered (I searched for a few days before posting).
So, that did not help, but I did figure it out. Makes no sense to me but, when I deleted the piston and then re-added it, it fires nearly every time. Sometimes it doesn’t fire properly, but I had that problem with the native integration so I don’t see that as an issue.
So don’t know why but removing and re-adding the piston solved my issue.