#fhem — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #fhem, aggregated by home.social.
-
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...
-
@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...
-
Für unser Sagiri-Infoterminal haben wir uns ein kleines Feature überlegt: die „Wetter-Ami“.
In charmanter Anlehnung an den klassischen „Wetter-Willi“ bekannter Heim-Wetterstationen zeigt unsere kleine Figur das aktuelle Wetter an, indem sie sich passend zur Temperatur kleidet.
Ursprünglich reichte unsere Skala von klirrenden -10 °C (Ami dick eingepackt im Schnee-Overall) bis hin zu sommerlichen 30 °C (Ami als fröhlicher Nacktspatz).
Doch dann knackten wir vor ein paar Wochen plötzlich die 35-Grad-Marke.
Das brachte uns ins Grübeln: Wie visualisiert man eine noch größere Hitze, wenn das Maskottchen eigentlich schon alle Hüllen fallen gelassen hat?
Die Lösung: Ami sitzt auf einem Eisblock, meditiert und genießt die Kühle. (Und bevor jetzt medizinische Bedenken wegen einer drohenden Nierenbeckenentzündung aufkommen – es geht hier rein um die Symbolik! 😉)
Vor ein paar Tagen dann die nächste Hiobsbotschaft der Wetterdienste: Es muss mit Temperaturen von über 40 °C gerechnet werden. Verdammt! Wie sollten wir da noch einmal nachschärfen?
Die Antwort ist so pragmatisch wie dramatisch: Wir belassen Ami auf ihrem Eisblock, entfachen aber um sie herum ein loderndes Höllenfeuer. Das Inferno ist optisch so gigantisch, dass einem schon beim bloßen Hinsehen der Schweiß ausbricht.
Und falls sich jemand fragt: Nein, 50 °C werden wir nicht mehr implementieren. Das wäre dann nur noch ein brennender Friedhof.
Für alle Technikinteressierten gibt es hier das kleine Programm für unsere Wetter-Ami. Wir haben aktuell sieben verschiedene Ami-Stile im Einsatz. Der folgende Code zeigt, wie die Website die entsprechenden Temperaturwerte direkt aus FHEM ausliest:
```
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Wetter-Ami & Home Control</title>
<style>
/* GRUNDSTRUKTUR */
body {
margin: 0;
padding: 0;
display: flex;
width: 100vw;
height: 100vh;
overflow: hidden;
background: transparent;
font-family: 'Segoe UI', Tahoma, sans-serif;
}/* SIDEBAR LINKS */
aside {
width: 280px;
height: 100vh;
background: rgba(240, 240, 240, 0.7);
padding: 15px;
box-sizing: border-box;
border-right: 1px solid rgba(0,0,0,0.1);
overflow-y: auto;
flex-shrink: 0;
}/* HAUPTBEREICH RECHTS */
main {
flex-grow: 1;
display: flex;
flex-direction: column;
justify-content: center;
align-items: center;
position: relative;
}/* BUTTON STYLING */
cv-nav ul {
margin: 0;
padding: 0;
}cv-nav li {
list-style: none;
margin: 0 0 .6em 0;
padding: 0;
width: 100%;
}cv-nav a {
display: block;
padding: 1.2em 0.5em;
text-decoration: none;
font-weight: bold;
text-align: center;
border: 2px solid black;
border-radius: 12px;
box-shadow: 0 5px 10px white inset;
color: black;
background-color: #FCB900;
transition: all .2s ease-in-out;
cursor: pointer;
font-size: 1.1em;
}/* HOVER / TOUCH EFFEKT */
cv-nav a:hover,
cv-nav a:active {
color: black !important;
background-color: #a2f740;
transform: scale(1.02);
box-shadow: 0 2px 5px rgba(0,0,0,0.2);
}/* RESPONSIVITÄT FÜR HANDYS */
@media (max-width: 800px) {
aside {
width: 200px;
padding: 10px;
}
cv-nav a {
font-size: 1em;
padding: 1.4em 0.3em;
}
#info-display { font-size: 1.5rem !important; }
}/* WETTER ANZEIGE */
#info-display {
position: absolute;
top: 20px;
font-size: 2.2rem;
font-weight: bold;
color: #333;
text-shadow: 1px 1px 2px white;
}#wetterbild {
max-width: 95%;
max-height: 70vh;
width: auto;
height: auto;
opacity: 0;
transition: opacity 0.5s ease-in-out;
}.visible { opacity: 1 !important; }
</style>
</head>
<body><aside>
<cv-nav>
<ul>
<li><a onclick="setFhem('Licht_Aus', 'on')">Alles AUS</a></li>
<li><a onclick="setFhem('Licht_Aus_Kamin', 'on')">Kaminzimmer AUS</a></li>
<li><a onclick="setFhem('Licht_Aus_Kueche', 'on')">Küche AUS</a></li>
<li><a onclick="setFhem('Licht_Eingang_Ost', 'off')">Außen AUS</a></li>
<li><a onclick="setFhem('Licht_Flur_oben', 'off')">Oben AUS</a></li>
<li><a onclick="setFhem('Licht_Aus_Salon', 'off')">Kino AUS</a></li>
<li><a onclick="setFhem('Licht_Schlafzimmer_Ron', 'toggle')">Nachttisch Ron</a></li>
<li><a onclick="setFhem('Licht_Schlafzimmer_Elisa', 'toggle')">Nachttisch Elisa</a></li>
<li><a onclick="setFhem('Licht_Aus_Schlafzimmer', 'on')">Schlafzimmer AUS</a></li>
<li><a onclick="setFhem('Licht_Aus_Dusche', 'off')">Dusche AUS</a></li>
<li><a onclick="setFhem('Licht_Aus_Bad', 'off')">Bad AUS</a></li>
<li><a onclick="location.reload()">Refresh</a></li>
</ul>
</cv-nav>
</aside><main>
<div id="info-display">--°C / --% Hum.</div>
<img id="wetterbild" src="" alt="Wetterbild">
</main><script>
const FHEM_BASE = "http://shinobu:8083/fhem";
const WETTER_DEVICE = "Wetter_FuchsbauIP";
const IMAGE_BASE = "http://lala/Wetter-Ami/";
// HIER: Anzahl der Grafiksets definieren
const NUMBER_OF_SETS = 7;async function setFhem(device, command) {
const url = `${FHEM_BASE}?cmd=set%20${device}%20${command}&XHR=1`;
try {
await fetch(url);
console.log(`Befehl an ${device}: ${command}`);
} catch (e) { console.error("Fehler:", e); }
}async function updateWeather() {
try {
const url = `${FHEM_BASE}?cmd=jsonList%20${WETTER_DEVICE}&XHR=1`;
const response = await fetch(url);
const data = await response.json();
if (!data.Results) return;
const readings = data.Results[0].Readings;const temp = readings["1.ACTUAL_TEMPERATURE"] ? parseFloat(readings["1.ACTUAL_TEMPERATURE"].Value) : 0;
const hum = readings["1.HUMIDITY"] ? parseInt(readings["1.HUMIDITY"].Value) : 0;
const rain = readings["1.RAINING"] ? readings["1.RAINING"].Value : "no";displayWeather(temp, hum, rain);
} catch (e) { console.error("Fehler:", e); }
}// NEU: Funktion zur Berechnung des tagesaktuellen Sets
function getCurrentSet() {
const now = new Date();
const startOfDay = new Date(now.getFullYear(), now.getMonth(), now.getDate()).getTime();
const localDays = Math.floor(startOfDay / (1000 * 60 * 60 * 24));
return (localDays % NUMBER_OF_SETS) + 1;
}function displayWeather(t, h, isRaining) {
const img = document.getElementById('wetterbild');
const info = document.getElementById('info-display');
info.innerText = `${t.toFixed(1)}°C / ${h}% Hum.`;let nr = "";
if (t >= 40) nr = "000";
else if (t >= 35) nr = "00";
else if (t > 30) nr = "10";
else if (t > 28) nr = "20";
else if (t > 26) nr = "30";
else if (t > 24) nr = "40";
else if (t > 22) nr = "50";
else if (t > 20) nr = "60";
else if (t > 18) nr = "70";
else if (t > 15) nr = "80";
else if (t > 13) nr = "90";
else if (t > 10) nr = "100";
else if (t > 5) nr = "110";
else if (t > 0) nr = "120";
else if (t > -5) nr = "130";
else if (t > -10) nr = "140";
else nr = "150";const rainBool = (isRaining === true || isRaining === "yes" || isRaining === "1" || isRaining === "true");
// NEU: Aktuelles Set abfragen
const activeSet = getCurrentSet();// NEU: activeSet in die URL einbauen (z.B. http://lala/Wetter-Ami/2/100r.png)
img.src = `${IMAGE_BASE}${activeSet}/${nr}${rainBool ? "r" : ""}.png`;
img.onload = () => img.classList.add('visible');
}window.addEventListener('DOMContentLoaded', () => {
updateWeather();
setInterval(updateWeather, 60000);
});
</script></body>
</html>
```#fhem #wetterwilli #amichan #mizuno #sailormerkur #hitze #isgarnichtwarm
-
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.
-
@ron Ui... Das ist ne grosse, coole Migration! Wir bleiben noch bei #FHEM, auch wenn ich parallel eine #homeassistant Instanz am laufen habe, um manchmal, durchaus etwas neidisch, zu schauen was da so geht.
Wir haben ziemlich viele Homematic Komponenten wo fhem auch nativ die Zentrale ist, also ohne HM-CCU. Wie wirst du diese Komponenten in HA ansteuern?
-
**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-InventurBeispiel:
{ 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 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-InventurBeispiel:
{ 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.
-
**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
-
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. -
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
-
**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?
-
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 ü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 😁 -
**Der Weg zum individuellen Smart Home: Abschied von Amazon Echo & Einzug von Node-Red**
Vor einiger Zeit haben wir eine Entscheidung getroffen: Die Amazon-Echo-Geräte müssen nach und nach weichen. Den Anfang machte unser Echo Show 15, der durch ein **43-Zoll-Touchdisplay** ersetzt wurde. Da ein so großes Display auch eine entsprechende Oberfläche braucht, haben wir uns für ein komplett eigenständiges Infosystem auf Basis von **Node-Red** entschieden.
Hier laufen jetzt alle Fäden zusammen: Fahrpläne, das aktuelle Wetter, unsere Kalender und die Energieverbräuche im Haus sind auf einen Blick sichtbar.
**Warum Node-Red und nicht FHEM-Boardmittel?**
Unser Backend ist zwar weiterhin #FHEM, aber die nativen Oberflächen (wie das ansonsten sehr gute FUI) stießen bei meinen individuellen Wünschen an ihre Grenzen. FUI ist klasse, bleibt aber weitgehend im FHEM-Kosmos.
Mit Node-Red habe ich dagegen die volle Freiheit:
Die Einbindung externer Dienste ist wesentlich flexibler.
Die Gestaltung der Ansichten (Wetter, Kalender etc.) ist völlig frei.
Ein besonderes Highlight: Ich habe den bekannten „Wetter-Willy“ nachprogrammiert – allerdings in einer speziellen Version. Bei uns ist es **Ami (aus Sailor Moon)**, die je nach Wettervorhersage automatisch die passende Kleidung anzieht. Ein kleiner Nerd-Faktor, der das System erst richtig sympathisch macht! ✨
**Die mobile Ergänzung: Der „kleine Bruder“ für die Hosentasche**
Da man nicht immer vor dem großen Display steht, wollte ich die gleiche Logik auch für die schnelle Bedienung am Smartphone haben.
Entstanden ist eine mobile Node-Red-App, die auf pure Effizienz getrimmt ist. Kein langes Suchen in irgendwelchen tiefen Menüstrukturen, sondern direkter Zugriff auf das Wichtigste:
Morgens mit einem Klick die benötigten Lampen steuern.
Ein schneller Blick in den Tageskalender.
Alles optimiert für die „Ein-Hand-Bedienung“ zwischendurch.
**Wie geht es weiter?**
Zugegeben, durch diese neue Oberfläche hat sich FHEM bei uns wieder ein wenig Verweildauer „erkauft“. Das System läuft stabil, aber perspektivisch steht auch hier eine Ablösung auf dem Plan, um das Setup noch moderner zu gestalten.
Es bleibt ein Work-in-Progress – genau wie die vollständige Ablösung von Amazon. Aber mit dem 43-Zöller und der neuen Handy-App ist ein großer Meilenstein erreicht und der Kreis schließt sich langsam.
#SmartHome #HomeAutomation #NodeRed #FHEM #SailorMoon #AmiMizuno #DIY #SelfHosted #Visualisierung #Dashboard #OpenSource #AmazonExit
-
So, mal Klartext: Der Echo Show 15 bei uns im Flur ging mir schon ewig dermaßen auf den Keks!
Das Ding mutiert zur reinen Dauerwerbesendung, die man nicht mal abstellen kann. Und der Nutzen? War eh schon immer mau. Als Bilderrahmen ein Witz (viel zu klein!) und die Zwangswerbung war echt der Showstopper.
Es war Zeit, den Anfang vom Ende der Amazon-Ära bei uns einzuläuten!
Rauswurf! Der Echo Show 15 war das erste von 12 (!) Geräten (Echos, FireTV, etc.), das hochkant rausflog. Ganz ehrlich, das Teil war (direkt nach der lahmen FireTV Box ohne GBit-LAN) der absolute Fehlkauf des Jahrhunderts. Also: Weg mit dem Schrott!
Okay, ABER: So ein Info-Screen im Flur... Kalender, Wetter, schnelle Notizen... das war schon praktisch. Das wollten wir irgendwie behalten.
Und wie es der Zufall so will: Nach 'nem Hardware-Shuffle bei uns stand plötzlich ein fetter 43-Zoll 4K-Monitor arbeitslos rum. Gleichzeitig langweilte sich mein Raspi 400 ("Sagiri") zu Tode.
Moment mal... Monitor? Check. Computer? Check. Hmmmm... Da geht doch was!
Blöd nur: Im Flur mit 'ner Maus rumfummeln? Nee, danke. Der Echo Show hatte ja wenigstens Touch. 'ne Touchfolie für den 43-Zöller? Kurz gegoogelt und... HOLY MOLY! Schweineteuer. Da bist du sofort im vierstelligen Bereich. Vergiss es.
Irgendwann bin ich dann über Infrarot-Rahmen gestolpert (GreenTouch, für die Nerds). Das Ding packst du quasi *vor* den Monitor. Innen sind LEDs, die ein unsichtbares Gitter spannen. Finger durch? BÄM – Touch-Eingabe! Ob das klappen kann?Und WIE das klappt! Das rockt richtig!
Unser Monitor hat kaum Rand, aber egal. Den IR-Rahmen pappt man mit Doppeltape drauf. Ein bisschen Nervenkitzel war's schon – bei dem Tape hast du nur *einen* Versuch, keine Korrektur. Also, zu zweit, paar Mal "trocken" geübt, angehalten, Luft angehalten... und... passt! Monitor hochkant gedreht – zack, 43-Zoll-Touch-Tablet!
Hardware steht. Jetzt die Software. Was soll drauf? Wie soll's aussehen?Der Plan: Wir drei (meine Familie) kriegen eigene, persönliche Dashboards. Weil ich eh mittelfristig von FHEM weg will (Richtung HomeAssistant) und die Standard-Dashboards alle lahm fand, hab ich alles in NodeRed gebaut. Damit hatte ich ja schon bei FHEM und meinen Victron-Sachen rumgespielt.
Bei der Optik hab ich mich fett bei Star Trek bedient: LCARS! Oben 'ne Leiste für unsere persönlichen Ansichten, links ein Menü für spezielle Seiten, rechts schnelle Status-Infos. Und ganz unten ballert ein RBB24-Newsticker durch.
Was muss rein? Klar: Unser Kalender, Wetter, Lichter ausknipsen, Haus-Status. Absolutes Must-have: Robins Stundenplan (heute/morgen), der natürlich Ferien und Feiertage checkt. Und weil's geht: Abfahrtszeiten vom Bus um die Ecke.
Das Teil soll natürlich nicht 24/7 leuchten. Plan A (der coole Plan): Kamera drüber! Wenn einer davorsteht -> Display an. Und (jetzt kommt's!): Gesichtserkennung! Das Display sollte *wissen*, wer ich bin und *meine* Seite zeigen. Für Gäste gab's 'ne Touri-Seite.... Tja. Das war dann wohl *etwas* zu ambitioniert.
Problem 1: "Sagiri" (der Raspi) kriegt den Monitor nicht aus. HDMI abschalten? Fehlanzeige. Lösung? Der gute alte Holzhammer: 'ne Funksteckdose, die in FHEM hängt. Sagiri funkt jetzt an FHEM: "Mach Saft an!" oder "Mach Saft aus!". Klappt.
Problem 2: Die Gesichtserkennung. Lief... naja... instabil. Lag vielleicht weniger am Raspi als an meiner Faulheit, tausend Trainings-Fotos von uns zu machen. Egal. Plan B: Die Kamera checkt jetzt nur *ob* einer da ist. Display geht an. Und die eigene Seite? Ist ja nur einen Fingertipp entfernt. Passt auch.
Aber fast wär's GANZ gescheitert! Der Standard-USB-Kamera-Node in NodeRed ist andauernd abgeschmiert. Nach 'ner Stunde war Schicht im Schacht. Panik! Zum Glück hab ich irgendwo einen 8 (!) Jahre alten, völlig verstaubten Node ausgegraben, den ich eigentlich nie nutzen wollte... und siehe da: Das Ding läuft stabil wie ein Panzer! (Und wenn der auch zickt, kommt 'n oller Bewegungsmelder drüber. Das geht *immer*.)
So! Hardware: Check. Software-Hürden: Genommen. Der Rest war pure Fleißarbeit am Code.
Und jetzt? FERTIG! Unser "LCARS-Echo-Killer" hängt und läuft. Hat mich alles in allem (Material besorgen + Programmieren) gut zwei Wochen gekostet.
Und jetzt grübel ich... Hmmmm... Was, wenn ich den 65-Zöller in der Küche auch... *touchy* mache? Die FireTV Box nervt mich eh. Der TV könnte doch GoogleTV... Nur mal so'n Gedanke...
#pi400 #nodered #fhem #echoshow #lcars #fhem #smarthome #dashboard #greentouch
-
@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.
-
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.
-
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.
-
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.
-
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
-
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
-
Die Installation einer Wallbox haben wir genutzt, einen Shelly Pro 3EM in den Sicherungskasten zu integrieren.
Ich wollte endlich sehen, wieviel Leistung wir wirklich abrufen.
Der Shelly ist ein 3-Phasen-Messgerät. Die Leistung wird induktiv gemessen.
Die Installation war einfach, da spare ich mir ein näheres Beschreiben.
Doch der erste Eindruck war ernüchternd. keines meiner erhofften Ziele wurde unmittelbar erreicht (Bild 1)
Weder konnte ich sagen, wieviel Leistung WIRKLICH gerade von meinen Geräten gezogen wurde, noch wieviel in Netz an eigener Leistung eingespeist wurde.
Zum Glück messe ich den Solar-Ertrag separat und speichere diesen Wert in ein laufend (alle 5 Sekunden) aktualisiertes Reading.
Addiere ich nun die Active Power aller drei Phasen und addiere den Solarertrag, habe ich den gesamten Leistungsabruf.
Der Shelly wird in FHEM per MQTT eingebunden.
Am state-format etwas herumgefriemelt, ergibt sich auch eine akzeptable Anzeige (Bild 2).Wozu brauche ich diesen Gesamtleistungswert? Ich kann damit das Zuschalten der Batterie viel besser auf den Leistungspunkt steuern. Vor dem Shelly fehlten mir immer ca. 50-150 Watt (+ Heizungskessel, dessen Messschalter mir zwischenzeitlich kaputt gegangen ist. Die Heizung selbst zieht zwischen 1500 Watt (Anzünden) und 150 Watt normaler Betrieb mit allen Pumpen etc.), die ich nicht gemessen hatte und die damit immer aus dem Netz bezogen werden mussten, obwohl Akku-Strom vorhanden war. Ganz sauber ist das noch nicht, da die Victron-Orions keine auf den Punkt gebrachte Leistung bereitstellen. Ein Orion kann bis zu 50 Watt mehr (oder weniger) Leistung liefern, als er grundsätzlich soll. Und auch während des Betriebes bleibt die Leistung nicht konstant. Insbesondere wenn die Orions heiß werden, und sie werden SEHR heiß, sinkt ihr Wirkungsgrad.
Daher investiere ich ja soviele Ideen in die Kühlung. Mittlerweile wird kein Orion mehr über 60°C warm, selbst die 50°C werden nur noch selten überschritten. Positiv ist, dass die Kühlung an der Energie-Ausbeute nichts negativ verändert hat. Denn der bessere Wirkungsgrad wird durch die Kühlung nicht aufgefressen. Die Geräte fahren also auf weniger Verschleiß und liefern sogar geringfügig mehr Energie als Strom, als durch die Kühlung "verloren" geht.
BTW: Der Energieverbrauch, der mit dem Shelly gemessen werden kann, interessiert mich allerdings gar nicht. Ich habe direkt vor unserem Zähler einen Sensor sitzen, der ca. alle 5 min den Zählerstand übermittelt. Da sich der Zähler innerhalb von 5 min nur wenig ändert, reicht mir das.
-
So, mittlerweile ist es doch akut geworden, sich über das Logging in FHEM Gedanken zu machen. Nach 1,5 Jahren haben sich 87.000.000 Datensätze haben sich in der DbLog angesammelt. Vernünftig handhaben lassen sich diese Daten kaum.
Es ist also Zeit sich einmal grundlegende Gedanken zum logging zu machen.
1. Grundregel: Logging generell ausstellen für JEDES neue Gerät. In die fhem.cfg gehört dieser Befehl:
```
attr global DbLogExclude .*
```Damit wird erreicht, dass kein Gerät Daten loggt. für jedes Gerät wird explizit entschieden, ob es geloggt werden soll:
```
attr DEVICE DbLogInclude READING1,READING2,READING3
```2. Nur Veränderungen werden geloggt:
Ohne die folgende Zeile wird *SEHR* viel protokolliert.```
attr DEVICE READING1,READING2,READING3
```Damit werden nur geänderte Daten geloggt.
3. Genau überlegen, wofür man die geloggten Daten *WIRKLICH* braucht.
Mir fallen nur 2 Gründe ein: um Fehlern auf die Schliche zu kommen, für Diagramme (Plots, also statistische Erhebungen). Es werden beim Logging ja zwei Tabellen bedient: Eine Tabelle enthält immer den letzten Wert und eine Tabelle enthält auch historische Werte. Wann immer auf aktuelle Werte zurückgegriffen werden soll, wird die current-DB bemüht und nur für Plots und dergleichen wird auf die Histrory zurückgegriffen. Und genau diese wird sehr schnell sehr gross. Bei mir nach 1,5 Jahren knapp 1 TB.Und je größer die Datenbank, bei MariaDB wird der Zugriff auf die Daten immer langwieriger. Und irgendwann ist sogar das Löschen kaum noch möglich.
Ich habe Schritt für Schritt angefangen zu löschen
```
set DBLog delete OldDays TAGE
```löscht alles, was älter als TAGE ist. Ich habe Monatsweise gelöscht. Mein System löscht ungefähr 300.000 Datensätze pro Stunde. Pro Monat sind ungefähr 5 h notwendig. In der zeit kann nicht in die Datenbank geschrieben werden. Es gehen aber keine Daten verloren, sie werden zwischengepuffert. Bei mir waren das durchaus im Bereich 30.000 bis 40.000 Datensätze. Ich weiss nicht, wieviele Datensätze das System zwischenspeichern kann... Da ich zum tageswechsel rechenintensive Routinen laufen habe, hab ich es immer so getimet, dass ich weit vor Mitternacht aufgehört habe. Nach 3 Tagen hatte ich ein halbes Jahr Daten über Board gekippt.
4. Da im Laufe der Zeit immer mehr protokolliert wurde, habe ich mich rangesetzt, und bin die Geräte durchgegangen und hab Unsinniges gelöscht. Dazu habe ich aber eine Liste aller Devices gebraucht. Über FHEM weiss ich nicht, wie man hier eine Liste bekommen kann. Das habe ich daher ausserhalb von FHEM gemacht: mit phpMyAdmin. Der folgende SQL-Befehl gibt alle Devices aus und sagt auch, wie viele Datensätze enthalten sind.
```
SELECT history.DEVICE, Count(history.DEVICE) AS
AnzahlvonDEVICE
FROM history
GROUP BY history.DEVICE;
```sowas kommt dabei raus:
```
Robin_6fachTaster6 6
RonIP 3608305
RouterIP 176987
Schlafzimmer_Thermostat_Clima 30604
Serverstrom 2252086
ShellyBad 63924
SpielZimmer_Heizung_Messwerte 675
```DIe Geräte mit nur wenigen Treffern sind egal, da wird eher nichts (mehr) protokolliert. Aber alle anderen schaut man sich an. Bei Thermostaten kann man viel sparen: denn wenn man neben dem Stellmotor noch einen Wandthermostaten verwendet, braucht man beim Stellmotor ausser der Ventilöffnung, wenn man die braucht, werden Temperatur noch Luftfeuchtigkeit protokollieren, das tut man beim Wandthermostaten.
Bei Strommessern habe ich die Stromstärke mitgeschrieb en. Wozu? Hab ich noch nie gebraucht.
Bei Schaltern braucht man nicht mitloggen, wie oft man geschaltet hat. u.s.w. u.s.f.
Ich werde jedenfalls noch weiter löschen, bis ich beim 1.1.25 angekommen bin. Da ich zwischenzeitlich die zu speichernde Datenmenge ordentlich ausgemistet habe. Sollten die anfallenden Daten überschaubar sein. Am Interessantesten sind bei mir die Energie-Messwerte. Da könnte man überlegen, ob man die Daten nicht FHEM ausdünnen läßt. z.B. einmal im Monat schmeisst man alles weg, ausser den letzten Wert. Oder man mittelt die tageswerte und hebt nur den Mittelwert auf. Mal schauen. Aber insgesamt denke ich, alles was länmger als 1 Monat zurückliegt, ist eher uninteressant und kann weg. Aber als Daten-Messi fällt es natürlich schwer, sich von Datenmüll zu trennen!
#fhem #dblog #mariadb #wermisstmisstmist -
@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.
-
Wegen unsererem Terrorkessel wollte ich in unserer FHEM Anzeige, wir nutzen FUIP, welches echt ganz große Klasse ist, eine Übersicht über unsere Thermostate haben. Natürlich hat FUIP hier eigens dafür konstruierte Views enthalten (Views sind das, was andere Oberflächen möglicherweise mit Widgets, Komponenten, Controls, Steuerelemente etc. benennen). Aber die waren mir zu groß, zu analog oder eben nicht für eine Übersicht geeignet.
Mir schwebte so etwas wie in Bild 1 vor. Das für EINEN Thermostaten zu realisieren ist auch gar nicht so schwer:
1x FUIP::View::Select um die Temperatur einzustellen (man kann hier schön all die Werte weglassen, die man nicht braucht (bei mir nur Werte von 15 bis 25°C möglich)
1x FUIP::View::LabelTemperature um die IST Temperatur anzuzeigen
2x FUIP::View::LabelHumidity um die Luftfeuchtigkeit und die Öffnung des Motorventils am Stellmotor anzuzeigen.Alles in allem muss man also 4 Geräte auswählen, 4 Readings, 4 Beschriftungen, 4 Titelbezeichnungen und ggf. das eine oder andere am Aussehen ändern.
Bei 10 Ventilen sind das 160 Einstellungen. Uhhhh... das ist viel.
Das muss doch einfacher gehen. Zum Beispiel in dem ich das für ein Gerät anlege und dann einfach 9 mal dupliziere. Da die Geräte nur unwesentlich anders heissen, alle die gleichen Readings haben, würde sich der Aufwand massiv reduzieren.
Lange Rede kurzer Sinn: Eine Möglichkeit, mehrere Views zu duplizieren gibt es nicht.
Aber durch das intensive Lesen diverser Anleitungen, auch hier vielen Dank, FUIP ist aktuell schon ziemlich gut dokumentiert, habe ich eine einfache Lösung gefunden. Ich habe die 4 Views aus Bild 1 zu einem Template gemacht. Und man kann die jeweiligen Devices und Readings als Variablen festlegen (Bild 2). Und natürlich kann man diese variablen Felder schon vorbelegen. Zur Erinnerung: Bei mir unterscheiden sich die Gerätenamen durch eine feste Namenskonvention nicht allzusehr. Damit wähle ich als View nicht die einzelnen Views aus, sondern das von mir definierte Template, passe die Devices an und natürlich die Beschriftungen und einmal den Titel der Views (Bild 3, hier ohne die Möglichkeit das Reading auszuwählen, da das bei mir nicht notwendig ist, da dieses bei allen Heizungsthermostaten bei mir gleich war, aber gemäß Bild 2 kann man das natürlich auch selektierbar machen, wenn man es braucht) und innerhalb weniger Minuten waren die 10 Anzeigen definiert (Bild 4)
#fhem #fuip #views #templates #duplizieren #variabel #devices #readings #thermostat #smarthome
-
Am 13. Januar hatte ich einen 4fach-Zigbee-Taster in FHEM eingebunden (MQTT).
```
Readings
IODev mqttBroker
Kaminzimmer4fachTaster_action 3_double
...
Kaminzimmer4fachTaster_battery 100
availability online
```Mittels notify habe ich das einzige relevante Reading abgefragt (Kaminzimmer4fachTaster_action).
Es hat auch grundsätzlich das getan, was ich erwartet habe. Nur war der Schalter unerwartet zickig.
Aus heiterem Himmel ging plötzlich das Licht an oder aus.Zuerst hatte ich das manchmal sehr langsame abarbeiten im Verdacht.
Aber dann war es plötzlich unerwartet einfach und ich habe zum ersten Mal das Attribut "event-on-change-reading" begriffen.
Diesem Attribut habe ich das Reading "Kaminzimmer4fachTaster_action" zugewiesen (siehe Readings-Auszug oben). Und schon verhielt sich die Zicken-Biene nicht mehr zickig.
Was macht das Attribut?
Nun, es sorgt dafür, dass nur dann ein Event ausgelöst wird, wenn sich das Reading wirklich (!) ändert. Notify war ja auf genau das Reading angesetzt. Sprich: wenn sich das Reading ändert, soll die im Notify programmierte Funktion abgearbeitet werden (Kurzgefasst, das jeweilige Licht an- oder ausschalten)
Jetzt ist der Taster Batteriebetrieben. Das bedeutet, er geht regelmäßig in den Energiesparmodus. Und jedesmal wenn er aufwacht und die Readings per MQTT übermittelt, glaubt das notify: "Oh, eine Änderung, dann leg ich jetzt los". Und schaltet das Licht aus, wenn es an war oder umgekehrt.
Und hier kommt das gesetzte Attribut ins Spiel: Jetzt wird das notify-Event nur noch ausgelöst, wenn sich das Reading WIRKLICH ändert. Ein Aufwachen aus dem Sleep-Modus löst damit kein notify-relevantes Event mehr aus.
Der Spuk ist vorbei.
-
Zigbee ist schon ganz nett. Aber warum in Drei-Teufels-Namen sind die Hersteller nicht in der Lage, ihre Wandtaster im üblichen Rasterformat für gängige Mehrfachrahmen zu produzieren?
Gira kann das, aber dafür machen die ihren Zicken-Bienen-Produkte auch fast doppelt so teuer wie z.B. EQ3 ihre HomaticIP Taster.
Warum kann das z.B. Moes nicht? Oder die anderen meist chinesischen Hersteller. Der Chinamann kopiert doch sonst auch ohne mit der Wimper zu zucken. Warum nicht hier? Auch Shelly (die ich eigentlich wegen des IP-Adress-Verbrauchs nicht weiter verfolge) kann nicht das 55-mm-Maß. Warum nicht? Ich will das teure HomematicIP mit ihrem Scheiss Duty-Cycle nicht mehr. Aber wenn ich die Taster nicht ins Gira-Rahmen-Format bekomme, bleibt einem Final ja nichts anderes übrig.
Was mache ich nun mit dem Moes Star Ring Scene Switch? Den in FHEM einzubinden war tatsächlich echt leicht. Und mit dem 4-Fach-Taster kann ich jetzt 8 Dinge schalten (eigentlich 12, aber bei meiner nicht vorhandenen Geduld drück ich eine Taste nicht 5 Sekunden, um eine Aktion auszulösen).
Zurückschicken oder behalten?
#fhem #zigbee #homematicip #moes #eq3 #gira #system55 #shelly
-
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?
-
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
