Update FHEM / Neuinstallation Raspi 1=>5

[rasti]

Hallo,

ich habe mich nun endlich durchgerungen mein FHEM neu aufzusetzen. Es wurde seit 2016 nie geupdated (nur wenn's unbedingt nötig war mal ein Modul manuell dazugeladen) und lief seither auf einem Raspberry Pi 1 mit 8GB SD- Karte. Ich habe mir nun einen Pi 5 gekauft, einen NVME-SSD-Adapterboard https://shop.pimoroni.com/products/nvme-base?variant=41219587178579 und eine 512GB SSD. Ich war positiv überrascht, wie schnell und einfach das ganze von der Hand ging. PI-OS-Image in Windowsrechner auf SD Karte gebracht, von der SD gebootet und dann übern Pi Desktop ein Image auf die SSD gebracht, gebootet und FHEM installiert. Ging alles sehr fix und problemlos, kein Vergleich zu dem Murks vor ein paar Jahren. Ich hoffe jetzt mal, dass das neue System nun etwas länger durchhält....

Die alte Installation ist auf 192.168.178.6 und nur ans LAN angeschlossen, die neue Installation soll auch wieder ans LAN und läuft derzeit aber über WLAN 192.168.178.199.

Folgendes ist auf dem Pi 1 installiert bzw. hängt dran

Das sollte problemlos laufen =>
- Onewire über USB => sollte 1:1 auch auf dem PI5 laufen
- FS 20 über WLAN-CUL Interface => sollte 1:1 auf dem PI5 laufen
- Steuerung Onkyo-Verstärker + Panasonic TV => geht über LAN, sollte 1:1 auf dem PI 5 laufen
- Modbuszähler ausgelesen über ein TCP/IP Gateway  => sollte 1:1 auf dem PI 5 laufen
-  Victron über TCP/IP Gateway  => sollte 1:1 auf dem PI 5 laufen

Wo ich mir unsicher bin =>
- Homematic Thermostate über HM-CFG-LAN LAN Konfigurations-Adapter
   => da bin ich mir nicht so sicher ob ich die Teile aus der fhem.cfg einfach so übernehmen kann

- Verbindung zu Fritzbox (Anruferanzeige + Nummernsuche im internen/externen Telefonbuch
   => keine Ahnung wie das mal ging....und wieviel Aufwand der Transfer ist

- diverse Geräte (z.B. Fronius-WR) die per HTTPMOD abgefragt werden
   => geht das einfach mit dem neuen FHEM 1:1?  war da nicht mal was von wegen blocking/non blocking oder ähnliches  ?!?

Wo ich gar nicht so recht weiss wie ichs machen soll =>
- ich habe über 30 mit einer alten TASMOTA-Version geflashte Shellies, Sonoffs etc. die alle über MQTT gelesen/gesteuert werden. Bislang war da ein Mosquito auf dem selben Raspi 1 wie FHEM installiert, also dieselbe IP. FHEM und der MQQT Broker brauchen bei mir auch in Zukunft unbedingt dieselbe IP 192.168.178.6 über LAN. Soll ich da nun besser den integrierten Broker aus FHEM nehmen oder wieder einen Mosquito aufsetzen ? Was ist einfacher, wenn man die alte fhem.cfg verwerten will ?

- Ich nutze Tablet UI zur Visualisierung von FHEM. Vor Jahren gabs mal ein Problem dass die in FHEM integrierte Tablet UI auf einem Pi1 zu langsam war da gabs hier im Forum Anleitungen einen Apache.Server auf dem Pi zu installieren und die Seiten darüber auszugeben. Das habe ich gemacht, führte leider zu viel Pfusch am Code wo ich heute nicht mehr durchblicke. Muss ich wohl neumachen ?!?

Ich würde mich über ein paar Tipps sehr freuen, bevor ich mit dem Umbau und Umzug beginne.....wird ein größerer Akt, allein die fhem.cfg ist 150kB groß.

Viele Grüße

Ralf

[rudolfkoenig]

Wg. externer vs. interner MQTT Server:
ich meine ein Wechsel von Extern auf Intern sollte ohne Konfigurationsaenderung in FHEM moeglich sein, wenn man den Namen des MQTT2_CLIENTs fuer MQTT2_SERVER uebernimmt (danach bitte FHEM neustarten).
Das stimmt nicht fuer die andere Richtung.

Andererseits, wenn alles schon angelegt ist, sind die Vorteile fuer MQTT2_SERVER marginal, ich wuerde bei der alten Konfiguration bleiben.

[Beta-User]

Wg. externer vs. interner MQTT Server:
ich meine ein Wechsel von Extern auf Intern sollte ohne Konfigurationsaenderung in FHEM moeglich sein, wenn man den Namen des MQTT2_CLIENTs fuer MQTT2_SERVER uebernimmt (danach bitte FHEM neustarten).
Das stimmt nicht fuer die andere Richtung.

Andererseits, wenn alles schon angelegt ist, sind die Vorteile fuer MQTT2_SERVER marginal, ich wuerde bei der alten Konfiguration bleiben.

Gab's denn 2016 schon MQTT2_.*?!?

Vermutlich ist noch "MQTT" der IODev-Type.

Dann wird die Migration ggf. deutlich schwieriger. Ich würde empfehlen, den internen Server zu aktivieren, MQTT (altes IO-Modul) darauf hören lassen, und dann nach und nach die Devices in die neue Welt umziehen, also direkt MQTT2_SERVER als IO-Modul verwenden.

CUL_HM (mit dem LAN-GW als IO) sollte auch kein Problem sein, allerdings läufst du mit dem "single-IO" Gefahr, dass da irgendwann nichts mehr geht - die Dinger sterben irgendwann. Daher besser in diesem Fall eine VCCU (CUL_HM) dazwischenziehen und ggf. dann mind. ein weiteres IO besorgen (das alte PI-PCB). Für's erste bitte die CUL_HM-Geschichten unbedingt via fhem.cfg übernehmen (also ausnahmsweise manueller Edit außerhalb FHEM!). Sonst ist das Modul beleidigt und du musst diverse Dinge von Hand nachziehen...

Zu Fritzbox gibt es zwischenzeitlich viele Änderungen, da vermutlich am besten neu anfangen.

[rasti]

Gab's denn 2016 schon MQTT2_.*?!?

Ende 2018 kamen meine Tasmota-Geräte mit MQTT

Die sind so eingebunden in FHEM

Code Auswählen Erweitern

define Mosquitto MQTT 192.168.178.6:1883
attr Mosquitto keep-alive 120
attr Mosquitto room 2__MQTT

################################

define Sonoff_Basic_1 MQTT_DEVICE
attr Sonoff_Basic_1 IODev Mosquitto
attr Sonoff_Basic_1 alias Licht  Erker (SoB-1)
attr Sonoff_Basic_1 autoSubscribeReadings 1
attr Sonoff_Basic_1 devStateIcon ON:10px-kreis-gruen OFF:10px-kreis-rot
attr Sonoff_Basic_1 eventMap on:ON off:OFF
attr Sonoff_Basic_1 group Shellies_und_Sonoff_Basics
attr Sonoff_Basic_1 publishSet on off toggle cmnd/Sonoff_Basic_1/POWER
attr Sonoff_Basic_1 stateFormat state
attr Sonoff_Basic_1 subscribeReading_network tele/Sonoff_Basic_1/LWT
attr Sonoff_Basic_1 subscribeReading_state tele/Sonoff_Basic_1/POWER
attr Sonoff_Basic_1 webCmd on:off:toggle
Module mit "mmqqt" im Namen siehe hier =>
Du darfst diesen Dateianhang nicht ansehen.