Rises Above acting up? WebCore

⚙️ Custom Apps and Drivers webCore
1

I use Rises Above in a piston to determine when my TV is on. It works perfectly setting flag above a power draw and clearing the flag when it dorp below a limit (off).
I tired using it in the same manner for my humidity check and it only triggers when it rises above the setpoint but on the next event, even though still above, fails the test.

61 > 55 false
|+42ms|║║Comparison remains_above = false (event device/attr eXcluded)|
|+45ms|║║Condition #2 evaluated false (7ms)|
|+54ms|║║Comparison (integer) 61 remains_above (integer) 55 = false (1ms)|

I have this from @nh.schottfam and it saems like my working piston for my TV follows this.

"remains above (and rises) are using the device readings (when they occur) as the time portion ie the reported event times
so remains_above is (this device reading and the last device reading are > compval) (where there is a subscription on the device:attribute being checked)
return oldValue!=null && oldValue>compval && curval>compval
where:
oldValue is the last reading of of the device
curval is the current reading of the device
compval is your comparison value for remains above."

image
image1215×850 40.3 KB

2

So both of these are trigger comparisons, so they will only possibly be checked if that is the cause for the piston running (ie not a test).

  • rises above requires this event reading to be the transition from below the requested to above (ie a transition)

  • remains above requires this to be the 2nd (or further) reading which is still above.

the statement in your logs:

Comparison remains_above = false (event device/attr eXcluded)|

suggests that the first comparison, the event that ran the piston was not the trigger for this run.
It does appear the event was the trigger for the 2nd part of the OR

This suggests the event was the first transition of <=55 -> 61, where rises above would have been true, but remains above would be false.

It would be good to see a couple of executions (ie some history) to better understand what transitions are happening....

The other option is that webCoRE did not have history of a previous execution due to that trigger firing. This could be because you just changed the piston and the webCoRE cache is cleared, I'm not sure this is the case however.

I will look if I can further improve webCoRE logging to make things clearer on what it is seeing.

There is a condition comparison

device:attribute was less than value, which will as a condition tell you now if the value is less (and does not depend on the value changing being the trigger for the piston).

If you want the piston to wakeup on events for the device:attribute, you would need to do always subscribe or other tricks mentioned:

3

Thanks for the info as to the operation.
Mostly what I thought.
I did go to the sensors and actually "prime" them for a first event and I knw it needed history to compare to.
The event you see is after it was coming down from 80%.
Not a big deal just didn't work as expected like my other pistons.
I reworked this one to just check for change events and test with regular conditions; not as fancy. :slight_smile:

4

I pushed an updated webcore piston file that has improved logging if debug/full logging is on.

If you have user install, your can update the piston file and run you piston again. It should give us logs on what it is seeing.

5

Thanks.
Sadly I went to the HE stable release last month trying to rule out some oddities.
I do like the user install as I can test any fixes you do ahead but now I'm stuck waiting for an HE push.
I have never used hub vars but I assume it's possible to run a user install and pass a global var via this method to the internal WC instance piston?

6

yes Hubitat globals @@ in webcore can be shared across applications.