Rule only executes to 1/2 trigger

Setup, Configuration and Use Scripts & Rules
,
1

Hi all!

I’ve tried to simplify an existing rule from the community for my application.
(original: My Central Heating Solution using Thermal Actuators )

My rule:

rule "Heating"
when
	Item TargetTemp1 received update or
	Item TempSensor1 received update
then
    var Number hylow = 0
    var Number hyhigh = 0
		hylow = (TargetTemp1.state as Number) - 0.3
		hyhigh  = (TargetTemp1.state as Number) + 0.3
		if (TempSensor1.state !== NULL) {
				if (TempSensor1.state <= hylow)  {
					if (Living_Room_Heat.state == OFF) { 
						Living_Room_Heat.sendCommand(ON) 
											}
									}
				if (TempSensor1.state >= hyhigh) {
					if (Living_Room_Heat.state == ON) { 
						Living_Room_Heat.sendCommand(OFF) 
											}	
									}
							}
end

The rule seems to work fine when the TargetTemp1 is updated, however, when SensorTemp1 is changed, there is no execution.
I’ve tried to use “changed” instead of “received update” but it is the same result.

TempSensor1 is the temperature item from z-wave Aeotec Multisensor 6, USB powered
OpenHab 3.1, running on habian, PI4.

May I have your help?

Thank you!

2

How can you tell? There are pathways through your rule that would result in no visible action. Use logInfo() to reveal key paths and values within a rule.

The usual cause of trouble when temperature sensors are involved is that you have overlooked the use of Quantity types, i.e. values with units of measurement.

3

Thank you for your input! I was sitting next to the Living_Room_Heat item (=pump), so I see and hear when it changes and starts heating that’s why I didn’t start logging in the first place.
My experience was that when I’ve changed value of TargetTemp1, over or under the value of TempSensor1 the heating started and stopped respectively. However, when the TargetTemp1 was untouched, and only TempSensor1 reported lower values and even went below the value of TargetTemp1, the rule didn’t start the pump.

Nevertheless, I’ve added a line to the rule:

logDebug ("heating", "target: {}, sensor: {}, pump: {}, ", TargetTemp1.state, TempSensor1.state, Living_Room.state

Now I can see the exact states. Is there a way to log the calculation value of hylow and hyhigh as well?
I’ve tried but then the rule didn’t start:

2021-10-27 15:04:13.647 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘heating_mode-1’ failed: The name ‘hylow’ cannot be resolved to an item or type; line 9, column 138, length 5 in heating_mode

4

Remember that we can’t.

Yes. Do it after you have done your calculation.

5

I’m not sure if this makes a difference, but you’ve got too many equals signs. !== should be !=.

Is that IF condition just in case the batteries run out on your temperature sensor? It seems extremely rare that it should ever be NULL.

6

Well, if you don’t persist/restore it (and why would you, for a sensor) it’ll be routinely NULL after every reboot until the sensor “checks in”.

7

I’m just running a default persistence strategy, so it would be more work to exclude sensors than to leave them in. I can appreciate that doing so would reduce a lot of updates, since they change frequently. Would that make much difference to system performance?

Besides “lazy”, the other reason I can think of to persist would be to chart sensor values over time. I don’t personally do that, though.

8

There have been poor performance directly linked to “persist everything”- this is clearly linked to update frequency, in turn a product of the technology providing the updates. In short, beware of e.g. Modbus traffic, but hardly likely to be a problem for zwave.
There’s nothing “bad” about default everything, it’s leaving it in place unthinkingly that causes issues. And that part is easy to do by us all. :wink:

1 Like
9

Thank you very much for all the input!
This evening, I had time again to work on the rule. I’ve reviewed the log files, turns out there were delay in temp. sensor reporting. Connection was unidirectional in z-wave network map. I’ve moved them closer, and now seems good so far. I’m glad it wasn’t the rule.

Cheers!

1 Like