Folks have noticed that webCoRE produces warnings in the IDE, typically based on trigger usage that is questionable or an outright error.
Here is an example from the webCoRE Forum:
Few things to know:
-
webCoRE on HE produces more checks / warnings than ST does. These checks are appropriate to ST also, just the code there does not check.
- so it is possible you see no warnings on ST, and you do on HE
-
while likely an error, it is not always an error depending usage
So What is going on?
When doing comparisons in webCoRE, there are two ways you may be using a device:
-
as a condition - you care about the current value of the device:attribute pair
- in general conditions do not wake the piston except in special circumstances
-
as a trigger - you want the piston to execute because of a change to the value of the device:attribute pair
-
triggers can be further broken down into:
-
tracking - the trigger is comparing the current event value to a previous event value
- examples include: changes*, drops*, rises*, remains*, stays*, range*, becomes*
-
momentary - the event occurred, but does not have any dependency on previous values
-
-
Tracking comparisons require the trigger comparison is crossed on each execution, so that the old value can be tracked for future runs.
-
-
In this example, the trigger comparisons are tracking and are nested beneath statement restrictions (only when) that can cause the trigger comparison to not be evaluated (and therefore not tracked properly for the future) on each execution.
- This can lead to incorrect in the future comparison results as some values will not be kept up to date.
So what to do?
Several options:
-
in this example the restriction could be coded into the if statement (vs. the restriction)
- ie if (trigger and condition) then do something
-
if you are using the device:attribute pair in a tracking trigger comparison elsewhere in the piston (at proper level), you likely can ignore the warning as the tracking is occurring because of this other usage -> ie you don't have to do anything. In effect this is a form of trigger aggregation.
-
you could consider trigger aggregation
- This works because you put the aggregated triggers at level 1 (looking left to right). This ensures the variable tracking occurs. You could then use the trigger again nested, and while you would see a warning for this usage, the aggregated triggers at level 1 ensure proper operation/tracking.
-
likely several other choices
