I refreshed the browser and it still shows “ON”. I checked the device in SharpTools and it also shows “ON”, and I noticed the timestamp was 1/7 at 10:30 PM.
First, I don’t know what would have caused the “ON” trigger at 10:30 PM last Tuesday, but it was followed by an “OFF” at the same time. I’m wondering why it would stay “ON” in SharpTools for 4 days…
I’ve noticed this happening with other devices randomly, but this one caused me to walk through the snow to physically verify the “INTAKE AIR” in the Greenhouse was “OFF”, which it was.
If you want to share the device ID or doc ID, I can take a closer look at what events the device reported with their precise timestamps.
You might also be able to check from the Mu SmartThings Advanced site, but I can’t remember what details they report and I have vaguely remember you have to like cover your mouse curer over the timestamp to see the full precision date or something quirky like that.
Yes, or more specifically the SmartThings platform reported an on and an off event for the exact same timestamp.
If SmartThings sends the events across really fast, it’s possible for the events to come in out of order and get processed out of order. The SharpTools event receiving pipeline has logic that can handle out of order events, but it relies on the timestamps reported by the connected smart home hub.
Normally even if the events came in out of order, the system could still leverage the reported event timestamps to figure out which even was the newest and thus the latest value that should be persisted.
It looks like the device reported both on and off events with the same exact timestamp, so whichever event was processed last would be considered the newest event (timestamp is greater than or equal to the current stored value). In this case, I suspect that the the on event came in after the off event and the SharpTools event receiving pipeline considered it the latest event. Normally even some minor different in time (like hundredths of a millisecond) can be used to disambiguate.
Since no further events were received, that last value was persisted.
Running a fresh device synchronization would cause SharpTools to perform a full device sync and pull over the state as reported by SmartThings.
Thanks for the explanation. So it sounds like I need to rethink at least the rule (or trigger) that turns that device ON and OFF to handle such things. If it was February/March and I was heating the greenhouse, it would not be good to have cold intake air coming in, or the opposite in August if it didn’t come ON instead…
Remember, the tile AND the logs showed the Device ON, but it was physically OFF. Since it was showing ON on SharpTools, I would have thought the rule that turns it OFF below 70* would have triggered it to go OFF. It showed ON for a few days. Something doesn’t seem right.
If it’s a SharpTools rule and it used this device within an IF Condition, keep in mind that the IF Conditions currently reach out to the source smart home hub (SmartThings) to get the current reported state. From what you mentioned, SmartThings was reporting it as off as you expected.
Without knowing why those events were generated or why they both had the exact same timestamp, it’s hard to say for sure.
If you have a rule that is toggling it on then immediately back off, you might consider adding a slight delay in between those actions assuming that works fine with your device and with your goal. eg. on(), wait 2 seconds, off()
Ahhh. That’s it! It would not turn it OFF if SmartThings was showing it OFF.
Nope. The rule turns it ON at >77* and OFF at <70*
The device tile changes color when the state is ON, which is what SharpTools thought it was. And since the temperature UNFORTUNATELY didn’t go over 77, nothing should have happened. I guess the real mystery is why it even triggered at all at 10:30 PM. SmartThings mystery…
EDIT: The rule didn’t trigger, it was SmartThings that for some reason went ON/OFF…
