Hi everyone, hope someone can point me in a better direction as I’m struggling a bit here:
When creating a new rule, a simple one → when humidity over x% Then turn on the fan
I don’t think this is working “>79%”.
Is it supposed to work? How do you guys work this in the basic rule engine, I really don’t want to make this more complicated than needed…
You can’t. You need to enter the exact state in there.
@florian-h05 wdyt about adding some sort of options for comparison operators, defaulting to equals (or “any”, which hides the state input perhaps?). Looking at it from UI/UX design aspect, would that be helpful, or would it add more confusion/complexity for the “average user”?
That would be amazing!
No more complexity than what we already have in the condition step:
Maybe I’m missing some situation of creating an unending loop, which could have been the reason for not making this an option from the beginning… but this limitation actually prevents me of doing a lot of basic rules which depend on temperature, or humidity values going above (or under) a certain value which would then trigger an item.
Not as simple as what you’re after, but you could potentially use the hysteresis profile to switch a proxy Item at your limits (and then run a rule based on the switch Item state, if required)?
(Assuming the Item is linked to a Thing Channel, of course…)
That’s an interesting suggestion you put forward @hafniumzinc , I’ll definitely check that out! But I still maintain that the rule engine could do with some additional love:D
Edit: huh… I don’t have it… any hints? It’s a switch item…
This is what rule conditions are for.
Add a trigger for any change to the Item.
Then add a condition for the > 75%.
Note that the state is unit aware.
This is why rule conditions exist and were created. I’m not sure I’m for adding this functionality in more than one place.
It costs next to nothing for a rule to trigger all the time on every change in the sensor but only rarely do something when certain conditions are met. With rule conditions you set the circumstances in which you want the rule to run. In this case I expect you’d only want to run the rule when the humidity > 75% and the fan isn’t already ON. So you’d add two Item conditions, one for the > 75% and one for the switch != ON.
And this is a big reason why Conditions exist for this instead of doing it all on the trigger. The condition is often more complicated than a simple > and often involves additional Items or other information too (e.g. does a timer already exist in the cache?).
Only if all the conditions evaluate to true will the rule’s actions be executed. Otherwise the actions are skipped.
So you can do this now with a 100% UI rule (i.e. no code). You just need to use the “but only if…” part of the rule.
More information on Conditions can be found at https://www.openhab.org/docs/concepts/rules.html#conditions.
If you have a really complicated condition (example below) you can use a Script Condition. The last line of the script needs to evaluate to true or false and only if it’s true will the rule’s actions be executed.
var equipment = actions.Semantics.getEquipment(items[alertItem]);
var statusItem = items[equipment.name+'_Status'];
if(equipment === null || statusItem === null) {
console.warn(alertItem + ' does not belong to an equipment or equipment doesn\'t have a Status Item!');
false;
}
else {
var statusItem = items[equipment.name+'_Status'];
console.debug('Sensor status reporting called for ' + alertItem + ', equipment ' + equipment.label + ', is alerting ' + isAlerting + ', and is initial alert ' + isInitialAlert
+ ', current equipment state is ' + statusItem.state);
// Sensor is offline Sensor back online
(isAlerting && statusItem.state != 'OFF') || (!isAlerting && statusItem.state != 'ON');
}
In the above Script Condition (JS) it looks to see if the parent Equipment of the “triggering” Item (this is a rule called by another rule so treatealertItem as if it were event.itemName) exists and if so if that Equipment has a “Status” Item. If either of these are false don’t run the rule. If both exist, check to see if the Status Item is already in the right state and if not return true (if isAlerting and the status is OFF that means the status Item needs to be changed to ON, and vice versa).
But in your case, all you need are a couple of Item conditions, no code required.
As for the hysteresis profile, what version of OH are you running? There have been some fixes over the past bit that fixes this somewhat. MainUI wouldn’t show the profiles that do not match both the channel and the Item type basically hiding all the profiles that change the type like the Hysteresis profile does.
In OH 4.3 M4 it looks like this:
A+ comment, this is a couple days worth of content on me to study 
thank you so much, that really helps, I was thinking about this the wrong way apparently. I’ll rethink my rules with your hints in mind.
About the missing profile, I’m on the same version??
I might have found a bug… I was looking at a switch item, following the documentation i understood that only switch items work for the meantioned profile.
That’s the same version as mine. That’s kind of weird then. Something else is going on that’s making them not show up.
In the screen shot above I’ve linked a MQTT Number Channel to a Switch and that’s the list of profiles that came up. But this was also at Link time. I haven’t gone to another existing link to see if the list is different though. Maybe that’s the difference?
You’re right! I totally forgot!
However, it seems to be missing the ability to check for received command in the “But only if” part.
And to make it clear the “trigger at any change”. I think that right now it says “even if it doesn’t change value” which can be misinterpreted.
How? I have an mqtt switch and when linking an item they are filtered by switches only… I don’t see other items?
Only number channels ( like temperature) can be linked to switch items with profil ‚range‘ or ‚hysteresis‘
Can you show me a picture of what you mean? I’m trying to link a humidity item in a switch channel. I don’t even see any item that isn’t a switch.
Select thing config page
Select the channel you like to add an item to and select Type ‚switch‘
Scroll down to profil settings and select the one you want. Fill upper and lower limits.
That’s what it looks like afterward
Huh… following your instructions it worked… I was probably tired and had my eyes crossed.
Thank you! I’ll be doing some tests with this!
I’ve never tested that. If that’s the case an issue should be filed. You should be able to test for that in a condition without resorting to a Script. Overall the UI rules stuff could use some improvements in lots of areas. That’s just one of them.
I am not sure what you are referring to here. I don’t see “Even if it doesn’t change value” anywhere but am probably looking in the wrong places.
Right, so when you create a rule the first step is the “when” trigger, and this is what you see:
Or:
What I think is missing, from an UX standpoint, because logically you can argue with that, is the “any”. Any change of state.
Not “X” or “from X to Y”, just “any”.
“Any humidity state change” → turn on the fan → but only if → humidity is above 80%.”
This makes sense to me.
It may be that leaving the state “empty” implies all. But I don’t know that yet, and having it written in the rule GUI would help in making it clear because nothing makes me thing that being empty means any state change triggers the rule.
OK, so the first one (an item state changes) is equivalent to Rules DSL “Item X changed”. The second one (and item state is updated) is equivalent to Rules DSL “Item X received update”.
The first only triggers the rule when the Item’s new state is different from it’s old state. The second one triggers the rule even if the Item is updated to the same state.
Indeed you have to select the correct one for under what conditions you want to rule to run. Almost always the change trigger is going to be what you want.
You do not have to pick the state. That part is optional. You usually will not put in anything for Number, Dimmer, DateTime, etc type Items.
Yes, the state fields are optional and leaving them blank means any change or any update.
The UI shows “Required” in the description next to fields that are not optional (see the description of the Item filed in your screenshot which reads “Required the name of the item”).
If it doesn’t say that, the field can be left blank. Note that this is a UI wide convention. Here;s one of my rule templates showing the first three roperties are required but the rest are not:
I think that is what’s supposed to tell you that leaving it empty is allowed, same as it should tell you for Things, Binding Configs, Rule Templates, widgets, etc.
I’m sure this can be improved in the docs (I’m not sure the best place though) but I think we need to be careful on the Rules pages. Since a convention has been established we need to be deliberate in breaking that convention or if we change the convention we need to do it the same way everywhere.
Absolutely, I’m not necessarily advocating for change for the sake of change. Instead a bit of clarity, or an additional example for instance, goes a long way.
Your explanation made total sense and now I get to redo a bunch of my rules xD
