There is no queryable persistence service registered with the id 'jdbc'

mtrax · August 9, 2024, 11:39pm

I have just noticed my startup openhabjs script is failing but just before I see the following error:

[nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the id ‘jdbc’
then after my script fails (see below). I’ve just updated to the latest 4.2.1 patch and I’m pretty sure this did used to work …

 Failed to execute rule EV-Energy-startupComplete-d40eb4fb-80a2-48ee-9276-0f4d8e5c99f0: TypeError: Cannot get property "numericState" of null: TypeError: Cannot get property "numericState" of null
        at <program> (energy_EV.js:14)
        at _run (@openhab-globals.js:2)
        at execute (@openhab-globals.js:2)
        at execute (@openhab-globals.js:2)

line: 14 is using persistence service to query historical values

rules.when().system().startupComplete().then(event => {
...
var daySoFar = Energy_EV_energy_interval.persistence.sumSince(new Date(new Date().setHours(0, 0, 0))).numericState //sum since midnight 
...

if I re-save script it works fine… is this a timing issue, as it should execute after startup completed
thanks

rlkoshak · August 10, 2024, 6:30pm

It might be the case that jdbc isn’t yet loaded and online by the time run level 100 is reached.

If you set a timer to execute this say 10 seconds after the rule triggers does it work?

This is a really awkward way to do this. First of all you should be using time.ZonedDateTimes instead of JS Date. Being that, why create a new Date with a new Date? it’s redundant.

The “official” way to get midnight is time.toZDT(“00:00”).

mtrax · August 11, 2024, 2:26am

thanks for the reply
a timer or sleep ok?
I just put a sleep after startup was executed

java.lang.Thread.sleep(8000)  ;  // wait 8 secs

This appears to fix it, I assume jdbc initialization isn’t somehow using Startup event, which is a bit frustrating.
and thanks updating the midnight reference as suggested.

I see if the logs the service I assume is ready about 8 seconds later

2024-08-10 09:22:53.595 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the id 'jdbc'
2024-08-10 09:22:53.595 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the id 'jdbc'
...
2024-08-10 09:23:01.755 [INFO ] [persistence.jdbc.internal.JdbcMapper] - JDBC::openConnection: Driver is available::Yank setupDataSource

mtrax · August 11, 2024, 11:10am

github.com/openhab/openhab-core

Add a PersistenceService bundle tracker

openhab:main ← J-N-K:persistencebundletracker

opened 04:30PM - 17 Jul 24 UTC

J-N-K

+212 -116

While working on adding time series support to the Awattar binding I found that …- depending on the installation order - things might get initialized before all persistence services are ready. It might happen that this leads to issues with persisting data (because a state or time series is sent before the persistence service is ready). I propose to add a persistence service bundle tracker (similar to what we have for script engine factories) and prevent early thing initialization. Adding the new `persistence=services` ready marker as a requirement to start level 30 and delaying thing initialization until that level is reached makes sure that persistence services are ready. Increasing the minimum start level for thing initialization also solves another issue reported on the forum: things initialized before scripting add-ons might result in warnings that a script engine factory is missing for the `SCRIPT` transformation used in profiles. There might be a short delay in startup but IMO the benefits outweigh that - and maybe it doesn't influence the total startup time that much because the scripting add-ons and the persistence add-ons are just started earlier than before. They are now using more ressources during early startup but less on later levels.

Might be fixed I hope?

rlkoshak · August 12, 2024, 1:12am

Long term a timer would be better. For testing a sleep is fine.

Just the opposite really. The start levels do not account for persistence being available. So run level 100 is reached whether or not persistence is ready.

Should work, but be aware that this means that the rule will run 8 seconds later (based on those logs), not that persistence is going to be available sooner.

mtrax · November 26, 2024, 7:22am

since last update I have now changed to 12secs …
this is not a great way to manage my code.
is there no better way if I need to retrieve from persistence after startup

rlkoshak · November 26, 2024, 3:06pm

If the add-on is not available then there really isn’t anything else you can do.

Though there has been some work to include persistence in the startup process so it contributes to the runlevel now and the PR you linked to above has been merged. Are you still on 4.1? Is it still a problem in the latest 4.3 milestone?

mtrax · December 7, 2024, 10:15pm

I’m currently on openHAB 4.2.3 ( on Ubuntu repo package), and yes it appears to be still an issue, although increasing the “sleep” or wait time does work for now.