FOX ESS Homeassistant Integration - Versionsgeschichte

Chris T. Ludwig: /* Vorhaben */

2026-07-05T15:16:33Z

Vorhaben

← Nächstältere Version		Version vom 5. Juli 2026, 17:16 Uhr
Zeile 66:		Zeile 66:
	„Vorbildlich“ bezieht sich aber nur auf die '''HA-Architektur auszen herum''': Config Flow, Coordinator, Entity-Basis, Diagnostics usw.		„Vorbildlich“ bezieht sich aber nur auf die '''HA-Architektur auszen herum''': Config Flow, Coordinator, Entity-Basis, Diagnostics usw.

	Die Register-Implementierung in entity_descriptions.py empfinde ich als Katastrophe. Vielleicht frage ich mal bei '''Nathan Marlor''' nach, wie auf sowas kommt. Grrrrr!		Die Register-Implementierung in entity_descriptions.py empfinde ich als Katastrophe. Vielleicht frage ich mal bei '''Nathan Marlor''' nach, wie man auf sowas kommt. Grrrrr! Wahrscheinlich hat er klein angefangen und dann wurde immer nur dazugepackt. Jetzt wird es immer schwieriger Monster zu beherrschen. Bei einigen Versuchen die Registerliste mit entity_descriptions.py abzugleichen ist es mir kaum gelungen eine Systematik zu erkennen, die eine Ueberarbeitung/Kontrolle der Register erleichtert.

	Die '''Registermodellierung''' ist davon getrennt — und gerade bei Modbus-Integrationen ist das oft der schwaechste Teil.		Die '''Registermodellierung''' ist davon getrennt — und gerade bei Modbus-Integrationen ist das oft der schwaechste Teil.

Chris T. Ludwig: /* Gibt es Beispiele, die eine HA Geraeteintegration mit einer zentralen json Datei oder einer SQLite DB als Konfigurationsbasis benutzen? */

2026-07-05T15:08:07Z

Gibt es Beispiele, die eine HA Geraeteintegration mit einer zentralen json Datei oder einer SQLite DB als Konfigurationsbasis benutzen?

Änderungen zeigen

Chris T. Ludwig: /* gibt es beispiele die eine ha geräteintegration mit zentralen json datei oder sqlite db als configuration basis benutzen */

2026-07-05T15:05:53Z

gibt es beispiele die eine ha geräteintegration mit zentralen json datei oder sqlite db als configuration basis benutzen

← Nächstältere Version		Version vom 5. Juli 2026, 17:05 Uhr
Zeile 1.296:		Zeile 1.296:
	Deshalb wuerde ich fuer dieses Projekt sogar einen Schritt weiter gehen als YAML: '''eine zentrale JSON- oder SQLite-basierte Registerdatenbank''', aus der die Home-Assistant-Entitaeten zur Laufzeit generiert werden. Das wuerde nicht nur die Wartbarkeit verbessern, sondern auch den Vergleich verschiedener Wechselrichtermodelle (H1, KH, H3, H3 Pro usw.) erheblich vereinfachen.		Deshalb wuerde ich fuer dieses Projekt sogar einen Schritt weiter gehen als YAML: '''eine zentrale JSON- oder SQLite-basierte Registerdatenbank''', aus der die Home-Assistant-Entitaeten zur Laufzeit generiert werden. Das wuerde nicht nur die Wartbarkeit verbessern, sondern auch den Vergleich verschiedener Wechselrichtermodelle (H1, KH, H3, H3 Pro usw.) erheblich vereinfachen.

	==~~gibt~~ es ~~beispiele~~ die eine ~~ha geräteintegration~~ mit zentralen json ~~datei~~ oder ~~sqlite db~~ als ~~configuration basis~~ benutzen==		==Gibt es Beispiele, die eine HA Geraeteintegration mit einer zentralen json Datei oder einer SQLite DB als Konfigurationsbasis benutzen?==
	Ja, aber sie sind überraschend selten.		Ja, aber sie sind überraschend selten.

Zeile 1.507:		Zeile 1.507:
	Für eine große Modbus-Integration wie FOXESS – mit Hunderten von Registern, vielen Wechselrichtermodellen und ständig neuen Firmwareständen – halte ich dagegen eine datengetriebene Architektur (JSON oder besser SQLite) für langfristig wartungsfreundlicher. Sie würde nicht nur die Pflege vereinfachen, sondern auch Werkzeuge wie deinen Register-Analyzer erheblich unterstützen.		Für eine große Modbus-Integration wie FOXESS – mit Hunderten von Registern, vielen Wechselrichtermodellen und ständig neuen Firmwareständen – halte ich dagegen eine datengetriebene Architektur (JSON oder besser SQLite) für langfristig wartungsfreundlicher. Sie würde nicht nur die Pflege vereinfachen, sondern auch Werkzeuge wie deinen Register-Analyzer erheblich unterstützen.

	[1]: https://developers.home-assistant.io/docs/core/entity~~/?utm_source=chatgpt.com~~ "Entity \| Home Assistant Developer Docs"		[1]: https://developers.home-assistant.io/docs/core/entity "Entity \| Home Assistant Developer Docs"
	[2]: https://developers.home-assistant.io/docs/creating_integration_file_structure~~/?utm_source=chatgpt.com~~ "Integration file structure"		[2]: https://developers.home-assistant.io/docs/creating_integration_file_structure "Integration file structure"

Chris T. Ludwig: /* In deinem konkreten Fall */

2026-07-05T15:03:46Z

In deinem konkreten Fall

← Nächstältere Version		Version vom 5. Juli 2026, 17:03 Uhr
Zeile 1.290:		Zeile 1.290:

	<span id="in-deinem-konkreten-fall"></span>		<span id="in-deinem-konkreten-fall"></span>
	== ~~In deinem~~ konkreten Fall ==		== Im konkreten Fall ==

	~~Aus unseren bisherigen Gespraechen weisz ich, dass du bereits einen '''Register-Analyzer''' fuer die FOXESS-Integration entwickelt hast. Genau deshalb faellt dir wahrscheinlich auf,~~ wie schwer sich die Informationen derzeit extrahieren lassen. Waeren die Registerdefinitionen in YAML, JSON oder einer Datenbank abgelegt, koennte dein Analyzer sie direkt auswerten – ohne den Python-Code parsen zu muessen.		Auffalled ist wie schwer sich die Informationen der Register derzeit extrahieren lassen. Waeren die Registerdefinitionen in YAML, JSON oder einer Datenbank abgelegt, koennte dein Analyzer sie direkt auswerten – ohne den Python-Code parsen zu muessen.

	Deshalb wuerde ich fuer dieses Projekt sogar einen Schritt weiter gehen als YAML: '''eine zentrale JSON- oder SQLite-basierte Registerdatenbank''', aus der die Home-Assistant-Entitaeten zur Laufzeit generiert werden. Das wuerde nicht nur die Wartbarkeit verbessern, sondern auch den Vergleich verschiedener Wechselrichtermodelle (H1, KH, H3, H3 Pro usw.) erheblich vereinfachen.		Deshalb wuerde ich fuer dieses Projekt sogar einen Schritt weiter gehen als YAML: '''eine zentrale JSON- oder SQLite-basierte Registerdatenbank''', aus der die Home-Assistant-Entitaeten zur Laufzeit generiert werden. Das wuerde nicht nur die Wartbarkeit verbessern, sondern auch den Vergleich verschiedener Wechselrichtermodelle (H1, KH, H3, H3 Pro usw.) erheblich vereinfachen.


	==gibt es beispiele die eine ha geräteintegration mit zentralen json datei oder sqlite db als configuration basis benutzen==		==gibt es beispiele die eine ha geräteintegration mit zentralen json datei oder sqlite db als configuration basis benutzen==

Chris T. Ludwig: /* Kritik */

2026-07-05T15:00:52Z

Kritik

← Nächstältere Version		Version vom 5. Juli 2026, 17:00 Uhr
Zeile 1.009:		Zeile 1.009:
	=Kritik=		=Kritik=

	==~~warum~~ hinterlegt man die ~~register~~ der verschiedenen ~~modell~~ nicht in yaml oder xml ~~dateien~~ ?==		==Warum hinterlegt man die Register der verschiedenen Modelle nicht in yaml oder xml Dateien ?==

	Ich halte das sogar fuer eine der groeszten architektonischen Schwaechen der FOXESS-Integration. Die Entwickler haben sich fuer einen '''codezentrierten Ansatz''' entschieden, obwohl ein groszer Teil der Informationen reine Konfigurationsdaten sind.		Ich halte das sogar fuer '''eine der groeszten architektonischen Schwaechen der FOXESS-Integration'''. Die Entwickler haben sich fuer einen '''codezentrierten Ansatz''' entschieden, obwohl ein groszer Teil der Informationen reine Konfigurationsdaten sind.

	Man muss allerdings unterscheiden, '''welche Informationen''' ausgelagert werden koennen und welche nicht.		Man muss allerdings unterscheiden, '''welche Informationen''' ausgelagert werden koennen und welche nicht.

Chris T. Ludwig: /* Ausgabe/Auswertung */

2026-07-05T14:59:34Z

Ausgabe/Auswertung

Änderungen zeigen

Chris T. Ludwig: /* Vorhaben */

2026-07-05T14:56:05Z

Vorhaben

← Nächstältere Version		Version vom 5. Juli 2026, 16:56 Uhr
Zeile 60:		Zeile 60:
	* umfassende Uebersetzungen		* umfassende Uebersetzungen

	Es gehoert zu den qualitativ besten Community-Integrationen fuer Home Assistant und ist eine ausgezeichnete Vorlage fuer eigene Geraeteintegrationen.		Es gehoert zu den qualitativ besten Community-Integrationen fuer Home Assistant und ist eine ausgezeichnete Vorlage fuer eigene Geraeteintegrationen. Sie hat aber nach meiner Einschaetzung einen riesigen Nachteil. Durch dieses dauernde Ergaenzen von Registern von neuen Modellen und Versionen ist eine schlecht wartbare Zusammenstellung von vielen Dateien geworden.

	Es ist schon irre, welcher Overhead erzeugt wird, nur um ein paar Byte vom MODBUS auszuwerten. Deshalb kaeme ich nie auf die Idee z. B. fuer ein SignatureDisplay die Entitaeten aus HA zu verwenden. Mit gefuehlt 10 Zeilen Code bekommt man alle notwendigen Werte per MODBUS aus dem FOX und augenfreundlich auf JEDEM Display angezeigt.		Es ist schon irre, welcher Overhead erzeugt wird, nur um ein paar Byte vom MODBUS auszuwerten. Deshalb kaeme ich nie auf die Idee z. B. fuer ein SignatureDisplay die Entitaeten aus HA zu verwenden. Mit gefuehlt 10 Zeilen Code bekommt man alle notwendigen Werte per MODBUS aus dem FOX und augenfreundlich auf JEDEM Display angezeigt.
Zeile 66:		Zeile 66:
	„Vorbildlich“ bezieht sich aber nur auf die '''HA-Architektur auszen herum''': Config Flow, Coordinator, Entity-Basis, Diagnostics usw.		„Vorbildlich“ bezieht sich aber nur auf die '''HA-Architektur auszen herum''': Config Flow, Coordinator, Entity-Basis, Diagnostics usw.

	Die Register-Implementierung in entity_descriptions.py empfinde ich als Katastrophe. Vielleicht frage ich mal bei '''Nathan Marlor''' nach wie auf sowas kommt. Grrrrr!		Die Register-Implementierung in entity_descriptions.py empfinde ich als Katastrophe. Vielleicht frage ich mal bei '''Nathan Marlor''' nach, wie auf sowas kommt. Grrrrr!

	Die '''Registermodellierung''' ist davon getrennt — und gerade bei Modbus-Integrationen ist das oft der schwaechste Teil.		Die '''Registermodellierung''' ist davon getrennt — und gerade bei Modbus-Integrationen ist das oft der schwaechste Teil.

Chris T. Ludwig: /* Allgemeines */

2026-07-05T14:42:20Z

Allgemeines

Änderungen zeigen

Chris T. Ludwig: /* Ausgabe/Auswertung */

2026-07-05T09:53:54Z

Ausgabe/Auswertung

← Nächstältere Version		Version vom 5. Juli 2026, 11:53 Uhr
Zeile 487:		Zeile 487:
	python3.12 modbus_register_analyzer_V0.9l.py entity_descriptions.py --csv > ausgabe.csv		python3.12 modbus_register_analyzer_V0.9l.py entity_descriptions.py --csv > ausgabe.csv


			[[:File:ausgabe.xls]] NB: csv ist in diesem Wiki (noch) nicht erlaubt, daher xls

	Beispiel		Beispiel

Chris T. Ludwig: /* Analysetool entity_descriptions.py */

2026-07-05T09:52:59Z

Analysetool entity_descriptions.py

← Nächstältere Version		Version vom 5. Juli 2026, 11:52 Uhr
Zeile 482:		Zeile 482:
	</syntaxhighlight>		</syntaxhighlight>
	</div></div>		</div></div>


	~~[[:File:ausgabe.xls]]~~

	=Ausgabe/Auswertung=		=Ausgabe/Auswertung=