2020-09-30 9:05:07 AM EDT
time is correct under hub status
2020-09-30 9:05:07 AM EDT
time is correct under hub status
Wow I feel dumb, the alert that is 1 hour late is coming from RM not WebCore.. built a piston just to report time before I realized that
I gave RM a shot but I will be using WC going forward.
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?
Yes I had just realized the same. Changing the TCP to 'never' did the trick. Thanks!
To answer your question, I was using a virtual momentary button in ST so never had the issue.
Yeah, the auto-off on the virtual switch tripped me up the first time I used one also. Didn't notice the setting lower in the Preferences.
Thanks for the fast response, much appreciated.
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.
Can you post the full logs of this running (here or Private message)? If you have the full logs from ST, that can help for comparison.
I will get them but, I don't think I have the rules from ST anymore since I brought everything over. I will get for this rule.
You say it worked in ST but the logic seems flawed to me. The first line says only execute when the presence hasn't changed for 2 minutes but the triggers are presence changing.
One thing I like about RM is it's a bit more clear as to what your triggers are. Something happens you do something. I have never used the only when in webcore so maybe what you are doing is ok. I would use a time function to keep track of when the presence changed and then base off of that. That just seems more clear to me, but your way is probably okay as well It just doesn't make sense to me.
You would probably get more definitive answers over at the webcore forum. There are serval people over there that monitor and they are pretty good at diagnosing problems with your pistons.
$weather and webcore.
Im new to this and it appears things have changes somewhat ..
you cannot sign up for darksky
and apiXU.com send me to weatherstack.com
I did get a key on weatherstack.com and I did put in the webcore settings under apiXU type
Is that correct ?
I'm not sure how what I put for current temperature....
i tried $weather.current.temperature but that didnt seem to work....
The $twcweather i used on smartthings seemed to tell me what to put but maybe i'm just confused...
can anyone straighten me out ?
I think OpenWeather is your best current choice.
see:
Thanks for that very clear explanation....
I was able to signup for openweather.... it took a while to find the key but i think i got it... its like 60 char long.
I updated webcore with the key and updated lat and long
it seems like i can get weather info ON the website (see below)
but when I click to show structure under the storage ...i get
any suggestions ?
Anything in the HE logs?
you did 'done' your way out of webcore you made settings changes?
Turn on webcore logging to see if there are errors. Ensure settings were inputted correctly.
thanks for the help
I reinput my key and i can see data in web page but I DO get the following error (and for sure I did all the dones in webcore : )
i see
ok, im an idiot.... the web is very deceiving,,,i searched for openweathermap ...and signed up only to find out that i signed up for rapidAPI and not openweather.....
I just signed up for openweather..and will try that ...they say it takes a while
I fell into exactly the same trap.
Took me ages to work out what was going wrong.
Forgot all about it.
Very deceiving how they lead you down that path.
Everything works... able to use temp in webcore...thanks all !!!
and I'm not happy that someone else fell into the same trap....but it reaffirms how they are very deceiving!