Did it receive the event? What does the event history show?
My experience is things are slow and an HE update. (cpu/db is busy, zwave network may not be settled).
That said if HE gets an event, it should deliver it (maybe slowly) to the apps that are subscribed.
The logs would help to understand did the device see the event, and did the piston receive the event. It is possible while system is down / restarting that events (from devices) are lost - in this case neither HE (and therefore) apps will process the event that occurred while the system was down or not fully up and running.
So I agree things need to settle after a restart, as the system is quite busy for 3-4 mins typically, immediately after a restart.
Piston did not receive an event. I did not have piston log on but "last executed" time was from yesterday and not from morning. Other piston which fired up minute after worked normally and received event from HE. After couple of hours that one malfunctioning piston worked normally.
At the morning device reported an event but it was never passed to webcore for some reason.
HE has been running normally and it was restarted yesterday when updated.
Is that "log piston executions?" setting something I should enable from HE under WC settings? At least it would be helpful to confirm if piston executes or not.
In webcore console, select the piston, change the "Logging level" setting (scroll down) it could be
"minimal" or "medium" is fine (no need for full).
or
In HE console Apps-> select your piston (will be under webcore parent) -> "Logging Level". again same "minimal" or "medium". And done/next your way out
@nh.schottfam
Bit of a bug in WC I think.
I have been trying to delay execution of a Blink command as it needs 3-4 seconds between commands. I was having no luck until I spotted the trace maxing out at 1000 ms even though I have the piston set to 3000 ms.
Next time you update can you make the execution delay match the piston setting?
+66ms
║╔Execution stage started
+170ms
║║Injected command execution delay 1000ms after [Garage Cam].DisableMotionDetection(); lastPause: null
for everyone to be aware, I showed how this parameter for sleep could be overridden to resolve this issue in his piston execution.
basically the nice / long run monitor was not viewing these short delays as a sleep, so after a period of time they started rate limiting piston execution.
I'm guessing that every update I will have to fix this code line or can you make it permanent?
My Blink cameras work great now that I can pause the mass enable/disables with 4000ms pauses.
HOWEVER, someone there helped me discover that the issue is only with pistons created in the Hubitat version of WebCore. If they're created in a SmartThings version of WebCore and the imported into Hubitat's, they work. I've found the same thing.
Anyone else dealing with this? I believe I'm running the latest version of WebCoRE (0.3.113) and Hubitat (2.2.7.123)
I'm noticing that positions run but it is missing actions at times. Very strange. I will need to more research, but it stated (example. locking the door) but it doesn't actually do it.
Try turning command optimizations off (Edit, click on piston title line, click on gear icon); that will always force the command to be sent even if webCoRE thinks the device is already in the intended state). Useful when the hub's copy of the device's state and the actual state are not the same.
What actions in particular? If it is mostly a door lock, then the door lock could be the problem. I have implemented Webcore to do a refresh, wait 2 seconds, and then lock/unlock as needed.
I find especially with door locks, they don't update very well. Sometimes if the door is manually locked or unlocked, it won't update properly in Hubitat. As an example, if you lock the door and it does not update properly, then Hubitat thinks it is unlocked. If you then try to unlock it, it will not do anything as it thinks the door is already unlocked. Typically a refresh will update the locked / unlocked status, and then issuing the command works (at least for me it does).
Disabling command optimizations should work here as well. This forces the command, even if it is currently in that state. But personally, I would start with a refresh and wait to see if that works
Two days ago noticed that one of my piston was not working anymore. According log it seems that piston is not able to receive location mode changes anymore. I get that null error too and piston log shows just weird xvnmljgffjkk or something when mode changes.
I removed location if's from piston and now use security system status. Anyone else having this issue?
I'm running latest released version on webcore and Hubitat too.
