Migrating my rules to Jython

Setup, Configuration and Use Scripts & Rules
,
21

What you might be looking for is…

if event.oldItemState != NULL:
22

Thanks really! I saw it earlier…
But that will use which persistance service?

23

Persistence is not being used here… the event provides the previous state to the rule engine. What is available depends on the event type. I’ve documented these here as event object attributes…

https://openhab-scripters.github.io/openhab-helper-libraries/Guides/Event%20Object%20Attributes.html

24

Thanks that makes sense, and when I started to use these in Rules DSL I also thought that no persistance is needed here, but DSL worked differently…

25

The implicit variables available in the DSL are the same type of thing… no persistence needed for them either.

So, how is the migration going?

26

Thanks!

It is fairly easy. I had experience with Python before so it is not that hard for me…
However there are still some “building blocks” where I don’t really know what is the best way to do…

For example switch cases, which I had a bunch of them in the DSL.

27

Your best bet it if/elif/else statements. Python doesn’t really have switch statements. And the way switch statements work in Rules DSL is so similar to if/elif/else that it should be pretty straight forward.

28

This is what I did. Just calling a function with the needed parameters, so it is not so redundant.

29

And one theoretical question for that you might know the answer.
When the Rules DSL will become obsolete/deprecated? The next development iteration will move to 3.0 and lot will change there. Does 3.0 will mean the end of DSL also?

30

The rules DSL has been obsolete for a long while. It will likely be completely removed in OH 3.0. The rules files will still be usable in some form… probably through a migration tool.

I offer migration services for beer donations :beer:! This would be great for…

2 Likes
31

I would not state it that way. The rule DSL is still the main official way of writing rules - nothing is obsolete about it.
Yes, the plan is to have the new rule engine in place for 3.0 and with it Jython rules as a standard means. But I doubt that we can drop rule DSL support as there are a lot of rules out there, which should continue to be working, otherwise we won’t have much acceptance of 3.0. If anybody comes up with a 1:1 migration script from DSL to Jython, this would be neat, though.

2 Likes
32

Thank you for your answer!

Just one another small question I just discovered:

items["ChromecastAppName"] != "Backdrop"

These conditions doesn’t seem to work, even if the provided Item is a String type Item in openHAB. So I really need to convert all of them to string (str) to make this work or is there any other way?

33

The documented way in the Helper docs is

if items["ChromecastAppName"] != StringType("Backdrop")

But yes, you need to convert them so they are of the same type on both sides of the comparison. Without converting the left to str or the right to StringType you have two different types which cannot be equal.

This is one of the few areas where Jython is a little weaker than Rules DSL. On the other hand, often Rules DSL gets the autoconversion to get both sides to the same type wrong, so it’s arguable whether this really is a weakness in Jython at all.

1 Like
34

Thanks! Yes I forgot to say that I tried that way also and it works. But either way you have to cast the value…

35

Also what happens when using the sendCommand(String, String) where it triggers a proxy item which then triggers a rule where the value is checked as ints?

36

sendCommand(String, String) works the same way as it does in Rules DSL. The second String eventually get’s parsed into what ever state is appropriate for that Item type. So what happens in your scenario depend son what type the proxy Item is. Assuming the proxy Item is a Dimmer Item, the state will be a PercentType.

37

Thanks, I assumed this, but I haven’t found any reference for this!

38

Yes I feel the same… Even smaller breaking changes causes problems for most of the users and just dropping the DSL completely from one release to another is not the best idea in my opinion.
However as I’m migrating my rules, a migration script might seem possible… At least for the majority of the rules.

39

How can I access the Ephemeris actions in a Python rule? I assume something needs to be imported but I haven’t found what…

40

There is a blurb in the official docs and I have a update to push to the HL docs.

Try…

from core.actions import Ephemeris

Ephemeris.getNextBankHoliday()