Items files not being fully parsed at startup

The problem as I understand it is that Karaf starts up all the bundles in parallel and doesn’t provide a good mechanism to say “wait for foo to start before trying to start bar”.

A difficulty is that foo may need bar loaded first … but only if rhubarb binding is configured.
The highly modular nature of openHAB works against it here, some thing as apparently simple as “wait till the items are loaded” … well, ok, but there may or may not be an indeterminate number of files and a separate JSONB source.

1 Like

Does any of the bundles depend on each other during start up?
As far as I understand the whole system could be loaded, but keeping things, items and rules untill last, and in that particular order.

There was an issue opened a long time ago (OH 2.0 time frame), work was done on it and it was determined that there was no way to do this in Karaf.

I dont believe that…

Lets look at it in a practical way (and a bit logic to me).
When you start openhab from scratch, there are no bundles loaded. Whatever you do from here, it requires first the bundle/addons, then the thing and then the items. You cant really do it the opposite way, (well, you can when using config files, but it sure wont work, and it wouldnt make any sense).

Doing exactly the same when restarting after clean cache should be possible… Or at least, thats the logical part to me.

openHAB itself is several Karaf bundles.

Then I look forward to your PR that fixes the problem. You clearly know more than I or the devs.

1 Like

I assume the problem is that Karaf never “finishes” loading configuration. One of its selling points is that it can be reconfigured on-the-fly without restarting.

The upside to this is that you can do things like install a binding without needing to restart. Without having a look at the openhab-core source I assume it also has a hand in dynamically reconfiguring things when *.items files etc. change.

The downside to this is that you have to deal with dynamic configuration changes somehow. There are no nice and clear “stages”, at best you might get a notification that current configuration is “stable”.

With something as complex as openHAB it’s going to be easy to make a mistake in a dependency graph/ configuration change handler somewhere which results in things acting in a way you did not intend.

1 Like

They are, and they can and will work at first startup just fine. Did you ever see a totally fresh openhab fail on the first startup? :wink:
Things gets messy when you start to add exstra, like bindings, things and items. And even more messy when rules are added.

Never said that. And you know it :unamused:

You implied that add YOU know it

PR goes here.

Well, yes, but the stuff like bundles and bindings and persistence and blah has nothing much to do until you start adding the final working parts naturally it’s stress free.

No, I said I dont believe it. Thats not the same as knowing!
I dont believe the moon is flat as a pancake either. But I have never been there. So it´s wrong of me saying I dont believe it?

Futher more I gave an example, which, from a logical aspect should indicate WHY I find it hard to believe.

Exactly my point in my previous logical example.

Rich says there is no way… But where is the difference is that procedure, and the manual one, where the user add his stuff one by one? A trade off may be, it take much longer to start. But is that a bad trade off rather than an unstable system, or a system which need another restart? I´m used to do a coupple of restarts every time I have cleaned the cache… It takes quite a while longer as well.

Specially for Bruce and Rich…
No, I DONT KNOW. And I SORRY if I´m wrong. I See this stricly from a very simple and logical aspect! There may be something preventing this from working, which I have no idea of. Then I´m sorry, again! I DONT KNOW!.

This problem has existed since before OH 2.0 was released. Looking through the issues shows at least one issue (there have been dozens over the years) that was opened in 2016 and continued to be worked on with new ideas proposed from that point until 2018 when ESH was merged into OH 3. Presumably the issue was moved over from there to openhab-core but I didn’t look for it.

I counted about 8 developers/maintainers including Kai himself who worked on this issue .

When you say “I don’t believe it” you are saying that the maintainers are either lying to you or they are incompetent. I doubt you would think they are lying to you which leaves that you think they are incompetent. If the maintainers are incompetent than you must know something we don’t in order to make that assessment.

And logical analysis doesn’t help. Aristotle logically deduced that women have fewer teeth than men because women have smaller mouths. He never bothered to actually look and count teeth. He was applying logic out of ignorance and came to the wrong conclusion.

Maybe it’s a language difference, but after being told that the experts in the system have spent years looking for a solution, your reply of “I don’t believe it, it can’t be that hard” can only mean “you and all of the people who have looked for a solution are ignorant or incompetent or both.”

please don’t feed the troll, this was an interesting conversation

I think you are all being a bit unnecessarily harsh on @Kim_Andersen. You seem to have got the wrong end of the stick.

Let’s all take a step back and look at the simple exchange that started this argument (emphasis mine):

I think that is a perfectly reasonable response with no implications about the character of the core developers and no implication that @Kim_Andersen thinks they know better than them.

There probably are many ways to approach doing it in Karaf.

There is even the concept of “run levels” in OSGi even though it is all about dynamically loadable components:
https://docs.osgi.org/specification/osgi.core/7.0.0/framework.startlevel.html

The thing is this is a difficult problem to solve and different solutions have different trade-offs.
As we have seen with @evansnp’s problem the “fully dynamic” solution may in general be good but it exposes itself to problems with race conditions if required dependencies are not defined perfectly.
Some approaches with “run levels” may result more stable deterministic behaviour but have an unacceptably long “stutter” as you have to roll back run levels on a config change and then pause at each level to make sure you are ready to move on.

The fact that the core developers have been discussing this problem since at least 2016 and not yet found a “run level” solution that is better than a “fully dynamic” solution does not imply the problem is impossible or that the core developers are unskilled. It implies that the problem is very hard to solve and there may not be an “perfect” solution taking either approach.

Now let’s go back to having a nice discussion without assuming ill intent and piling on people.

1 Like

Ross, thank you, I’ve read a number of your posts in the development forum where you have helped a number of folks with technical issues and am impressed with your programing knowledge and hope you continue to contribute to OpenHAB. Rich and I have however been around here a little longer and know this guy has a tendency to climb up on his soapbox and suggest things should be done a certain way and when people gently explain to him it is an all volunteer effort and if he believes something should be done a certain way, then he is welcome to volunteer to contribute, he simply answers with a wall of text that ultimately just wastes everyone’s time.
Again, you seem to really know your stuff and I for one hope you don’t take this the wrong way. If you like I can search a little and provide several examples of his antics

ok, just for fun here is a good one where Kim suggest someone should maintain a database of which binding are being currently developed and which ones have been abandoned. Rich suggests the task is a fool’s errant but encourages Kim to do it if he feels like it
be warned 125 posts

Thanks for your support Ross…
Unfortunatly there are some people here, who will go through whatever post beeing made, only to find words to suit their own idea of the person, and totally ignoring the rest af the post. (Andrew once again just showed that). They simply cant accept others having another opinion/idea/suggestion/whatever.

It is quite frustrating when some people always turn to becoming unpolite, disrecpect and choose a personal path, simply because they either dont understand or dont agree. “Normal people” would ask, if they dont understand, but want to. When they finally understand, they will decide wether they agree or not, and either argument for/against, or leave it at that.
Unfortunatly this isn´t the case here (once again).

I always accept other people opinions. It doesnt mean I will agree with them, but I accept their opinion. I always respect them, unless they´re given me a reason not to, like beeing unpolite, disrespectfull and direct personal attacks, while ignorering the whole point. As you can see from Andrew, this is a part he has a huge problem with. The only post he contributed to this thread, is a personal vendetta against me where he, once again, managed to ignore aprox 99% of what I´ve written, and focused on the one and only thing which suits he personal opinion about me, “I dont believe that”.
That makes it highly difficult to have a nice (or just a polite) respectfull discussion with a person like that stepping in like that.

As usual, I´ll rest my case… I dont need this kind of discussion with anyone who seem more focused on twisting peoples post in a way to ruin the debate and turning it into a personal matter. I´m sure these few people will go on anyway. So its probably best to just leave them to discuss their “world” among themselves. I´m out.

This debate is starting to look like the systemd debacle in Linux :slight_smile:

On the topic of “how does the cache age”

I’ve been able to try a 15 or so hour “system offline” (same calendar date), and the boot came up clean.

After a 36 hour sleep (different date obvs), the usual odd missing Items and method/action - in this case
- Rule 'frost check': The name 'triggeringItem' cannot be resolved to an item or type; line 132, column 6, length 14
In this case, one more reboot appeared to come up clean, rather than the usual two.

I speculate this cache, or parts of, “expires” either on a calendar date change or >24 hours or so.

@rossgb, while I don’t agree with everything he said, Andrew has a point in his latest post.
I’m also one of the dinosaurs and “people” @Kim_Andersen is targeting in his recent “final” post.
I also could contribute quite some more threads on Kim’s, well art of discussion.
But I won’t as I don’t wanna turn up the heat.

Instead I’ll just throw in some facts for those interested:

Use of these has been proposed a number of times. Latest attempt is 3 days ago by myself to add this to openhab-distro. Myself and others tested that, of course.
But Kai once more refused to introduce OSGi start levels because they can cause are all sorts of problems. It’s probably also a “dogma” thingy, but given he has 10+ yrs experience in programming OSGi, I do not question his statement.

On the flip side, good news if you read on is that he also said he started work on an “alike” feature as part of his works on the next-gen rules engine.
CAUTION: this is not directly targeted at the problem here so might not help right away, and it’s (probably) not there before OH3.