@guessed. What can we do for this major problem ?
What do you think about my idea to catch the item not found exception and wait for 1s before retrying?
Itās not forgotten.
I started a prototype using a resettable timer. Since thereās no āIāve loaded a complete config fileā (batch) event, Iām resetting the timer each time a change-event comes through.
When the timer expires, I force a full reload. This will handle both the startup event, as well as any change-event during runtime. It also means I can keep the timer-based delays relatively short, and still handle both large and small MiOS configurations.
Itās not optimal, since I force a full reload at that time, but Iām bundling the triggers to minimize how often it occurs as thereāll be a flood of updated events when that comes through. In my config I have 1000+ Items bound so the alternative, loading them one-at-a-time from MiOS, wasnāt practical.
Anything large, thatās bridged, will have a similar issue.
Anyhow, itās inching along as Iām short on spare time atm (next/past few months)
My OH2 System is only in test, on a VM, fired up as I need it. Iām waiting for the non-binary alternative to the DB Config to come about before I move over. Seen too many of these become non-recoverable in my day-job to have one at the core of my HA.
@guessed ok thank you.
Were you able to reproduce my issue?
I agrre, the config in binary files is a problem. On my side, the lack of authentication is another reason to remain in 1.8.
No, but I was tackling the problem in a different way to avoid the potential. I could never work out how the specific set of criteria could be met, but Iām assuming itās a quirk of the compat layer.
@Lolodomo,
Hereās a rough version:
Itās the same as this source-code:
Basically it adds a (restartable) 5 second delay before loading content form the MiOS/Vera unit. If a new Item is found during that 5 seconds, then the clock starts again.
At the expiration of the time period, itāll perform a Full load of the MiOS/Vera data. This happens both at startup, as well as each time the Items file is changed.
Iāve so-far only tested it with OH2, under compat1x, so no validation has been performed against native OH1.
This is what the key logs elements look like on an Item-file edit (abbreviated):
2016-05-01 10:31:11.357 [DEBUG] [MiosUnitConnector] - run: URI Built was 'http://...' loop '216'
2016-05-01 10:31:11.526 [DEBUG] [MiosUnitConnector] - run: URI Built was 'http://...' loop '217'
2016-05-01 10:31:25.125 [DEBUG] [MiosUnitConnector] - run: sleeping, delaying reload sleepTime=5000
2016-05-01 10:31:30.125 [DEBUG] [MiosUnitConnector] - run: sleeping, delaying reload sleepTime=81
2016-05-01 10:31:30.207 [DEBUG] [MiosUnitConnector] - run: finishing sleep cycle.
2016-05-01 10:31:30.208 [DEBUG] [MiosUnitConnector] - run: URI Built was 'http://...' loop '0'
2016-05-01 10:31:31.326 [DEBUG] [MiosUnitConnector] - run: URI Built was 'http://...' loop '1'
The default period is 5s, but itās tunable (not that I think people will need to)
Did you get an opportunity to try it?
No sorry I forgot to do it and I cannot now.
Will do later during this week.
@guessed: I just tested quickly your test JAR in openHAB 2 beta 3 and it seems to work well, meaning I donāt have the item registry errors at startup.
Controls are still OK.
I even tried to reload the Vera and that looks ok too.
Remains to test this JAR with openHAB 1.8.3.
Thanks @lolodomo! Iāve submitted PR 4446 to put these changes into the 1.9 codeline (for openHAB 2.x consumption).
These changes are generic, but at this time I donāt plan on putting them into the 1.8 branch - it works fine under regular OH 1.x and theyāre not critical, so Iād like to keep changes there to a minimum.
@Gerardo_Palacios,
Did you get to the bottom of your issues? If not, please open a clean thread for the discussion, and Iāll look to chime in there.