Looks like with a simple apt install I can’t keep my OH2 installation:
$ sudo apt-get install openhab
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
openjdk-17-jre | java17-runtime | java17-runtime-headless | zulu17-jdk | temurin-17-jdk
The following packages will be REMOVED:
openhab2 openhab2-addons
The following NEW packages will be installed:
openhab
0 upgraded, 1 newly installed, 2 to remove and 196 not upgraded.
Need to get 110 MB of archives.
After this operation, 172 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
Battery reporting is really the one major flaw with nearly all the Zooz sensors. I see this and related issues on most them. I’ve got everything from leak sensors to tilt sensors and probably 1 out 5 gives reliable battery reports. The most common pattern seems to be close to what you’re seeing which is a new battery will start at 100%, drop to some low value (sometimes 20% sometimes 12%) often within hours and then remain at that value for many months. It worried me at first and now I just ignore it and replace the batteries when they actually stop working. The rest of the functions tend to be great (which is why I have many of them).
FWIW There should be no problem with either 700 or 800 controllers with the OH Zwave binding starting with 4.1 for “traditional” zwave. What is not supported is the 800 Long range inclusion but all long-range devices can be included in the traditional mesh network.
Long range is a “star” network (no mesh) on a slightly different frequency and is only permitted in North America. It also requires smart start and S2 security. I did a couple of LR tests with Zwave-js, (interestingly with the ZSE44 and a Zooz 800 stick) but reverted back to “traditional” that is supported by OH. I seemed to have dropped messages and couldn’t analyze because my Zniffer doesn’t pick up the LR frequency.
Per my earlier link, the 02P also has a smaller margin for error. @m2spring, if the ones you ordered are square, they’re the old versions. The 02P sensors are round.
A lot of sensors report battery life by comparing the current voltage to predetermined values, starting with 3V = 100%. 80% might be 2.85V, and 20% might be 2.7V (I’m guessing). So, what you’re seeing is that the voltage has fallen below the 0% threshold…but that’s still enough juice for the sensor to keep working.
A good-quality Lithium coin cell will start around 3.3V, so you’ll often see a sensor report 100% for an oddly long time before suddenly dropping a lot. As a result, the reported percentage doesn’t line up with our perception that the battery drain should be somewhat linear.
Bottom line: if your sensors report voltage, that’s a better way of determining remaining battery life.
That’s why @JustinG mentioned docker for openHAB 4 installation.
This way, your existing installation will not be touched.
Other option would be a „manual“ non package installation by downloading the zip file.
As said before, a bit more difficult, but not impossible two have both versions running.
Btw, you will need to change the ports for your second install….
Complete different way would be to setup a VM for openHAB 4 on your home server, if it is powerfull enough…
It might be worth mentioning that in the docs for the binding. Or if it’s mentioned I didn’t see it. Right now it states:
Note: As of OpenHAB 4.1 Controllers based on Silabs SDK 7 are partially supported. For SDK 7 controllers “Classic” inclusion (node numbers 1-232) is supported, but the higher power Long Range inclusion (node numbers over 255) is not.
which, with the absence of mention of SDK 8 ot 800 series here or anywhere else in the docs implies they aren’t supported. It’s good to know that they are supported.
That is probably too technical. Both 700 and 800 controllers use SDK 7, the “partial supported” only applies to the last clause about LR inclusion. There is no SDK 8 yet AFAIK.
Frankly I agree. The docs asa written right now are too technical for someone who only casually knows Zwave to understand what is and is not supported.
I am in a similar situation and plan to move from 2.5.12 to 4.1.x
Today using lots of rules now reading I could use UI instead of textual configuration. What does that mean?
Can I transfer my rules somehow using UI, or is that just for the items and things as I understood it?
I thought I move my rules after adjustments into the OH4 rules folder, is my assumption wrong?
Even on OH 2.5 you had the option to create Rules in the UI if you installed the Experimental Rules Engine. But as with Items and Things even in OH 2.5, managed Rules are completely separate from .rules files.
There is no import/export capability (well, there kind of is for Items but that’s a different discussion).
I cannot stress enough that the people who have the most problems in OH 3+ are OH 2.5 users who do not read the Getting Started Tutorial. Everything you need to know about creating rules in the UI is covered there.
If you decide to migrate your rules to become managed, assuming Rules DSL, it will mean:
create the rule from MainUI → Settings → Rules
fill out the proforma info (UID, name, description, tags)
add a trigger based on what triggered the original rule used
add an Inline Script as the action choosing Rules DSL as the language; the stuff between then and end in your original rule goes here
If you use global variables, you’ll have to use the cache instead (see the implicit variables section of the docs). If you import classes you’ll have to use the full class name instead.
However, if you are going through the effort, I would recommend going all the way and instead of just migrating your Rules DSL to be managed to instead rewrite your rules using Blockly. Surprisingly, even though it’s a graphical programming environment originally intended to teach programming to kids, Blockly is far more capable than Rules DSL is and it’s capabilities are only growing whereas Rules DSL is basically stagnant.
Note, even if you keep your rules as unmanaged text files there are a significant number of changes you’ll have to make to your Rules DSL code. Be sure read the breaking changes sections for all the announcements between 3.0 and 4.1 and apply them accordingly. Or take this opportunity to reassess and recreate your config in a way that takes advantage of all the great new features that have been added to OH in the three years since 3.0 was originally released.
If you decide not to use managed rules, then you keep your rules in .rules files in the rules folder same as you always have.
Hmm I just had a look to Blockly and don’t really know if I understand that
Need to think about and maybe try if I could get a text rule I am using already in 2.5.12 up and running in Blockly. First I would need to setup some things and items using the UI …
There’s also JS, Ruby, Groovy and Python as options.
The big thing about Blockly though is it’s really hard to make syntax errors. And to a large extent it actively prevents you from making a lot of common mistakes. You can still make logical errors of course.
If you can do Rules DSL, I’ve no doubt you can do Blockly. If you can’t get your head around Rules DSL, well, you might be able to get your head around Blockly because you only have to worry about half of the sorts of problems you might experience while coding.
Have you given any consideration to persistence? I want to update from OH3 to OH4 and do some hardware migration/maintenance at the same time, which will result in a fresh OH installation. I’m ok with rebuilding everything bit by bit but what about the years of item state history I’ve collected? Can I backup and restore that? (And if so, can I do it incrementally/partially?)
If you use RRD4J as persistence service, you can backup the rrd files end restore them late one by one. Each item has its own file.
If your new items have different names, you can simply rename the corresponding rrd file name. Please make sure openHAB is not running while restoring/renaming rrd files.
