I have been chasing this for months, used to work for years - ha, same old story.
I even went to the built in WC and no luck.
When I call the Locks piston from Goodbye or GoodNight it sends commands to the devices faithfully but they never operate the command (see front door trace). I think it has worked twice out of 50 times.
Funny thing is I can create a test piston with just the Execute Locks line and it works every time.
@nh.schottfam Guru input?
Lock subroutine
28/03/2024, 14:06:18 +480ms
+4ms ╔Received event [HomeC8].time = 1711659978429 with a delay of 51ms, canQueue: true, calledMyself: false
+31ms ║Runtime (17586 bytes) initialized in 6ms (v0.3.114.20240115_HE)
+41ms ║╔Execution stage started
+178ms ║║Executed device command [Kitchen Door Lock].lock() (54ms)
+183ms ║║Executed virtual command [Kitchen Door Lock].wait [5000] (1ms)
+187ms ║║Requesting wake up at Thu, Mar 28 2024 @ 2:06:23 PM PDT (in 4998ms) for 8 (st:10)
+191ms ║╚Execution stage complete. (151ms)
+258ms ║Setting up scheduled job for Thu, Mar 28 2024 @ 2:06:23 PM PDT (in 4987ms)
+261ms ╚Event processed successfully (257ms)
Goodbye/Goodight pistons e.g.
In the Goodbye piston, just curious why you have a nested trigger on
Line 27 Any of {@GarageDoors}'s door is any of open
can you post (in PM if you like) green snapshots of the pistons?
It would be good to see in the IDE for each one medium logs of when they execute, and if the device handler in question shows it its "Events" the command being sent.
The Trace view in IDE is also interesting as it should show graphically what executed.
The 2nd piston (maybe both seem to be doing automatic condition subscriptions, but I'm not sure that is an issue)
I would also check in webCoRE main that the devices in question are available to webcore, I'm pretty sure they are, but just trying to eliminate things to further check.
There are times I check for conditions and WC tags them as triggers.
I don't think this is a trigger but deep down maybe WC thinks it is?
I will gather more detail but I can say that the events do show up in the Devices events list; they are just not executed unless I "Execute Piston" from a single one line test piston.
Will need @gopher.ny to have a look. Strange that commands are sent to the device but don't execute...
is your zwave mesh healthy? no ghosts?
If you see the device commands in the device Events, that suggests that webCoRE did send them to the device handler in the hub, but that the device handler/hub or device are having challenges communicating with each other.
So what might be going on?
- My first thought is you have a mesh, power, or device problem (which can cause a mesh problem).
There are articles about checking:
-
for ghosts, and how to remove them
-
My reading is C8 can be more sensitive than earlier models in regards to what is powering it. if you use different power supply or cables for your hub (power over ethernet, or different USB block).
-
for beaming devices like locks, do you have repeaters near by?
- locks typically want a beaming repeater nearby
-
it could also be the device or repeater nearby that is having problems
-
I have some older zwave devices, that at times do seem to miss commands, or responses back to the hub.
-
I have seen where the device handler state may say off, the the device is still on. I hit refresh in the device handler and the state matches....I have been removing these older devices as situations come up.
-
sometimes powering off (circuit breaker) clears this up, but I typically have seen others complain about issues with these same models in the forum.
I would check all those to ensure things are ok, and/or try experiements.
1 Like
Z-Wave is very healthy and stable, mostly DIRECT, no ghosts.
It's only this called piston that seems to fail.
I will move it out of those 2 calling pistons and have it called on a mode change trigger as a one line test piston. That always seemed to work when I wes testing.
Just as an extra. All lock devices work from the device list Lock command. They also work from the TileMaster tile on my dashboard which uses a cloud connection for each line.
Went for a walk today with the wife so I left BackDoor and Kitchen Door unlocked.
Test piston ran, sent the lock command to the devices from the piston.
One arrived (Kitchen) and locked, one never showed up (Back) in events therefore no lock.
I hit Lock from the Devices page and it locked immediately.
This is better than usual where they always arrive and nothing happens.
Still stumped.
29/03/2024, 15:31:22 +260ms
+4ms ╔Received event [HomeC8].time = 1711751482223 with a delay of 37ms, canQueue: true, calledMyself: false
+100ms ║Runtime (7109 bytes) initialized in 3ms (v0.3.114.20240115_HE)
+108ms ║╔Execution stage started
+186ms ║║Executed device command [Back Door Lock].lock() (64ms)
+265ms ║╚Execution stage complete. (157ms)
+282ms ╚Event processed successfully (278ms)
29/03/2024, 15:31:17 +77ms
+4ms ╔Received event [HomeC8].time = 1711751477056 with a delay of 21ms, canQueue: true, calledMyself: false
+35ms ║Runtime (7094 bytes) initialized in 2ms (v0.3.114.20240115_HE)
+42ms ║╔Execution stage started
+142ms ║║Executed device command [Kitchen Door Lock].lock() (88ms)
+146ms ║║Executed virtual command [Kitchen Door Lock].wait [5000] (0ms)
+149ms ║║Requesting wake up at Fri, Mar 29 2024 @ 3:31:22 PM PDT (in 4998ms) for 8 (st:10)
+153ms ║╚Execution stage complete. (111ms)
+217ms ║Setting up scheduled job for Fri, Mar 29 2024 @ 3:31:22 PM PDT (in 4987ms)
+218ms ╚Event processed successfully (216ms)
29/03/2024, 15:31:11 +717ms
+4ms ╔Received event [HomeC8].execute = :646ecab6117087e3b05f66e9fbe6adc8: with a delay of 63ms, canQueue: true, calledMyself: false
+148ms ║Runtime (7112 bytes) initialized in 8ms (v0.3.114.20240115_HE)
+151ms ║╔Execution stage started
+334ms ║║Command optimization: Skipped execution of device command [Front Door Lock].lock() because it would make no change to the device. (1ms)
+339ms ║║Executed virtual command [Front Door Lock].wait [5000] (1ms)
+342ms ║║Requesting wake up at Fri, Mar 29 2024 @ 3:31:17 PM PDT (in 4999ms) for 3 (st:5)
+346ms ║╚Execution stage complete. (195ms)
+1031ms ║Setting up scheduled job for Fri, Mar 29 2024 @ 3:31:17 PM PDT (in 4987ms)
+1033ms ╚Event processed successfully (1029ms)
This shows command optimization operating - was that portion correct?
Optomization was on and operated on the Front Door as expected; it was locked already.
Back Door Lock never arrived in Events list.
This all reminds me of the issues I have been having with my Blinds subroutines that you have been looking into. The commands are sent, arrive in the Events list but don't do anything. I find the Open and Close commands work all the time but Set Postion will get ignored until I issue it multiple times.
It feels to me like a device or mesh issue...
You can add command delays in your piston settings to help space things out for zwave as a test.
The above links on power supplies, ghosts, and mesh should be looked into.
The power articles describe if several commands are sent, the power drops if not using proper power supplies or cables.
I have 5-10 second delays when testing, didn't make any difference.
I'm going to move the lock subroutine piston back into the main code and test.
The Execute Blinds are used in many pistons so I'll leave that for now.
The conundrum is everything works From the Device list and as individual commands from within the main piston. Only when I modularize the code with calls do I get these failures.
Stay tuned.
So I think I have this figured out now.
When I execute a piston in Sync mode it does not wait for the piston to finish to continue code execution; It apprears to act Async.
In the logs you can see there is no pause in the timeline at 1442 ms.
When I insert a Wait 15s the Locks subroutine has time to finish before returning and executing the mesh intensive NIghtModeDevices off commands.
So is the Sync not working or are there other settingsw aty play?
02/04/2024, 11:08:12 +934ms
+3ms ╔Received event [Mode Night].switch = off with a delay of 19ms, canQueue: true, calledMyself: false
+38ms ║Runtime (10052 bytes) initialized in 3ms (v0.3.114.20240115_HE)
+39ms ║╔Execution stage started
+70ms ║║Executed device command [Alarm].on() (9ms)
+82ms ║║Executed virtual command setLocationMode (8ms)
+483ms ║║Executed device command [Thermostat].setHeatingSetpoint(15.0) (395ms)
+486ms ║║Command optimization: Skipped execution of device command [Thermostat].fanAuto() because it would make no change to the device. (0ms)
+1442ms ║║Executed virtual command executePiston (829ms)
+1448ms ║║Command optimization: Skipped execution of device command [Dining Room Light].off() because it would make no change to the device. (1ms)
+1451ms ║║Command optimization: Skipped execution of device command [Ensuite Light].off() because it would make no change to the device. (1ms)
Edited out device logs....
+1517ms ║║Command optimization: Skipped execution of device command [Staircase Light Group Activator].off() because it would make no change to the device. (1ms)
+1520ms ║║Command optimization: Skipped execution of device command [Workroom Light].off() because it would make no change to the device. (0ms)
+1533ms ║║Executed device command [Xmas Houses].off() (11ms)
+1549ms ║║Executed device command [Xmas Tree].off() (15ms)
+1555ms ║║Command optimization: Skipped execution of device command [Lily's Room Light].setLevel(10) because it would make no change to the device. (1ms)
+1559ms ║╚Execution stage complete. (1520ms)
+1565ms ╚Event processed successfully (1562ms)
This may mean absolutely nothing, but are you using Task Cancellation Policy on your WAIT statements? I found that I had to do that for some of my WAIT statements, especially those around 3 seconds and greater. A wake-up time is scheduled for those.
I found that some instructions were getting cancelled or not completing until I used "Never cancel tasks" on my WAIT statements.
To see if the execute piston is wait or not, you need to show in the IDE the execute piston statement:
When you set wait, it runs the piston, but if the piston does a wait, that piston will wait and the execute piston will return to the calling piston to continue.
If you really want a delay after calling execute piston, your wait after the execute piston call is appropriate.
What is the appropriate setting for a piston to be executed and NOT return until the end of the called piston? Setting Waits is hit and miss as you can never really guess the execution time a piston might take.
This is what I have:
