openHAB 3 notification rules/scripts

Setup, Configuration and Use Scripts & Rules
, ,
1

Hello,

I am a bit lost here trying to migrate my text based rules (in /etc/openhab/rules) into the GUI of openHAB 3.

What I use a lot are notifications through Telegram and XMPP.

Here are examples of the rules code I use until now:

XMPP:

val xmppAction = getActions("xmppclient","xmppclient:xmppBridge:xxx")
xmppAction.publishXMPP("user@xmppdomain.tld", new DateTimeType().format("%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS") + ": Test Message through XMPP")

Telegram:

val telegramAction = getActions("telegram","telegram:telegramBot:xxx")
telegramAction.sendTelegram(new DateTimeType().format("%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS") + ": Test Message through Telegram")

The ideal idea would be to create a helper script for each notification type which I can call with parameters (which e.g. contain the specific/different message for each notification). Is this possible, yet?

As I said, I lost track a bit. For sure I googled and looked here in the forum but did not find much which helps me. Maybe also because I am not very talented with programming. :wink:

Maybe someone can point me to the information I am looking for.

Thanks and cheers,
Roi

2

The first question is what is driving you to do this? There is no reason you need to abandon your .rules files unless there is some compelling reason. So make sure you are going though this extra work for some reason beyond “because I can.” It might be as simple as you want to be able to manage your Rules through MainUI.

This is not and probably never will be possible using Rules DSL. This is possible using JavaScript or Python. To see how to do it in JavaScript see OH 3 Examples: Writing and using JavaScript Libraries in MainUI created Rules.

3

The reason why I am working on this is because since upgrading to openHAB 3 it is “forgetting” my rules, sometimes, but it occurs several times per week. Sometimes (but very rare) it also forgot items. From what I was observing it only affects rules (and items) placed in the text files.

After restarting openHAB everything is fine again. And also when opening the text file(s), changing something and saving it. I can read in openlog.log that xxx.rules was loaded and the rules work again.

As I have many rules I can only guess how ofter this occurs as I do not notice a missing rule at once. Like alarm rules or stuff like this. What I can notice is if rollershutters to not open or close, the light does not go on in the cellar if there was motion detected. And so on.

With putting rules (and items) in the GUI I did not have any problems with these rules (and items) anymore.

That’s the reason.

4

Thank you! I will take a look and hopefully understand it and use it for my goals.

5

Have you filed an issue or opened a discussion about that? It shouldn’t happen and is a bug.

6

No, I did not, yet. The problem is that the error is there but I do not see anything else, e.g. in logs. Also no idea how to prove it, log it and so on.

7

Sometimes just knowing that the behavior occurs is enough to start an investigation. No one can guaranteed that it does get fixed. But it will never get fixed if you keep it to yourself.

8

OH3 is pickier about filenames. While in OH2 you got away with filenames like lights.outdoor.rules and lights.indoor.rules, in OH3 they will clash and editing one will mess up rules from the other.

Some people also seem to suffer from conflict problems with lights.rules and lights.items. That might be fixed now.

9

You are right. I will open up a bug report about this.

Thank you for this information. What does this mean exactly? My files are names like this:

shelly.items
shelly.rules
shelly.things

tasmota.items
tasmota.rules
tasmota.things

xiaomi.items
xiaomi.rules

My rule files can contain a lot of rules. Only some of the rule files have one or only a few rules.

10

Problematic in current openHAB stable release -

11

Oh wow. So I need to wait for a fix or rename the files? What about:

items-xiaomi.items
rules-xiaomi.rules

Or is this also too extreme for the picky OH3? I would like to identify my files without any hassle.

12

That would be fine. Every file ends up with a unique name, circumventing the bug.

13

Okay thank you. I will do that and restart OH3.

Btw, in my eyes a severe bug. Is it possible to push out a new stable version. It cannot stay that way. I mean, how would “normal” people “normally” name their files here? :wink:

14

It’s not a severe bug at all. It’s a nasty gotcha for a few users, but circumvention is trivial.

So far as you and I can see, a fix has been developed and is already available in the development “milestone” versions, part of the normal development cycle.
If it’s that important to you, use the milestone release, accepting that you may be exposed to other changes.
Or if it’s not important, wait.

15

You are right that it is not severe and also easy to circumvent. But the outcome is not too trivial and I would call it severe (if e.g. alarm rules do not work anymore and the user does not notice it). Also it is not that easy to get to it. See my case. It was only a coincidence. Personally I heard from two other people who have the same issue. Or might. Because sometimes after upgrading to OH3 some stuff was temporarily not working anymore. Looking back I think they have/had the same issue so I pointed them to this thread.

I am very happy that there are people like you and also @rlkoshak here to help users like me and also fixing stuff like this bug. :slight_smile:

For now, I renamed my files and to be extra sure restarted OH3 after that.

About my question in the start post of this thread I will take it slowly and only touch rules and switch them to the GUI if I need to. Like when creating new rules or changing a lot of things for existing rules.

Thank you all again! :slight_smile:

16

Seems a very logical thing to do… and I named my files like this too.

Whether this can be circumvented or not, it is a bug IMHO.
Imagine the outrage if opening a Word .doc would open a .pdf.

I am sure the reason for .rules. items was to clearly distinguish between them.

:slight_smile:

17

Here is the issue, the bug, that was opened, dealt with, fixed, and closed with the fix incorporated in development versions.

What else did you want to happen?