Der Shelly Multi Device Controller (SMDC) folgt klaren Designprinzipien, die in den nächsten Tagen erläutert werden. Die Reihenfolge gibt dabei auch eine strenge Priorisierung vor, ist also nicht zufällig gewählt!!

Stabilität first !✅
Nulleinspeisung second!✅
Effizienz third! ✅
- systemweite Bypass-Steuerung (new) ❗
Erhalt der Leistungsfähigkeit des Gesamtsystems (SoC-Balancing) ✅
Schnittstellenfähig ❗(kann in externe Automatisierungen einbezogen werden)

Legende:

✅ erledigt
❗ Arbeitsfeld

Heute

1️⃣ Stabilität

Herausforderungen sind:

asynchrone Request, die Kommunikation mit den Solarflows erfolgt ausschließlich über asynchrone REST-Calls
- Das Senden und Empfangen ist also entkoppelt, Antworten kommen irgendwann oder nie
- begrenzte Aufnahmefähigkeit des Shelly Environments (der "Briefkasten" zum Versenden von Requests ist voll und das führt unweigerlich zum Absturz)

Der Anspruch ist:

24/7 (läuft immer) ✅
- Requests werden seriell versendet (schützt den "Briefkasten")
- der Watchdog (ein Buchhalter) überwacht das Regelintervall. Werden die Arbeiten in einem Intervall nicht abgeschlossen, wird kein neues Intervall gestartet (schützt den Shelly vor Überlastung)
- alte Antworten werden einfach verworfen
- asynchron heißt "der Brief ist raus" ..."schauen wir mal wann die Antwort kommt"
- der Controller stellt sicher (über einen Zähler) dass nur passende Antworten im intervall verarbeitet werden, Antworten aus alten Intervallen werden einfach verworfen
TakeOver und Fehlertoleranz ✅ - ein nicht verfügbares Gerät wird sofort ersetzt, d.h. seine Lasten werden von anderen Geräten übernommen
- WLAN-Aussetzer oder andere Probleme machen Solarflows ggf. nicht verfügbar, Das erkennt der Controller sofort und nimmt das Gerät sofort aus der Lastverteilung, merkt man nicht, steht aber im Log
Transparent ✅ "Sag Bescheid wenn's schlimm ist, ansonsten halt die Klappe" - ein Kommunikationsmodul informiert, wenns kritisch wird sofort über Ausnahmesituationen
- Fehler in der Kommunikation kommen häufiger vor als man denkt (httpGetError), sind aber meist unkritisch, eine serielle Häufung kann aber kritisch sein
- je Fehlertyp gibt es einen Fehlerzähler (errorThreshold). Wenn dieser Wert überschritten ist, geht eine Meldung raus (an Whatsapp/Signal oder als Webhook), die Fehlerbehebung (meist magische Selbstheilung) wird auch berichtet
- die beste Meldung ist keine Meldung

Das neueste Konzept (Skipmode) ✅ ist: "Frage die Solarflows nur dann, wenn sich der Gridwert (Smartmeter) zu weit weg bewegt von seinem Sollwert (meist NULL)". Dies entlastet massiv die jeweiligen Endpunkte im Shelly und den Solarflows. Im Tagesbetrieb werden bis zu 40% weniger Anfragen gestellt (auf die Antworten braucht man auch nicht warten), Im Nachtbetrieb bis zu 60% weniger Anfragen, ganz ohne Einfluss auf Regelgeschwindigkeit.

Nächste Kapitel:
"(Insight Shelly Multi Device Controller) Prinzip 2: Nulleinspeisung - die Null steht"

Weiterführende Links

📖 Vollständige technische Dokumentation
🧭 Getting-Started-Wiki
🛠️ Konfigurationsassistent
💬 Fragen & Austausch: GitHub Discussions
🐛 Probleme melden: GitHub Issues
bis Version 3.x.x Script herunterladen
ab Version 4.x.x Script herunterladen