Unable to save RM rule if Boolean is true

I've decided to start playing with Booleans and have written a simple rule to start to get an understanding of how things work.
Here is the rule.


The issue is this.
If I set the temp to be < than 22, the rule is false and when I click 'Done' the rule saves OK. The rule Boolean is set to false.
If I change the temp to be > than 22, the rule is true and when I click 'Done' the rule does not save and finally times out to a 404 message.
Am I doing something wrong or is there an issue here.

I'm probably not the best person to help here, but shouldn't the "Define Rule" section have some logic conditions like AND and OR etc?

Hi @JohnRob I only have one condition defined so there won't be any AND or OR.
Thanks for the response though.
Like I've said, it's only a simple one for me to start playing and get my head around thenminstead of using Virtual Switches which is how I've been doing things in the past.
I gradually increase the complexity of my rules so I know where things go wrong in my rules as I develop them.

There is definitely an issue. Looking into it. I believe it has to do with changing the condition when there is not an explicitly defined rule. RM implicitly defines the rule when there is a single condition. I suspect that something is going off the rails when you changed the condition from > to <.

For now, the obvious work around is not to change the condition, but to remove the rule and create a new one.

Interesting to note: If you have multiple conditions, and by inference a rule defined with AND or OR, when you change one the rule becomes 'broken', and the text display no longer reflects what is happening. The text display would be for the rule before the change was made to the condition. If you open the rule at that point, you'd see that no condition is selected for the part of the rule where you changed the condition. You can select the changed condition, and hit Done, and all will be ok including the text display of the rule. This is not really an ideal situation, and one that should be addressed (such as by blanking out the rule text when a condition changes so it becomes obvious that the rule needs to be dealt with). I suspect the bad behavior you are seeing is related to this issue.

Thanks for the reply. Like I said above I was just playing really and this is not a representative rule anyway.
As long as you are aware and feel the need to fix, go for it.
Keep up the good work BTW, this set up is working much better for me than other systems I could mention. :wink:

There is an indirect infinite loop happening. Will be fixed in the next release. Stay away from setting your PB for This Rule.

1 Like

If you don't mind my asking, I don't understand a single condition with a name:

"Temperature of Lounge-Fish Tank Temperature Sensor. Fibaro., Lounge-Fish Tank Xiamoi Temperature Sensor any > 22.0"

Is it a group? If so how does one make a group with conditions?


These are both temperature sensors. So Bob selected the Temperature Capability for the condition and then chose two available sensors at once, finally specifying a comparison between them of > 22


And he chose the "any" option (the default) and not the "all of these" option. Had he selected "all of these" then the condition would only be true if both sensors were > 22.0. As he wrote it, the condition would be true if either sensor was > 22.0.

1 Like

Yes. Thanks Bruce. The "Relative to another device" is a very cool feature too.

I used to show those things in brackets, like this:

[Temperature of Lounge-Fish Tank Temperature Sensor. Fibaro., Lounge-Fish Tank Xiamoi Temperature Sensor] any > 22.0

Would that be easier to understand? Easy to revert back to that style, as it actually takes effort to remove the brackets.

Actually I got the "any > 22.0" However personally I think the brackets make it clearer. I can only imagine there are situations were the brackets help. I can think of none where the hurt (mislead)

BTW Thank you for the explanation. I find the HE capability almost an embarrassment of riches. I read most posts more to learn than anything else.


Hi @JohnRob.
All of the above. :smile:
I haven't used the 'compared to' option. Just any above 22. ( >22).
Hi @bravenel. Personally I prefer brackets as it gives a bit of definition between the devices and what we are looking for from the devices.

I like the brackets too...

OK, with a huge sample of opinion, brackets are coming back...

I think it's because it's less effort for you. :joy:

Hmmm, ya, it entails removing 14 characters of code from RM. Less is more. Next release.

1 Like

Brackets are back in RM: Hub Update 1.1.6

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.