Energy Saving Piston working but log fills with spam

#1

I have an Energy Monitoring Piston that’s is humming along perfectly and everything is functioning perfectly. However with this piston it keeps logging “Piston waited at a semaphore for 10085ms” every 2 minutes.

12/9/2018, 2:35:10 PM +704ms
+10261ms ║Piston waited at a semaphore for 10085ms
12/9/2018, 2:32:59 PM +555ms
+10191ms ║Piston waited at a semaphore for 10019ms
12/9/2018, 2:30:48 PM +800ms
+10244ms ║Piston waited at a semaphore for 10102ms

Is there a way to turn this off as it just fills up the log with spam. I have ideas to change the times on it to 4 min check, 10 mins off instead of 2,5. But it will still fill up the log considering I use my PC for the most part of every day. Anyone got any ideas or perhaps there is a another way to go about programming this piston so it doesn’t? Thanks.

image
image.png1178×1062 42.2 KB

#2

Noone has any ideas? Is there a way to clear the logs using a piston? That way just every day at midnight I can run an IF, THEN, ELSE to clear the log for the current piston.

#3

The logs can be turned off, or just ignored. WebCoRE automatically deletes old logs as new data comes in.

With that said, repeated semaphore waits usually means some streamlining can be done to your piston, since the log is just alerting you that there was a hold-up.
(hiding the log does not make the piston run any more efficiently)

Just so you are aware, your ASYNC IF will continue the block starting on line 39 immediately after the REFRESH command. It will not wait two minutes with your IF set to ASYNC.

Off topic, but I must say, I am a little concerned about cold-killing your PC. That doesn’t sound healthy, to be honest.

#4

I don’t think that’s how it works unless there’s something specific to longer waits. An asynchronous block runs all of its commands with normal sequence and timing, but the entire block will run alongside other logic that follows the block in the piston. Example:

#5

Great example @ipaterson … Maybe I am missing something, but it seems to confirm my earlier statement. (ASYNC IF will continue the block starting on line 39 immediately after the REFRESH command)

A1 = Refresh (line 34)
B1 = Line 39
B2 = Line 40, 41, 42, etc
A2 = Set variable (Line 36 two minutes later)

#6

Sorry I should have looked at what line 39 was, I thought you meant the line after the Wait.

#7

Good spot, thanks. I have modified it all now to be working perfectly. I have no issues with cold killing as it only turns off if power amount is under a certain value over 2 refreshes. I have tried it with internet drop outs and been using the same sort of setup in smart things for years with no issues, thank you for your concern though.
If anyone is interested, I ended up with this:

image
image.png1178×1799 82.7 KB

Working perfectly.

I was only worried about the logs as I have noticed it fills up the “Memory Used”. What issues are caused by filling up the memory used?

#8

I should also mention, I never really understood how to use the async if. I have read the information on it multiple times but just don’t understand it. So I have just been using trial and error and a lot of testing to see what works and what doesn’t.

#9

I have never had a single concern with the memory used number. I literally ignore that number.

The only issue that I have to keep in mind is the length (complexity) of a piston. There is a maximum size, and the piston will not be savable when we go past that. (don’t worry, it is a few hundred lines of code. I think 100k worth of text if memory serves me correctly)

Also, the larger the piston is, the smaller the log below it. (since they both share the same memory size) Old log data will drop off as new data comes in. In other words, how much log data is stored depends on the size of your piston.

#10

Generally speaking, I avoid using async whenever possible, but there are occasions where it works well. I think it depends on the coding ‘style’ really. I tend to program so the flow is top to bottom. An async can really mess up the logic in a piston designed to flow that way.

In other words, the coding techniques are totally different when an async is in play.

#11

Okay no worries. This is my biggest piston, still have another 10 device automation’s to add.
When I started with webcore I wasn’t sure weather to make pistons by device or by function. I ended up going by function, hopefully I don’t end up regretting it when I run out of. Currently uses 60%

Inkedindex_LI
Inkedindex_LI.jpg1178×5191 756 KB

#12

When saving the piston, my rule of thumb (from observations):

  • 21 chunks will always save
  • 22 chunks will sometimes save
  • 23 chunks will rarely save

For me, this guideline has been more accurate than using that percent. I would guess your piston above is at 20 or 21 chunks right now. (near maximum size) If you want to add more code, I would recommend splitting it into smaller chunks. (this will also alleviate many (all?) of your asyncs)

#13

Good observation. This limit varies and seems to usually depend on the memory available in the parent webCoRE smart app. The chunks are saved there temporarily before building the piston.

So the more pistons (and particularly the more data you have in tiles and piston state text) the fewer chunks you will be able to save.

The worst part of that is when you’re first starting out you can probably make a 30 chunk piston. However, revisiting that piston to make an edit after adding a few dozen unrelated pistons may not be possible. It won’t be able to save the whole thing because the webCoRE app has insufficient memory remaining. This happened to me, fortunately I was able to delete enough pistons and state messages in order to successfully edit it again.