NGRE without a thing

Setup, Configuration and Use Scripts & Rules
#1

PI4 OPenhabian 2.5.3

After some struggles with writing rules in the default OH language I took some advice to do some on-line training in Python and then try to use the NGRE or figure out if I can just put Python in a .py file and expect it to run.
I want to do some things with timers that I’ve been stuck on and chose that for this effort and started into NGRE to see right away that I need a thing. The garage door controller that I built does not have a “Thing”. There are two Items per door, one is a switch to control the door and the other is the status of the door (open, ajar,closed). The controllers use HTTP and the REST interface direclty so now I’m wondering what to do next. Is there a way to create a fake thing for purposes of NGRE?

#2

Why do you think you need a Thing? This is everything you can trigger a rule from (Things are not required)…

Here are some examples of using timers (I suggest using ScriptExecution.createTimer)…

https://openhab-scripters.github.io/openhab-helper-libraries/Examples/Timer%20Example.html

#3

There is an http binding, allowing to link calls to an Item.

Or you can make http calls directly from rules.
You’d still want Items to represent your physical devices, and allow display or control in UI

#4

The NGRE requires it.

image
image859×814 38.7 KB

#5

OK… that is not the NGRE. It uses it, but it is not IT. You are using the JSON rule editor in Paper UI. Also, you’ve selected a Trigger that requires a Thing. Select another Trigger, like ‘an Item state changes’. Scroll down if you do not see more options.

#6

I used the HTTP binding initially but either the polling had to be run very frequently or there was a delay to activate the door and for the status to update so I rewrote the rules and code on the opener to have everything be event based.

I don’t understand the comment “represenet your physical devices…”. I have seperate items configured for each door but what would be part of a channel, like the ip address, is coded into the rule. After thinking about your comment maybe I can change that and be able to make cleaner rules by using a item name that can be tweaked in the rule instead of having copies repeated.

#7

It is really not clear exactly what problem you are trying to solve and the way you put a few things makes me thing you don’t quite understand how OH works.

With OH 1.x version bindings like the HTTP binding you have an Item and a binding config on the Item. This Item represents a sensor or actuator of your physical device (the door in this case).

With OH 2.x bindings you have Things to represent the physical device. Things have a separate Channel for each sensor and actuator the device supports. You then expose those Channels to the rest of OH by linking them to an Item.

In either case, just about everything in openHAB operates on Items.

So, as Scott suggested, if you want to create a Rule using PaperUI which gets stored in the JSONDB, you would use one of the Item Rule triggers:

image
image1028×593 21.7 KB

It’s unfortunate that the Item triggers aren’t listed first but PaperUI sucks for creating Rules. It’s definitely possible to do so, but it’s not recommended (though once you have Rules in JSONDB they run really well and OH boot times are super fast).

But if you are looking to write Rules in more pure Python, forget about PaperUI and write your Rules un .py text files. See:

1 Like
#8

As you politely noticed - I am confused. I do however understand the OH1 - OH2 and Things concepts. I have numerous OH2 bindings in use and two OH 1 bindings. That is pretty straight forwards.

The Rules however have been a real struggle for me to develop and I appreciate you and others help in the community to to try to get to the point that I have enough knowledge and OH vocabulary to take control of most rule development and only ask the community interesting questions. I’ve gotten feedback a couple of times that my questions could be more concise and I also agree. I don’t know enough to clearly communicate the problem but always agres that a problem that is well defined is at least half solved.
In this case I am considering making a change to Jython/Python to get away from my struggles with Rules. I’ve put together a decent collection of working examples but only today discovered the “real” meaning of some very basic things. I have programming experience but all on old or proprietary languages.

To try to address this I decided to try Python and doing proper course work to to really know the basics. After getting through a good part of the lessons I came back to OH and wanted to try a bit. I thought the NGRE generated Python code and that I could start there. I installed it and then looked in the PaperUI and saw the “Rules” item and somehow thought it must be the NGRE. I did also do an upgrade through Openhabian today. Maybe it came from there or maybe it’s just been a while since I have been in Paperui because I normally use text files except to prototype new functionality.

I have started and will continue to read the docuements that you attached. I’ve completed the setup of the JSR223. I do however feel like I’ve traded one problem(not knowing DSL) for maybe 2 or 3 now. I have Jython installed, I am still thinking there is a UI for the the NGRE, I am wondering if that is the same thing I see referred to as the Experimental Rules Engine.

So, What I really want to do is write rules. I think I want to use Python because I can continue to have proper (hopefully) instruction in how to write the code. But maybe I am better to go back to copying snippets of code from places and trying them out with DSL.

What do you recommend?

#9

The UI rule editor in Paper UI will allow you to use scripted automation in Actions and Conditions, but the editor is horrible (much better in OH 3.0). Personally, I do everything in VS Code with pylint. If you have questions about how to implement the timer example I provided, post the code you are having difficulty with and I will gladly help out.

There are many reasons why using Jython with scripted automation is better than the rules DSL, but you will need to decide for yourself which to use. I’m confident after your first successful Jython rule you will agree.

1 Like
#10

@MickPB, I would encourage you to document your experience and the steps/resources that help you along the way, as this will be valuable information to share. I’m planning to do this when I tackle NGRE, and it will be helpful to have the perspective of other users who have no previous experience with Python. After we become familiar with something, it’s easy for that thing to become a blind spot when communicating the information to others.

1 Like
#11

A couple more questions to be sure I am headed where I think I am headed. Should I expect to be able to do have the same functionality in Python as I have used in DSL rules especially the HTTP Post and Get? …and I am curious Is NGRE and JSR223 the same thing?

Much appreciation for the support and the contributions.

#12

All of the functionality available in the rules DSL is available in scripted automation. However, you can do a LOT more in scripted automation, and the Jython helper libraries make things a LOT easier to do it. There are helper libraries for JS too, but they have less functionality (for now).

No. The Next Generation Rule Engine is a rule engine within OH and it will replace the old/legacy/classic rule engine in OH 3.0. JSR-223 was a specification for using scripting languages within Java. If you haven’t yet, read through this documentation… https://openhab-scripters.github.io/openhab-helper-libraries/index.html.