The last piece was industrial equipment. This one is a greenhouse.
Same structure, different demand from the floor. What happens most often here is that the equipment changes.
What this floor is like
Greenhouse sensors and valves are close to consumables. They do not survive many seasons of humidity and temperature swing, and by the time one needs replacing the same model is already discontinued. Another company's part goes in.
What happened then? The control code was edited. The new sensor has a different range, a different unit, a different response shape. Something in the code knows those, so that something is edited.
Not work a grower can do. So the equipment company is called, and until then that line runs by hand.

What removes that work
This magazine has the sample. A greenhouse node declares itself in six fields — identifier, role, kind, model, unit, value.
The key is that rules speak in kinds, not model numbers. Not "when this model's value exceeds 30" but "when a node of kind temperature exceeds 30".
Swap the sensor and the rule stands. As long as the new node declares itself as kind temperature, the rule already knows it. If unit conversion is needed, that is in the declaration too.
The sample's verification checks this by swapping the installed list for an entirely different set and running the same server twice. Only the arguments change. Not one line of control code changes, and both installations fall into the rules.
This content requires Developer or above
Sign in and upgrade your plan to continue reading.
View Plans