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.
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…
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?
Have you already opened a topic to discuss this? If you are looking for help in troubleshooting, al lot more information will be needed.
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.
I did, you’ve already seen it.
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
The kar file is located in the addons folder, but is an optional package.
I like to have things offline there-fore i use the offline add-ons.
You can download them on the openhab download page at the bottom of the page.
I’ve upgraded to openhab 2.5.2, and i’m now using the 2.5.2 addons, with remote back to false, the problem is now gone.
Ok, where can I find older addons? 2.4 was working flawlessly so they would works will be perfect. But I don’t find downloads archive at OpenHab site
Where do I disable remote back and what is it for? (Sorry, I know I’m asking too much, but want to have home stable as I had with 2.4, but need 2.5 for RPi4 compatibility
The RPI4 needs the newer Linux kernel in the latest Raspbian. As far as I know openHAB 2.4 should run in that OS. It is somewhat OS independent. Some of your devices may need the newer version & bindings though.
I know, but the actual openhabian image comes with 2.5, and I’m too old and too lazy to install stock raspbian and configure everything from the scratch. In my mind it makes a lot more sense to focus my efforts in trying to do whatever is necessary in order to fix 2.5 rather than be struck in an older version
The problem is that it is the first time I face and issue where logs does not give me a single clue of what binding is failing or what is going on. I tried clearing cache, reviewing /var/lib/openhab2/config/org/openhab/addons.config file for wrong restdocs reference, and my last attempt was to install a fresh system restoring the backup on it. Don’t know what else to do to get 2.5 working and prefer not to rollback to my working 2.4 backup, if possible
Forget about the idea of running a 2.5 core with 2.4 addons. It won’t work, and the problem with rules to reload is in the core, not in addons so you won’t get rid of it by that action.
Then again, it does not happen all by itself, only if you change at least an OH thing.
Try to find out what that trigger momentum is on your system. Enable
org.eclipse.smarthome.model.script.rules debug level so you get appropriate messages when rules reload, then try to correlate that with events (from events.log) shortly before to get at least ideas what rule or thing may be causing this to happen.
If you manage to identify that you can probably also work around the problem.