Hallo Community
mit meiner neuen DIY Anlage habe ich folgendes Problem: Ich habe einen Cerbo GX MKII, mittlerweile aktualisiert auf V3.41, welcher im LAN und WLAN periodisch (ca 4mal/Stunde) für knapp 2 Minuten nicht erreichbar ist. Während dieser Zeit kann natürlich die Batterie weder geladen noch entladen werden. Der LAN Anschluss hört auf zu blinken, ebenso am Switch. Andere Geräte am gleichen Switch laufen weiter. Während dieser Zeit ist weder ein Ping auf das LAN noch auf das WLAN Interface möglich. Nach dieser Zeit ist der Cerbo wieder erreichbar und das System mit MultiPlus-II und DIY Akku funktioniert wieder. Bis zum nächsten Stillstand …
Wer hat dazu Ideen?
Danke
Bernhard
Normalerweise hat die Erreichbarkeit im LAN keinen Einfluss auf die Funktionalität des Systems. Oder ist bei dir das BMS und das Gridmeter per LAN angebunden?
Danke für die Antwort!
Nachtrag: Als Gridmeter verwende ich ein Shelly 3EM, also über WLAN. Dieses ist im Cerbo eingebunden und aktualisiert sich auch regelmäßig - solange Verbindung bestellt.
Der Akku mit JK BMS ist über das Original-Kabel Typ A über Can Bus angebunden - ebenfalls im Cerbo ersichtlich
Hast Du im Cerbo spezielles programmiert? Nicht das LOgfiles das voll machen…
Benutzt Du die Fritzbox ??? Evtl. beim WLAN die Kanäle 12+13 sperren… manche Geräte mögen die nicht.
Sicher, dass der Cerbo das LAN/WLAN Problem hat und nicht der Shelly 3EM?
Wenn der 3EM im Zählerschrank eingebaut ist, kann der Schrank das WLAN ziemlich abschirmen.
Wie ist der Cerbo an dein Netzwerk angeschlossen? LAN-Kabel oder WLAN? Beides wäre unnötig oder sogar der Fehler.
Danke für eure Inputs!
- Es sind noch weitere Shellys integriert. Logfiles sind jeweils nur wenige MBs => habe alle gelöscht
- Router ist eine Fritz.Box 7530AX
-
- Shelly 3EM aktualisiert sich permanent im iobroker und in der Shelly App
- Cerbo hing per LAN und per WLAN drin => WLAN deaktiviert und schon wieder rausgeflogen
Hm, vielleicht eine doppelt vergebene IP Adresse?
LAN und WLan gleichzeitig ist kein Problem, läuft bei mir über ein Jahr an einer 7590AX. Habe aber beides mit statischen Adressen eingerichtet.
Hi @MrBS
Are you sure the Cerbo is not rebooting / restarting in those 2 minutes?
You have a quite high CPU usage and I can bet the Cerbo may get restarted by its watchdog…
The first load average is 9 and I know that by default the Cerbo is set at 6 to reboot.
You’re not the first one with Shelly and having problems and as you can see, more than 50% of the CPU time is spent on the Shelly drivers…
Hi Alex,
this sounds logical! I try to uninstall theShellys using the included uninstall.sh. After I rebooted, the shellys are still running and the cpu load is still over 80%.
What is the the best way to uninstall the shellys?
Thanx
You don’t need a physical uninstall.
You should first try to disable its run at boot and see if it’s OK.
For that go to the /service folder and find shelly’s folder.
In that folder you’ll find a file named run.
Modify that file’s attribute / properties and remove the executable flag (0644) for all users.
Reboot and you should be OK.
For undo it just put back the executable attributes (0755) and reboot.
But beware, shelly being an integral part of the system, the system or some of its subsystems may not function correctly after that…
@alexpescaru
Thank you again for your support!
Unfortunatelly I’m not a Linux Pro, so it is not to easy for me to work on the shell
The unsinstall.sh looked like this:
#!/bin/bash
SCRIPT_DIR=$( cd – “$( dirname – “${BASH_SOURCE[0]}” )” &> /dev/null && pwd )
SERVICE_NAME=$(basename $SCRIPT_DIR)
rm /service/$SERVICE_NAME
kill $(pgrep -f ‘supervise dbus-shelly-1pm-pvinverter’)
chmod a-x $SCRIPT_DIR/service/run
$SCRIPT_DIR/restart.sh
After running, nothing happened! So I thought it’s a good idea to replace
dbus-shelly-1pm-pvinverter
to
dbus-shelly-1pm-pvinverter01
After running, I noticed it disapeared at the top view
But when I rebooted, it was back again
Not a good idea to start renaming things. The system has some redundancies in place.
Activate Superuser access level in Cerbo. Settings - General - Access level.
Set a root password.
Activate SSH on LAN.
Download WinSCP.
Define a new site, SFTP protocol, Port number 22, your Cerbo IP at Host name, root at User name, above set password at Password.
Login and have fun becoming a Linux Pro…
Renaming was only, because of the unsinstall.sh did not work. The other stepps I did already:
Activate Superuser access level in Cerbo. Settings - General - Access level.
Set a root password.
Activate SSH on LAN.
Download WinSCP.
Define a new site, SFTP protocol, Port number 22, your Cerbo IP at Host name, root at User name, above set password at Password.
Login
But still don’t feel like a Pro
But again: Is there a way to completly remove the installed files?
Normally the uninstall script should also do what I’ve told you about modifying file attributes.
For service start:
Try to verify if in the /service folder it’s another subfolder named dbus-shelly-1pm-pvinverter
Go to that subfolder and see if inside it’s a run file.
Go to that file and bring up the file’s properties.
Uncheck all “X” attributes.
Reboot.
For installed files:
The main files, from what I know are in the /data folder, in order to not get deleted during firmware upgrade.
ok, looks like the problem is solved? The Shelly-PM subdirectories are deleted?
root@einstein:/service# ls
can-bus-bms.vecan0 dbus-shelly-3em-smartmeter nginx vedirect-interface.ttyS7
dbus-acsystem dbus-systemcalc-py openssh venus-access
dbus-adc dbus-tempsensor-relay ppp venus-button-handler
dbus-ble-sensors dbus-vebus-to-pvinverter serial-starter venus-html5-logger
dbus-digitalinputs flashmq service-advertiser venus-platform
dbus-fronius hub4control simple-upnpd vesmart-server
dbus-generator-starter llmnrd ssh-tunnel vrmlogger
dbus-modbus-client localsettings start-gui websockify-c
dbus-parallel-bms mk2-dbus.ttyS4 vecan-dbus.vecan1
dbus-pump mqtt-rpc vedirect-interface.ttyS5
dbus-shelly netmon vedirect-interface.ttyS6
root@einstein:/service#
Looks like I’m save again. CPU load is now not more than 20%
Although the problem with the restarts seems to be solved, remember what I’ve said before:
Shelly could be an integral part of the system and when its drivers are removed, the system or some of its subsystems may not function correctly after that…
Bitte in deutsch antworten, da dies extra ein deutschsprachiges Forum ist, ansonsten kann man sich die Unterteilung auch sparren.
Eine Übersetzung mit Google dauer 5s.
Please answer in German, as this is a German-language forum, otherwise you can save yourself the trouble of dividing things up.
A translation with Google takes 5 seconds.
Bitte bleiben Sie beim Thema und denken Sie daran, dass wir alle ein gemeinsames Interesse haben.
Danke.
(Google-Übersetzung)