@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.
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.
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?
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…
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
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
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.
@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 
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.
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.
@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 ?
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.
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
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
I’m still having problems every time one of my zwave devices gets reconfigured (i.e. the poll period that you can set in habmin).
I have set it to a day for all my zwave devices, but that’s still 7x a day where my system is not responding for 20 minutes.
Any suggestions on how to fix it?
Thanks!
Have you already opened a topic to discuss this? If you are looking for help in troubleshooting, al lot more information will be needed.
Hi 5iver,
Well this is the topic. If you read it from the beginning you will see that we found out that there is something causing a re-read of the rules when for example a zwave thing is reconfigured.
I also provided logs, but as far as I can see we’re still missing a solution. Correct me if I’m wrong!
I think it was mixed up earlier in this 76 post thread.
It has been suggested that if they are not the original poster, we should just ignore them.
1 Like
Hi Michael,
Where are this .kar file located?
Taking advantage of the much more time all we will be at home this days I tried to flash a new sd with latest openabian image running OpenHAB 2.5.2 (as it is also required to run the system on my new RasPi 4), and as soon as I recover the 2.4 backup the “System Restarted” rule gets executed every now and then as before. I’m desperate as I can’t see any clue in the log files on what is wrong