Two triggers, on event and on no event?

#1

1) Give a description of the problem
This piston works but I get a lot of waiting at semaphores. So I wondered if anyone here might have an idea of a better way.

2) What is the expected behaviour?
It does what it is supposed to. If the HEM does not generate a energy event in 5 minutes it means it locked up and I need to reset. A power cycle gets it going again.

3) What is happening/not happening?
I have tried using a counter that would increase from 0 to 100 and then reset and start over. Then instead of the 5 minute timer I set an if counter did not change for 5 minutes reset the HEM. This would reset every time there was a energy event. What is the best way to have two triggers, one when the device has an event and one if it doesn’t for some specified amount of time.

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

hemreset2
hemreset2.png1178×1072 107 KB

#2

Would something like this work?

If Power Meter 1's usage changes
then
  Switch 49
  do
     Wait 10 minutes
     Send Push Notification
     Flash off/on
     On

When the event subscription is triggered, it should restart the piston and break the 10 minute timer.

#3

Since power fluctuates so often, (technically, many times each second, all day long)… then pistons that trigger off those changes will often have semaphore delays. (your piston is literally updating {Last_event} all day long)

Ironically, the more accurate & precise your Power Meter is, the more likely the semaphore delays.
(unless it has internal code to ignore small variances)

#4

I am only looking at energy events which are occurring every 2 minutes. It’s kind of weird in that at my previous home they were occurring every 10 to 15 seconds. The device would lock up at least once every two to three days. The main reason I created my smartapp to monitor and reset it. When I moved it took me about a month to get the HEM re-installed and set back up. I am using the same DTH I used before but since moving it slowed down to every 2 minutes and it now hardly ever locks up. It is still just as accurate, as my power company has a website that will give me daily usage numbers and my HEM is always spot on with what they show.

@ ian_boje, interesting, I might have to play around with that. Thanks

#5

I’m having a bit of a brain fade at the moment. Would that actually work? The condition needs to evaluate to false to cancel the scheduled timer.

#6

I think what he is saying, and I still have’t tried it yet so I am not sure if it will work either, but if the TCP is default, “Cancel task on condition state change” then if the initial trigger occurs before the 10 minutes is up it will trigger and start again.

I would be using a energy event as a trigger and that will occur about every two minutes. Is that a condition state change?

#7

It rather depends. If it was proposed to replace the ‘only on events from’ bit with a simple trigger saying:

if Power Meter 1's energy changes

then, if the energy has actually changed since the last time it triggered, the condition will evaluate true which means the timer will not be cancelled due to a condition change as it was true before.

However that was the TCP. On reflection the new instance of the piston would enter the ‘then’ block and the TSP would come into play instead to replace the existing timer with a new ten minute (or whatever) one.

#8

Not sure this would work either on further reflection, If the energy value changes then it starts the timer. If it changes again, does that change the state of the original condition? It’s still TRUE isn’t it, I guess I just need to try it.

Maybe I should just go back to my smartapp for this particular function. The smartapp basically ran a Runin groovy command timer every time there was a energy event. So each energy event would reset the timer. The app did other things as well, that I moved out of the smartapp because they kept not firing. The app had worked great for over a year then all of a sudden timers would just not go off. It was supposed to write daily, weekly, and monthly energy usage to a thingspeak account.

At first it was only the monthly reset that just stop working. I had a cron timer that should write my monthly usage and reset my HEM at the end of my power company’s billing cycle.

I would check and the timer was active and set to fire on the correct date at midnight, but the next morning it would not have fired and I had to manually get my data. After a few months of this I wrote a backup piston in webcore that would check the HEM a couple of minutes after it was supposed to reset and if it wasn’t it would reset it. The webcore piston worked every time. Then after a month or two my hourly writes just stopped. I had made no changes to the smartappp so I got fed up and decided to just move everything to webcore. I did all this about 3 months ago and it has never missed an event.

Anyway if I could set an on event that would restart every time there was an event like the Runin command it would be the best option.

#9

It doesn’t change the condition so the Task Cancellation Policy wouldn’t apply. However, when it enters the ‘then’ block and encounters the ‘wait’ again, the default Task Scheduling Policy applies and basically starts the time over again. That’s how I think it works anyway.

#10

hemreset3
hemreset3.png1178×954 95.7 KB

Okay so this was much simpler than I thought. All I had to do was put everything inside the ON event loop. I added a 5 minute wait just before the section to toggle the plug. Each time the piston runs it schedules another run in 5 minutes when it gets to the wait. When a new event happens it starts over and reschedules the next run in 5 minutes. It never executes any commands below the wait. So…if the devices locks there will not be another event and it should complete the piston and reset the device.

One last question I changed TCP to never for the last section with the power toggle. If I understand correctly it should always complete that section of code before it restarts? Not sure that would be an issue but I want to make sure it completes all that code before it does anything else if it gets there.