Nach Update HMCCU Fehlermeldungen und langsames FHEM

[MadMax-FHEM]

Hatte gestern die Forks mit global BlockingCallMax auf 16 gestellt, aber heute Nacht war wieder ein Absturz. Was ist denn ein empfehlenswerter Wertt dafür?

16? Wirklich?

Noch mal: ein Fork für Blocking bedeutet, dass das KOMPLETTE laufende fhem geclont wird! Ich glaube nicht, dass 16 da viel hilft, weil du hattest ja weiter vorne einen "Baum" gepostet und der war ja schon groß aber (deutlich) kleiner als 16 (waren 11 bzw. dann wohl ohne "Original" 10) und auch da hattest du ja Probleme...

Bei mir steht der auf 5...

Was läuft zu FHEM sonst noch?
zigbee2mqtt mit einem ConbeeII-Stick
Tablet-UI für Anzeige auf einem Tablet
piVCCU

Also mal das was NICHT "in" fhem läuft ausgeklammert läuft bei dir auf einem PI3B(+) (wenn ich das recht im Kopf habe):

fhem
eine CCU (piVCCU)
zigbee2mqtt (zigbee Bridge)

Bei Tablet-UI bin ich raus, keine Ahnung was das für das System auf dem das läuft zusätzlich bedeutet...
...aber alleine schon fhem, CCU und zigbee2mqtt auf dem armen "kleinen" PI...

Also ich habe das verteilt auf andere PI, also deCONZ (Zigbee-Bridge) auf einem extra PI (CCU nutze ich nicht), d.h. bei mir läuft NUR fhem auf einem PI3B+ und das ganz geschmeidig...
Und um solche Probleme nicht zu bekommen, kommt da auch nichts anderes drauf (auch, wenn es sicher geht)...

Protokollierst du deinen Speicherverbrauch?
Also generell?
Weil es ja neben dem Blocking/Forking auch generell einen Speicheranstieg (bei fhem) geben kann (gibt Threads dazu im Forum und ich war vor Umstieg auf Buster auch betroffen / aber es soll wohl je nach "Konstellation" und verwendeter Module auch damit noch Probleme geben)...
...nur als weitere Idee...

Nach einem reboot sieht es so aus:

Code Auswählen Erweitern

pi@Raspi043BPlus:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         945364      335348      251656       13388      358360      544184
Swap:        102396           0      102396

vorher waren nur 65 GB frei angezeigt.

Der PI hat doch insgesamt nur 1GB, da können ja keine 64GB frei sein

Gruß, Joachim

[frank]

es ist doch völlig egal, was free anzeigt.
wenn das os "oom" sagt, war es zu wenig. 
nimm für deine ccu ein eigenen pi.

[bmwfan]

@MadMax-FHEM
Hörte das mit Forks das erste Mal und konnte mir nicht viel vorstellen. Habe keine Empfehlungen gefunden und dachte, ich halbiere mal den Standardwert zum Testen. Dann muss ich aber noch deutlich weiter herunter.

Hardware ist PI3b(+) mit 64 GB Speicherkarte.
Es läuft fhem, CCU (piVCCU), zigbee2mqtt auf dem ConbeeII aber nicht deConz, ebusd (Abfrage Vaillant-Heizung)

Ich habe schon einen 2.ten Raspi im Technikraum und über MQTT2 angebunden. War aber doch ein Aufwand, das zum Laufen zu bringen. Wie hast Du Deine PI dann miteinander für den Datenaustausch verbunden?

Speicherverbrauch protokollieren:
Bisher nicht, aber ich suche mal im Forum wie das geht und richte es ein.

1GB: Ich denke inzwischen halt auch in PC-Dimensionen. Sind natürlich 64 MB. 

@frank: Werde ich machen. Habe noch einen herumliegen. Muss nur erst recherchieren, wie ich dann die Daten zwischen den PI's austauschen kann. Ist mir noch nicht klar wie das geht, wenn ein PI die CCU ansteuert und der andere ihn mit Daten versorgen und welche abholen muss.

Danke für die Hilfe an alle.

[frank]

Speicherverbrauch protokollieren:
Bisher nicht, aber ich suche mal im Forum wie das geht und richte es ein.

alles, was du zusätzlich definierst, braucht doch noch mehr speicher.
schaffe erst mal platz, damit du "atmen" kannst.

[MadMax-FHEM]

Hardware ist PI3b(+) mit 64 GB Speicherkarte.
Es läuft fhem, CCU (piVCCU), zigbee2mqtt auf dem ConbeeII aber nicht deConz, ebusd (Abfrage Vaillant-Heizung)

Naja, die SD bzw. der Speicher darauf ist (erst mal) uninteressant, es geht um RAM!

Ja klar: du zigbee2mqtt ich deCONZ (beides eine "externe" Zigbee-Bridge   ) wollte nur sagen, dass das eine weitere Komponente/Server-Dienst außerhalb fhem ist...

@frank: Werde ich machen. Habe noch einen herumliegen. Muss nur erst recherchieren, wie ich dann die Daten zwischen den PI's austauschen kann. Ist mir noch nicht klar wie das geht, wenn ein PI die CCU ansteuert und der andere ihn mit Daten versorgen und welche abholen muss.

Naja eine CCU von einem externen PI einbinden geht doch GENAUSO wie lokal...
...gut andere IP nat.
EDIT: es gibt ja bestimmt auch bei piVCCU sowas wie eine Konfiguration, die man bestimmt auf das neue System/PI übertragen kann / also offen: wie bekommst du die piVCCU auf einen anderen Rechner/PI ohne, dass sich "da(bei)" was ändert... (nutze [noch] keine CCU)...

Gleiches gilt für zigbee2mqtt, einfach dort (also bei zigbee2mqtt) die IP des fhem mit dem laufenden MQTT2-Server angeben (falls dort noch "localhost" eingetragen ist / wenn da jetzt schon die fhem-IP drin steht, dann brauchst du gar nix ändern, außer zigbee2mqtt auf einen anderen PI o.ä. installieren und Stick und Config übertragen)...

Gruß, Joachim

[bmwfan]

Habe jetzt einige Plots, die ich nicht mehr brauche, gelöscht. RAM wurde schon geloggt, aber nicht angezeigt. Mache ich jetzt, um zu sehen wie die max. Belastung ist.
Filelogs, was nicht unbedingt benötigt wird, habe ich ausgeschalten.

Mal sehen, ob der PI jetzt stabiler läuft. Parallel schaue ich, dass ich für piVCCU einen eigenen PI spendiere. Dann kann ich auch mein FHEM auf einen PI legen, der durch die Nähe zur CCU-Hardware nicht im Schaltscharnk (schwer zugänglich) montiert ist.

@MadMax-FHEM: Danke für die Tipps der Enbindung. Werde ich so angehen.
Habe noch einen PI2 Model B herumliegen. Denkst Du, der packt CCU + zigbee2mqtt oder ist der dann auch überlastet?

[MadMax-FHEM]

Habe jetzt einige Plots, die ich nicht mehr brauche, gelöscht. RAM wurde schon geloggt, aber nicht angezeigt. Mache ich jetzt, um zu sehen wie die max. Belastung ist.
Filelogs, was nicht unbedingt benötigt wird, habe ich ausgeschalten.

Naja, das wird nicht die Welt retten

Hast du maxBlockingCall schon deutlich runter gesetzt?

@MadMax-FHEM: Danke für die Tipps der Enbindung. Werde ich so angehen.
Habe noch einen PI2 Model B herumliegen. Denkst Du, der packt CCU + zigbee2mqtt oder ist der dann auch überlastet?

Gerne.

Äh, da eher mal auf eine Antwort von zap warten oder im Forum suchen...
...oder einen neuen Thread mit genau der Frage aufmachen...

Aber (soweit ich das überblicke/im Kopf habe):

CCU2 (also "Original" von ELV) war Plattform (vergleichbar) PI2 -> langsam, bzw. kommt drauf an wieviele Geräte

CCU3 (also "Original" von ELV) bzw. Bausatz "Charly" ist Basis PI3 -> aktuell

Vielleicht beantwortet das schon die Frage...
...und zeigt u.U. auch, dass es evtl. (jetzt schon) nicht "schlau" ist eine CCU (und ein Zigbee-Gateway) zusammen mit fhem auf einem PI3 zu haben

Gruß, Joachim

[bmwfan]

blockingCallMax ist auf 4 gestellt.

CCU: Ich benutze als Hardware eine HB-RF-USB Platine von Alexander Reinert für die piVCCU. Diese läuft als CCU3 => also besser gleich auf einen PI3 gehen. Mal suchen. Vielleicht liegt noch einer herum.

Überlastung: Ich habe mir immer die CPU-Belastung angeschaut um abzuschätzen, ob ich noch was draufpacken kann, nicht aber das RAM. Bin halt vom PC gewohnt, dass RAM kein Problem mehr darstellt. Muss doch noch einiges umdenken bei den kleinen Kerlchen.

[Wernieman]

Da Du laut ps aktuell schon 4 FHEM-Prozesse hast, würde ich eher auf 5 Stellen, d.h. 1 für ping in "reserve".

Sonst auch die Empfehlung: Nimm die pivccu auf einen anderen PI, das ist das einfachste. Ob Du jetzt "lokal" per netzwerk oder übe echtes Netwerk gehst ...
Nachfrage: Sie sind doch per Kabel verbunden? Nicht per WLAN??

Logfiles reduzieren, ist gut für die SDCard, aber macht den Speicher auch nicht voll. Dein free sieht eigentlich gut aus, gehe deshalb wirklich von Problemen bezüglich "noch-blocking-ping" aus.

Wie man zigbe2mqtt auf einen anderen Pi schmeißen könnte, müssen Dir die Experten von "dort" erzählen. Weiß ja nicht mal, wie es in FHEM eingebunden wird.

[bmwfan]

Ist gerade wieder abgestürzt. Setze Blocking mal auf 5.

Eigener Pi (3B+ noch gefunden) für die piVCCU gerade am Aufsetzen.
Raspis sind über LAN verbunden und das Modul für die piVCCU über USB.

Danke für eure Hilfe.

@zap: Wenn der Pi aus dem stromlosen Zustand bootet ist HMCCU immer inaktiv. Vermute, dass dieser Prozeß nicht schnell genug hochfährt. FHEM muss dann immer manuell "restartet" werden, damit HMCCU läuft.

Code Auswählen Erweitern

2021.11.16 17:01:29.595 1: Including fhem.cfg
2021.11.16 17:01:29.670 3: telnetPort: port 7072 opened
2021.11.16 17:01:30.231 3: WEB: port 8083 opened
2021.11.16 17:01:30.241 3: WEBS: port 8084 opened
2021.11.16 17:01:31.526 2: Registering GEOFANCY geofancy for URL /geo...
2021.11.16 17:01:31.572 3: WEBhook: port 8088 opened
2021.11.16 17:01:32.179 2: eventTypes: loaded 10047 lines from ./log/eventTypes.txt
2021.11.16 17:01:32.294 3: Opening CUL_0 device /dev/serial/by-id/usb-busware.de_CUL868-if00
2021.11.16 17:01:32.347 3: Setting CUL_0 serial parameters to 9600,8,N,1
2021.11.16 17:01:32.456 3: CUL_0: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2021.11.16 17:01:32.461 3: CUL_0 device opened
2021.11.16 17:01:32.469 2: Switched CUL_0 rfmode to HomeMatic
2021.11.16 17:01:33.075 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
2021.11.16 17:01:36.956 1: HMCCU [myHMCCU3] CCU port 8181 is not reachable
2021.11.16 17:01:36.956 1: HMCCU [myHMCCU3] Initialized version 5.0 213171649
2021.11.16 17:01:36.957 1: HMCCU [myHMCCU3] Scheduling delayed initialization in 180 seconds
2021.11.16 17:01:36.962 3: myHMCCU3: unknown attribute rpcinterfaces. Type 'attr myHMCCU3 ?' for a detailed list.
2021.11.16 17:01:37.138 3: Opening myJeeLink1 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL014JZA-if00-port0
2021.11.16 17:01:37.141 3: Setting myJeeLink1 serial parameters to 57600,8,N,1
2021.11.16 17:01:38.150 3: myJeeLink1 device opened
2021.11.16 17:01:39.233 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2021.11.16 17:01:39.233 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2021.11.16 17:01:39.614 3: HM485: HM485: Converting device files
2021.11.16 17:01:39.614 3: HM485: ==============================
2021.11.16 17:01:39.616 3: HM485: hmw_central.xml up to date
2021.11.16 17:01:39.616 3: HM485: hmw_generic.xml up to date
2021.11.16 17:01:39.617 3: HM485: hmw_io12_sw14_dr.xml up to date
2021.11.16 17:01:39.617 3: HM485: hmw_io12_sw7_dr.xml up to date
2021.11.16 17:01:39.617 3: HM485: hmw_io12_sw7_dr_V3_02.xml up to date
2021.11.16 17:01:39.617 3: HM485: hmw_io_12_fm.xml up to date
2021.11.16 17:01:39.617 3: HM485: hmw_io_4_fm.xml up to date
2021.11.16 17:01:39.618 3: HM485: hmw_io_4_fm_V3_02.xml up to date
2021.11.16 17:01:39.618 3: HM485: hmw_io_sr_fm.xml up to date
2021.11.16 17:01:39.618 3: HM485: hmw_lc_bl1_dr.xml up to date
2021.11.16 17:01:39.618 3: HM485: hmw_lc_bl1_dr_V3_02.xml up to date
2021.11.16 17:01:39.618 3: HM485: hmw_lc_dim1l_dr.xml up to date
2021.11.16 17:01:39.618 3: HM485: hmw_lc_sw2_dr.xml up to date
2021.11.16 17:01:39.619 3: HM485: hmw_lc_sw2_dr_V3_02.xml up to date
2021.11.16 17:01:39.619 3: HM485: hmw_sen_sc_12_dr.xml up to date
2021.11.16 17:01:39.619 3: HM485: Loading available device files
2021.11.16 17:01:39.619 3: HM485: ==============================
2021.11.16 17:01:39.619 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2021.11.16 17:01:39.622 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2021.11.16 17:01:39.625 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2021.11.16 17:01:39.633 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2021.11.16 17:01:39.647 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2021.11.16 17:01:39.663 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2021.11.16 17:01:39.677 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2021.11.16 17:01:39.692 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2021.11.16 17:01:39.706 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2021.11.16 17:01:39.721 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2021.11.16 17:01:39.741 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2021.11.16 17:01:39.761 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2021.11.16 17:01:39.782 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2021.11.16 17:01:39.797 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2021.11.16 17:01:39.811 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2021.11.16 17:01:41.268 3: UPDATE_FTUI: Defined with URL https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt and interval 86400 featurelevel 6.1
2021.11.16 17:01:42.150 3: Pollenflug: Defined with URL http://www.donnerwetter.de/pollenflug/region.hts?plz=88483&PTag=0 and interval 3600 featurelevel 6.1
2021.11.16 17:01:43.547 3: Opening my_callmonitor device 192.168.178.1:1012
2021.11.16 17:01:43.554 3: FB_CALLMONITOR (my_callmonitor) - loading cache file ./log/my_callmonitor.txt
2021.11.16 17:01:43.556 2: FB_CALLMONITOR (my_callmonitor) - read 36 contacts from Cache
2021.11.16 17:01:48.066 3: ArduinoNano_Zisterne: Defined with URL http://192.168.178.45/ and interval 61 featurelevel 6.1
2021.11.16 17:01:48.361 3: LaCrosse_Kueche: I/O device is myJeeLink1
2021.11.16 17:01:48.378 3: LaCrosse_Bad_EG: I/O device is myJeeLink1
2021.11.16 17:01:48.666 3: MQTT2_FHEM_Server: port 1883 opened
2021.11.16 17:01:49.152 3: HMCCUDEV [Licht_BadOG_Spiegel] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:49.828 3: freezemon defined myFreezemon freezemon
2021.11.16 17:01:49.831 0: [Freezemon] myFreezemon: Unwrapping CallFn
2021.11.16 17:01:49.831 0: [Freezemon] myFreezemon: Unwrapping AnalyzeCommand
2021.11.16 17:01:49.831 0: [Freezemon] myFreezemon: Unwrapping HttpUtils_NonblockingGet
2021.11.16 17:01:49.831 0: [Freezemon] myFreezemon: Unwrapping Log3
2021.11.16 17:01:49.832 3: [Freezemon] myFreezemon: Wrapping Log3
2021.11.16 17:01:51.696 2: HMCCURPCPROC [d_rpc178026BidCos_RF] CCU not ready. Trying later ...
2021.11.16 17:01:51.703 2: HMCCURPCPROC [d_rpc178026HmIP_RF] CCU not ready. Trying later ...
2021.11.16 17:01:51.795 3: Modul 90_Jalousie.pm: Init Done with Version V 0.00.09 von gevoo - 18.12.2015 modifiziert JG
2021.11.16 17:01:51.795 3: Name = Jal_KU_Fenster, Parameter = Jalousie Jal_KU_Fenster_03 39 2
2021.11.16 17:01:51.796 1: Jalousie mit Rolloaktor Jal_KU_Fenster_03 verbunden
2021.11.16 17:01:51.798 3: Name = Jal_KU_Sued, Parameter = Jalousie Jal_KU_Sued_03 64 2
2021.11.16 17:01:51.799 1: Jalousie mit Rolloaktor Jal_KU_Sued_03 verbunden
2021.11.16 17:01:51.801 3: Name = Jal_WZ_Fest_Ost, Parameter = Jalousie Jal_WZ_Fest_Ost_03 64 2
2021.11.16 17:01:51.802 1: Jalousie mit Rolloaktor Jal_WZ_Fest_Ost_03 verbunden
2021.11.16 17:01:51.804 3: Name = Jal_WZ_Fest_Sued, Parameter = Jalousie Jal_WZ_Fest_Sued_03 64 2
2021.11.16 17:01:51.805 1: Jalousie mit Rolloaktor Jal_WZ_Fest_Sued_03 verbunden
2021.11.16 17:01:51.807 3: Name = Jal_WZ_Schiebetuer, Parameter = Jalousie Jal_WZ_Schiebetuer_03 64 2
2021.11.16 17:01:51.807 1: Jalousie mit Rolloaktor Jal_WZ_Schiebetuer_03 verbunden
2021.11.16 17:01:51.810 3: Name = Jal_WZ_SuedWest, Parameter = Jalousie Jal_WZ_Fest_SuedWest_03 64 2
2021.11.16 17:01:51.810 1: Jalousie mit Rolloaktor Jal_WZ_Fest_SuedWest_03 verbunden
2021.11.16 17:01:51.812 3: Name = Jal_WZ_West, Parameter = Jalousie Jal_WZ_Fest_West_03 64 2
2021.11.16 17:01:51.813 1: Jalousie mit Rolloaktor Jal_WZ_Fest_West_03 verbunden
2021.11.16 17:01:52.711 3: HMCCUCHN [Alarm_KueOst_HmIP] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:52.760 3: HMCCUCHN [Alarm_KueSued_HmIP] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:52.797 3: HMCCUDEV [HmIP_BDT_0008DA49929255_3] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:52.875 3: HMCCUCHN [Heiz_BadOG_Handtuch_HmIP] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:52.937 2: HMCCURPCPROC [d_rpc178026VirtualDevices] CCU not ready. Trying later ...
2021.11.16 17:01:52.952 3: HMCCUDEV [Thermostat_AZ] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:52.996 3: HMCCUDEV [Thermostat_BadOG] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:53.037 3: HMCCUDEV [Thermostat_BibOG] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:53.075 3: HMCCUDEV [Thermostat_Kue] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:53.109 3: HMCCUDEV [Thermostat_WZ] Cannot detect IO device, maybe CCU not ready or device doesn't exist on CCU
2021.11.16 17:01:53.135 1: Including ./log/fhem.save
2021.11.16 17:01:55.010 3: Opening myHMUARTGPIO device 192.168.178.53:4001
2021.11.16 17:01:55.013 1: CUL_HM start inital cleanup
2021.11.16 17:01:57.219 1: CUL_HM finished initial cleanup
2021.11.16 17:01:57.302 3: monitoring (Activity_monitoring) set Activity_monitoring active

[Wernieman]

HMCCU braucht immer lange zum booten. FHEM ist schneller. Habe hier hier mit einer CCU2 die gleichen Probleme, wenn nach einem Stromausfall die Systeme hochfahren. Eigentlich sollte das HMCCU-Modul das abkönnen, hatte aber bisher (noch) keine Zeit/Lust dazu, es zu analysieren, zu optimieren. Wahrscheinlich würde in reopen auf HMCCU-Connecktor ausreichen.

Wenn mit "blocking" ist es schon abschmiert, bringt Dir die 5 wenig. kannst ja mal gucken, ob der oom wieder zugeschlagen hat (wieder als root oder sudo):

Code Auswählen Erweitern

grep -i -e "oom" -e "i/o" /var/log/kern.log

Es gibt übrigens eine andere alternative: Ein System mit mehr Speicher (Hardware) ..... allerdings bin ich (persöhnlich) ein Freund von separieren. Auf meinem hauptsystem per docker, aber z.B. das externe "gateway" ist auch ein Pi. Und für gewisse Hardware (sispm-Dosen) gibt es auch noch einen 2. Pi. Wenn der Probleme auf dem USB-Bus bekommt, interessiert es mein Hauptrechner dadurch überhaupt nicht.

[zap]

Wenn die CCU als Software auf dem gleichen Rechner läuft wie FHEM, ist bei einem Neustart FHEM immer viel schneller wieder da.
Ich würde das auf 2 System verteilen, das macht vieles einfacher

Je nach Menge der Devices und der genutzten Schnittstellen hatte ich bei der CCU schon Startzeiten von >1 Minute

[bmwfan]

Hallo,

habe jetzt einen Raspi 3B mit piVCCU aufgesetzt. Läuft auch.

Habe einen Main-Raspi mit FHEM neu aufgesetzt, da das Backup des Haupt-Raspi nicht sicher gelaufen ist. Sporadisch wieder die Abstürze, sodaß ich mich entschlossen habe, FHEM komplett neu aufzusetzen. Dabei stoße ich natürlich immer wieder auf Probleme (HM485 erkennt nicht alle Aktoren, Shellys gehen noch gar nicht....) aber ich kämpfe mich durch.

Danke an alle, die mir geholfen haben.