I use a smart bulb to indicate the status of my front gate, which is not in view of our house. I have a Remootio add-on that allows me to query the status of the gate.
Knowing the status of our gate accurately in real-time is very important because we have dogs in the yard, and we need to know if the gate is open or closed.
To this end, I created created a virtual switch in SmartThings and three rules in Sharptools, as follows:
Switch - the switch is called Gate Trigger Switch #1
Rule 1 - if Gate Trigger Switch #1 changes state, set the bulb to the preferred color an brightness.
Rule 2 - if Gate Trigger Switch #1 has been off for longer than a minute, turn it on.
Rule 3 - if Gate Trigger Switch #1 has been on for longer than a minute, turn it off.
The above setup works exactly as expected - but only for 5-6 hours, then it stops working completely. None of the rules show anything in their logs after a certain point, no errors or other odd things in the logs, just the last successful iteration of all the rules, then…nothing.
Note that I also have a trigger set for if the gate changes state to open or closed, which sets the light correctly without issue and doesn’t fail. The reason for the above rules is to handle cases when the indicator light has been manually set by someone in the house, or by an inadvertent command, or the gate open/closed during a connectivity blip, or something else. Meaning, even though the gate open/close event correctly triggers and sets the light, I need to ensure the light is always correct, even if the smart bulb parameters are accidentally changed outside of these rules or the initial gate open/closed is somehow missed when it happens.
Does Sharptools put some kind of limit on repetitive rule firings? Is there any way for me to figure out what the reason is that my three rules completely stop firing after X hours?
Can you share more details about the rules? Maybe a rule screenshot showing the actual rule that is failing along with a screenshot of the logs from a period overlapping where the rule was running fine and then stopped?
You mentioned that the rules were repeating but I don’t see that in the example rule descriptions – they read like they are event driven.
You also mentioned that you have a ‘Remootio’ add-on that lets you query the status of the gate. Does it have a native event-driven integration with your smart home platform? … or are you somehow polling for status, eg. in a loop within a rule?
Of course if the switch isn’t updating its status, then none of the other rules would work, so you would want to start by verifying that first.
Yes, but you would see an error in the Rule Logs if you hit any rate limits. It’s 200 executions in 10 minutes as of this reply, but could change in the future.
The first two images show the rules that turn the virtual switch on and off on a 45 second interval.
The second two images show the final log entries of both rules when they stopped working this morning around 6:51am (I took the screenshot at 3:46pm and those were the latest log entries)
I think these rules that flip the switch stopping working are they key to my issue. If there is a better or more reliable way to run a rule every X seconds please let me know, but flipping a virtual switch after it had been in one state every X seconds and then flipping it back after another X seconds seems to be the one I see referenced most often.
With regards to the Remootio add-on, yes, it integrates with SmartThings and I can query the status (open/closed) in my rule that sets the indicator light.
I have created a boolean variable called $OneMinuteLoop.
I have one rule trigger that says if $OneMinuteLoop stays True for 30 seconds then trigger the rule. Note that this trigger does not seem to ever work, but I’m leaving it in just in case.
I have a second trigger that says if $OneMinuteLoop changes to True then trigger the rule. This one appears to work reliably, however the rule will never, ever start unless I manually change $OneMinuteLoop manually. I’d love to figure out or learn a way to have this rule fire automatically without the need for initial manual triggering. This was the point of me including the first rule (variable stays true for 30 seconds) but it never, ever fired the rule until I manually changed the variable.
The rest of the rule changes $OneMinuteLoop to false, flips a switch called ‘Gate trigger switch #1’ on (this triggers a separate rule that updates my status light) , waits for 30 seconds, flips it off (this also triggers the separate rule), waits for 30 seconds, then sets $OneMinuteLoop back to True, which then triggers this rule again, ad infinitum (I hope).
From your original rule logs, it looks like the last action was the on() command at 6:51:51 but then the turn off rule (which is triggered by the on event) never received the on event. I would check the SmartThings logs to make sure that the device actually turned on and emitted the on event.
It looks like your community level already increased, so you should be able to post more images now. If not, PM @support and I can manually increase your level.
I’m glad to hear that the new rule is working for you. That’s odd that the $OneMinuteLoop stays True for 30 seconds trigger wasn’t working reliably for you. If you want to revisit that by setting up another rule and sharing the relevant logs, I’m happy to take a closer look at it.
While we don’t officially support rule looping at the moment, there are a few best practices you should consider:
For example, I noticed you have device logic in your rule loop. If the device command fails to send for whatever reason, that risks the loop stopping altogether.
–
Can you share more details about why this rule needs to loop? I thought I read that it was related to knowing the status of the gate, but I don’t understand why the gate switch has to turn on and back off periodically?
The ‘gate switch’ that I’m flipping is just a conveniently named virtual switch that I use as a loop trigger, it is not related to the actual gate mechanism itself.
I want the rule to loop because it is important to me to positively check the status of the gate every 30 seconds and update indicator lights via a different rule. That different rule is triggered by the ‘gate switch’ changing state.
I’ve used the “stays $True for 30 seconds” trigger in multiple rules, some were just simple rules I was using to test if it worked. It has never worked for me, not even once. I don’t know why, the logs are blank. Could it be related to the act that I’m using a virtual switch as the trigger instead of an actual device? I’ll set up another test rule and virtual switch and share the logs in the near future.
Regarding me being able to post multiple images, I actually got the notification email of that restriction being lifted while I was composing my previous reply, but I wasn’t watching my email!
For reference, Gate Check Heartbeat switch is currently off.
As you can see, it appears the switch and rules are created and work correctly and then just…stop. I can see no messages in the logs or elsewhere.
The rules stopped firing at around 2:40am, and at 4:20pm I flipped the Gate Check Heartbeat switch on manually and the rules began running again, but for who knows how long.
As you can see, the rules in this case have no device changes or pauses, other than turning the switch on and off.
Should this not just keep working? Is there a better/different/reliable way to get rules to run on a 30 second schedule?
I’m also confused on the 30 second flip. I guess I don’t see what that actually does. Wouldn’t it be better to just use something like a contact sensor to monitor the gate? If closed light Green, If open light Red. If open longer than 30 seconds send message to…
Here’s a long distance sensor if your gate is far.
The sensor is part of my Remootio gate control, is integrated, and is required to be used before integrating with home automation (Google, Smart things, etc).
Having something poll on a schedule is the primary way to ensure that the telemetry data is fresh and/or to detect that the data stream is unavailable.
Even without the distance issue, there can always be hiccups, hub reboots, connectivity drops, etc that can miss a device change event, and having the “stays in one state” trigger should work reliably, and for me it does not. It works initially then stops working until a manual intervention is done.
I see many, many, many other people asking this same question on the SharpTools forums and the primary advice I see is either flipping a switch if it stays on or off for a certain period, or flipping a boolean variable if it stays true or false for a certain period.
For me, both of those methods work on initial setup, then stop working randomly (it seems) until the switch or variable are manually updated.
To me, this seems like basic functionality that is missing from a tool that is supposed to assist in automation.
Well, this can happen with any device. Doesn’t have to be SharpTools, could be WebCore, or SmartThings. Occasionally I’ll have a device miss a closed and I’ll get a message that a door is open when it is not. If you absolutely need 100% it sounds like you need to hard wire a contact sensor to a light. By way of example, I have an automated door on a chicken coop. I have 2 micro switches and use a 12 volt battery (Works even if power is out). Door open, light is green. Door closed, light is red. Look out the window to see which led light is on.
As an alternative, and it is a lot of work, but would be as close to hard wire as you will get, … would be to to create a trigger using time. Everyday at 12:00 AM at location Home, then every 1 minute thereafter. That’s 1,440 triggers!!!
I’m not thinking I would have a need for this level of wireless bullet-proof, but will watch for your solution!
