#fhem — Public Fediverse posts

Anfang Juli habe ich meinem #balkonkraftwerk einen neuen Speicher spendiert. Neben der vorhandenen Solix E1600 1. Generation werkelt jetzt der Nachfolger Solix 2. Der Vorteil: der alte Speicher kann weiter benutzt werden und erhöht mir die Kapazität auf das Doppelte. Über #FHEM #MQTT und ein #Python Script erfolgt die Kopplung zum Stromzähler und der Regelkreis für die Stromabgabe ins Hausnetz.

Die Abgabe ins öffentliche Netz konnte ich so sehr gut minimieren.

#solar #sonnenkraft #bkw

@messieass es empfiehlt sich so oder so, auf eine lokale Lösung umzustellen. @evcc oder #openEMS bieten dafür Lösungen an. Wahlweise integrierbar in eine Hausautomatisierung #openHAB #homeassistant #iobroker #fhem etc...

**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

Eine #FHEM - Ära geht nach 12 Jahren zu Ende.
Ein #RaspberryPi 2 diente die gesamte Zeit als FHEM #Server.
Er wurde soeben in den wohlverdienten Ruhestand versetzt "sudo shutdown -now forever" ;)
Er macht Platz für ein #homeassistant Setup auf einem Raspberry 3. Dieser ist absolut ausreichend für mein kleines Setup.

**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?

Ich überlege, nach über 11 Jahren #fhem auf #HomeAssistant umzusteigen.
Einen frischen #Raspberry hab ich schon mal aufgesetzt.
Aber die Migration bestehender Hardware erscheint mir ziemlich kniffelig... Ich zweifle gerade wieder am Vorhaben (vor allem aus Zeitgründen, mich da reinarbeiten zu müssen)

Hardware die ich gerne beibehalten würde:
- Jeelink 433 MHz für Temperatursensoren
- CUL 866Mhz für Homematik Aktoren und Sensoren (nicht IP, noch die alten)
- IR- Lesekopf auf USB für Stromzähler
- Conbee 2 für Zigbee
Falls jemand schon mal ein ähnliches Setup migriert hat, immer her mit den Tips 😁

Ich nenne einen 868MHz-#CUL (#SDR als USB-Stick) mein Eigen. Den habe ich früher als Adapter für #FS20-Geräte unter #FHEM verwendet.

Ich hätte eigentlich gerne einen #LoRa -Scanner. Kennt jemand eine Firmware für den CUL, den man als LoRA-Scanner einsetzen kann?

#Fedihelp

@nesges verrückt, ich kenne dich sonst nur als @dnddeutsch und sehe nun, dass du auch was für #FHEM machst. Ich bin da zwar nicht mehr aktiv, aber habe mal archetype, LuftdatenInfo, monitoring, msgDialog, Nmap und powerMap initial beigesteuert

#homeassistant ist ein wirklich gutes Projekt. Das Automationen nach einem Reboot allerdings ihren Status vergessen, empfinde ich als architektonische Fehlentscheidung. Das muss für jede einzelne Automation ein entsprechender Fall angefangen werden. Das hat mir bei #fhem damals besser gefallen. allerdings hat HA auch echt schicke Vorteile ggü. Fhem.

#smarthome

Tado macht sich unbeliebt

https://blog.sengotta.net/tado-macht-sich-unbeliebt/

Auf jeden Fall bei den ganzen Usern von Home Assistant, Openhab, FHEM und Co. Dann all deren Integrationen von Tado Produkten beruhen auf einer, meines Wissens nach inoffiziellen, API des Herstellers.

Und für diese API wird jetzt ein Ratelimit eingeführt wie man der nachstehenden E-Mail, die auch an mich ging, entnehmen kann:

Hello BjöRn,

We have an important update for users of our REST API, which—while never officially supported for third parties—we’ve historically left open and unrestricted. We’ve always believed in fair use, and we intend to continue supporting that principle.

The API is commonly used by third-party and open-source platforms (e.g., Home Assistant), as well as by users running their own custom scripts. Nevertheless, a small fraction of very frequent API users are currently responsible for a disproportionately high share of our server expenses.

To ensure long-term stability and to avoid restricting access for everyone, we will begin introducing daily usage limits for API calls.

Your daily quota will depend on whether you have an active tado° Auto-Assist subscription:

Without Auto-Assist: 100 requests/day
A small daily quota, which should still support basic use cases that are not available via tado’s local APIs: HomeKit for V3/V3+ devices or Matter for tado° X devices. We have updated the documentation on how to access the REST API to reflect these changes.

With Auto-Assist: 20.000 requests/day
This should cover even more demanding use cases, and the subscription fees enable us to offset the increased costs associated with additional server calls.

We’ve shared these changes very early in our consideration process with Home Assistant, the largest open-source software using the unofficial tado° REST API, asking them to adapt their integration to rely more on tado’s local APIs. We understand this creates challenges for community projects. Therefore, we will slowly ramp down limits over the next few months for a smooth transition.

Our goal is to strike a fair balance, ensuring that responsible use remains possible while keeping infrastructure costs under control.

Thank you for your understanding.

Warm regards,

Your tado° Team

Und für die User keine Auto-Assist Subscription haben (oder ein altes Gerät wie ich wo Auto Assist / Geofence halt ein garantiertes Feature war) sind die 100 Anfragen am Tag sehr wenig, vor allem wenn man mehrere Heizkörperthermostate hat etc.

Dementsprechend steil gehen gleich viele User auf Github im Home Assistant Issue Tracker:

https://github.com/home-assistant/core/issues/151223

Ich habe da meine Meinung auch kund getan und dafür natürlich kein „Daumen hoch“ bekommen. Eher recht viele Downvotes, aber gut es ist halt Github: das X der Codehosting Plattformen. Codeberg.org ist die nettere Alternative (schamlose Werbung für dieses tolle Projekt).

Nichtsdestotrotz: Manche haben tausende Pfund / Euro etc. für die Tado Hardware ausgegeben, gerade wegen der inoffziellen offenen Cloud API (hört sich blöd an ist aber scheinbar so), und scheuen sich jetzt die 30€ im Jahr extra für den Auto Assist auszugeben. Die meisten davon haben diese Hardware auch Freunden und Familie empfohlen wegen der offenen inoffiziellen Cloud API. Wie steht man denn jetzt nur da.

Ehrlich gesagt fehlte hier wahrscheinlich bei den Projekte wie Home Assistant etc. ein großer warnender Hinweis. Woher soll der normaler User auch wissen das die Integration auf das Wohlwollen des Herstellers angewiesen ist.

Tado wirft man jetzt vor nur zusätzlich Kasse machen zu wollen, indem man die ganzen Home Assistant etc. User in ein Subscription Modell treibt. Abwegig ist das nicht nicht. Cloudserver wollen bezahlt werden und nur noch wenige Hardware Hersteller deren Produkt Cloudfeatures benötigt kommen ohne ein Abo Modell aus. Warum sollte es bei Tado anders sein. Denn ganz ehrlich, wenn es nur an einigen wenigen Akteuren liegt die die API missbräuchlich nutzen (wie in der Mail beschrieben), könnte man diese sicher auch auf anderem Wege blocken ohne alle API User abzustrafen.

Aber ganz ehrlich: dieses rumgejammer der Community ist doch nur peinlich. Nur weil man sich vorher nicht vernünftig informiert hat, sich so über den Hersteller zu echauffieren, ist doch kindisch.

Möchte ich ein Produkt was ohne Cloud Zwang auskommt, und dazu kann ich nur raten, dann muss ich mich vorher gründlich informieren. Kaufe ich ein Produkt was auf der inoffiziellen Cloud Api des Herstellers aufbaut kann ich mich nicht beschweren wenn die auf einmal weg ist. Und hier ist Sie ja noch nicht einmal weg.

#cloudzwang #fhem #homeassistant #openhab #smarthome #tado

@bjoern

Orrr. APIs nicht-rückwärtskompatibel ändern, wer kommt auf so Blödsinn? In dem fall #Shelly

Usecase: Terrasse hat Licht mit Bewegungsmelder. Wenn man im Sommer abends draußen sitzt will man aber auch dauer-an oder dauer-aus haben. Also Shelly zwischen BWM und Lampe gepackt.

Mit #FHEM über MQTT dann auf Wunsch input detached gesetzt (nicht output zugehörig) und den output auf an oder aus.

Für Normalbetrieb mit BWM den Ausgang wieder auf Follow-Input, dass es auch bei Ausfall WLAN/FHEM geht.

Wo wird eigentlich FHEM in 10 Jahren stehen? 🤔 Wird es das Projekt sein, dass irgendwann nur noch von denjenigen eingesetzt wird, die selbst daran schrauben? Versteh mich nicht falsch, aber bei FHEM wird ein wichtiges Bedürfnis von mir schon allein durch die Screenshots nicht erfüllt: Eine ansprechende Optik. 😞 FHEM ist ein bisschen der Onkel, der seit 40 Jahren den gleichen Pulli trägt beim Familienfest. #FHEM #SmartHome #HomeAutomation #TechnikTrends

@spmrider Bei dem Board hätte das sogar sein können. Das konnte damals gut in #FHEM integriert werden 🙂

@bodomenke @rsa mit perl doifs können eigene Automationen programmiert werden. Also nicht im yaml Syntax, sondern mit einer Programmiersprache. In #fhem mit Perl, da die Software darauf basiert.

@rsa mir fehlen die #fhem perl doifs in #homeassistant am Meisten. Ich habe keine Entsprechung dafür gefunden. Habe ich was übersehen?

Ich habe gerade testweise #HomeAssistant installiert. Was soll ich sagen… ich denke #fhem wird die längste Zeit mein #smarthome gewesen sein. Auch wenn ich wenig Lust auf die Migration hab. Fhem läuft bei mir seit 9 Jahren und das kommt was zusammen. Aber was HA schon alles ohne zutun mitbringt ist sehr überzeugend.

ziemlich happy mit der Energiefluss Visualisierung in #HomeAssistant 😁

Die Powercalc Integration ist da wirklich sehr ausgefuchst. Die Communities aus #fhem und #iobroker haben gute Vordenkerarbeit geleistet, auch wenn es sich nun „leider“ woanders auszahlt 🤷‍♂️

#homeautomation #stromverbrauch #stromzähler #balkonsolar #balkonkraftwerk #elektromobilitat #elektroauto

@rsa ich hab mir an #fhem damals die zähne ausgebissen und bin sooooo froh dass ich auf #homeassistant umgestiegen bin!

zwischen den zwei systemen liegen welten!

Ist schonmal wer von #fhem auf #homeassistant umgestiegen? Hat sich der Schritt gelohnt?

#smarthome

Ich möchte einmal ein Zwischenfazit über unsere Rebellen-Solatr-Anlage ziehen.
Zur Erinnerung, wir haben ein Balkonkraftwerk, das maximal 800 Watt Leistung abgeben kann. Diese 800 Watt gibt es aber, beim Winkel unserer Anlage, maximal Ende Juni, Anfang Juli. Aktuell kommen wir kaum noch über 600 Watt. Die Anlage ist abgeregelt, d.h. sie läuft in Abhängigkeit vom Verbrauch. Da Ferien sind läuft hier ein Gaming-PC, eine Abregelung findet also kaum statt. Ohne Gaming-PC haben wir hier einen Grundbedarf von ca. 250 W. Sprich, dieser Wert wird quasi nie unterboten.
Neben diesem Balkonkraftwerk haben wir noch weitere 8 Panel, die einen Akku speisen. Ist der Verbrauch im Haus höher als das Balkonkraftwerk liefert, können bis zu 800 Watt zusätzlich ins Haus eingespeist werden. Um halbwegs rechtskonform zu sein, werden niemals mehr als 800 Watt insgesamt bereitgestellt. Die 10 Panel waren schon installiert, bevor die Modulleistung nicht mehr 2000 W übersteigen durften.

Was kommt aus der Gesamtanlage heraus?

Mit dem Balkonkraftwerk können wirjetzt in der hellen Jahreszeit maximal 4 kWh Eneergie einsammeln. Die Batterie speichert 7 kWh. Natürlich können die Panel, die die Batteriespeisen auch direkt ins hausnetz einspeisen (steuerungstechnisch aber wie angesprochen insgesamt nur 800 W insgesamt). Aktuell sammeln wir so um 12 kWh pro Tag ein.
Unser Mehrbedarf liegt bei ungefähr 10 kWh pro Tag. Durch unsere Anlage reduziert sich der Energiebezug aktuell also auf die Hälfte unseres gesamten Stromungers.

Anders ausgedrückt, statt 24kWh pro Tag müssen wir nur knapp 12 kWh pro Tag bezahlen.

Nun wird es spannend zu sehen, ob diese Rechnung ungefähr 210 Tage im Jahr funktioniert, bzw. ob wir 12 kWh pro Tag x 210 Tage pro Jahr einsparen. bei unserem aktuellen Strompreis rechnen sich alle Investitionskosten (also *WIRKLICH* alle, Kabel, Stecker, Sicherungen etc.) nach ca. 6 Jahren.

Was bleibt festzustellen:

1. 7 kWh-Batterie sind im Sommer ok, von 24 h hilft sie ungefähr 19 h, dass der Energiebezug nicht ins uferlose abgleitet.

2. 8 Panel laden im Sommer diese 8 kWh relativ sicher auf

4. Es gibt noch eine Energielücke von grob 4 kWh, die ein Akku noch zusätzlich liefern müsste. Dann sind aber mindestens 6 weitere Panel erforderlich.

5. Im Winter werde ich definitiv zu wenige Panel haben. Das ist aber besser, als wenn ich im Sommer den Akku über 24 h nicht wenigstens einmal geladen UND entladen bekomme.

6. Aktuell ist die Akku-Technik mit ca. 30% an den Gesamtkosten beteiligt. Ein weiterer Akku würde den Kosteenanteil auf ca. 50% heben (da sind 6 panel und die notwendige Verkabelung schon berücksichtigt). Die vorhandene Technik, MPPT, DC-DC-Konverter, Wechselrichter, verkraften grob 8 weitere Panel: insgeamt 2x(2x(4in Reihe)parallel)parallel). Was 126 V bei 2x26 A bedeutet. Oder maximal 6560 W. (+ 800 W Balkonkraftwerk).

#solar #photovoltaik #technik #panel #mppt #wechselrichter #victron #orion #pylontech #fhem