Trying to Make Phillips Hue Bulbs Blink and Return to Original State

[scottycope]

1) Give a description of the problem
The Phillips Hue Bulbs are not returning to the prior state before the piston was run. Also, the transition from color to color could be a little smoother.

2) What is the expected behavior?
When a virtual switch is triggered, I want the lights to blink green and white 6 times. When the loop is complete, the lights should return to the prior state.

3) What is happening/not happening?
The lights blink OK (not great, but OK - timing, intensity could be better). They blink 6 times and then at the end of the loop they don’t return to the current state. The lights simply stay white (the last color in the loop).

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)

[WCmore]

When using Philips Hue bulbs, and trying to return to a specific color, only use Hue, Saturation & Level. If you attempt to return using the RGB code in color, it will never match.

Strange, I know, but true

[eibyer]

Also add a second or two pause between capture and the following tasks.

[scottycope]

Sorry for the delay in responding to your comments. Life took over for a few days.
Anyway, your suggestions have been very helpful. Adding a one second delay between the capture and the following tasks seemed to allow the lights to return to the prior state. Thanks!

I am now only capturing Hue, Saturation and Level. For the most part, everything seems to work as desired now. However, right around the time the green/white blinking loop ends, the lights turn red for a second and then turn off. Any idea why that may be happening? I’m attaching my (slightly) updated piston here.

[WCmore]

right around the time the green/white blinking loop ends, the lights turn red for a second and then turn off. Any idea why that may be happening?

I think that if you restore the hue before the saturation it will not do that.

[scottycope]

I modified the way I am setting colors. Instead of “set color to Green”, I’m trying to set it using HSL all at once. I am seeing some slight red flickering in there. Does that mean that I should go back to setting the colors individually - hue, saturation THEN level?

also, it doesn’t even seem like it is calling the restore lines of code now as the lights do not turn off after executing the color toggles. I added in the call to piston 3, which speaks the word “restore” to confirm that it’s firing that code but, most of the time, it doesn’t even get there.

I am triggering this piston via a virtual switch. i click the switch one time to turn it on and the piston starts firing. however, i noticed that, maybe 3/4 of the way through, the virtual switch turns off, but i’m not sure why. I’m not manually doing that. I’ve even disabled the portion of code that was turning the switch off because I was trying to determine if the switch state was maybe forcing the piston to stop mid-execution once the switch turned off. So far, I am not sure.

I have changed the initial event to “when switch changes to on” so that this loop won’t keep running forever. I’m not sure if that would have an impact as well.

Any additional insights into this monster I am making? Thanks!

[WCmore]

I may be unique, but I often set colors by any old method… but when I am returning it to a previous color, HSL works well on my Philips Hues. I normally have it all in one line, but splitting it up into three commands shouldn’t be a problem. I suspect the 1 sec delay you placed between Hue / Sat / Lvl makes the transition a bit more obvious.

---

I am triggering this piston via a virtual switch. i click the switch one time to turn it on and the piston starts firing. however, i noticed that, maybe 3/4 of the way through, the virtual switch turns off, but i’m not sure why. I’m not manually doing that.

Lines 55-59 above flips back off your virtual switch, so the last block would not run (since Switch 1 is no longer on). I think you made a wise choice changing the initial line to IF Switch 1 changes to on. This will keep your trigger nice and sharp, and as long as you keep this code towards the bottom:

… it’ll be ready for the next execution.

[scottycope]

Below is my updated piston. A few changes:

• I’ve eliminated the “Log” actions and am now just capturing states of the bulbs.
• I’m also only setting the color via the HSL command and not individually with delays.
• Similarly, I’m only restoring the colors via the HSL command.

What I am seeing is this:

• The piston runs and sets the initial color correctly to green. Somewhere in between the toggle from green to white, the bulbs turn red. I’m not sure why. Perhaps it is an issue with transition from one color to another. How could I update the code to prevent that so that I only see green and white?

Also, when the code to restore the colors is run, sometimes the lights are restored to the original colors and sometimes they are not. In addition, only some of the bulbs are restored, not all of them. I tried looking at the logs and it seems that, when it came to restore the color of one of the bulbs, it restored it to a different color, which, to me, means it captured an incorrect color.

Do I need to change the delays that I have? Add new ones?

Finally, the virtual switch turns off after the piston runs yet there is no code in this piston (or the one it is calling) to do that.

Thank you for your help!!

[WCmore]

A few observations:

I have never been happy with the capture/restore attributes.
I tend to set variables, and restore from those variables instead.
(this lets you actually see the numbers stored)

Also, instead of looping, I tend to use the “Flash” command.
It lets you pick a duration for each color, plus how many cycles you want.

Something like this will only show the colors you specify:

This writes my original & final color to the log:
(Ideally, both lines should match)

I try to keep my network chatter to a minimum, so I normally only program this for one bulb at a time, but your mileage may vary. (sending too many commands to too many devices simultaneously means a command may occasionally get lost along the way)

Also important to note that after the first 10 seconds pass, you may see a tiny hiccup in the color cycle. This is because webCoRE sets up a schedule to finish the task. (You can resolve this by keeping the full cycle under 10 seconds, or you can make it barely noticeable by increasing the time each color lingers)

---

the virtual switch turns off after the piston runs yet there is no code in this piston (or the one it is calling) to do that

Are you using a Virtual Switch, a Simulated Switch, or a Momentary Button?
(MB turn themselves off automatically, SS do not. I have never used a VS)

[scottycope]

Thank you for the input. I think I am getting closer. The updated piston is below. The flash function works much better than the way I was doing it before. No more red in transition!!

However, I am still having issues with trying to restore colors / switch. To test, I had one light yellow, one light blue and one light off to start. When I fired the piston, all lights changed color as they were supposed to. They were not totally in sync with each other but I think that’s OK as it’s just a matter of timing of the events running.

After the flashing, It restored all colors to white (screenshot of the log below). The light that was off turned off again but the blue and yellow lights both stayed white. And it looks to have written the restore command twice to the logs. Not sure why the log shows restores twice but it’s restoring the wrong color!

I had to handle the restores separately since I didn’t know how to restore them all at once. Maybe there’s a better way but I don’t know it.

What am I missing?

Thank you!!!

[scottycope]

As for the virtual switch, I created it through the ST classic app, using the Virtual Device Creator. It is showing as a Virtual Switch in IDE. I don’t know how a VS operates but, I guess with the way the piston is set up now, it doesn’t really matter. I just didn’t want it to run forever. Looks like the VS is doing that.

[WCmore]

According to your logs, it looks like your capture failed. I think it is due to the double curly brackets you have.

I use an ‘Expression’ with no curly brackets whatsoever, like this:

Which spits out:

(webCoRE automatically adds those curly brackets)

---

it looks to have written the restore command twice to the logs. Not sure why

This is because each time a trigger changes (in either direction) the entire piston runs top to bottom. Something turned off EaglesGreen.switch ~20 seconds after it came on. (so line 62 onwards ran twice)

---

One other petty note that may help with troubleshooting… In my piston above, you might not have noticed that my Capture log is written differently than my Restore log.

I did this intentionally because I wanted the captured log to show the variables captured, and I wanted the restore log to show the actual status of the device. Obviously, this is simply a log, so this part has no bearing on the functionality. I just find it helpful when troubleshooting.
(the way yours is currently worded, both logs will be always be identical, so it won’t help any)

[scottycope]

Thanks for the insight again. I ditched the switch created via Virtual Device Creator and, instead, created a Simulated Switch through IDE. This way it stays on until I turn it off (I have that line in my code, just commented out).

I made the changes (I think) as you suggested to the restore state. Your captures and restores are green. Mine are blue. I don’t know if that’s a personal setting or not.

On to running the pistion and the logs…The Capture portion for the colors seems to be running successfully now. I am not so sure it’s capturing the switch state of the bulbs, though. When the lights flash, the timing is all wacky, sometimes the flash takes longer than others; sometimes it doesn’t finish all 6 flashes.

Even more peculiar, the Restore log doesn’t seem to be showing the correct values. Is there something in my code I need to adjust? Do I need to throw a few delays in there? Is my Restore log correct?

I apologize if I’m bombarding you with annoying questions. I’m still new and you’ve been immensely helpful. Thank you!!

Capture portion of the log:

Restore portion of the log:

Updated piston:

[WCmore]

Your captures and restores are green. Mine are blue. I don’t know if that’s a personal setting or not.

The blue text means you went with Value instead of the green Expression that I use.

Either can work, but the syntax is different. Personally, I stopped using Value as soon as I got familiar with the Expression box. I like how I can see more text, PLUS it gives instant feedback on the results right there. (as seen above)

For reference, this is the exact Expression that would work for your Capture log:
'Capture B1 - Hue: 'b1Hue' / Sat: 'b1Sat' / Lvl: 'b1Level

…and your Restore logs:
'Restore B1 - Hue: '[b1 : hue]' / Sat: '[b1 : saturation]' / Lvl: '[b1 : level]
(no curly brackets are used with Expressions, and all text is inside quotes except for variables & [device:attribute] etc)

If you decide to stay with Value, then some quotes are dropped from my above example, and some curly brackets must be added. (Although I have not used Value in over a year though, so I am a bit rusty on the specifics)

---

When the lights flash, the timing is all wacky, sometimes the flash takes longer than others; sometimes it doesn’t finish all 6 flashes.

This is likely because of the 10 second warning I mentioned earlier. When the combined total duration of this piston lasts more than 10 seconds, webCoRE programs a ‘wakeup’ for the remainder of the piston. This often causes a small hiccup in the cycle. I try to keep all flashes under 9 seconds total to prevent this.

---

Even more peculiar, the Restore log doesn’t seem to be showing the correct values. Is there something in my code I need to adjust? Do I need to throw a few delays in there? Is my Restore log correct?

Just to clarify, I think that you mean that the lights returned to the proper color, but the log is not showing the correct data? If this is what you mean, I suspect that it may take a moment for the new color to be registered by your ST hub. You could delete your “Restore logs” and add a brand new block to the very bottom that says:

This should give the hub enough time to update to the new status.

(again, this code is using Expressions, so it will be different syntax if you choose Value)

---

The only other idea I have at the moment is (depending on your setup) you might want the very last command to be: "Turn off Switch 3". This would ‘reset’ the SimSwitch so it will be ready for the next use.

[Svenne]

Was this ever fully resolved?

[Jani]

I just tested this and it does not work like it is suppose to work
For me it seems that switch state is always “0” even if bulb has been on before piston runs.

Everything else works but switch state problem makes it unusable in my case.

EDIT: sorry…actually I was confusing this to another similar topic:

Revert to original state once complete?

@WCmore Here ya go… [20181229a_TestingCaptureRestore] NOTE: The only part that is working (with regard to Capture/Restore) is the part I added (the switch state) to what you posted. That is what makes me think perhaps these other commands just don’t work with the ‘Friends of Hue’ Iris lights that I have.

That is the piston I’m using and it does not understand that switch state thing…