Restore Color does not work


#1

1) Give a description of the problem
I want to store the color and restore it then for my lightstripe (Kasa|TP-Link)

2) What is the expected behaviour?
It should store the color at beginning, then switch to sky blue. After that, wait 30 sec. After that it should switch to the original color.

3) What is happening/not happening?
At the end it does not switch to the original color, but to white.

**4) Post a Green Snapshot of the piston!

5) Attach logs after turning logging level to Full

12.1.2022, 20:56:58 +714ms
+0ms ╔Received event [Mein Zuhause].test = 1642017418713 with a delay of 0ms
+35ms ║RunTime Analysis CS > 19ms > PS > 6ms > PE > 11ms > CE
+38ms ║Runtime (37786 bytes) successfully initialized in 6ms (v0.3.113.20210203) (36ms)
+42ms ║╔Execution stage started
+47ms ║║Cancelling statement #9’s schedules…
+58ms ║║Executed virtual command [Fernseher Licht].saveStateLocally (6ms)
+62ms ║║Cancelling statement #11’s schedules…
+74ms ║║Executed virtual command setVariable (3ms)
+81ms ║║Executed virtual command log (2ms)
+86ms ║║null
+87ms ║║Executed virtual command log (1ms)
+89ms ║║Cancelling statement #4’s schedules…
+101ms ║║Executed physical command [Fernseher Licht].setColor([[hex: #00BFFF, hue:54, saturation:100, level:50]]) (6ms)
+102ms ║║Executed [Fernseher Licht].setColor (8ms)
+104ms ║║Cancelling statement #6’s schedules…
+108ms ║║Executed virtual command wait (1ms)
+109ms ║║Requesting a wake up for Wed, Jan 12 2022 @ 8:57:28 PM CET (in 30.0s)
+113ms ║╚Execution stage complete. (71ms)
+115ms ║Setting up scheduled job for Wed, Jan 12 2022 @ 8:57:28 PM CET (in 29s)
+134ms ╚Event processed successfully (133ms)


#2

Well, for testing, you definitely do NOT want to be testing variable pushes (line 47) at the same time as testing “capture & restore” (line 48). Only test one method at a time.

Personally, whenever I capture and restore anything (bulb levels, bulb colors, thermostat, fans etc) I try to use specific type variables (not dynamic). It gives me much more control and options, and I have found it much more predictable and reliable compared to using the built-in “capture & restore”.

Your mileage may vary.


It is also wise to add a brief WAIT after ‘Set variable’ and before changing to Sky Blue.
(to give the bulb a moment to respond with the current color)


#3

Here is a sample piston to capture and restore color via Hue and Saturation:


Note there is math going on behind the scenes here, so the Hue may be slightly off on the restore.
(seen in the logs, but undetectable to the human eye)

Clipboard01


#4

It is not working for me:

Logs
13.1.2022, 14:18:59 +965ms
+99ms	║Hue0, Saturat:100


#5

Put the wait before any other tasks to give the piston time to store the info.


#6

How long should it wait? Multiple Seconds?


#7

Sorry, I was in a rush earlier… in your example piston, move the wait to line 27


#8

The WAIT should be after setting the variables, but BEFORE logging or changing colors.

500ms works on many bulbs, but some bulbs are slow to respond, so it may need a second or two.


#9

Even with waiting for 5 seconds, I get a 0

image

13.1.2022, 22:15:02 +401ms
+102ms	║Hue0, Saturat:100

#10

Can you try importing and testing my piston above?
(import code: 8h9j)


#11

I did. Weird, now it is working.

13.1.2022, 22:21:44 +409ms
+651ms	║Captured Hue = 190 / Sat = 100 / Level = 20

#12

You should be able to tweak that piston to fit your needs.


#13

Yes, thanks! You know, why this is sooo weird?


#14

Your structure was frustrating me a bit (I am meticulous when it comes to coding), so I did a few things differently in that piston…


#15

Ok. Haha! I am brand new to webcore, so that’s why. I am a Java and C# coder, so the logic part is easy for me, but webcore is a bit cursed, how smth works the best.


#16

I don’t think webCoRE is cursed… it just has so many elements that not all of them work in all situations…

For what it’s worth, it’s great to have coding (logic) background, but I would encourage new users to bring a blank slate when programming in the SmartHome world… (IE: good practices in one does not necessarily equal good practices in the other)