openHAB 5.2 Milestone discussion

[rlkoshak (Rich Koshak)]

@Nadahar

. If you use 5.17.1 you should be fine, or you can wait for the next release, probably 5.18.1.

And if you don’t want to wait you can install just the older version of the openhab npm module.

From a terminal navigate to $OH_CONF/automation/js and run npm install openhab@5.17.1. Then in MainUI navigate to Settings → JavaScript Scripting and disable the cache option. That will cause the add-on to use this installed version of the add-on rather than the version that is bundled with the add-on.

Just remember to re-enable the cache and removenpm uninstall openhab to go back to the add-on version.

[Nadahar (Nadar)]

@rlkoshak

Just remember to re-enable the cache and removenpm uninstall openhab to go back to the add-on version.

There is something I’m missing here, because according to @florian-h05, 5.18.0 doesn’t come with any version of the add-on, it was created/released yesterday, so only users that explicitly upgrade should see it. It seems like there is some “auto update” in action somewhere that eagerly upgrades to the latest version.

[florian-h05 (Florian H.)]

@Nadahar

This has already been addressed, but the fix hasn’t been released yet. It will be in a matter of hours I believe. The problem isn’t with M5, but with version 5.18.0 of the JS helper library. If you use 5.17.1 you should be fine, or you can wait for the next release, probably 5.18.1.

This actually needs 5.18.0, which breaks other things. Wait for 5.18.1.

[florian-h05 (Florian H.)]

@Nadahar

There is something I’m missing here, because according to @florian-h05, 5.18.0 doesn’t come with any version of the add-on, it was created/released yesterday, so only users that explicitly upgrade should see it. It seems like there is some “auto update” in action somewhere that eagerly upgrades to the latest version.

The issue with rules.runRule needs 5.18.0 to fix it, it affects everything before 5.18.0, M5 ships 5.17.1. The rules.runRule issue was caused by your change to the threading of RuleManager.runNow.

However 5.18.0 introduces the issue that @milo was experiencing, so everyone, please wait for 5.18.1 if you want to manually upgrade openhab-js.

[florian-h05 (Florian H.)]

I’ve just published 5.18.1.

[milo (M)]

Unfortunately nothing changed on my side…still on 11 out of 64 rules are loaded…

M5build with 5.18.1 js lib

[John_Siemon]

Just want to share an observation. I upgraded from 5.2.M2 to 5.2.M5 and I have noticed that the bundle state for a couple of bundles remain stuck at Resolved no matter how long I wait or how many restarts I perform. I am running OH as a docker, and this behavior does not occur with M2. If I manually perform a “bundle:start xyz” then they become Active. I tried deleting the cache and tmp and performing a clean install, but the behavior persists.

[Nadahar (Nadar)]

Are you sure that this is a problem? I don’t know exactly why it has changed, but OSGi will start some components on demand. These looks like they are related to DSL rules/scripts. If you don’t use any, they might just stay on “resolved”. Do you use DSL rules, and if so, is there a problem with them not executing like they should?

[Mherwege (Mark Herwege)]

I don’t see changes in the persistence service that could cause this.

Can you log the time with timezone on both versions? Could the timezone be wrong, and therefore it returns the current state?

@jpg0 Could [influxdb] Move keep() after ordering/pagination for ~1000x query performance improvement by jpg0 · Pull Request #20654 · openhab/openhab-addons · GitHub have anything to do with this?

[John_Siemon]

Yes. All of my rules are dsl text files. M2 does not have this issue, they go to an Active state quickly. TBH, Im not sure if it is a “Problem”, because I haven’t tested M5 enough. That’s why I framed it as an observation.

[Nadahar (Nadar)]

@John_Siemon

Im not sure if it is a “Problem”, because I haven’t tested M5 enough. That’s why I framed it as an observation.

I understand that, I’m just saying that OSGi “is supposed to” behave this way under some circumstances, so we should make sure that they don’t start when they are needed before considering it a problem. There has been done various changes here and there, including upgrades of Xtext/Xtend that could be the cause of the change in behavior without posing a problem.

[John_Siemon]

Understood. At this point all I can say with certainty is the this is very different behavior than what I see in M2. I will continue to evaluate.

[Nadahar (Nadar)]

@John_Siemon

I will continue to evaluate.

Do they remain not started if you run a DSL rule?

@Lolodomo

It was changed to not have these bundles started, as they are not necessary at runtime.

That explains it - they aren’t started because they aren’t needed at runtime, but is there because they are needed at compile time.

[Lolodomo]

It was changed to not have these bundles started, as they are not necessary at runtime.

Feature `openhab.tp-xtext`: don’t activate `org.eclipse.xtend.lib` (#5317)

[John_Siemon]

I manually forced several rules to run, but the bundles remained Resolved and not Active. I see now this was intentional, but then why load them at all? The few rules I tested seem to run without issue. Under what circumstance would they become Active? It seems this change was made in 5.1.1, but 5.2M2 loads them at runtime. That’s is why I was confused. Just trying to improve my knowledge as to how things work under the hood.

[Nadahar (Nadar)]

@John_Siemon

It seems this change was made in 5.1.1, but 5.2M2 loads them at runtime.

If you look at the actual commit:

Feature openhab.tp-xtext: don’t activate org.eclipse.xtend.lib (#5317)

…you can see that it is only present in M4 and M5:

@John_Siemon

I see now this was intentional, but then why load them at all?

As I understand it, that’s not up to OH - it’s done by Xtext, which OH uses to provide DSL:

Do not require Xtend.lib at runtime, when using XBase

So, all OH can do is not to start them.

[jpg0]

I took another look at the PR, and the changes should be benign - they reorder the generated flux to allow influxdb to optimise it’s query. I guess it’s possible that it’s exposed some other bug in a lower layer.

The way to find out would be to run the flux directly against the db, then we can see if the reordering is causing the issue.

// How it looked in M2
from(bucket: "") // not sure what this is in your setup
|> range(start: -100y, stop: )
|> filter(fn: (r) => r._measurement == “feedin_energy_today”)
|> keep(columns: [“_measurement”,“_time”,“_value”])
|> last()

// How it is now in M5
from(bucket: "")
|> range(start: -100y, stop: )
|> filter(fn: (r) => r._measurement == “feedin_energy_today”)
|> last()
|> keep(columns: [“_measurement”,“_time”,“_value”])

@Vaclav_Provaznik could you give this a try? You’d need to use the influxdb web app or cli.

The other change in there is a fix around aliasing: is there an alias configured for feedin_energy_today?

[Vaclav_Provaznik (Václav Provazník)]

Thanks for looking into it, I did try the flux and there is an interesting suspicious difference which I don’t understand (M5 returning two values?!), where the first one seems to be the one M5 is always working with, hence when I am calculating difference, it fails to 0 (which is how I found out something is wrong).

So it seems it is not result of not finding anything in influx and reverting to some other persistence source, but I suspect something may be wrong with the series in my influx. Still don’t understand how this can happen and how to fix (can try dropping that particular value, but would like to keep the history).

Note I needed to modify the stop: by adding 0m as it was throwing error.

Full log:

root@ee5f030e99c2:/# influx query
from(bucket: "openhab/autogen")
|> range(start: -100y, stop: )
|> filter(fn: (r) => r._measurement == "feedin_energy_today")
|> keep(columns: ["_measurement","_time","_value"])
|> last()
Error: failed to execute query: 400 Bad Request: compilation failed: error @2:24-2:28: missing property value
root@ee5f030e99c2:/# influx query
from(bucket: "openhab/autogen")
|> range(start: -100y, stop: 0m)
|> filter(fn: (r) => r._measurement == "feedin_energy_today")
|> keep(columns: ["_measurement","_time","_value"])
|> last()
Result: _result
Table: keys: [_measurement]
   _measurement:string                      _time:time                  _value:float
----------------------  ------------------------------  ----------------------------
   feedin_energy_today  2026-06-03T15:23:00.870000000Z                          7.78
root@ee5f030e99c2:/# influx query
from(bucket: "openhab/autogen")
|> range(start: -100y, stop: 0m )
|> filter(fn: (r) => r._measurement == "feedin_energy_today")
|> last()
|> keep(columns: ["_measurement","_time","_value"])
Result: _result
Table: keys: [_measurement]
   _measurement:string                      _time:time                  _value:float
----------------------  ------------------------------  ----------------------------
   feedin_energy_today  2025-06-30T21:32:00.000000000Z                         24.67
   feedin_energy_today  2026-06-03T15:23:00.870000000Z                          7.78

I was trying the timezones before, it is set up through TZ=Europe/Prague for both openhab and influxdb and also Openhab GUI shows it properly.

M2 verbose logging shows

│2026-06-03 17:28:34.274 [INFO ] [openhab.core.model.script.script_dbg] - DEBUG [Saved] Feedin components -> feedinNow: 7.81, feedinPrev: 7.26                    │
│2026-06-03 17:28:34.277 [INFO ] [openhab.core.model.script.script_dbg] - Current ZonedDateTime: 2026-06-03T17:28:34.276873580+02:00[Europe/Prague]               │
│2026-06-03 17:28:34.285 [INFO ] [openhab.core.model.script.script_dbg] - Formatted Time: 2026-06-154 17:28:34 CEST (GMT+02:00)

I’m not aware of any aliases, this is the item definition in .items

Number feedin_energy_today "Today FeedIn to Grid [%.1f kWh]" <energy> (gSolaxModbus, gSolaxModbusSelection) ["Measurement", "Energy"] {channel="modbus:data:localhostTCP:inputRegisters100:FEEDIN_ENERGY_TODAY:number" }

If you can provide transformation for other functions (maximum, minimum, change, …) I can run them as well, but I think this goes down to some issue in how influx treats the request…

[Vaclav_Provaznik (Václav Provazník)]

Thought once more, and this is the answer:

root@ee5f030e99c2:/# influx query
from(bucket: "openhab/autogen")
|> range(start: -100y, stop: 0m )
|> filter(fn: (r) => r._measurement == "feedin_energy_today")
|> last()
Result: _result
Table: keys: [_start, _stop, _field, _measurement]
                   _start:time                      _stop:time           _field:string     _measurement:string                      _time:time                  _value:float
------------------------------  ------------------------------  ----------------------  ----------------------  ------------------------------  ----------------------------
1970-01-01T00:00:00.000000000Z  2026-06-03T15:57:36.850008228Z                   value     feedin_energy_today  2025-06-30T21:32:00.000000000Z                         24.67
Table: keys: [_start, _stop, _field, _measurement, item]
                   _start:time                      _stop:time           _field:string     _measurement:string             item:string                      _time:time                  _value:float
------------------------------  ------------------------------  ----------------------  ----------------------  ----------------------  ------------------------------  ----------------------------
1970-01-01T00:00:00.000000000Z  2026-06-03T15:57:36.850008228Z                   value     feedin_energy_today     feedin_energy_today  2026-06-03T15:57:00.870000000Z                          7.96

So the series columns changed over time and the first pipe is returning two “last” because of this and keeping only the three makes it invisible.

I guess you inverted the operations for the last() to trim the data before the column filter so maybe the “brute force fast solution” would be:

from(bucket: "openhab/autogen")
|> range(start: -100y, stop: 0m )
|> filter(fn: (r) => r._measurement == "feedin_energy_today")
|> last()
|> keep(columns: ["_measurement","_time","_value"])
|> last()

Still, interesting…

[jpg0]

Yep, you nailed it. I switched the operator order to allow influxdb to optimize the last() call, which results in huge speedup for large datasets. In your case you have two tables with the same name and last() does not work across tables (keep() does), resulting in duplicate results.

I have submitted another PR to perform some type of ‘refilter’ as you suggest: [influxdb] Fix regression from 20654 with multi-tables by jpg0 · Pull Request #20885 · openhab/openhab-addons · GitHub