Openhab unstable after upgrade to 2.5

Setup, Configuration and Use Beginners
Tags: #<Tag:0x00007f4330dbc458>
#56

No, M6 is milestone 6. After that came RC1, then came 2.5 stable.

#57

Then what does M6 have to do with this topic?

#58

Please read the first message in this topic.

#59

At least the zwave binding required to delete and recreate all zwave things when updating from 2.4 to 2.5 Mx. Perhaps that was not done and now the bugs appear?

“System started” also is triggered on every rule modification and every item change. When doing development that is not - well - funny at times. Due to the not predictable start up order I also delay all rule execution by 5 minutes - hopefully after all bindings are loaded and the system is stable.

Below is the workaround code I am using. Basically all rule execution is blocked while
viTimeEvent_System_Starting == ON

Anything which needs to run at system startup is triggered on viTimeEvent_System_Starting changed to OFF

The code should catch those other “System started” events as well.

var int iSystemAlreadyStarted = 0
val int ciStartUpTime = 300

rule "rTimeEventSystemStart"
when System started
then
    // Delay all rule execution and trigger generation until system is stable
    // but only on the first call
    // System started is triggered on every rule or item change
    if (iSystemAlreadyStarted == 0)
    {
        viTimeEvent_System_Starting.postUpdate(ON)
        createTimer(now.plusSeconds(ciStartUpTime)) [|
            viTimeEvent_System_Starting.postUpdate(OFF)
        ]
    }
    iSystemAlreadyStarted = iSystemAlreadyStarted + 1
end

Note: this reply was accidentally posted in another thread as well.

#60

Really??!! I have 50+ zwave items, do I need to delete and recreate them all? Why? Is there any way to be sure this is the cause before such an annoying task? or better a workaround to avoid it

#61

Zigbee and Z-Wave manual install script has a script to do it all for you.

You definitely need to delete and recreate your Zwave Things when upgrading from 2.4 to 2.5.

#62

@rlkoshak: The need to recreate things was mentioned in the 2.4 Breaking changes section:

But the 2.5 release notes do not mention the need to recreate things.

#63

But this is down until I et in a fix for the new build pipelines. Just update to 2.5.1-2 or wait until this weekend.

If everything is working as you would like, then don’t bother. But there it’s possible that the Z-Wave Thing definition for a device you have was updated. In order to get those changes you will need to delete and rediscover your Things.

#64

Would it be possible for the zwave binding to somehow indicate the definition is out of date, so only affected ones could be removed/re-added?

#65

No. This affects more than just Z-Wave and is not something for a binding to be concerned with. Hopefully, this PR will provide the needed core functionality…

Until then, this rule helps…

#66

Hi,

first time I post here, so let me quickly introduce myself:

Martin, from Berlin/Germany. For a long time in IT-business. Former Eclipse committer. Big fan of home automation (although I live in a flat and in my case it should be called flat automation) and also a huge fan of openhab.

Now back to the important things:

I had the same problem as described above (regular restart of the rules). A found a lot of posts around this but nothing help until I gave up and focused on another problem: After I upgraded to 2.5 stable my MAX! cube gave me regularly the following INFO:

[INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! cube : 192.168 .xxx.xxx


This was so annoying, that I disabled the log entry some time ago ^^

I now looked into this problem again and solved it by setting the MAX! Cube to “exclusive mode” in the paper UI.

What should I say: It does not only solve the MAX! issue. Also my rules do not start again. System works as expected on 2.5 stable.

Without knowing the internals of openhab my guess would be that the MAX! binding somehow detected and error and uninitalized the items which led to a restart of the rules (where the items were included).

Hope this helps others.

Cheers,

Martin

[SOLVED] Rules reload on MAX! binding reconnect
#67

I recreated all the zwave things when I upgraded from 2.3 to 2.4 and was a pain (I didn’t know about an automated way of doing it as @rlkoshak and @5iver pointed), that’s why I complained now. By that time last year zwave binding changed a lot and it was mandatory to do it

I didn’t see any mention to zwave breaking changes in 2.5 release notes, and also read a recent post from @chris stating that z-wave binding 2.5 was pretty much the same as 2.4, no mayor changes, so I’m unsure if it this binding is the source of my problem. I don’t have any MAX! cube either, but it might be any other binding such as astro, broadlink, is causing the instability after the upgrade. Who knows! The challenge now is to find out which one is the one to blame as there is no clue in the logs

#68

this is normally a sign that the memory of your cube is corrupted. Would be surprised if it is related to the upgrade.

Try to access your cube with the regular app, there is (unfortunately) a high chance that room info is lost there as well.

#69

@marcel_verpaalen you might be right. Maybe I was to quick, because the restart oif the rule started again after I fixed the Max! settings. Cube indeed lost all information which seems to be a common problem from time to time.

I checked the events.log and also saw the [me.event.ThingUpdatedEvent] every time before my rules reload. Thing is, it only happens for my 2 z-wave thermostat. I also have a switch, an extender, a motion detector, door sensor. They are never updated.

I also to remove and add the devices, increase the wakeup time, remove restdocs from addons.cfg and downgraded (only the z-wave binding) to 2.5 M5. All with proper start/stop, cache removal etc I was running on 2.5. M5 distribution before and never had this problem.

I removed both things (the 2 thermostats) via paper UI and then the system was stable. Unfortunately I was then of course not able the control the devices.

So in my scenario something regularily updates my z-wave thermostats, but I couln’nt figure out yet who and why :smiley:

#70

I used a clean install (of openhab 2.5) on fresh Debian buster on my pi (3b+).

The system started rule was triggered every five minutes. Could not find any culprit in the logs (used trace level), on a non-scientific whim I removed any items added by simple mode (I sometimes use it when i’m to lazy to code).
2 days in and not a single restart, could be worth a try.

#71

Well thanks for letting us know but I don’t think that’s a solution or approach to recommend to others to try.
If it works since you removed all simple mode created items then probably because one of them was the culprit but it’s coincidential that it was a simple mode one.

To summarize threads on this symptom, the most often encountered reason is the restdocs to have moved to ui which your addons.cfg has to reflect
Plus this really weird one with the maxcube thing to change.

#72

@chris: please have a look at Openhab unstable after upgrade to 2.5 and the log in the next post.
It’s weird that an update to a ZWave thing causes rules to reload.
That may or may not be a ZWave or a generic thing thing as we’ve seen it with the max binding, too. Still can’t explain that.
But why does an update to an item change the thing ?

System started triggered every minute with 2.5.0 stable
#73

I’m not sure - all of this is done outside of the binding. The binding knows pretty much nothing about items - the only thing it knows is when a channel is linked or unlinked, and when this happens all the ZWave binding does is to start or stop polling. Bindings only deal with Channels (so in the above example, the binding is informed that the channel is linked - it doesn’t know what item etc it’s linked to).

The binding knows nothing about rules, or even how a thing is defined (ie if it is through text files or the UI etc - pretty much everything like that is completely unknown to the binding). The binding just runs itself - it sends updates when a channel changes, and it gets informed when there’s a command sent to a channel, or a configuration update on the thing.

#74

Followup: I also tried to remove the z-wave devices that causes the restart and added them manually to a *.thing file. The system is more or less stable now. I even switched bak to 2.5 stable.

Every 1-2 hour I can see a restart caused by a failed Shelly device. Need to check this as well, but it is not that problematic as the 5-min restart period.

Interestingly: Only my two z-wave thermostats were moved to a file. All other z-wave devices are still configured by simple mode and don’t cause any problem.

Cheers,

Martin

#75

Hey,

I had the exact same issue, i am used to using the openhab .kar file and setting remote to false.

When i changed that back to remote=true and removing the .kar files, everything works fine.
Did not report any issue…

Michael