Yes, that is the time it usually happens. Will try and disable my.openhab to see if that could be the cause.
I had major issues this week with ethernet.
Granted a few disconnects are not the end of the world, but a flaky connection when downloading and changing stuff caused me no end of grief. With various gpd codes being corrupt, and not able to use use apt-get at all.
I had the RPi2i using a 2.0a usb power adaptor (PiHut) and then one usb to a powered usb hub (also PiHut) which was powering my external hdd (because I was fed up of constant SD corruptions), usb sound adapter and RFXcom
When I switched to WiFi, everything was able to sort itself out. And whilst I was ready to start using my multimeter, the 16+ hours I spent getting it back to a working state convinced me to let it be. As I and sure it will do something obscure again soon, that will require hours of research to fix 
1 Like
Also do not overclock. I’m wondering why so many people have problems. Usually they just run fine like a microcontroller. But you should let it run at its specs and not change clock speeds.
1 Like
No overclock here, have removed the my.openhab binding now and will see how that works out. If that does not work I will switch to a wifi adapter, and use a cron job to check the wifi connection, and reset it if there is no connection. Not sure how to do that with eternet.
You can use a watchdog for this. The Raspberry even has a hardware watchdog which works, even if the OS is completely frozen: http://linux.die.net/man/8/watchdog
But having said that, waiting until something is broken to “auto-pseudo-fix” it is a really hacky approach you shouldn’t aim for.
1 Like
I’m experiencing the same problems but with wifi. after some days it stops responding but attached devices still work, like z-wave but my hue’s won’t work anymore.
My workaround here is to check the router/fritz.box with the network-health binding. if this changes to OFF i wait for some minutes, check the item again and if it’s still offline i execute /etc/init.d/networking restart
this seems to work, and i don’t have to reboot the whole raspi.
Looks like in my case it was the xbmc binding causing the dropout. Will report back in a few days to confirm.
Edit: No, it was not the xbmc binding. Will continue investigating.
Well, in my case it was a flakey pi. Got a new one , and has been running stable for 5 days now.
My Raspberry Pi 2 has dropped out yesterday and now again today, it had been working for a month before dropping yesterday.
I cannot connect to openhab through the web interface locally or ping the RPi. But I have portforwarding set up and I can connect to the RPi from outside my network.
All my Wifi devices connect to the MQTT broker without issue, But i cannot SSH into the PI.
No idea why, did anyone work out what it was?
Ever since day 1 with OpenHAB I‘m experiencing random complete disconnects of my Raspi 3B+ (running Docker / OpenHAB) from ethernet (no link anymore) after a couple of days or weeks.
What‘s odd:
- When this happens, the Raspi seems to be still running fine (headless) but the Ethernet LEDs are completely off (even when I unplug / reconnect the network cable).
- When this happens, the only thing that helps is a reboot. Afterwards everything is fine again.
- I changed the Ethernet cable already.
- I already did a fresh install of everything.
- Power supply also looks fine though.
Any clues?
I would try:
- Running openHABian to confirm that docker isn’t the issue.
- Trying a USB ethernet adapter. This doesn’t tell you where the actual problem is (could still be hardware or software), but might be the simplest fix.
Thanks. Will try switching hardware (at least what’s not been changed).
Btw: My logs show the following readings when the link went down / the Raspi NIC LEDs are switched off:
Jul 6 07:57:01 raspberrypi dhcpcd[588]: eth0: carrier lost
Jul 6 07:57:01 raspberrypi dhcpcd[588]: eth0: deleting route to 192.168.0.0/24
Jul 6 07:57:01 raspberrypi dhcpcd[588]: eth0: deleting default route via 192.168.0.1
Jul 6 07:57:01 raspberrypi avahi-daemon[404]: Withdrawing address record for 192.168.0.150 on eth0.
Jul 6 07:57:01 raspberrypi avahi-daemon[404]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.150.
Jul 6 07:57:01 raspberrypi avahi-daemon[404]: Interface eth0.IPv4 no longer relevant for mDNS.
Jul 6 07:57:02 raspberrypi avahi-daemon[404]: Got SIGHUP, reloading.
Jul 6 07:57:02 raspberrypi avahi-daemon[404]: No service file found in /etc/avahi/services.
Does this look familiar to anyone?
I usually try googling specific phrases in error messages. In this case, I tried “Withdrawing address record for 192.168.0.150 on eth0”.
This result suggests switching to a static IP (I assume from the router).
This epic Ubuntu bug report/discussion includes a few theories, and spans from May 2016 until January 2022.
Whatever the case, it sounds like an OS issue and not a hardware fault.
Thanks a lot for the hint, @rpwong. Will try switching to a static IP address on the Raspi.
And yes, I did spend endless hours on finding a solution on this on the net, though it hasn’t crossed my mind that I might be looking at a potential bug or edge case that could potentially be solved via a static IP address.
1 Like
I’m not sure I would have thought of a static IP address either.
I reserve IPs for all of my RPis and IoT devices, for no reason other than I needed to years ago when I was using an Android app called Automation Manager to control my Kasa switches. Now I just do it out of habit.
What’s odd: Even with a static IP address I got exactly the same behavoir after a couple of days (deactivated ethernet adapter / dead ethernet LEDs) and the same log entries in syslog:
Jul 12 08:24:01 raspberrypi dhcpcd[579]: eth0: carrier lost
Jul 12 08:24:01 raspberrypi dhcpcd[579]: eth0: deleting route to 192.168.0.0/24
Jul 12 08:24:01 raspberrypi dhcpcd[579]: eth0: deleting default route via 192.168.0.1
Jul 12 08:24:01 raspberrypi avahi-daemon[406]: Withdrawing address record for 192.168.0.150 on eth0.
Jul 12 08:24:01 raspberrypi avahi-daemon[406]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.150.
Jul 12 08:24:01 raspberrypi avahi-daemon[406]: Interface eth0.IPv4 no longer relevant for mDNS.
Jul 12 08:24:02 raspberrypi avahi-daemon[406]: Got SIGHUP, reloading.
Jul 12 08:24:02 raspberrypi avahi-daemon[406]: No service file found in /etc/avahi/services.
In case someone has an idea, it would be highly appreciated, since I’m fighting with this behavior for months now.
Do you have anything using the USB ports on your raspberry pi?
My rpi3 has been crashing randomly for years and for me it looks like the USB ports become unavailable which disconnects my SSD. I believe the ethernet port shares the USB bus.
My problems started when I added a zwave stick and got worse the more things I connected to the USB ports.
Ha, good point. I am indeed using a z-wave and a wmbus stick.
What I’m currently trying out now (as said, I’ve tried out many things over the months) is
dtparam=eee=off
in /boot/config.txt in an attempt to make sure that it’s not related to some energy saving problem. Because, and I find this very peculiar, the Raspi keeps running like normal, but just the Ethernet device appears to be completely deactivated (as said, both LEDs on the port, link and activity, are dark).
Update: After having had this problem for over a year now, setting his parameter seems to have solved the problem (at least for now, t+11 days). Finally!
Update 2: Not so fast: Problem is back. Raspi is again not reachable, with the Ethernet LEDs being of until a reboot. So also the second potential fix related to the power saving did solve it. So probably not related to a power savings problem.
1 Like
Interesting thread, I’m having similar problems with my raspberry 4 setup (docker, openhab, zwave, external SSD) as well.
The system is running unstable and I wasn’t able to determine the cause. I’m stressing the little box to the edge, I must say: there’s openhab, nextcloud, a mysql db, mosquitto and a reverse proxy with Let’s Encrypt running …
I’m using the hardware watchdog to reboot the server and recently added a test for the network interface as well. Since then - fingers crossed - the box gets restarted without manual intervention.
I’ve had strange lockups of the box before where the watchdog didn’t trigger. The system was unreachable over ethernet, manual intervention didn’t work as well (keyboard, connected via USB).
Using the watchdog to restart the box almost daily isn’t a solution, I’d like to migrate some services to new raspberries, but that’s a different problem at the moment …
When I started with OpenHAB some time back, I had lots of problems with “system not reachable anymore”. As it turned out, I was looking at a bunch of root causes, which I managed to find and solve one after another, except for the one described above, which still drives me nuts (will open a thread in the official Raspberry forum soon).
Root causes I did find and fix:
- Spontaneous freezes 1: SD card broken. Classic. I managed to find traces in the logs that led me to the culprit, though “green Raspi LED stuck being on” was also a good hint which I could’ve understood earlier.
- Spontaneous feeezes 2: Swap too small. My setup also stresses the little box a lot. In the end, the systeminfo binding led me to the idea that “full swap” had something to do with it. Could be solved pretty easily.
- Spontaneous “deactivated Ethernet”: As said, still no clue. Have tried many things so far…
Update: For those who’d like to follow / face similar problems: I did open a new thread in the Raspberry forum, since I believe I’m looking at a Raspi-specific problem (rather than an openHAB or Docker-specific problem).