Great job guys
I’ve decided to give 4.0 a try last night to see what the logs throw at me. Transition went really smooth and everything is looking good and is working fine so far.
What i haven’t figured out yet is how i’m able to whitelist my shell scripts again.
2023-03-02 04:45:12.358 [WARN ] [ng.exec.internal.handler.ExecHandler] - Tried to execute '/etc/openhab/html/muellabfuhr/trash.sh %2$s', but it is not contained in whitelist.
contents of misc/exec.whitelist , just in case i need to go and see the eye doctor and finally need a pair of glasses
/etc/openhab/html/muellabfuhr/trash.sh %2$s
Owner, rights and location (misc/exec.whitelist) are correct and the contents are unchanged.
It has been working fine with 3.4. Guess there has been a change that i kinda missed?
I wanted to say that for the first time in a long while I’m usually getting a completely clean start. Great work to everyone!
However, I’ve been seeing something odd the past few snapshots which I’m pretty certain is a timing issue. I’m still investigating and need to confirm this but it seems that two out of every three starts of OH, any rules that trigger soon after runlevel 40.
20│2023-03-02 10:35:25.924 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'rules_delayed' failed: <eval>:1:4 Expected ident but found {│
20│var {helpers} = require('openhab_rules_tools'); │
20│ ^ in <eval> at line number 1 at column number 4 │
for every rule that runs during this period. It’s always that first line of the rule it complains about. Once runlevel 100 is reached (maybe as early as 80, I’m adding stuff to verify) the rules work just fine.
It’s not the worse thing in the world, though it does break my Delay Startup rule which is supposed to turn off some rules that shouldn’t fire until start is closer to complete.
I’m going to try to narrow down the timing a little better but reporting the initial behavior in case someone can say “Oh I know what’s going on!”
Answered my own question. For addon’s that don’t do anything karaf specific, or use new features from above java 11, the following works to create a hybrid build of the jar…
A fix was done yesterday to jupnp and the fix is working.
Unfortunately, the last snapshot (3344) is still packaged with the old jupnp version (2.6.1) while the version 2.7.0 is required.
As most experts on the status+stability of 4.0.0-SNAPSHOT are hanging around in this thread, let me ask the question here: Do you think we are now ready for a first milestone release? Our release build has finally been fixed yesterday (thanks to @pfink!), so that we could do a milestone any time. Let me know, what your feeling is and if you see some critically broken things right now that should be fixed first.
I’m running a recent snapshot build (#3346) in 2 locations. Both installations have around 30 addons installed. One location has about 150 things and 2000 items; the other has about 120 things and 1300 items. Both are running very smoothly.
The only thing I’d like to see included in the milestone release is the support for channel groups in the thing update instructions. It feels to me like the thing update instructions are a large and new feature that would benefit from testing through a few milestones releases. If we miss the March milestone release, we only have the April and May milestone releases before the full release in June. There also are a few addon PRs that are dependent on this change.
I too have been running the 4.0 Snapshot as my production system and the last week has been pretty smooth. I’m still seeing a few issues around startup (see above with the Shelly binding after a cache clean and that intermittent problems with rules). I’m also seeing a couple of errors from the zwave and ZigBee bindings but they do not seem to impact their ability to function.
Once OH comes up it runs really smoothly. I love watching my events log zooming by with openhab.log mostly silent because nothing’s wrong.
My system is more modest with 15 bindings, 382 Items, 71 Things, and 65 rules (about a third of which come from rule templates posted to the marketplace).
From my side I see no major bugs that absolutely have to be fixed. Though we might want to spend a little bit on a migration guide given the need to upgrade the OS many will face to get the required version of Java.
I too have my pet major feature of like to see added sooner rather than later in the overhaul to UoM. That’s one breaking change that could impact a lot of users so getting it in front of a wider audience sooner can help us develope migration guides and possibly even migration tools.
But that shouldn’t stop the creation of a milestone.
I’d like to second this. The PR for my binding has been open for more than one year, and I’m definitely not the only one who has a long standing PR like that. Since the 4.0 migration will be a pain for the addon marketplace [1] it would be great if somebody could check the queue of pending PRs before it’s too late in the 4.0 cycle.
[1] Since the jars are not compatible, one needs to open 2 threads to support both versions, which both is harder to keep track of and dilutes discussions between both threads. It would have been great if the marketplace supported multiple jars/kars per thread and choosing the right one by checking the version number or some metadata.
I think it’s pretty stable too now and packed with new features compared to 3.4. So I’d create an M1 ASAP so we don’t loose any more time with testing. It will hopefully also give users a stable milestone to revert back to in case unstability is introduced due to more changes.
After some major difficulties last weekend, the snapshots are stable again.
Some new features are still in progress but I think there is nothing that should prevent generating a first milestone.
Have some issues since yesterday with IPCAMERA binding
sending a picture if someone rings on door
rule "Haustuer Foto"
when
Item Haustuer_Klingel changed to ON
then
{val telegramAction = getActions("telegram","telegram:telegramBot:Telegram_Bot")
telegramAction.sendTelegramPhoto("http://192.168.1.12:8080/ipcamera/192168493/ipcamera.jpg", "Haustür")
Haustuer_Klingel.sendCommand(OFF)}
end
Haustür:Download failed with status 500
calling the URL from browser result:
Just to count it up, there are currently 32 open PRs for new addons. Legitimately some (about 8 from what I I can count) are stale and need attention. About half of the rest are sitting at a point where they need to get reviewed, some for the first time, some by the “Add-ons Maintainers” group, and some getting close to the year mark. Some are just needing modification to the 4.0.0 changes (addon.xml for example) but were otherwise reviewed and ready.
Great work to everyone!
So I’d create an M1 ASAP so we don’t loose any more time with testing. It will hopefully also give users a stable milestone to revert back to in case unstability is introduced due to more changes.