Piston stopped working


#1

So I have a very simply piston, controls an outlet and shuts off after 60 minutes. Worked fine for a week and then as of today did not. I write logs and the piston stopped logging 17 hours ago.
I refreshed the dashboard, hit test, nothing … Paused and restarted piston and now working/logging again.
any Ideas ?
Piston below, thanks


#2

Why use a variable for this?
Why not just say
“Outlets paower stays greater than 1W for 60 minutes”.


#3

Thanks for the quick reply, not sure that addresses the question ? As I said it works, until it didn’t …


#4

Sorry. Should have followed up.
I cannot see a reason why it would work and then stop.
Do the logs show the power dropping below 1W?
When I have issues I always try and simplify the rules as much as possible and make sure they are stable. That includes not using variables when they are unnecessary.
Give it a try not using variables first.
If it continues to be unreliable, try leaving logging on ‘Full’ and when it fails look at the logs.


#5

NP, here’s a snip of the log:
11/25/2018, 1:29:54 PM +816ms
+1ms ╔Received event [Outlet].power = 0 with a delay of 48ms
+119ms ╚Event processed successfully (119ms)
11/25/2018, 1:19:53 PM +707ms
+1ms ╔Received event [Outlet].power = 0 with a delay of 48ms
+7873ms ║Piston waited at a semaphore for 7765ms
+7892ms ╚Event processed successfully (7892ms)
11/25/2018, 1:19:27 PM +707ms
+1ms ╔Starting piston… (v0.3.108.20180906)
+201ms ║Subscribing to Outlet.power…
+336ms ╚Piston successfully started (335ms)
11/25/2018, 1:19:20 PM +120ms
+112ms ╔Stopping piston…
+194ms ╚Piston successfully stopped (83ms)
11/24/2018, 9:55:01 AM +391ms
+2ms ╔Received event [Outlet].power = 0 with a delay of 54ms
+6622ms ║Piston waited at a semaphore for 6512ms
+6640ms ╚Event processed successfully (6640ms)
11/24/2018, 9:54:56 AM +290ms
+1ms ╔Received event [Outlet].power = 753 with a delay of 56ms
+1640ms ║Piston waited at a semaphore for 1503ms
+1698ms ║Power: 753 Energy :Switch: on
+1843ms ║Device on more than programmed minutes: 60, powering off
+1870ms ║Power: 753 Energy :Switch: on
+1874ms ╚Event processed successfully (1874ms)
11/24/2018, 9:27:43 AM +590ms
+1ms ╔Received event [Outlet].power = 788.9 with a delay of 55ms
+142ms ║Setting up scheduled job for Sat, Nov 24 2018 @ 9:54:50 AM EST (in 1627.187s)
+154ms ╚Event processed successfully (154ms)
11/24/2018, 9:27:38 AM +526ms
+1ms ╔Received event [Outlet].power = 788.5 with a delay of 47ms
+285ms ║Setting up scheduled job for Sat, Nov 24 2018 @ 9:54:50 AM EST (in 1632.108s)
+296ms ╚Event processed successfully (296ms)


#6

So my concern is , this piston is literally about the most simple. 1 if and 1 action …
I don’t mind taking the variable out, but then that leads to me being concerned about ever using any variable at all. If it could cause a problem in something as basic as this, then I shutter to think what problems arise if I ever use them.
I’m thinking over all maybe even though this is short it may not be the most efficient? I notice this:
Memory used: 59% (59087 bytes)
That’s an awful lot of memory no?
Although I just removed the variable and hard set to 60, and same memory usage, so I’m thinking there must be a better way to write this? Either way though, I reported this as a bug because it should have never gotten in this state regardless…


#7

No. Each piston can be up to 100k including logs.
In the logs posted above did it work OK. From what I can see

It looks like it should have turned off. Did it?


#8

I’m not sure when it stopped yesterday. Supposedly 9.55 am. Yes it’s working now as the logs show … but not till I reset it.


#9

I’m afraid all I can suggest is you wait for it to fail and get the logs straight away before they get overwritten. The logs work like a leaky bucket scenario. The oldest ones will drop out of the log. If you are not getting much in the logs then the longer they last.
Sorry I cannot suggest more.
BTW. I do stand by my variables comment though. :slight_smile:
I have used global variables for storing devices and the like so that they can be used across multiple pistons. This means you only have to alter the global variable and not lots of pistons should you need to make changes to the device list.
If you are using very simple variables, as in your case, I would try and keep away from them.
Just my personal preference really. :wink:


#10

ya, thinking something else is going on here and why I reported a bug.
I’m using globals as well.
BTW: As for logging that doesn’t apply here, I pasted all that should be needed, covering both before and after the reset …