Switch Condition not working - Bug?

[Paul1964]

I’m not sure whether this is ia bug, or I’ve misunderstood how this should work? Below is a short test piston to demonstrate the issue.

When The switch is turned on, the piston executes as expected from top to bottom. The http is called and the piston suspends awaiting the response. It then wakes up when the call returns, but when it gets to the switch turned on condition, it evaluates as false as it thinks the switch has not changed.

This is a short excerpt from a larger piston to demonstrate the issue, I’m aware there are other ways to write this (put http call inside the if statement)

23/01/2023, 21:49:23 +518ms
+3ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 1ms, canQueue: true, calledMyself: false
+8ms ║RunTime initialize > 7 LockT > 0ms > r9T > 1ms > pistonT > 0ms (first state access 3 m:6 3 4)
+10ms ║Runtime (6840 bytes) initialized in 1ms (v0.3.114.20230113_HE)
+26ms ║╔Execution stage started
+32ms ║║Calculating (string)http status= + (string)401 >> (string)http status=401
+34ms ║║http status=401
+36ms ║║Executed virtual command log (1ms)
+39ms ║║Comparison (enum) on changes_to (string) on = false (1ms)
+40ms ║║Condition #5 evaluated false (2ms)
+41ms ║║Condition group #4 evaluated false (condition did not change) (3ms)
+43ms ║╚Execution stage complete. (17ms)
+44ms ╚Event processed successfully (42ms)
23/01/2023, 21:49:23 +346ms
+2ms ╔Received event [Fault NAS-316].switch = on with a delay of 27ms, canQueue: true, calledMyself: false
+27ms ║RunTime initialize > 27 LockT > 0ms > r9T > 22ms > pistonT > 20ms (first state access 2 m:5 2 25)
+29ms ║Runtime (6760 bytes) initialized in 22ms (v0.3.114.20230113_HE)
+30ms ║╔Execution stage started
+38ms ║║Sending asynchttpGet web request to: 192.168.0.51
+40ms ║║Executed virtual command httpRequest (2ms)
+42ms ║║Requesting wake up at Mon, Jan 23 2023 @ 9:49:47 PM GMT (in 23999ms) for 1 (st:2)
+45ms ║╚Execution stage complete. (14ms)
+109ms ║Setting up scheduled job for Mon, Jan 23 2023 @ 9:49:47 PM GMT (in 23991ms)
+110ms ╚Event processed successfully (109ms)

[eibyer]

Does the web call have to be first or the use case will break if moved below the switch event?

[Paul1964]

The use case in the main piston does require the code to be like this, its quite a complex piston that tests a nas & its plex media server are operating correctly.

The sample piston demonstrates the issue. I had a similar issue when I first moved to HE, where a switch changed within a piston & tested by the same piston were not evaluated correctly. i.e if the piston turned a switch on, it would be activated again, but would be evaluates as already on, rather than off from when the piston was originally called. This was a bug, and was fixed.

I suspect this is a similar issue, being caused by the sleep/wake-up from the http call.

This is the post for the similar problem I mentioned

HE vs ST handling of virtual switches

I’ve had a piston to control my garage doors which has worked flawlessly for years. I’ve just moved it to HE, and it no longer works. The logic is rather complex to follow, however I’ve identified a difference with HE. The piston has a virtual switch which can be used to open/close the door. It also gets updated if the door is opened/closed manually. When the door is closed manually, the piston changes the VS to off (it was on). The piston fires again, but on reaching the “if switch change…

[E_Sch]

I’ll have a look at these

At first pass, it seems to rely on that changes to only stores the updated variable on changes to evaluation.

• while there have been some changes here in HE, both ST webCoRE and HE could update this for other accesses.

I’ll keep looking

As to the previous issue, are you saying it is causing you problems again?

[Paul1964]

Thanks for investigating.
The previous issue is fine, I was just referencing at a similar type of bug

[E_Sch]

So I have posted an update to the user install webCoRE on HE

HPM repair is how to get it.

Can you try it out and see if it resolves this issue (I’m not pushing this to everyone until I see the fixes work)

[Paul1964]

I’ve tried that, and it looks as though its now working as I’d expect, see log from the original piston with the new code.
25/01/2023, 18:21:27 +863ms
+3ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 0ms, canQueue: true, calledMyself: false
+11ms ║RunTime initialize > 10 LockT > 0ms > r9T > 2ms > pistonT > 1ms (first state access 4 m:8 4 6)
+13ms ║Runtime (6839 bytes) initialized in 2ms (v0.3.114.20230113_HE)
+49ms ║╔Execution stage started
+58ms ║║Calculating (string)http status= + (string)408 >> (string)http status=408
+61ms ║║http status=408
+65ms ║║Executed virtual command log (4ms)
+69ms ║║Comparison (enum) on changes_to (string) on = true (0ms)
+72ms ║║Condition #5 evaluated true (5ms)
+73ms ║║Condition group #4 evaluated true (condition changed) (7ms)
+78ms ║║Switch turned on
+80ms ║║Executed virtual command log (3ms)
+84ms ║╚Execution stage complete. (34ms)
+89ms ╚Event processed successfully (85ms)
25/01/2023, 18:21:15 +535ms
+3ms ╔Received event [testSwitch].switch = on with a delay of 27ms, canQueue: true, calledMyself: false
+10ms ║RunTime initialize > 9 LockT > 1ms > r9T > 2ms > pistonT > 1ms (first state access 3 m:6 4 5)
+13ms ║Runtime (6760 bytes) initialized in 2ms (v0.3.114.20230113_HE)
+15ms ║╔Execution stage started
+24ms ║║Sending asynchttpGet web request to: 192.168.0.51
+27ms ║║Executed virtual command httpRequest (3ms)
+32ms ║║Requesting wake up at Wed, Jan 25 2023 @ 6:21:39 PM GMT (in 23998ms) for 1 (st:2)
+37ms ║╚Execution stage complete. (22ms)
+100ms ║Setting up scheduled job for Wed, Jan 25 2023 @ 6:21:39 PM GMT (in 23984ms)
+102ms ╚Event processed successfully (100ms)

Many Thanks for fixing and making webcore such an awesome product.