FHEM Forum

Aktueller Status siehe Post #18

Hallo zusammen,

nachdem mein FHEM immer größer geworden ist (ca. 200 Sensoren/Aktoren) wird dem RasPi 4 die Last allmählich zu groß, sprich die Auslastung ist ziemlich am Anschlag.

Deshalb will ich nun auf den leistungsstärkeren RasPi 5 umsteigen.

Da ich im Laufe der Jahre eine Menge Dinge auf dem RasPi installiert habe von denen ich mit Sicherheit nicht mehr genau weiß was genau und wie habe ich bisher jedes Update HW/SW ohne Neuinstallation bewerkstelligt. Das war zwar immer ein Riesenaufwand und hat mich schon damals einige Nerven gekostet, hat am Ende aber immer geklappt und alles hat wie vorher funktioniert. Deswegen wollte ich das auch diesmal wieder so machen. Nachdem ich nun schon fast zwei Wochen in die Migration per Update gesteckt hatte mußte ich Heute einsehen daß das diesmal wohl nicht funktioniert. Dafür reichen meine Linux-Kenntnisse einfach nicht aus.

Mein bisheriges Vorgehen:

• einen Klon von der M2-SSD auf eine SD-Karte gezogen und einen zweiten RasPi 4 damit bestückt
  ==> OK, RasPi bootet und FHEM funktioniert
• das Upgrade auf Bookworm durchgeführt
  ==> viel Arbeit, aber am Ende OK, RasPi bootet und FHEM funktioniert
• versucht mit dieser SD-Karte den RasPi 5 zu booten
  ==> gescheitert, weil der RasPi 5 einen neueren Kernel benötigt
  ==> alle Versuche den Kernel zu upgraden sind fehlgeschlagen, bzw. gefundene Lösungsansätze überfordern meine Kenntnisse

Heute habe ich dann den Entschluß gefaßt es doch mit einer kompletten Neuinstallation zu versuchen, aber wie ich schon befürchtet hatte nahm die Katastrophe auch hier ihren Lauf und ich war sehr schnell
wieder am Ende.

Das habe ich bisher gemacht:

• 64Bit RasPi-Image auf die Nvme-SSD des RasPi 5 geflasht
  ==> OK, RasPi bootet
• FHEM-Backup generiert, vom laufenden System (alter RasPi 4)
• nach dieser (https://internet-artikel.de/fhem-installieren-update-upgrade-backup-restore) Anleitung das FHEM-Backup auf den neuen RasPi 5 zurückgespielt
  ==> das scheint auch soweit funktioniert zu haben (keine Fehlermeldungen)
  ==> Nach dem Reboot war es aber vorbei, FHEM startet nicht

Der erste Anhaltspunkt den ich habe ist die Ausgabe vom "systemctl status fhem":× fhem.service - FHEM Home Automation    Loaded: loaded (/etc/systemd/system/fhem.service; enabled; preset: enabled)    Active: failed (Result: exit-code) since Thu 2024-04-25 19:54:27 CEST; 7s ago  Duration: 328ms    Process: 2021 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)  Main PID: 2023 (code=exited, status=255/EXCEPTION)        CPU: 449msApr 25 19:54:27 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 5.Apr 25 19:54:27 raspberrypi systemd[1]: Stopped fhem.service - FHEM Home Automation.Apr 25 19:54:27 raspberrypi systemd[1]: fhem.service: Start request repeated too quickly.Apr 25 19:54:27 raspberrypi systemd[1]: fhem.service: Failed with result 'exit-code'.Apr 25 19:54:27 raspberrypi systemd[1]: Failed to start fhem.service - FHEM Home Automation.Das ist jetzt der Stand. Meine bisherigen Recherchen haben mich leider noch nicht weitergebracht und ich stehe ja erst beim 1. Schritt der Neuinstallation. Ich muß auch noch die pivccu3 installieren und einige andere Dinge. Wer weiß welche Katastrophen mich da noch alle erwarten.Ich bin echt mal wieder frustriert und hoffe nun auf Eure Hilfe (zur Selbsthilfe).GrüßeBernd[/list]

Guten Morgen Bernd,

da wären die letzten Zeilen im FHEM Log interessant, hier (https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Die_letzen_Zeilen_im_existierenden_FHEM_Log_anzeigen) steht wie Du da ran kommst

Wahrscheinlich hast Du die Voraussetzungen für einige Module nicht installiert.
Wenn Du keine Doku dazu hast, kannst Du auf deinem alten System auch nachschauen. Hier (https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html) habe ich mal aufgeschrieben wie es geht.

Gruß Otto

Guten Morgen Otto,

vielen Dank für die schnelle Antwort.

anbei die letzten log-Einträge:
2024.04.26 00:57:38.858 1:    (eval)                              called by fhem.pl (2763)
2024.04.26 00:57:38.858 1:    (eval)                              called by fhem.pl (2762)
2024.04.26 00:57:38.858 1:    main::CommandReload                called by fhem.pl (2065)
2024.04.26 00:57:38.858 1:    main::LoadModule                    called by ./FHEM/10_TASMOTA_DEV      ICE.pm (70)
2024.04.26 00:57:38.858 1:    main::TASMOTA_DEVICE_Initialize    called by fhem.pl (2779)
2024.04.26 00:57:38.858 1:    (eval)                              called by fhem.pl (2762)
2024.04.26 00:57:38.858 1:    main::CommandReload                called by fhem.pl (2065)
2024.04.26 00:57:38.858 1:    main::LoadModule                    called by fhem.pl (2130)
2024.04.26 00:57:38.858 1:    main::CommandDefine                called by fhem.pl (1278)
2024.04.26 00:57:38.858 1:    main::AnalyzeCommand                called by fhem.pl (1129)
2024.04.26 00:57:38.858 1:    main::AnalyzeCommandChain          called by fhem.pl (1417)
2024.04.26 00:57:38.858 1:    main::CommandInclude                called by fhem.pl (628)
2024.04.26 00:57:38.858 1: reload: Error:Modul 10_MQTT_DEVICE deactivated:
 Can't continue after import errors at ./FHEM/10_MQTT_DEVICE.pm line 74.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_DEVICE.pm line 89.

2024.04.26 00:57:38.858 0: Can't continue after import errors at ./FHEM/10_MQTT_DEVICE.pm line 74.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_DEVICE.pm line 89.

Undefined subroutine &MQTT::Client_Define called at ./FHEM/10_TASMOTA_DEVICE.pm line 127.
Da ergibt sich ja schonmal ein Hinweis, aber wie kann ich denn nun dieses "fehlerhafte/veraltete" Modul updaten?

anbei auch noch das beanstandete Modul:10_TASMOTA_DEVICE.pm

Wo kommt denn das Modul 10_TASMOTA_DEVICE.pm her? :o
Standard ist das nicht bzw. deprecated...
https://github.com/klein0r/fhem-tasmota/blob/master/README.md

Hi,

ich hab das gerade gefunden. Das wird für die SonOff-Bridge benutzt, die ich aber zur Zeit nicht verwende. Von daher könnte ich das auch löschen, oder updaten (wie?).
keine Ahnung woher das kommt. Ich habe viele Tasmota-Geräte integriert, aber eigentlich alle per MQTT2. Ich kann mal in alten Backups suchen wann das installiert wurde. Vielleicht ist das ja auch unnötig, dann lösche ich es einfach. Bisher hat es aber offensichtlich nicht gestört.

Das zweite "fehlerhafte" Modul 10_MQTT_DEVICE.pm habe ich nicht gefunden. Ich verwende ja eigentlich nur MQTT2. Evtl. ist das auch nur ein Uralt-Überbleibsel und kann auch gelöscht werden.

Ich werde beide einfach mal löschen und schauen was passiert. Melde mich dann wieder.

10_MQTT_DEVICE.pm braucht das cpan Modul  Net::MQTT.
MQTT2 braucht vielleicht eher 10_MQTT2_DEVICE.pm

Nachdem ich die beiden fehlerhaften/veralteten Module 10_TASMOTA_DEVICE.pm und 10_MQTT_DEVICE.pm entfernt hatte ging es mit den Fehlermeldungen erst richtig los.

Jetzt hat er Fehler zur JeeLink und zur pivccu3 Installation ausgespuckt.

Daraufhin habe ich dann die pivccu3 nach dieser (https://technikkram.net/blog/2019/07/14/pivccu3-umstieg-homematic-auf-den-neuen-raspberry-pi-4/) Anleitung neu installiert. Ich weiß, das ist eine Anleitung für den Pi4, aber etwas anderes habe ich nicht gefunden. Die Installation ist auch problemlos durchgelaufen.

Nach einem Neustart gibt es nun diese Meldungen im log:
2024.04.26 12:02:55.852 1:
myJeeLink: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0: No such file or directory

2024.04.26 12:02:56.475 1:
reload: Error:Modul 88_HMCCU deactivated:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/aarch64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.

2024.04.26 12:02:56.475 0:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/aarch64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 136, <$fh> line 4353.

2024.04.26 12:02:56 3:
[UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)

2024.04.26 12:02:57.008 1:
Including fhem.cfg

2024.04.26 12:02:57.217 1:
myJeeLink: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0: No such file or directory

2024.04.26 12:02:57.777 1:
reload: Error:Modul 88_HMCCU deactivated:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.36.0 /usr/local                                               /share/perl/5.36.0 /usr/lib/aarch64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_p                                               erl ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.

2024.04.26 12:02:57.777 0:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/aarch64-linux-                                               gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/aarch64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.36 /usr/share/perl/                                               5.36 /usr/local/lib/site_perl ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36, <$fh> line 4340.

Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 136, <$fh> line 4353.

Ich habe keine Ahnung wie ich das alles fixen soll. Ich suche weiter im Netz, aber im Moment sehe ich schwarz.

Zitat von: Guzzi-Charlie am 26 April 2024, 14:34:10Can't locate RPC/XML/Client.pm

Du musst das entsprechende Perl Modul installieren.
Geht wahrscheinlich mit dem debian Paket librpc-xml-perl.
sudo apt install librpc-xml-perl

Zitat von: Guzzi-Charlie am 26 April 2024, 14:34:10Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0

Der Stick fehlt, bzw gab es Änderungen mit der Zuordnung /dev/serial/by-id/ bzw. gab es dann eine Rechte Änderung in Bookworm. Was gibt Dir im Terminal das zurück?
ls -lha /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0Vermutung: Du musst den User fhem in die Gruppe plugdev tun.
sudo usermod -a -G plugdev fhemEdit: das war Unfug
sudo addgroup fhem plugdev

Zitat von: Guzzi-Charlie am 26 April 2024, 14:34:10Die Installation ist auch problemlos durchgelaufen.

Aber läuft denn die piVCCU auch so wie sie soll? ???

Hallo Otto,

das Installieren der librpc-xml-perl hat funktioniert UND hat den ersten Erfolg gebracht!!

• FHEM hat jetzt gestartet und das WEB-IF läßt sich öffnen und bedienen.
• Die Hauptfehlermeldung im log ist im Moment:
  FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:0A00009C:SSL routines::http request (peer: 192.168.178.15) <-- das ist mein PC
• die Meldung wegen des fehlenden JeeLink-Sticks ist korrekt. Der steckt im Moment ja noch am Produktiv-System, kann ich aber mal umstecken.
• die Zuweisung von fhem zur Gruppe plugdev hat so erstmal nicht funktioniert. Da kam folgende Fehlermeldung:
  addgroup: addgroup with two arguments is an unspecified operation.
• die piVCCU läuft, allerdings noch ohne Inhalt. Da muß ich erstmal schauen wie ich da ein Backup vom Produktiv-System erstellen und wie ich das dann einspielen kann.

Jetzt sehe ich wenigstens etwas Licht am Ende des Tunnels. Ich habe aber vermutlich noch einiges zu tun. Ich muß noch fhempy module und Modbus-Schnittstellen wieder in Gang bringen.

Zitat von: Guzzi-Charlie am 26 April 2024, 18:09:34die Zuweisung von fhem zur Gruppe plugdev hat so erstmal nicht funktioniert. Da kam folgende Fehlermeldung:

Weil das Unfug war, ich habe das ohne zu prüfen aus einem anderen Beitrag kopiert. Ich habe den Beitrag editiert. Aber Du musst das nicht tun, wenn es nicht das Problem ist!!!

Zitataddgroup [--gid ID] GRUPPE
   Eine Benutzergruppe hinzufügen

addgroup --system [--gid ID] GRUPPE
   Eine Systemgruppe hinzufügen

adduser BENUTZER GRUPPE
   Einen existierenden Benutzer einer existierenden Gruppe hinzufügen

So, bin wieder ein Stück weiter und gleichzeitig ein kleinen Schritt zurück:

• das Backup der piVCCU konnte ich (vermeintlich) erfolgreich einspielen.
  Ein paar Geräte sind noch offline, aber das dauert ja immer eine ganze Zeit. Außerdem ist der RF-Stick jetzt nicht mehr zentral im Haus. Damit haben einige Geräte wahrscheinlich keinen Empfang.
• die Meldung des JeeLink im Log ist auch weg. Der steckt jetzt auch am neuen PI 5
• Allerdings komme ich gerade nicht auf das FHEM WEB-IF, keine Ahnung warum? Da hatte ich ja schonmal Verbindung, allerdings hatte es auch da schon öfters "Connection Lost" gemeldet
  Wo kann ich denn nachschauen woran das liegt?
• Die aktuellen Fehlermeldungen im Log sind:
  
  Code Auswählen Erweitern
  setuuid: Please define BridgeSonoff first
-> das liegt am gelöschten Tasmota-Modul und ist erstmal unwichtig
Cannot load module SIP
setuuid: Please define FHEM_SIP1 first
Cannot load module SIP
setuuid: Please define FHEM_SIP2 first
Cannot load module SIP
setuuid: Please define FHEM_SIP3 first
-> die SIP-Funktionen benutze ich im Moment auch nicht, also auch unwichtig
Cannot load module BindingsIo
setuuid: Please define fhempy_local first
-> das brauche ich und muß ich wohl nachinstallieren, schaue ich gerade wie.
SecurityCheck:
  telnetPort is not password protected
  MQTT2_FHEM_Server is not password protected

Protect this FHEM installation by configuring the allowed device allowed_WEB
You can disable this message with attr global motd none
Autosave deactivated
2024.04.26 19:30:47.223 1: Modbus_KG: Can't open /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0: No such file or directory
-> der USB-Stick steckt am Produktivsystem
2024.04.26 19:30:47.224 1: Modbus_KG2: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_B001BIRB-if00-port0: No such file or directory
-> der USB-Stick steckt am Produktivsystem
2024.04.26 19:30:47.235 0: HMCCU [d_piccu3] Scheduling post FHEM initialization tasks in 12 seconds
-> ???
2024.04.26 19:30:47.309 1: usb create starting

Zitat von: Guzzi-Charlie am 26 April 2024, 20:07:302024.04.26 19:30:47.309 1: usb create starting

wenn er hier stirbt, dann solltest Du initialUsbCheck ausschalten ;)
Aber eigentlich solltest Du das schon immer aus haben, heisst sollte in deinem Backup drin gewesen sein.
Da jetzt nix geht: usb Sticks rausziehen
neustarten
attr initalUsbCheck disable 1oder
delete initalUsbCheck Danach save und USb Sticks wieder dran und neustart.

Und ich hoffe Du bist am mitschreiben!!! ;D

Ich sehe gerade daß FHEM in der "top"-Anzeige mit 100% läuft. Da scheint also was noch nicht zu stimmen.

Ich hatte mir ja vom Umstieg auf den RasPi 5 mindestens eine Halbierung der Last versprochen.
Wenn FHEM auf meinem aktuellen System RasPi 4 zwischen 90 und 100% ausgelastet ist, dann habe ich manchmal auch Schwierigkeiten auf das WEB-IF zuzugreifen.

auch das spricht für initialUsbCheck aus :)

Das hat wohl tatsächlich das System blockiert. Jetzt sind es nur noch < 1%.
Auf das WEB-IF komme ich aber trotzdem nicht.

Was steht im Log?
Port und IP richtig?
ss- lntuDa war ne HTTPS Fehlermeldung? Du hast dein Web auf HTTPS gehabt?

Jetzt hat es mir gerade meinen Kommentar beim Abschicken ins Nirwana geschickt weil Du gerade in dem Moment geantwortet hattest.

Also nochmal:

• ich habe den initialUsbCheck in der fhem.cfg per attr disabled
• die USB-Sticks wieder angesteckt
• den RasPi rebooted
• piVCCU läuft
• FHEM läuft auch (lt. "top") mit ca. 2-5% CPU-Last
• Oh Mann, guter Hinweis, es geht NUR mit https, d.h. ich komme jetzt auch wieder auf das WEB-IF
• aktuelle Fehlermeldungen:
  
  Code Auswählen Erweitern
  2024.04.26 21:01:07.232 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:0A000416:SSL routines::sslv3 alert certificate unknown (peer: 192.168.178.15)
2024.04.26 21:01:09.833 1: myJeeLink: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0: Permission denied

Ich werde dann am WE versuchen den restlichen Kram zu finden/nachzuinstallieren und dann melde ich mich wieder.

Morgen muß ich erstmal (wenn, wie vorhergesagt das Wetter schön wird) draußen arbeiten und einen Balkon abbauen um dann nächste Woche ein Garagendach (Flachdach) neu abdichten zu können.

Erstmal vielen, vielen Dank für die Unterstützung. Durch Dich habe ich Heute mehr erreicht als in den ganzen zwei Wochen davor. Jetzt bin ich wieder zuversichtlich das der Umstieg auf den RasPi 5 doch klappt und ich den vielleicht nächste Woche produktiv schalten kann und dann hoffentlich meine ganzen Performance-Probleme erledigt sind.

Hallo,

inzwischen habe ich FHEM auf dem neuen RasPi 5 produktiv geschaltet. Grundsätzlich scheint es zu funktionieren.

Es gibt aber noch ein paar Sachen die nicht funktionieren.

Hier die Fehlermeldungen aus dem FHEM-log (nach Neustart):

• 2024.04.28 12:48:29.805 1: myJeeLink: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0: Permission denied
  -> fehlende Rechte? -> erledigt
• 2024.04.28 12:48:33.885 1: IEC1107_rs485: Can't connect to 192.168.0.83:20108: Network is unreachable
  -> keine Ahnung woher diese IP kommt und ob das überhaupt relevant ist.
• 2024.04.28 12:48:33.906 1: IEC1107_rs485: cannot open file /fhem/trunk/fhem/drs110m.classdef for class drs110m.
  -> solch ein Directory/file gibt es auch in der alten Installation nicht
• 2024.04.28 12:48:34.195 1: reload: Error:Modul 10_BindingsIo deactivated:
  -> das Modul 10_BindingsIo ist in der neuen Installation am gleichen Ort wie in der alten Installation vorhanden  -> erledigt
  Can't locate Protocol/WebSocket/Frame.pm in @INC (you may need to install the Protocol::WebSocket::Frame module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/aarch64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl ./FHEM/lib) at ./FHEM/10_BindingsIo.pm line 10, <$fh> line 11386.
  BEGIN failed--compilation aborted at ./FHEM/10_BindingsIo.pm line 10, <$fh> line 11386.
• 2024.04.28 12:48:34.813 1: define FL_PV_WR_T41 FileLog %L/PV-WR-T41_%Y-%m.log PV_WR_T41:active_power.*|PV_WR_T41:back_up.*|PV_WR_T41:battery_mode.*|PV_WR_T41:error_codes.*|PV_WR_T41:grid_mode.*|PV_WR_T41:hours_total_h.*|
  PV_WR_T41:house_consumption_W|PV_WR_T41:inverter.*|PV_WR_T41:load.*|PV_WR_T41:meter_active.*|PV_WR_T41:meter_l.*|PV_WR_T41:mppt1.*|PV_WR_T41:mppt2.*|PV_WR_T41:mppt3.*|
  PV_WR_T41:on_grid_l.*|PV_WR_T41:pExport_kWh|PV_WR_T41:pImport_kWh|PV_WR_T41:pv1.*|PV_WR_T41:pv2.*|PV_WR_T41:pv3.*|PV_WR_T41:pv_.*|PV_WR_T41:rssi|PV_WR_T41:speicherverluste|
  PV_WR_T41:today_.*|PV_WR_T41:total_.*|PV_WR_T41:ups.*|PV_WR_T41:work_mode:
  Can't open /opt/fhem/log/PV-WR-T41_2024-04.log: Permission denied
   -> fehlende Rechte?  -> erledigt
• 2024.04.28 12:48:38.601 1: Modbus_KG2: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_B001BIRB-if00-port0: Permission denied
   -> fehlende Rechte? -> erledigt
• 2024.04.28 12:48:38.701 1: usb create starting
  2024.04.28 12:48:45.985 1: TCM_ESP3: Can't open /dev/ttyUSB0: Permission denied
  2024.04.28 12:48:45.986 1: TCM_ESP3: Can't open /dev/ttyUSB1: Permission denied
  2024.04.28 12:48:45.999 1: usb create end
   -> erledigt
• 2024.04.28 12:48:48.426 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:0A000126:SSL routines::unexpected eof while reading (peer: 192.168.178.128)
  -> das ist die Verbindung zu meinem Loxon MiniServer Go
• 2024.04.28 12:48:48.494 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:0A000416:SSL routines::sslv3 alert certificate unknown (peer: 192.168.178.15)
  2024.04.28 12:48:48.582 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:0A000126:SSL routines::unexpected eof while reading (peer: 192.168.178.128)

Die Fehler 8. und 9. wiederholen sich dann ständig

Hi,

trotz schönem Wetter :)
Du musst

• Dein SSL bereinigen / wieder richtig konfigurieren / alte Zertifikate installieren
• Die Berechtigung der seriellen Schnittstellen prüfen und den Benutzer fhem eventuell in die richtige Gruppe stecken (siehe #7)
• Du musst die Berechtigungen der Dateien prüfen und die ev. Korrigieren chown -R fhem: /opt/fhem
• Du musst die fehlende Software nachinstallieren (Can't locate Protocol/WebSocket/Frame.pm in @INC (you may need to install the Protocol::WebSocket::Frame module) )
• Bi 2 und 3 fällt mir nichts ein.

Gruß Otto

Fehler 2+3:
Darum wird es gehen.
https://forum.fhem.de/index.php?topic=56171.0

Warum hast du nicht mit apt den Raspberry hochgezogen (Buster >> Bullseye >> Bookworm)?

Warum bist du nicht auf ein Barebone(Mini-PC) gewechselt mit N100 CPU z.B.?
Braucht am Ende nicht mehr Strom und du hast eine vernünftige Datenspeicheranbindung.Bei in Summe nicht viel mehr Geld für alles zusammen.
Man hat dann aber keine GPIO's. Wenn man die benötigt ist es doof.

Was war dein Grund für die Wahl auf einen Raspberry 5?

@Otto,

Danke für die schnelle Antwort, aber leider bringt mich das nicht weiter. Mit Deinen Antworten hast Du ja Recht, aber das WIE ist mein Problem.

Die Dateiberechtigungen hatte ich (vermeintlich) korrigiert, aber nach dem reboot ist alles wieder beim Alten.
Die Rechte standen auf pi:pi (5.) sowie auf root:root (1. und 6.) geändert hatte ich das (vermeintlich) mit "sudo chown  -hR fhem:dialout /dev/serial/by-id/"

Bin also im Moment kein Stück weiter.

@kask,

Zitat von: kask am 28 April 2024, 14:45:15

• Warum hast du nicht mit apt den Raspberry hochgezogen (Buster >> Bullseye >> Bookworm)?
  ==> Hatte ich ja erst versucht. Auf Bookworm bin ich auch gekommen, aber nicht mehr auf den RasPi 5 weil der einen anderen Kernel benötigt.
  ==> Weil es nicht funktioniert (siehe mein erster Post). Nach zwei Wochen habe ich aufgegeben
• Warum bist du nicht auf ein Barebone(Mini-PC) gewechselt mit N100 CPU z.B.?
  ==> Weil ich davon erst Recht keine Ahnung habe.
• Braucht am Ende nicht mehr Strom und du hast eine vernünftige Datenspeicheranbindung.Bei in Summe nicht viel mehr Geld für alles zusammen.
• Man hat dann aber keine GPIO's. Wenn man die benötigt ist es doof.
  ==> würde ich nicht benötigen.
• Was war dein Grund für die Wahl auf einen Raspberry 5?
  ==> Es ging nur um die Performance. Der RasPi 4 war am Anschlag.

Dann müssen wir detaillierter arbeiten, Du verstehst meine Anmerkungen falsch:
Was liefert Dir (Ausgabe bitte posten)
ls -lha /dev/ttyUSB*
ls -lha /dev/serial/by-id/
ls -lha  /opt/fhem/log/PV-WR-T41_2024-04.log
Für Fehler 4. musst Du das Paket libprotocol-websocket-perl installieren, ich hoffe Du weißt noch wie das geht?

Du kannst SSL für FHEMWEB erstmal deaktivieren und später wieder in Betrieb nehmen, FHEM Kommandozeile:
attr TYPE=FHEMWEB HTTPS 0Danach save

ls -lha /dev/ttyUSB*
crw-rw----+ 1 root plugdev 188, 0 Apr 28 15:45 /dev/ttyUSB0
crw-rw----+ 1 root plugdev 188, 1 Apr 28 15:45 /dev/ttyUSB1
crw-rw----+ 1 root plugdev 188, 2 Apr 28 15:45 /dev/ttyUSB2
crw-rw----  1 root dialout 188, 3 Apr 28 15:49 /dev/ttyUSB3
crw-rw----+ 1 root plugdev 188, 4 Apr 28 15:45 /dev/ttyUSB4

ls -lha /dev/serial/by-id/
total 0

drwxr-xr-x 2 root root 140 Apr 28 15:45 .
drwxr-xr-x 4 root root  80 Apr 28 15:45 ..
lrwxrwxrwx 1 root root  13 Apr 28 15:45 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root  13 Apr 28 15:45 usb-FTDI_FT232R_USB_UART_AK072UA9-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Apr 28 15:45 usb-FTDI_FT232R_USB_UART_AL006UL7-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root  13 Apr 28 15:45 usb-FTDI_FT232R_USB_UART_AR0JY0EF-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root  13 Apr 28 15:45 usb-FTDI_FT232R_USB_UART_B001BIRB-if00-port0 -> ../../ttyUSB4

ls -lha  /opt/fhem/log/PV-WR-T41_2024-04.log
==> hier hat die Änderung offensichtlich funktioniert
-rw-r--r-- 2 fhem dialout 112M Apr 27 11:40 /opt/fhem/log/PV-WR-T41_2024-04.log

Bei den Verzeichnissen ..by-id und ..by-path habe ich es gerade nochmal versucht. Ein List direkt nach der Änderung bestätigt die Änderung, aber nach dem reboot ist alles wieder wie vorher. 

Zitat von: Guzzi-Charlie am 28 April 2024, 15:56:12Bei den Verzeichnissen ..by-id und ..by-path habe ich es gerade nochmal versucht.

Ich habe nie gesagt: Du sollst dort die Berechtigungen ändern! Ich habe gesagt Du sollst den User fhem in die richtige Gruppe tun! Die hat sich bei Bookworm geändert!
sudo usermod -a -G plugdev fhemDanach FHEM neu starten!

Zitat von: Guzzi-Charlie am 28 April 2024, 15:56:12Bei den Verzeichnissen ..by-id und ..by-path habe ich es gerade nochmal versucht. Ein List direkt nach der Änderung bestätigt die Änderung, aber nach dem reboot ist alles wieder wie vorher. 

Dann musst Du doch irgendwann mal verstehen: Linux will das nicht  ;D  ;D  ;D

Ein fhem neustart wird vermutlich nicht reichen nach der aktion.
Man wird sich ausloggen müssen bzw. eine neue Session aufmachen müssen.
Zur Not ein reboot.

Zitat von: kask am 28 April 2024, 16:11:08eine neue Session aufmachen müssen.

Das tut der fhem.service beim Neustart ;)

ZitatDas tut der fhem.service beim Neustart

Da hast du vollkommen wahr. Ich war gedanklich noch auf der console.

Ein Besitzerwechsel von den Verzeichnissen /by-id/ und /by-path/ funktioniert nicht weil die nicht persistent sind.
Die Inhalte der Ordner werden erst angelegt wenn da Hardware ist. Und die wird erst beim booten frühestens erkannt oder beim einstecken.
Und dann wird der Inhalt dazu angelegt. Also sind die beiden Pfade immer ganz neu!
Wenn du das ändern müsstest dann mußt du woanders was abändern damit die Rechte beim einhängen der Devices anders veregben werden.
Aber das musst du nicht machen.
Nur mal als Info für dich warum das nicht geht und du da auch keine weitere Energie drinne verschenken must.

Ich hab fhem jetzt noch in die plugdev-Gruppe gehängt, aber der chown-Befehl hat scheinbar trotzdem was an den Berechtigungen geändert. Jedenfalls habe ich seitdem keine Fehlermeldungen dieser USB-Sticks mehr. Der List zeigt auch für alle Gruppen (Owner, Group, Sonstige) alle Berechtigungen an. Und fhem gehört ja wahrscheinlich auch zu "Sonstige", oder?

Jetzt habe ich nur noch die Fehlermeldung vom JeeLink-Stick, aber da ist vielleicht was anderes nicht ok. Das ist aber erstmal nicht so wichtig. Da suche ich später weiter.

Was jetzt noch wichtig ist, ist die Installation des Websocket Frame.pm Moduls. Sonst funktioniert mein fhempy nicht und ich kann die Hybrid-Wechselrichter und das E-Auto nicht abfragen. Ich habe auch schon gesucht, aber bisher nichts gefunden.

Zitat von: Guzzi-Charlie am 28 April 2024, 17:00:38Was jetzt noch wichtig ist, ist die Installation des Websocket Frame.pm (https://frame.pm/) Moduls.

Hast Du meinen Post nicht gelesen?  :o  Oder warum fragst Du so komisch? Oder funktioniert das nicht?
sudo apt install libprotocol-websocket-perl
Die Berechtigung bei /dev/serial/by-id/ ist völlig "egal", die Berechtigung bei /dev/ttyU* ist wichtig und da ist fhem jetzt in der plugdev Gruppe und damit funktioniert jetzt alles. Der chown Befehl hat daran nichts nachhaltig geändert.

Zitatlrwxrwxrwx 1 root root  13 Apr 28 15:45 usb-FTDI_FT232R_USB_UART_AK072UA9-if00-port0 -> ../../ttyUSB0
crw-rw----+ 1 root plugdev 188, 0 Apr 28 15:45 /dev/ttyUSB0

Sorry, hab ich was übersehen?
Hab das Websocket jetzt installiert.

• Die Websocket Fehlermeldung ist jetzt weg
• Fhempy funktioniert trotzdem noch nicht, aber ich glaube ich muß da noch was nachinstallieren. Das schaue ich gleich mal nach.
• Die USB-Sticks funktionieren jetzt alle, auch der JeeLink.
• Was jetzt noch fehlt sind die Punkte 2. und 3. Da muß ich nochmal nachforschen wie das damals (vor ca. 5 Jahren) installiert wurde

Zitat von: Guzzi-Charlie am 28 April 2024, 17:39:13wie das damals (vor ca. 5 Jahren) installiert wurde

ich wiederhole mich:
Und ich hoffe Du bist am mitschreiben!!! ;D sonst ist in 5 Jahren das Problem wieder da

Ja, diesmal habe ich alles aufgeschrieben, Danke.

Bei meinem ersten Ansatz (Update statt Neuaufsetzen) hatte ich das auch direkt gemacht und auch alle Abweichungen dokumentiert. Damit konnte ich das Update auch problemlos mehrmals wiederholen. Am Ende bin ich aber dann doch gescheitert, weil das s.g. Cross-Upgrade (mit Kernel-Wechsel) gar nicht geht oder das zumindest meine Fähigkeiten auf jeden Fall meilenweit übersteigt. Deshalb am Ende doch die Neuinstallation.

Am Ende war es dann doch nicht so aufwendig als gedacht (wenn die Fähigkeiten ausreichen) :)

Das fhempy-Binding konnte ich jetzt auch installieren. Jetzt müssen nur noch die Daten von den Wechselrichtern wieder kommen.

OK, das fhempy-binding konnte ich zwar jetzt in FHEM anlegen, aber funktionieren tut es leider nicht.

Es kommen die folgenden Fehlermeldung im log:
2024.04.28 18:07:25.258 1: fhempy_local: Can't connect to ws:127.0.0.1:15733: 127.0.0.1: Connection refused (111)
2024.04.28 18:07:25.258 1: BindingsIo (fhempy_local): ERROR during connection setup: 127.0.0.1: Connection refused (111)

Woran könnte das liegen? Wo könnte ich nachschauen? Die obskuren IP-Adressen scheinen aber richtig oder unwichtig zu sein. Das sieht im alten System genauso aus.

Von fhempy habe ich keine Vorstellung, da musst Du sicher im entsprechenden Unterforum einen Thread aufmachen.

Obskur sind die IP Adressen nicht, das ist Dein lokaler Host. Also fhempy will eine Verbindung zu einem Dienst öffnen, den er lokal auf deinem PC erwartet.
Vermutung: Du hast irgendeinen Dienst nicht installiert, irgendwas was damit etwas tut: "kann die Hybrid-Wechselrichter und das E-Auto nicht abfragen. "

Noch mehr geraten: Du musst einen fhempy Server installieren?
https://github.com/fhempy/fhempy

OK Otto,

ich Danke Dir nochmal vielmals.

Ich wende mich dann wg. fhempy an Dominik und wegen dem IEC-Problem an Cooltux.



Grüße und noch einen schönen Sonntagabend
Bernd

P.S.
Der fhempy-Server ist installiert. Was fehlte war das fhempy-Binding (BindingsIO). Offensichtlich reicht das aber noch nicht. Irgendetwas fehlt da noch.

kurzer Nachtrag:

fhempy funktioniert inzwischen auch wieder nachdem ich es komplett neu installiert hatte.

Jetzt fehlt nur noch die Anbindung der IEC1107-Geräte. Mal sehen wann sich Cooltux meldet.

Hallo Otto,

ich habe jetzt ein weiteres Problem. Meine Rolladensteuerung (mit Intertechno-Aktoren und IT-Gateway) funktioniert nicht mehr.

Gestern Abend hat es noch funktioniert und alle Rolläden sind heruntergefahren. Ich habe Gestern Abend HTTPS wieder eingeschaltet weil meine FHEMnative-Visu (warum auch immer) nur im HTTPS-Modus funktioniert. Ich bin mir allerdings nicht sicher ob ich das vor dem automatischen runterfahren der Rollos oder danach wieder aktiviert habe. Das sollte aber doch nichts miteinander zu tun haben, oder?

Das Ganze läuft über die bekannte Steuerung mittels Dummy, zugehöriges notify und Logikanteil in der 99_myUtils.

Dummy:
defmod dy_Roll_AZ dummy
attr dy_Roll_AZ alias Fenster (Süd)         
attr dy_Roll_AZ cmdIcon auf:Roll_AUF ab:Roll_ZU stop:Roll_STOP
attr dy_Roll_AZ devStateIcon auf:rc_BLANK ab:rc_BLANK stop:rc_BLANK
attr dy_Roll_AZ eventMap BI:auf B0:ab BS:stop
attr dy_Roll_AZ group OG.Arbeitszimmer
attr dy_Roll_AZ icon fts_shutter
attr dy_Roll_AZ room Rolläden,Obergeschoß
attr dy_Roll_AZ sortby 11
attr dy_Roll_AZ webCmd ab:auf:stop
notif:
defmod n_Roll_AZ notify dy_Roll_AZ:.* {\
    my $v=Value("dy_Roll_AZ");;\
    if ($v eq "auf") {rollo_az("auf")};;\
    if ($v eq "ab") {rollo_az("ab")};;\
    if ($v eq "stop") {rollo_az("stop")};;\
    }
Anteil in myUtils:
sub rollo_az {
 
 my ($state) = "$_[0]";
 my $pid = 0;


if ($state eq "auf")
 {

system("echo \"TXP:0,0,10,10920,91,42,0,57,18,8,4,4,8,4,8,4,8,8,4,4,8,8,4,8,4,8,4,8,4,4,8,8,4,8,4,4,8,4,8,4,8,4,8,8,4,4,8,4,8,8,4,4,8,4,8,4,8,8,4,8,4,8,4,8,4,8,4,4,8,4,8,4,8,4,8,4,8,4,8,8,4,4,8,4,8,4,8,8,120,0;\" | nc -u 192.168.178.121 49880 & pid=$! sleep 1 kill $pid 2>/dev/null >/dev/null");
}
 else
 {
    if ($state eq "stop")
    {
system("echo \"TXP:0,0,10,10920,91,42,0,57,18,8,4,4,8,4,8,4,8,8,4,4,8,8,4,8,4,8,4,8,4,4,8,8,4,8,4,4,8,4,8,4,8,4,8,8,4,4,8,4,8,8,4,4,8,4,8,4,8,8,4,8,4,8,4,8,4,8,4,4,8,4,8,4,8,4,8,8,4,4,8,8,4,4,8,8,4,4,8,8,120,0;\" | nc -u 192.168.178.121 49880 & pid=$! sleep 1 kill $pid 2>/dev/null >/dev/null");
    }
    else
    {
system("echo \"TXP:0,0,10,10920,91,42,0,57,18,8,4,4,8,4,8,4,8,8,4,4,8,8,4,8,4,8,4,8,4,4,8,8,4,8,4,4,8,4,8,4,8,4,8,8,4,4,8,4,8,8,4,4,8,4,8,4,8,8,4,8,4,8,4,8,4,8,4,4,8,4,8,4,8,4,8,4,8,8,4,8,4,4,8,4,8,8,4,8,120,0;\" | nc -u 192.168.178.121 49880 & pid=$! sleep 1 kill $pid 2>/dev/null >/dev/null");
    }
 }
}
Es sieht so aus als ob die myUtils nicht mehr ausgeführt wird.

Ich habe bisher folgendes getestet:

• das IT-Gateway angepingt
  -> ist erreichbar
• IT-Gateway Neustart
  -> keine Änderung
• mit WireShark die IP-Adresse vom IT-Gateway geprüft
  -> keinerlei Netzwerkverkehr
• reload von my_Utils durchgeführt
  -> keine Änderung
• den Dummy in FHEM getestet
  -> funktioniert, schaltet um und erzeugt einen Event
  -> im notify sehe ich allerdings nichts
• dann den Befehl des notify {rollo_az("auf")} direkt über die FHEM Befehlszeile eingegeben
  -> liefert "-1", keine Aktion des Aktors
• Eingabe des kompletten Befehls aus myUtils
  {system("echo \"TXP:0,0,10,10920,91,42,0,57,18,8,4,4,8,4,8,4,8,8,4,4,8,8,4,8,4,8,4,8,4,4,8,8,4,8,4,4,8,4,8,4,8,4,8,8,4,4,8,4,8,8,4,4,8,4,8,4,8,8,4,8,4,8,4,8,4,8,4,4,8,4,8,4,8,4,8,4,8,4,8,8,4,4,8,4,8,4,8,8,120,0;\" | nc -u 192.168.178.121 49880 & pid=$! sleep 1 kill $pid 2>/dev/null >/dev/null")}
  in der FHEM Befehlszeile
  -> Unknown command {system("echo, try help.
  -> Unknown command \", try help.
  

  Unknown command {system("echo, try help.

  
  

Hast Du eine Idee wo ich noch suchen könnte?

Moin,
Wenn Du Befehle die ; enthalten in der FHEM Kommandozeile testen willst, musst Du die ; immer schützen - also verdoppeln ;;

Geh doch erstmal eine Etage tiefer auf die System Kommandozeile und versuche das
echo "TXP:0,0,10,10920,91,42,0,57,18,8,4,4,8,4,8,4,8,8,4,4,8,8,4,8,4,8,4,8,4,4,8,8,4,8,4,4,8,4,8,4,8,4,8,8,4,4,8,4,8,8,4,4,8,4,8,4,8,8,4,8,4,8,4,8,4,8,4,4,8,4,8,4,8,4,8,4,8,4,8,8,4,4,8,4,8,4,8,8,120,0;" | nc -u 192.168.178.121 49880

Zitat von: Guzzi-Charlie am 29 April 2024, 11:51:53liefert "-1", keine Aktion des Aktors

system() liefert eine -1 zurück, die Routine wird aufgerufen

Ich würde aber vermuten mit deinem Gateway stimmt was nicht.

Gruß Otto

So, komme gerade frisch gestärkt vom Mittagessen.

Wenn ich den Befehl direkt in die Konsole eingebe, dann kommt: -bash: nc: command not found

Das mit dem Gateway was nicht stimmen könnte habe ich natürlich auch schon gedacht und es deshalb auch schon neu gestartet, leider ohne Ergebnis. Und wie gesagt: Anpingen läßt es sich und zeigt auch sonst erst mal keine Auffälligkeiten. Das schließt zwar nicht aus das es defekt ist, aber das wäre schon ein ziemlicher Zufall, daß ausgerechnet nach meinem RasPi-Austausch das Gateway kaputt geht. Außerdem müßte ich doch die UDP-Befehle in WireShark sehen, oder?

Zitat von: Guzzi-Charlie am 29 April 2024, 12:49:02bash: nc: command not found

da steht das Problem, Du hast nc (netcat) nicht installiert. Dann ist es aber noch nie gegangen - maximal hat dein alter Pi den Befehl abgesetzt :)

sudo apt install netcat

Zitatmaximal hat dein alter Pi den Befehl abgesetzt

jetzt wo Du es sagst. Du hast Recht. Der alte Pi lief Gestern Abend noch, zwar auf einer anderen IP, aber klar der hat dann natürlich die Befehle gesendet.

Ja, und kaum macht man es richtig, schon funktioniert es, Danke.

Der Befehl sudo apt install netcat funktioniert allerdings so nicht direkt. Es gab eine Fehlermeldung, das man das Package explizit angeben muß.

Es gibt: netcat-openbsd 1.219-1 und netcat-traditional 1.10-47

Ich habe das "traditional" installiert.