Laundry Monitor Piston - Semaphore Log


#1

1) Give a description of the problem
Based on some other pistons, I put together a piston to alert when laundry is done washing or drying. I have changed around the piston a couple different ways and it works perfectly. My only concern is I see continuous messages in the logs stating “Piston waited a semaphore of *** seconds”. I am wondering if my piston is just not written correctly or should be written more efficiently.

2) What is the expected behaviour?
Piston working as expected but logs are concerning.

3) What is happening/not happening?
Semaphore log messages seen.

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full
I turned on logging but haven’t done laundry again yet so no good logs to upload.


#2

Any time we subscribe to a device’s power, we can expect that piston to be running all day, every day. (since power fluctuates nearly non-stop)

Essentially, when a piston is running, but a new trigger comes in, the piston will use a semaphore delay to wait approx 10 seconds… Hopefully, this will give enough time for the first instance to complete, so the logic can run thru the code top to bottom… yet again.

This means while the piston is running, you can practically guarantee that it will try to run again and again. Constantly waiting for the time to expire / cancelling / resetting a new timer etc…

In your case, it will be doubly bad, since this piston is monitoring two device’s power


Note:

If you set your logging level to Full, you will likely be amazed at just how much commotion those triggers are causing. (unless your devices have inaccurate/vague power sensors)


#3

Thanks for the info. You’re right, I did turn on logging and there is a lot going on. I understand what you’re saying about the piston trying to run over and over during its course. It makes total sense.

Maybe I’ll make two pistons instead of one. That should help a little.

My next option would be to use multi purpose sensors and monitor vibration but I suspect the same issue will occur.

Thanks for the info as always. My 1st piston had a lot of elseif which I know how much you love :wink:


#4

Monitoring vibration will give you much less semaphore delays. (although you’ll still have some)

The logic is: The vibration will never fire unless there are clothes in the wash. (or you bump the machine)

On the other hand, the power will likely change all day, every day…
(Even if the machine is not obviously running)


#5

My absolute all time favorite code… :sunglasses:


Edit:

This may surprise you, but I use ELSEIF in Expressions all the time…

pic

IF Less than A, then X,
ELSEIF between A and B, then Y,
ELSEIF greater than B, then Z, ELSE X

It is just so rare to see it used properly in the body of a piston…


#6

Wow, That’s a whole new level of webcore. Not sure I’ll ever get there :thinking:

Programming and code really isn’t in my area of expertise but it’s fun tinkering with pistons and learning from the experts like you.

On a related note, the semaphore messages only seem to occur during laundry cycle. No power fluctuations seen yet that would cause the piston to keep running. Still monitoring logs though and also writing power to fuel stream.