How often do you restart the server running openHAB

It is a ZME UZB1 for Z-Wave. I use this in a VirtualBox VM with USB mapped from the real Hardware.

But the restarts mostly stem from the mentioned timer and calendar problems: Timers don’t trigger actions anymore and calendars don’t get updates. - Only Z-Wave takes long to recover after restart.

The other problem was re-mapped USB-devices for the EnOcean stick (which is what I wanted to address with a 2.4 update and the new binding.)

When I first experimented with OH I had my USBZB-1 stick with Windows drivers and just mapped the COM ports to the VirtualBox VM.

I use Cyrus Z-Wave stick.

Sadly it takes some time before z-network starts to function lag-less. Don’t have much experiences in this world but I would say this is unrelated to the OpenHab nor host machine or hardware where you run it.

I migrated to a clean 2.5 build a month ago and also setup network from scratch. One SM-810 door sensor is giving me a headache, while other of the same brand works fine …

Does your controller have any zombie nodes saved on the network? That can cause routing havoc.

Thanks for this, but there is no such thing like windows involved, and yes I have some “zombies” in the network and also nodes which don’t function properly. I’m not familiar with mapping serial ports to the VM from Linux to Linux with VirtualBox.

But - as Igor points out - this is not a bug really. The Problem is, that I do have to restart OH that frequently for non-z-wave- reasons. If Z-Wave was connected via bridge like Hue and Xiaomi are, the Z-Wave Network would not be re-initialized that often.

Unfortunately the main tool I know for removing the zombies is a Windows tool. I have occasionally plugged my controller into a Windows machine to use Zensys Tools.

I am running on the PI 3. The only time I have to restart the PI is when I unplug the ZWave USB stick to associate with a device. I do restart OH more often as I am still actively working on the rules. I would guess that without power interruption, and without tinkering, my system could be up for months.

I am using a tool called Z-wave PC Controller v5.38 to remove zombies. There is no need to restart - just moving USB controller to my laptop, zombie cleaning, re-plugging back and restarting Openhab. Probably this can be achieved also from Openhab ? … but since it works I didn’t explore it further.

I never did this but am sure someone wrote some quick tips:
https://www.google.com/search?q=mapping+serial+port+virtualbox
so you don’t need to scrap manuals.

It’s great to receive some support here, but actually I’m not having trouble with a Z-Wave Network taking its time. I’d like - if possible - to avoid the reason to restart.

Perhaps someone also has an idea - or even has similar issues - why Timers and Calendar Updates silently stopping to work. This is the real problem since it renders the house “unreliable” in some aspects like controlling the heating or blinds.

I’m on windows and decided to reboot the pc every month.

Before this, my pc hangs every 4 to 8 weeks. I don’t know why, but now with the reboot it is very stable.

Then maybe it’s better to not post in a zwave related topic but create a separate one. :wink:

If i read your post correctly, you enjoy USB problems (with EnOcean or Zwave) or timers stop working or the CalDAV binding stops working.

It’s plenty of possible sources, you will most likely not get a general solution. Try to handle each problem separately.

Just my 2 cents worth…

Had an instance of openHAB 2.1 running on Win7 pro using a Intel NUC i7 (attached to a UPC) that ran for about 3 year(ish - didn’t bother checking the uptime) - a couple of other things ran on it as well (blueiris, some custom stuff, etc). Retired the whole setup earlier this year when I sold the home…

In my instance - RPi3, OH2.4, 30 Z-wave nodes, Node-Red, Google calendar, MQTT 1.x binding, I don’t have to reboot up to 3 months and longer, as long as I don’t change the system. However there were few moments, when I wasn’t able to figure out the issue and had to restart. BTW OH 1.8 was far more stable - I was running it up to 6 month without any issues and needed to restart only on change.

I understand your thoughts and I’m absolutely on your side - home server needs to run stable. As not nice, but usual solution in embedded environment - you can introduce a watchdog system, which would restart your server, when something stalls. This can be internal or external thing, which would trigger on some timeout. However when you introduce such, be careful to introduce a kind of counter to know how often your system was restarted, as otherwise you won’t know if there are unusual issues.

I only reboot when I make changes, it is just a good time to reboot since changes are rare. Sometime I go months between changes. My pi just keeps running!

Don’t jump topics. Open new, specific threads for your issues, please.
How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community

1 Like

From openHAB you are supposed to be able to add the Thing, mark it as failed, exclude, and then delete. I think most of us have been unable to get that to work.

I reboot my Rpi3B once a week - at night with a cron-job.
The cause is the knxd with a TPUART on the same system, Openhab is ok, but the knxd is running, but no KNX-Traffic is routed from and to the bus :frowning:
But…it doesn’t matter, at night, after the scheduled backup, and the things/items goes online after the boot!

I’m in a similar situation: every once in awhile, OH stops receiving updates from my Wemo Motion sensor, and the easy/reliable solution is a quick reboot. If not for that, I could probably run endlessly without rebooting.

Better try restarting the binding only from Karaf.

I usually only notice when I go to my kitchen for a late-night snack and the light doesn’t turn on automatically. Next time I’ll leave it alone until I’m fully awake, and maybe set up a rule that I can trigger when I’m half-asleep.

Actually, I guess I could just restart the binding restart regularly to avoid stumbling around in the dark altogether. :wink: