Can someone help me with this logic? I haven't been able to format it quite. A simple piston that checks if I arrived RECENTLY AND when I open my garage door AND when it's between a certain time. The idea is that I want to turn on the lights if I arrive home in the evening. But in order to do so, I have to check if I am PRESENT but was recently NOT PRESENT.
if User's presence was not present for less than 4 minutes
and
Garage Entry's Doors contact changes to open
and
User's presence is present
It's the top line that I am having trouble with... I want to know if I was recently NOT present. Changing "less than" to "at least" also does not seem to work. I'm not sure of the logic webcore uses.
Does anybody have any issues with the WebCore time functions? For example:
time("11:00:00 PM")
That should return today's date at 11PM in the local time zone. On SmartThings, it did; but on Hubitat, it seems to return 11PM GMT, ignoring the fact that my local time zone is 4 hours behind, and it gives me 7PM in my local time zone.
Edit: It might be a different issue, because
time("10:00:00 PM")
also returns 7PM.
Edit2: I think I figured it out -- the time() function doesn't accept seconds:
time("11:00 PM")
time("11:10 PM")
time("23:00")
all return the correct values.
This is a difference from the SmartThings version, which accepted seconds; and the datetime() function in HE WebCore, which also accepts seconds.
Hi all. I hope this is the correct thread to post general Webcore on Hubitat questions. If it isn't, please point me to the right thread.
I'm a longtime Webcore on ST user who just switched over to HE. I am having an issue with some pistons not sending notifications, but other pistons do. The pistons that do work seems to work nearly every time; the ones that do not work never work.
I have attached an example of one piston that does not send notifications, and two that do. Can you see anything wrong in the piston, or suggest any other fixes please?
Logs attached. I have tried both a trigger and a condition as you can see in the logs. It seems that the trigger/condition does fire the piston, but then the piston reevaluates the trigger/piston in its execution stage. The triggering device is a virtual switch with auto-off set to 500ms so by the time the execution stage runs the switch has turned itself off.
What I don't understand is why the execution stage reevaluates the switch state?
9/30/2020, 9:49:18 AM +279ms
+1ms ╔Received event [VSW: Cooling off].switch = off with a delay of 1191ms, canQueue: false, calledMyself: true
+5ms ║RunTime initialize > 3 LockT > 0ms > rtDT > 1ms > pistonT > 0ms (first state access 2 2 1)
+7ms ║Runtime (5788 bytes) successfully initialized in 1ms (v0.3.110.20200916_HE)
+8ms ║╔Execution stage started
+15ms ║║Comparison (enum) off changes_away_from (string) off = false (0ms)
+17ms ║║Cancelling condition #2's schedules...
+19ms ║║Condition #2 evaluated false (6ms)
+20ms ║║Cancelling condition #1's schedules...
+22ms ║║Condition group #1 evaluated false (state changed) (11ms)
+26ms ║╚Execution stage complete. (19ms)
+60ms ╚Event processed successfully (59ms)
9/30/2020, 9:49:16 AM +599ms
+4ms ╔Received event [VSW: Cooling off].switch = on with a delay of 45ms, canQueue: true, calledMyself: false
+19ms ║RunTime initialize > 18 LockT > 2ms > rtDT > 2ms > pistonT > 1ms (first state access 14 6 12)
+22ms ║Runtime (5790 bytes) successfully initialized in 2ms (v0.3.110.20200916_HE)
+23ms ║╔Execution stage started
+39ms ║║Comparison (enum) on changes_away_from (string) off = true (1ms)
+41ms ║║Cancelling condition #2's schedules...
+44ms ║║Condition #2 evaluated true (9ms)
+46ms ║║Cancelling condition #1's schedules...
+48ms ║║Condition group #1 evaluated true (state changed) (13ms)
+49ms ║║Cancelling statement #3's schedules...
+743ms ║║Executed physical command [Downstairs thermostat].off() (688ms)
+744ms ║║Executed [Downstairs thermostat].off (690ms)
+1421ms ║║Executed physical command [Upstairs thermostat].off() (674ms)
+1423ms ║║Executed [Upstairs thermostat].off (677ms)
+1425ms ║║executeTask: Execution time exceeded by 124ms, Waiting for 150ms; lastPause: null
+1583ms ║║Executed virtual command [Downstairs thermostat, Upstairs thermostat].wait (2ms)
+1586ms ║║Requesting a wake up for Wed, Sep 30 2020 @ 9:49:28 AM EDT (in 10s)
+1602ms ║╚Execution stage complete. (1578ms)
+1629ms ║Setting up scheduled job for Wed, Sep 30 2020 @ 9:49:28 AM EDT (in 10s)
+1631ms ╚Event processed successfully (1629ms)
9/30/2020, 9:49:17 AM +134ms
+3ms ╔Received event [VSW: Cooling off].switch = off with a delay of 46ms, canQueue: true, calledMyself: false
+6ms ╚Event queued (5ms)
9/30/2020, 9:49:02 AM +845ms
+5ms ╔Received event [187 Montgomery Avenue Hubitat].test = 1601473742845 with a delay of 0ms, canQueue: true, calledMyself: false
+33ms ║RunTime initialize > 32 LockT > 1ms > rtDT > 19ms > pistonT > 18ms (first state access 12 7 25)
+37ms ║Runtime (5884 bytes) successfully initialized in 19ms (v0.3.110.20200916_HE)
+38ms ║╔Execution stage started
+45ms ║║Condition #2 evaluated false (4ms)
+46ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+50ms ║╚Execution stage complete. (12ms)
+54ms ╚Event processed successfully (52ms)
9/30/2020, 9:48:51 AM +498ms
+22ms ╔Subscribing to devices...
+26ms ║Using Attribute subscription
+189ms ║Device missing from piston. Loading all from parent (158ms)
+199ms ║Subscribing to VSW: Cooling off.switch...
+213ms ║Piston controls Downstairs thermostat...
The piston is subscribed to the switch event, so on/off will trigger the piston. The switch gets turned on, the piston does its thing, the auto-off kicks in, the piston sees the event so it cancels the timer.
Maybe set your auto-off longer than your wait or set TCP to never. Did your virtual switch in ST have an auto-off?
I'm see an issue with particular function.
I'm try to prevent (flapping) retrigger.
I'm using the if something hasn't changed in the x (time); If true (run). If not (don't run)
This doesn't seem to be working for me. I have used this on ST and this has worked but I don't see working here.
Maybe I'm doing something wrong. Note I know I have restriction 3 places testing and it falls in all three attempts.