Single LED light, multiple notifications ( EZmultiPli sensor )

kthejoker20 · 2019-02-20 03:39:05 UTC

1) Give a description of the problem
This piston is using a lot of memory. It works, but not very reliably.

2) What is the expected behavior?
When the expected trigger state is true, the piston should fire the LED lights, even when the trigger state changes.

3) What is happening/not happening?
When the trigger state changes, the LED do not fire, and the mailcheck variable is triggering the LED.

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

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

UPDATE:

Use the working piston at the end of this thread.

guxdude · 2019-02-20 06:00:16 UTC

Try this out. I don’t have a color changing LED but you can put your devices back in where appropriate. Basically, every time one of the conditions change, this updates the color list and then cycles through the colors. You will have to add the repeat if that is what you want also.

kthejoker20 · 2019-02-20 15:47:01 UTC

Wow this is a great improvement. Never thought to do it that way.

One problem though, the lights are staying on. So say, I open the door, the light goes red. Then I close door. The light doesn’t go out.

I think in each group for the else statement, I need to figure out a string to remove the color from the color list. So if that device is closed, the color should be remove so that the color no longer flashes.

Here is my update piston.

guxdude · 2019-02-21 02:12:50 UTC

Hmm. The way I wrote it, the list starts blank each time. It is supposed to trigger on any change (open/close or true/false) and then rebuild the list based on the current conditions. Strange that it is not turning off. You can go into the piston and see what the latest value is for the color list and perhaps see the logs. When the door closes, that light should no longer make it into the list.

When you say doesn’t turn off, you mean it stays on continuously? Two things I didn’t;t do from your original post. I didn’t make the colors repeat (it only goes through he list once) and I didn’t;t turn the light off. You can add an off command to the end and/or add a repeat wrapper around the for loop.

kthejoker20 · 2019-02-21 06:25:08 UTC

Ok did some tinkering and added the repeat loop.

I think what it was missing, is what to do if all the devices were off, which would be to shut off the led.

Here is what i got, but it looks messy.

The forums won’t let me post the piston picture.

but here is the backup code.

Robin · 2019-02-21 15:47:33 UTC

@kthejoker20

You triggered our spam systems due to repeated links to postimg and got yourslef blocked.

We have lifted the blocks on this occasion but please upload your images directly to this forum so they are saved here for posterity.

WCmore · 2019-02-21 17:47:46 UTC

Just a heads-up. There is no way I am digging thru a log 20 pages long.

The courteous way to post a log is to:

Clear the log
Run the piston to capture the errors
Post the log

This shows us the important stuff, without all the extra clutter.

guxdude · 2019-02-23 05:45:35 UTC

I think within the first if, you could hold just add another if:

If count(colorList) is 0
Then
    Turn off
     Exit
Endif

kthejoker20 · 2019-02-25 21:15:20 UTC

The above statement worked great. The lights shuts off now.

Now, I can’t get it to repeat itself properly. It seems to be due to a device handler or firmware issue.

It does work, but stops repeat loop after 8 cycles.

What I have done is split this into 2 pistons. I have it working with 2 pistons. What I did was delete the repeat loop and simply added “execute piston” for the same piston with the for loop. I’m sure that’s a ghetto way to repeat, but it works until someone smarter then me can provide knowledge.

Piston 1 setting the colors per device notification

Piston 2 Setting the color on the single light, cycling through colors if multiple notifications

kthejoker20 · 2019-02-26 00:40:05 UTC

Further testing, it only cycles 7 times, then it stops again.

It works fine with other light bulbs RGBs, no problem.

I am using it on the EZmultipli LED sensor. I wonder if this is a device handler or firmware problem at this point.

guxdude · 2019-02-27 06:59:06 UTC

In piston 2, I don’t think you need the second if. I think it should just look like:

if count is 0
 turn off
 exit
end if
for index=0 to count step 1
do
  set color
  wait 3 second
end for

Note that the set color and the wait can be in the same ‘with’. no need to separate them.

As for your repeat problem, I don’t see where you have implemented any repeat at all. This is only going to run through once for each event so you may only be seeing the cycles associated with turning on/opening each device. I forget, did you want this to loop indefinitely or what was the trigger to stop repeating?

kthejoker20 · 2019-02-27 15:51:18 UTC

I want it to loop indefinitely.

Then when any of the triggers from the other piston change, that will fire the piston again.

If the state changes to 0 or 1, those will stop the piston from repeating, and leave the color solid.

guxdude · 2019-02-27 17:05:57 UTC

OK, then you need to wrap a repeat loop around the for loop. You will have to drag the for loop into the do section of the repeat loop. For the ‘until’ condition, I suggest you use count(@LEDcolor) is 0.

kthejoker20 · 2019-03-01 07:55:04 UTC

GOT IT WORKING…

What threw me way off way the backend stuff that smartthings does. That 10 second delay is something we can’t get around.

I’ve merged everything into 1 piston.

But this piston is now fully functioning. It will hiccup every 10 seconds, but no worry, it will continue on, thats normal for the limitations we have to work with.

kthejoker20 · 2019-03-02 17:24:36 UTC

After running it for a while, it is still broken.

I thought it was working, but this piston still permanently freezes after so many cycles. The light will stay solid when its suppose to flash colors

Anyone have ideas?

guxdude · 2019-03-04 07:17:38 UTC

Is it always freezing on the same color or is it random? Does it freeze when none of the trigger conditions are changing or is it when there are a certain number of colors? I log might be too long but if you could trim down to the last cycle where it freezes, that could be helpful.

kthejoker20 · 2019-03-04 16:36:38 UTC

It’s freezing on random colors. The trigger is able to reset the light color when it freezes.

I attached the log, getting the waiting for semaphore again.

3/4/2019, 12:53:00 PM +146ms
+2ms ╔Received event [Home].time = 1551725578605 with a delay of 1540ms
+7895ms ║RunTime Analysis CS > 44ms > PS > 7801ms > PE > 50ms > CE
+7897ms ║Piston waited at a semaphore for 7757ms
+7902ms ║Runtime (45337 bytes) successfully initialized in 7801ms (v0.3.10a.20190223) (7897ms)
+7905ms ║╔Execution stage started
+7906ms ║╚Execution stage complete. (2ms)
+7936ms ║Setting up scheduled job for Mon, Mar 4 2019 @ 12:53:07 PM CST (in 1s)
+7950ms ╚Event processed successfully (7950ms)
3/4/2019, 12:52:57 PM +845ms
+1ms ╔Received event [Home].execute = recovery with a delay of 81ms
+10152ms ║RunTime Analysis CS > 25ms > PS > 10077ms > PE > 50ms > CE
+10153ms ║Piston waited at a semaphore for 10021ms
+10156ms ║Runtime (45339 bytes) successfully initialized in 10077ms (v0.3.10a.20190223) (10153ms)
+10157ms ║╔Execution stage started
+10171ms ║║Condition #97 evaluated false (7ms)
+10174ms ║║Comparison (dynamic) locked changes = false (1ms)
+10176ms ║║Cancelling condition #98’s schedules…
+10177ms ║║Condition #98 evaluated false (5ms)
+10180ms ║║Comparison (dynamic) yes changes = false (1ms)
+10182ms ║║Condition #99 evaluated false (4ms)
+10183ms ║║Cancelling condition #96’s schedules…
+10184ms ║║Condition group #96 evaluated false (state changed) (22ms)
+10187ms ║╚Execution stage complete. (31ms)
+10189ms ╚Event processed successfully (10189ms)

guxdude · 2019-03-05 05:33:06 UTC

I have heard the semaphore wait is usually indicative of too much traffic causing lag. Perhaps try changing the wait to 3 or 5 seconds and see if it works better.