Ich habe jetzt Homegear installiert. Grundsätzlich würde ich vermutlich meine Homematic-Geräte darüber nach Home Assistant bekommen. ABER: Ein parallel-Betrieb mit FHEM ist definitiv ausgeschlossen. Und damit kann ich nicht sanft migrieren.

Es bleibt also beim Plan, neue Logik wird in NodeRed definiert, vorhandene Logik wandert Schritt für Schritt nach NodeRed, bis in FHEM nur noch die Geräte stehen.

#homeassistant #fhem #nodered #homematic #homematicip #homegear

Der Wechsel von FHEM auf Home Assistant ist abgesagt

Der 1. Grund: Homematic geht nur einzubinden, wenn ich die Komponenten an der CCU3 neu anmelde. Vorher natürlich von HMUARTLGW abmelden. Das ist bei den alten Komponenten nicht trivial. Zum Anbinden muss man nämlich einen Taster am Gerät anschließen. Nur so kann man die Komponente ablernen und neuanlernen. Allerdings laufen über diesen Tasteranschluss 230 V. Also Sicherung raus, zwei Kabel rein. Sicherung wieder rein. Beide kabel mit den Kabelspitzen zusammentippen, ein paar Sekunden zusammen halten und das Gerät ist dann hoffentlich gelöscht. Neu anlernen. und das bei ziemlich genau 60 Komponenten. Sorry, nein. So nicht.

Der 2. Grund ergibt sich daraus, wie man das Problem aus 1 etwas entschärfen kann. Man bindet in FHEM einen MQTT-CLienten ein, baut eine Bridge und immer wenn ein Homematic-Gerät schaltet, kann das Home Assistant als MQTT auslesen. Das Funktioniert tatsächlich auch. Die notwendigen Attribute kann man mittels KI schnell erzeugen und fast genauso schnell über die Befehlszeile eingeben. Der Nacharbeit-Aufwand aber war beträchtlich. Ich musste bei allen state in die Eventliste packen. also 60 Komponente abklappern (oder wieder von der KI erzeugen lassen und über die Befehlszeile eingeben). Aber: die vporhandenen Zigbee-Geräte haben in HA dann nicht mehr funktioniert. Das lag vermutlich an der neu eingerichteten MQTT-Brücke/Broker.

Alles in allem ist mir das alles zu fummelig. Da bleibe ich lieber bei FHEM + Nodered.

Die Logik baue ich Schritt für Schritt wann immer ich mal etwas ändern muss in NodeRed nach. auf diese Weise wird FHEM irgendwann mal nur noch die Geräte enthalten.

Damit kann ich leben.

In NodeRed habe ich, darüber hatte ich unlängst geschrieben, drei FHEM Nodes definiert (sind Sub-Nodes):

a) Schreiben von Readings
b) Lesen von Readings
c) ausführen von befehlen (z.B. on oder off)

Ich kann also über NodeRed sehr leicht Werte auslesen/schreiben oder Geräte schalten.

Ein Vorteil ist auch, die Alexa Integration braucht nicht angefasst werden.

Na schön. Bleibt festzuhalten: HA ist nichts für mich und meine Installation.

#fhem #homeassistant #nodered #zigbee

**Die Zeit für FHEM ist abgelaufen. Wir wechseln auf Home Assistant. **

FHEM stürzt regelmäßig über Nacht ab. Das macht mir das Logging kaputt, das macht unnötigen Aufwand, weckt Zweifel an der Stabilität. Oberflächen kontruieren in FHEM ist defakto unmöglich, externe Tools sind erforderlich, bei uns z.B.FUIP und Nodered und Standard-HTML. Klar, Nodered ist nicht der Weisheit letzter Schluss, aber in letzter Zeit sind viele Dinge bereits nach Nodered ausgewandert (unsere Solarsteuerung zum Beispiel).

Eine Installation, die weit über 15 Jahre alt ist, wechselt man natürlich zum einen nicht über Nacht aus und zum anderen nicht ohne einen konkreten Plan.

Unser System umfasst WLAN-Komponenten, ZigBee, Homematic, HomematicIP, HomeConnect, Echos und ALexa, Fritzbox u.a. Mindestens fünf andere Rechner liefern Zuarbeiten (NodeRed-Dashboards, Solarsteuerungen, Datenbank-Logging u.a.).

Ein Migarationsplan muss her:

**Phase 0: Inventur**
- Geräte-Inventur
- Logik-Inventur

Beispiel:
{ WriteFile('fhem_inventur_doif.txt', fhem('list TYPE=DOIF')) }

**Phase 1: Die Basis-Infrastruktur**
- Logging einrichten (MariaDB 10, machte bisher auch das Logging in FHEM
- Steuersysteme (zigbee2mqtt, Fritzbox, HomeConnect, ggf. Homematic und IP)

**Phase 2: Geräte-Migration (Hardware & APIs)**
- WLAN-Geräte
- zigBee-Geräte
- Homematic und HomematicIP
- Fritzbox, Fritzbox-Geräte
- HomeConnect
- Victron-Anlage mit allem was dazu gehört (MPPT, Batterie, CerboGX etc.)

**Phase 3: Die Logik**
- ATs
- notifys
- DOIFs
- sonstige Perl-Programme
- die Logik direkt über Nodered, HA dort einbinden

**Phase 4: Frontend & Visualisierung**
- Mein großes Infoterminal (NodeRed-Oberfläche)
- der kleine Bruder fürs Handy
- eine Mini-Version für den Desktop
- allgemeines FUI-Frontend

**Phase 5: Sprache & Benachrichtigungen**
- alexa einbinden
- E-Mail-System
- Status per Alexa verkünden

**Phase 6: Aufräumen und Abschalten.**
- Abschalten in FHEM, der Funktionen, die in HA umgesetzt wurden.
- Prüfen was übrig blieb
- Aufräumen (Dateien löschen, Datenbanken löschen etc.)

Ich denke, es wird mindestens ein Jahr dauern.

#fhem #homeassistant #nodered #migration #perl #MQTT #wlan #shelly #zigbee #homematic #HomematicIP #homeconnect

Die Pampa, das ist das Gebiet kurz vor Polen, also fast Sibirien, hatte jetzt gut 90 min Stromausfall.

Und ich musste mit Entsetzen feststellen, dass ein Großteil meiner Notfall-Szenarien nicht funktionieren.

Positiv:
1. Der Internet-Router lief durchgängig (allerdings hatte ich die Notfall-USV nach ca. 10 min. wie geplant an die Notfallsteckdose unserer Solaranlage angeschlossen)
2. Als der Strom wieder da war, haben sich die kritischen Systeme (Kühlschrank und Eisschränke) wieder eingeschaltet.

Negativ:
1. FHEM lief zwar, war aber nicht wie eigentlich geplant im Netz
2. die anderen Server liefen durchgehend, waren aber auch nicht im Netz (Illyachan, CCU3)
3. die CCU3 erkannte nach dem Ausfall einen Teil der Komponenten nicht. Das ist riskant, es war vermutlich nur Zufall, dass die kritischen Steckdosen erkannt wurden. Ein Neustart der CCU3 hat das Problem zwar gelöst, aber ich will nicht nach jedem Stromausfall das System neustarten. Es soll einfach weiterlaufen.

Das HomematicIP-System ist Mist, da sich die Komponentne nicht den letzten Status (An/Aus) merken und von Hand eingeschaltet werden müssen (die programmierte Automatik greift nicht, wenn die CCU die eigenen Geräte nicht sauber wieder erkennt.)

Am einfachsten ist noch die Netzwerkconnection der Server. Hier muss nur die Switch-Kette angepasst werden.

Das CCU3-FHEM-Konstrukt: Wenn beide im Netzwerk bleiben, sollte das meiste auch kein Problem mehr sein. Die HomematicIP-Komponenten bleiben ein Problemfall. Ich denke, wenn mir nichts Schlaues einfällt, werden die perspektivisch ausgemustert.

#fhem #ccu3 #stromausfall #notfallplan

**Node-RED & FHEM: Warum „Keep it simple“ manchmal der bessere Weg ist**

Ich habe mich in letzter Zeit intensiv mit der Verbindung von **Node-RED** und **FHEM** beschäftigt. Ursprünglich hatte ich die dedizierten FHEM-Nodes im Einsatz, aber ehrlich gesagt: Wir sind keine Freunde geworden. Die Dokumentation war für mich lückenhaft, und was schwerer wiegt: Das Schreiben von Readings hat mein FHEM regelmäßig in die Knie gezwungen.

Wenn man bei der Fehlersuche mehr damit beschäftigt ist, die Logik der Nodes zu verstehen, als den eigentlichen Flow zu fixen, läuft etwas falsch.

**Die Lösung: Zurück zu den Basics.**

Ich habe mir drei Subflows „geklöppelt“, die rein auf der **HTTP-Schnittstelle** basieren. Das ist stabil, transparent und vor allem: Es stürzt nichts mehr ab.

**Die drei Werkzeuge im Überblick**

Ich nutze jetzt drei spezialisierte Subflows für die tägliche Arbeit:

**1. Get Reading**

Hiermit hole ich mir aktiv Werte aus FHEM ab.

**Konfiguration:** FHEM-URL (ist im Subflow als Default hinterlegt), Device-Name, das spezifische Reading und der Datentyp (**Zahl, String oder Boolean**).

**Funktionsweise:** Der Knoten benötigt einen Trigger (z. B. eine Injection oder einen Impuls aus einem anderen Flow). Am Ausgang wird der Wert sauber in `msg.payload` ausgegeben.

**2. Set Reading**

Das Gegenstück, um Werte in FHEM zu schreiben.

**Konfiguration:** Identisch zum „Get“-Knoten, allerdings ohne Datentyp-Wahl.

**Funktionsweise:** Der Wert, der in FHEM geschrieben werden soll, wird einfach per `msg.payload` an den Eingang des Knotens gereicht.

**3. Execute Command**

Für die klassischen Schaltbefehle.

**Konfiguration:** URL, Device und der Befehl (z. B. `on`, `off`, `toggle`).

**Einsatz:** Perfekt für die schnelle Steuerung, ohne direkt Readings manipulieren zu müssen.

**Warum dieser Weg?**

Die Subflows sind im Grunde nur schlanke Kapseln um HTTP-Requests. Das macht sie extrem wartungsfreundlich. Wer schon mal Stunden mit der Fehlersuche in komplexen Drittanbieter-Nodes verbracht hat, wird die Einfachheit der HTTP-Web-Schnittstelle zu schätzen wissen.

**JSON-Import**

Für alle, die ähnliche Probleme mit den Standard-Nodes haben oder einfach eine schlanke Lösung suchen, ist hier das JSON zum Importieren in Node-RED:

[
{
"id": "sf_logic_prep",
"type": "function",
"z": "fhem_subflow_id",
"name": "URL bauen",
"func": "const baseUrl = env.get(\"FHEM_URL\");\nconst device = env.get(\"FHEM_DEVICE\");\n\nmsg.url = `${baseUrl}/fhem?cmd=jsonList%20${device}&XHR=1`;\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 210,
"y": 80,
"wires": [
[
"sf_logic_http"
]
]
},
{
"id": "sf_logic_http",
"type": "http request",
"z": "fhem_subflow_id",
"name": "",
"method": "GET",
"ret": "obj",
"paytoqs": "ignore",
"url": "",
"tls": "",
"persist": false,
"proxy": "",
"authType": "",
"senderr": false,
"headers": [],
"x": 370,
"y": 80,
"wires": [
[
"sf_logic_extract"
]
]
},
{
"id": "sf_logic_extract",
"type": "function",
"z": "fhem_subflow_id",
"name": "Wert wandeln",
"func": "const readingName = env.get(\"FHEM_READING\");\nconst targetType = env.get(\"RET_TYPE\");\n\ntry {\n let rawValue = msg.payload.Results[0].Readings[readingName].Value;\n \n if (targetType === \"Zahl\") {\n msg.payload = parseFloat(rawValue.replace(',', '.'));\n } else if (targetType === \"Boolean\") {\n let low = rawValue.toLowerCase();\n msg.payload = (low === \"true\" || low === \"on\" || low === \"1\" || low === \"yes\");\n } else {\n msg.payload = String(rawValue);\n }\n \n return msg;\n} catch (e) {\n node.error(\"Reading '\" + readingName + \"' nicht gefunden!\");\n return null;\n}",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 540,
"y": 80,
"wires": [
[]
]
},
{
"id": "sf_set_logic_prep",
"type": "function",
"z": "fhem_set_subflow_id",
"name": "URL bauen",
"func": "const baseUrl = env.get(\"FHEM_URL\");\nconst device = env.get(\"FHEM_DEVICE\");\nconst reading = env.get(\"FHEM_READING\");\nconst val = msg.payload;\n\n// Wert sicherheitshalber URL-kodieren (falls Leerzeichen o.ä. enthalten sind)\nconst encodedVal = encodeURIComponent(val);\n\nmsg.url = `${baseUrl}/fhem?cmd=setreading%20${device}%20${reading}%20${encodedVal}&XHR=1`;\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 220,
"y": 80,
"wires": [
[
"sf_set_logic_http"
]
]
},
{
"id": "sf_set_logic_http",
"type": "http request",
"z": "fhem_set_subflow_id",
"name": "",
"method": "GET",
"ret": "txt",
"paytoqs": "ignore",
"url": "",
"tls": "",
"persist": false,
"proxy": "",
"authType": "",
"senderr": false,
"headers": [],
"x": 410,
"y": 80,
"wires": [
[]
]
},
{
"id": "sf_cmd_logic_prep",
"type": "function",
"z": "fhem_cmd_subflow_id",
"name": "Befehl bauen",
"func": "const baseUrl = env.get(\"FHEM_URL\");\nconst device = env.get(\"FHEM_DEVICE\");\nconst command = env.get(\"FHEM_COMMAND\");\nconst val = msg.payload;\n\n// Basis-URL mit set Befehl\nlet fhemCmd = `set%20${device}%20${command}`;\n\n// Wenn ein Wert in msg.payload mitgeliefert wird, hänge ihn an\nif (val !== undefined && val !== null && val !== \"\") {\n fhemCmd += `%20${encodeURIComponent(val)}`;\n}\n\nmsg.url = `${baseUrl}/fhem?cmd=${fhemCmd}&XHR=1`;\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 220,
"y": 80,
"wires": [
[
"sf_cmd_logic_http"
]
]
},
{
"id": "sf_cmd_logic_http",
"type": "http request",
"z": "fhem_cmd_subflow_id",
"name": "",
"method": "GET",
"ret": "txt",
"paytoqs": "ignore",
"url": "",
"tls": "",
"persist": false,
"proxy": "",
"authType": "",
"senderr": false,
"headers": [],
"x": 410,
"y": 80,
"wires": [
[]
]
}
]

Vielleicht hilft es ja dem einen oder anderen, sein Smart Home Setup etwas stabiler zu gestalten. Fragen oder Feedback dazu gerne in die Kommentare oder per Direktnachricht! 🚀

#FHEM #NodeRED #SmartHome #HomeAutomation #IoT #Schnittstellen #Hacking

**Projektbericht: Upgrade der PV-Anlage auf Victron-System**

Am vergangenen Wochenende wurde die bestehende, Orion-gesteuerte „Rebellen-Solar-Anlage“ erfolgreich auf ein System mit einem **Victron MultiPlus II** umgerüstet.

**1. Standort und Vorbereitung**

Die Installation erfolgte mangels eines (offiziell existierenden) Kellers in der Küche. Besonderes Augenmerk lag auf kurzen Leitungswegen zum Sicherungskasten und den MPPTs sowie einer sauberen Verlegung in Kabelkanälen. Da die kritische IT-Infrastruktur im Haus (Server, „Kuschelmammut“) keine längeren Ausfallzeiten toleriert, wurde die Überbrückungszeit der USVs durch eine zusätzlich bereitgestellte, voll geladene EcoFlow abgesichert.

**2. Hardware-Konfiguration (System „Hardcore-Otaku“)**

Die Komponenten wurden fachgerecht installiert und intern wie folgt benannt:

**Wechselrichter:** Victron MultiPlus II (*„Nadia“*)
**Steuereinheit:** Cerbo GX (*„Sakura“*)
**Laderegler:** 2x MPPT (*„KeroChan“* & *„KeroChan II“*)
**Speicher:** Pylontech C3000 Blöcke (*„Utena“*)
**Zusatzkomponenten:** Lynx Distributor, Phoenix 250 Wechselrichter (*„Hinotori“*) sowie ein 48V/12V-Transformator zur Versorgung der temperaturgesteuerten Schaltschrank-Lüftung.

**3. Technische Herausforderungen: Verkabelung und Lastmanagement**

Bei der Montage der Batterien trat ein Kompatibilitätsproblem auf: Die beschafften Rohrkabelschuhe (35–50 mm²) passten nicht zu den benötigten 25 mm²-Anschlüssen. Nach rechnerischer Prüfung der Leitungsquerschnitte (theoretisches Minimum 16 mm²) wurde vorerst mit nur einem25 mm² Kabel verkabelt. Da erste Lasttests bei 4000 W (ca. 85 A Gesamtlaufladung) eine unerwünschte Wärmeentwicklung zeigten, wurde das System softwareseitig wie folgt begrenzt:
**Lade-/Entladelimit:** 2500 W (entspricht ca. 20 A pro Batterieblock). Dies gewährleistet einen thermisch stabilen Betrieb und schont die Pylontech-Zellen.

Wir werden auf jedenfall noch ein 2. Kabel an der Batterie anschliessen, wie geplant, um die Leistung bei Bedarf steigern zu können.

**4. Inbetriebnahme und Software-Integration**

Die physische Inbetriebnahme verlief ohne kritische Zwischenfälle („thermonuklearer Notfall“ blieb aus). Folgende Software-Hürden mussten jedoch genommen werden:

**MPPT-Konfiguration:** Der zweite Laderegler erkannte die Systemspannung nicht automatisch. Eine manuelle Umstellung auf 48 V über das Smartdisplay löste das Problem.

**Smart-Meter-Bug:** Der Shelly Pro 3EM lieferte nach der Einbindung in die Venus-OS-Oberfläche (Sakura) fehlerhafte Werte. Nach Analyse der aktuellen Firmware-Version wurde die Standard-Einbindung gelöscht und durch eine alternative Implementierung ersetzt, was die Datenintegrität wiederherstellte.

**5. Fazit und Monitoring**

Nach Abschluss der Hardware-Arbeiten erfolgte am Montag die Einbindung der Daten via **Node-RED** in das bestehende **FHEM-System**. Die Benutzeroberflächen wurden entsprechend aktualisiert.

**Status:** Das System ist vollumfänglich betriebsbereit. Puh.

#solar #victron #pylontech #anime #fhem #shelly #photovoltaik

I don’t want to set up a #smarthome, but the current timer switch just doesn’t cut it. Unfortunately, the documentation for smarthome stuff seems to assume that you already know everything…

I’d like to use an existing headless #RaspberryPi with a RaspBee II to control a single Ikea Trefakt socket. What would be a lightweight way of doing this without GUI, without #HomeAssistant, without Docker?

Would #FHEM fit the bill? Or any other recommendations?