openHAB 4.0 Milestone discussion

Setup, Configuration and Use News & Important Changes
389

Forgive me if this isn’t the right place to post but I’m struggling with units of measurement as it relates to humidity for several of my items in OH4. I posted previously and rlkoshak linked me to the current documentation (thx!) including this thread.

For example my ecobee thermostat sensors have items that are type = Number:Dimensionless, class = measurement, property = humidity. Prior to OH4 these reported correct correct quantity and units, eg. 49%. However in OH4 these now report 0.49.

I understand that I should be using Unit metadata to set these but I’m not having any success with the units setting of (Percent + ’ %').

Can anyone suggest the proper units metadata code?

390

I had a similar problem with with memory percent. I just went to number from number:dimensionless. Not sure about the metadata part.

391

Hello all,
Can I configure the new scene feature only in the main gui or als possible with files?

1 Like
392

Greetings all, to everyone, especially Kai, thank you for your tireless efforts on OH! I’m in the process of upgrading to OH4 now from 3. The question I’m about to ask may end up needing to be moved, as it regards jsr233/jython and the helper libraries and their compatibility with OH4.

After installing OH4.0.0-SNAPSHOT (I couldn’t figure out where to download M3… the download page says M3, but links you to the SNAPSHOT, but it seems stable enough…) I started slowly firing up the system, adding my bindings, items, etc. No issues yet. When I copied the “helper” libraries over, it began processing and loading them all. It actually went very smoothly except for one error that I have noticed so far.

The conf\automation\jsr223\python\core\components\100_DirectoryTrigger.py file threw an error while loading.

This is the offending block of imports:

try:
    from org.openhab.core.service import AbstractWatchService
except:
    from org.eclipse.smarthome.core.service import AbstractWatchService

Basically, OH4 no longer has ‘AbstractWatchService’, so it caught that error, and then since this is not OH2.5 there is no longer ‘eclipse.smarthome’ and an unhandled error was generated. This isn’t a big deal, but I like things to work, so I started looking around in the binaries, and indeed could not find a ‘AbstractWatchService’ but could find a ‘WatchService’, so i adjusted the block of code to read:

try:
    from org.openhab.core.service import WatchService as AbstractWatchService
except:
    from org.eclipse.smarthome.core.service import AbstractWatchService

Now it loads just fine, and I decided I’d try to see if it works. After finding the example for Directory trigger in the community here, I set it to watch the \conf\scripts folder, and to trigger on ‘ENTRY_CREATE’, ie when a file is created in the directory. When I add a file to the directory it clearly sees the ENTRY_CREATE event and starts processing, but instead of causing an OpenHAB event, it throws an error:

Detected invalid event (hash must not be null for CREATE/MODIFY): DirectoryChangeEvent{eventType=CREATE, isDirectory=false, path=C:\OpenHAB\conf\scripts\New Microsoft Excel Worksheet.xlsx, count=1, rootPath=C:\OpenHAB\conf, hash=(null)}

It seems like it’s so close. I’m wondering if this has to do with certain arguments the “WatchService” is looking for vs. what the “AbstractWatchService” Sends. Anyways, I can do further testing or send other data if needed.

If anyone has any news on if there are updated jython scripting helper libraries in the works for OH4, please let me know.

393

I have prepared this draft, I don’t know if it can help, because it don’t know what you mean by “units setting of (Percent + ’ %')”. Did you try to set unit to %?

Number:Dimensionless Relative_Humidity "Relative Humidity" { channel = "myweatherbinding:hygrometerthing:humidity" }

might need adjustment when channel is of type system.atmospheric-humidity because it has state description “%.0f %%” and system default is “Abstract unit one (one)”. Set the unit metadata to %:

Number:Dimensionless Relative_Humidity "Relative Humidity" { unit="%", channel = "myweatherbinding:hygrometerthing:humidity" }
394

It is UI only, but basically it is just another „look“ for the rules editor and using rules under the hood. If you want to have the same functionality file-based, just create a rule in your favourite language with no triggers that commands the given Items to a defined state and set the „Scene“ tag on it.

395

Is there an example?

What ist the benefit of the scene tag? I have a rule which starts at morning/evening/night time and I do everything in there what I want to do for the morning/evening/night

So maybe I was not really involved in the discussions

396

Thx for the help. I resolved the issue, it turns out I needed to do a full cache clean and restart to have the units metadata take effect. But the humidity values are displaying fine now.

Cheers

397

Try escaping the percent sign (Percent + ’ %%')

398

Unfortunately Jython support is largely abandoned. I know of no one who is actively supporting either the add-on nor the Helper Library. But when you figure this out I’m sure @CrazyIvan359 will accept a PR to the Helper Library.

Rules DSL:

rule "My Scene"
when
then
    MyItem1.sendCommand(ON)
    MyItem2.sendCommand(50)
    ...
end

It will show up under the Scenes page in MainUI instead of in the Rules page.

1 Like
399

Same here. Upgrade from 3.4.4 to 4.0M3 . The gateway cannot be initialised. But the whole thing in a Docker environment Docker version 24.0.2, build cb74dfc x64.

400

I need to declare “My Scene” first in the Main gui or can I declare it also in a text file?

401

It’s just a rule like any other. From the UI’s perspective, the only thing that makes it special is that “Scene” tag.

My example above is everything you need to do. You should never (and frankly cannot) mix UI and file based.

I can state the answer to your original question differently. No, you cannot create a Scene in a text based rule. Scenes as implemented in the UI, are only supported by the UI.

However, you can create the exact same capability in a file based rule as shown above. Create a rule with no triggers that command the Items to the desired state for that scene. If it’s supported in the rules language of your choice, add the “Scene” tag to the rule, though don’t expect it to show you much in MainUI under Scenes because the structure expected there is different from your file based rule. As with all file based rules, it’ll be read only also. Also, if you are using file based rules, why look at it in the UI in the first place?

1 Like
402

How to trigger than the scene?

403

Did you read this documentation at the end? Rules - Scenes | openHAB
Maybe this helps.

1 Like
404

Ahhh thanks…I haven’t switched to OH4 docu

405

That still works for me too, I haven’t moved to meta data info. Here is my Zooz zwave sensor item:

Number MasterBathHumidity “MasterBathHumidity [%.2f %%]” (MasterBath, gPower) { channel=“zwave:device:89127db0ae:node50:sensor_relhumidity” }

406

Migrating away from Jython is something I hope we do not ever have to do! I have found one issue so far, although it is minor and doesn’t seem to affect anything with my current deployment, there is a change to the core that broke Directory Trigger, I think. I reported it to @rlkoshak and @CrazyIvan359. See my post linked below…

I am hoping that at a minimum we can just keep the add on and helper libraries alive and integrated with the OpenHAB core. I don’t need any more features, just the ability to have my current rules function. A few years ago (around the time of the switch to OH2.5 or 3.0 I definitely remember reading from multiple sources that “jsr233/jython” was going to be the way of the future as far as script based rules, which made me very happy, and I went all-in! I hope it doesn’t die on the vine!

2 Likes
407

I’m not going to sugar coat it. The likelihood of that is very low in my opinion. Very little activity is going on in the upstream Jython project (only two PRs merged in the last year). Only Python 2.7 is supported which is now years past end of life with Python 3 support nowhere in sight. The Helper Library is not a part of the openHAB project itself and the last merge to it is over two years ago.

If native support for Python rules is going to be a thing, we need some intrepid developer to work on a GraalVM Python 3 add-on. Hopefully that will happen before Jython completely dies on us. But when it does, the Helper Library that gets written for it will almost certainly be very different from the Jython one. Both JS Scripting and jRuby’s helper libraries go to great lengths to present a native language interface to openHAB and I would encourage the helper library for a Python 3 library to do so as well.

In short, IMO, you are on borrowed time. Something somewhere is going to break upstream and we will not be able to fix it. At that point you’ll be forced to migrate. If it were me, I’d start preparing for the future by migrating to a different supported language.

If you really love Python, HABApp is an excellent platform, it’s native Python 3 and very well supported. If you want to try something new, JS Scripting and jRuby have very mature helper libraries that are part of the openHAB project itself (no risk of it just being abandoned) that come with the add-on or can be installed from the add-on (no need to clone GitHub repos or anything) and are very well documented. If you want something more visual, Blockly is nearly capable of anything that any of the other languages can do now too.

I was one of those boosters but shortly after OH 3 release:

  • upstream Jython has become all but abandoned
  • the developer supporting the add-on and Helper Library disappeared right as OH 3 was released
    • no one has really picked back up support for the add-on since then
    • the Helper Library became dead and had to be forked to make the changes to support OH 3 and development largely stopped as JS Scripting and jRuby surpassed it in ease of use
  • first JS Scripting (at my urging) followed by jRuby matured and made changes to help support UI rules developers as first class citizens instead of an after thought.

As OH 3 progressed, it has become increasingly clear that Jython has been left behind. I strongly urge any new development to use anything but Jython. I strongly caution existing users of Jython to consider gradually migrating to something else.

And I really hope that someone decides to tackle a GraalVM Python add-on.

4 Likes
408

Wow, Rich thanks for the detailed history/explanation. I always enjoy trading your posts, even if they’re bad news! I have done a fair amount of Javascript (webpage/app) coding, so I will probably go with JS scripting and the helper libraries. I would like to stay as close to home/native OpenHab as possible and it seems like that is the way to go, rather than HABapp. But, I don’t know much about it. If you have any advice about which of those you’d recommend, I would be happy to hear.

Thank you again!