Dev-Talk

[danielperna84]

Diskussions-Plattform für Entwickler

Hier soll der öffentliche Austausch von Ideen stattfinden.

Aktuelles Thema: nur ein Server-Objekt oder mehrere? Bei pyhomematic haben wir in Home Assistant nur einen XML-RPM Server gestartet. Primär um Ressourcen zu sparen, denn damals lief HA hauptsächlich auf schwachen Pi's mit wenig RAM. Bei einem moderneren System ist es nun eine Überlegung wert ggf. mehrere Server zu verwenden. Dadurch gäbe es eine klare Trennung der Events usw.. Gibt es darüber hinaus noch Vorteile? Bisher gab es wohl noch kein Profiling davon wieviel Ressourcen so ein RPC-Server verbraucht. Ein weiterer Vorteil der Trennung wäre ggf. das alte Thema mit dem Locking Proxy. Bei einem gemischten System würden sich solche Geräte dann weniger in die Quere kommen.

Weiteres Thema: werden zu viele Entities erzeugt? Da wir blind (fast) alle Parameter (zumindest die mit Events) aus den Paramsets als Entities bereitstellen, können das sehr schnell sehr viele werden. Es gibt ja schon die ignorierten Parameter. Die Liste muss also ggf. noch erweitert werden. Allem voran können da vermutlich die *_STATUS Parameter rein. Die sind in der Praxis glaube ich nicht wirklich relevant in Home Assistant.

[SukramJ]

Ich bin für getrennte Server:

1. Das Thema Ressourcen ist nur dann ein Problem wenn man mehr als eine CCU hat.
2. Laut HA-Analytics sind nur noch 18,3% der Systeme RPi3.
3. Es ist auf absehbare Zeit nicht anzunehmen das die pyhomematic basierte Integration als Alternative entfallen wird.
4. Ein klare Trennung hätte viele Vorteile:
   4.1. klare Zugehörigkeit zur CCU
   4.2. Cachefiles pro CCU
   4.3 sicheres entfernen, neu starten, .. eines ConfigEntry in HA, wenn man mehr als eine CCU hat.

[SukramJ]

Ich meine, das pro CCU ein Server gestartet wird, der seinerseits mehrere Clients/Interfaces(also Wired, RF, IP-RF, IP-Wired) hat.

[danielperna84]

Ok, das ist eine gute Lösung. 👍

[SukramJ]

Sehr schön. Das entspricht dann meinem aktuellem Entwicklungsstand.

[SukramJ]

Hierzu noch ein Punkt:
Wenn mehrer Server gestartet werden können macht ein "globale" Datenstruktur wie hahomematic.data in der Breite aus meiner Sicht keinen Sinn mehr.

Ich würde CLIENTS und INSTANCES(mehrere Server) in data belassen, aber den Rest in die Server Instanz verschieben.
Was denkst Du?

[danielperna84]

Ja, ergibt Sinn. Mein Ansatz war ja, dass es nur einen Server gibt. Aber mit mehreren funktioniert das nicht mehr. Die Daten können also ruhig zu den einzelnen Instanzen.

[SukramJ]

Es werden zu viele Entitäten erzeugt!
An meiner CCU sind 95 Geräte angemeldet, die in hahomematic 2449 Entitäten erzeugen.
Bei der aktuellen pyhomematic Integration werden bei mir 265 Entitäten erzeugt.
Statt, wie bei pyhomatic sehr viel in Attribute zu packen macht es mehr Sinn, wie in hahomeatic, relevant Werte einzelne Entitäten zu erzeugen. Ich kann mir gut vorstellen, das im Schnitt pro Gerät 5(?) Entitäten sinnvoll seien könnten.

Ich finde den Ansatz sehr gut, das neue Geräte mit einer Grundfunktionalität in HA angelegt werden, ohne das zuvor eine Definition in hahomematic oder der HA-Integration stattfinden musste.

Über meine 95 Geräte hinweg gibt es >130 unterschiedliche Parameter.
Ist vielleicht ist ein Whitelist für relevante Parameter übersichtlicher?
Vorschlag:

• eine Whitelist für relevante Parameter, aus denen Entitäten erzeugt werden.
• eine Whitelist für relevante Parameter, aus denen Attribute einer Entität erzeugt werden.

[danielperna84]

Spontan könnte man das ja so machen:

dev_list = {
	"HmIP-SomeDevice": {
		"parameters": ["STATE", "FOO", "BAR"],
		"special_entity": None,
	},
	"HmIP-SomeClimateDevice": {
		"parameters": ["HUMIDITY"],
		"special_entity": climate,
	},
	"HmIP-SomeOtherClimateDevice": { # Hat kein HUMIDITY
		"parameters": [],
		"special_entity": climate,
	}
}

Blöd finde ich hierbei jedoch, dass man dadurch viele Duplikate hätte, da man das dann wirklich für jeden Typ explizit so erfassen müsste. 🤔

[SukramJ]

Der Ansatz ist schon mal viel versprechend.

[SukramJ]

Die aktuelle Implementierung sieht ein wenig anders aus.
Die Definition hat sich aber nach unzähligen Umbauten so weit als nutzbar gezeigt. Eine entsprechende Dokumentation muss ich noch ergänzen.

[LotusHenry]

Gibts dazu eigentlich schon was Neues?
Grundsätzlich find ich die HaHomematic prima. Für mich machen aber sowohl Attributes als auch Sensors je nach Verwendungszweck Sinn.
Z.B. beim HmIP-eTRV stört mich, dass der Ventil-Level nicht auch als Attribute übergeben wird.
Da jeweils eigene Templates zu defnieren wo die benötigten Werte zusammengeführt werden macht Sinn bei 1 oder 2 Devices aber nicht wenn man 20 oder mehr hat.
Da ich viel mit Tabellen arbeite, würde das die Arbeit ziemlich vereinfachen.
Ideal wäre, wenn man eben irgendwo selbst definieren könnte (ähnlich wie beim Unignore) was man zusätzlich als Attribute sehen will.

[SukramJ]

@LotusHenry

• der Thread ist aus 2021
• du hast das eigentliche Thema verfehlt
• Attribute werden in HA in 2023 nicht mehr für Werte verwendet
• eine Eigenattributierung werde ich nicht implementieren.

[danielperna84]

@SukramJ

Hi,

wie weit ist denn (gefühlt) die neue Integration deiner Meinung nach? Technische issues kommen ja in letzter Zeit eigentlich kaum noch. Meistens sind's ja dann Layer 8 Probleme. Gibt's noch irgendwas auf deiner Agenda was du hier machen willst bevor das hier in den Core kommen soll?

[chrste90]

Um auch nochmal auf den Namen zurückzukommen. Falls es wirklich nur möglich ist, eine homematic-Integration anzubieten, wäre so etwas möglich:

• homematic
  • homematicip_cloud
  • homematicip_local
  • config_flow

Also im Prinzip beide Integrationen komplett getrennt zu entwickeln und über eine vorgeschaltete ConfigFlow-Seite entweder in die eine oder die andere Integration zu springen? Für den Anwender würde das dann wie eine Integration aussehen, aber im Prinzip bleibt es bei der strikten Trennung.

---

Bzgl. Migration: Ich habe mein Produktivsystem auf diese neue Integration umgestellt und sehe eine Migration auch kritisch. Das Hauptproblem hier war vor allem, die Automatisierungen und Skripte umzustellen und hier war dann z.B. bei Rolläden der Wechsel von der alten Entity auf das jetzt verfügbare Gerät, irgendwelche Parameter, die vorher über Attribute ausgelesen wurden, sind jetzt als Entity verfügbar etc und das sind glaube ich Dinge, die eine Migration auch nicht leisten kann. Wäre es hier nicht sinnvoller, die alte Integration durch die neue zu ersetzen und ausführlich zu dokumentieren, welche Dinge der Nutzer jetzt anpassen muss, damit wieder alles wie vorher funktioniert?

[emufan]

Ich würde die (ip-cloud und ccu) nie zusammenführen. Das macht das ganze doch nur zu konfus. Und vielleicht möchte ja auch einer beide getrennt (von multiplen Instanzen mal abgesehen).

[Lemocin]

Und vielleicht möchte ja auch einer beide getrennt (von multiplen Instanzen mal abgesehen).

Das wäre kein Problem, die Integration kann ja mehrfach eingerichtet werden.

Ich würde die (ip-cloud und ccu) nie zusammenführen

Da stimme ich zu. Bis auf die Namen haben die Systeme softwareseitig doch recht wenig miteinander zu tun.. Das zu mixen wäre eher schlecht.

[chrste90]

Deshalb auch die Frage, ob man beide getrennt entwickeln, aber trotzdem als eine Integration nach außen anzeigen lassen kann. Die Homematic-Integration wäre dann eigentlich nur noch eine Abstraktion, um entweder die Local- oder Cloud-Integration zu laden und hier sollte man dann ja auch mehrfach die Homematic-Integration laden und konfigurieren können, so dass multiple Instanzen möglich wären.

Ich kenne mich mit der HA-Programmierung aber auch nicht gut aus, deswegen weiß ich gar nicht, ob das überhaupt möglich ist. Im Idealfall habe ich mir das so vorgestellt, dass eine erste Seite im ConfigFlow nach der Art der Anbindung fragt und je nach Auswahl würde sich dann für die weiteren Schritte entweder der HomematicIP-Local- oder HomematicIP_Cloud-ConfigFlow öffnen und dann durch die Konfiguration der jeweiligen Anbindung führen.

[danielperna84]

Ich habe hier mal eine neue Diskussion gestartet um etwas Ordnung zu halten bei so einem wichtigen Thema.

[danielperna84]

@SukramJ und wer sonst noch was dazu sagen will

Zum Thema der Umbenennung von custom_homematic / hahm zu homematicip_local: Wie groß ist denn der Aufwand das umzusetzen? Und in welcher Form soll / kann ich hier Zuarbeit leisten? Ein Breaking change für unsere Tester war ja ohnehin abzusehen, und ich finde jetzt wäre ein guter Zeitpunkt dafür.

Hintergrund der Frage ist, dass u. A. Jens nun in seiner Doku diese Integration empfiehlt (ein potentiell recht großes Publikum), und ich bei den bestehenden HM-Issues am liebsten auch sagen würde "wechsel' am besten zu homematicip_local". Damit würde ich aber erst anfangen wollen, wenn der Name final ist und die Leute nicht irgendwann nochmal ihre Automationen usw. umbasteln müssen. Ob / wenn homematicip_local dann - auf welchem Pfad auch immer - im HA Core landet, dann tut's den Usern nicht mehr weh. Dann müssten sie ja glaube ich einfach nur das custom component löschen und der Code vom Core übernimmt.

Ich glaube wir gewinnen nicht wirklich viel, wenn ich das custom_homematic Repo umbenenne / neu aufsetze. Der Inhalt wäre ja der gleiche (nur mit anderer HA domain). Und das würde uns ersparen lauter URLs in den Blueprints, Manifest usw. zu ändern.

[Lemocin]

Auto_Discovery hab ich auf die IP-Adresse zurückgestellt.

Meldung kam nicht mehr. Danke!

[danielperna84]

Hab jetzt auch mal mit Migrationspfad 1 migriert. Bin leider nicht vorher dazu gekommen. Habe dieselbe Meldung im Log wie hier beschrieben: #375

Aber die Funktion scheint nicht beeinträchtigt zu sein.

[noxhirsch]

Nachdem ich gestern meinen Server gekillt habe (die Hardware), kam ich erst jetzt zum Testen. Ich habe mich für Migrationspfad 2 entschieden - das hat auch super funktioniert. Nur die HmIP Heizungsgruppen wurden nicht direkt ersetzt, aber das ist ja bekannt und nicht anders möglich👍 Vielleicht sollte der Hinweis nochmal ans Ende der Migrationspfade gesetzt werden - die Liste, warum die Änderung nötig ist, habe ich ehrlich gesagt nur grob überflogen (weil ich den Hauptgrund ja schon kannte) und mich auf die Migrationspfade konzentriert.
Noch ein Vorschlag für Migrationspfad 2: Um es für die Benutzer zu vereinfachen, könnte man die ganzen Shell Commands z.B. mit && zu einem Befehl zusammenfassen. Dann könnte man die aktuelle Befehlsliste als Erklärung der einzelnen Befehle dahinter setzen (bzw. auch für User die lieber einen Befehl nach dem anderen durchlaufen lassen).

[pvizeli]

Ich würde es nicht unbennen, wenn es ein custom component bleibt... -> #12 (reply in thread)

[SukramJ]

@Lemocin Kleine Vorwarnung mit 1.0.5 setzten wir nun doch auf die Seriennummer. Du must also die erkannte Instanz ignorieren.

[SukramJ]

Moin,
@Baxxy13 hat im HM-Forum eine interessante Umfrage zum Thema Homeassistant / Homematic(IP) Local - Umfrage zu möglicher Verbesserung gestartet.

Wäre schön wenn Ihr euch das mal anschauen, kommentieren und auch Voten könntet.

@eikowagenknecht @Lemocin @emufan @noxhirsch @itn3rd77 @chrste90 @danielperna84

[SukramJ]

Dann wird wohl einer der Parameter (active_profile, boost_mode, control_mode, heating_cooling, humidity, party_mode, setpoint, set_point_mode, temperature, level, state) sofern vorhanden und lesend nutzbar, noch keine Daten haben.

Dein "hübscher" Name liegt wohl u.a. an weiteren Doppelpunkten, die nicht nur den Kanal abtrennen.

[emufan]

Hast Du dennoch eine Idee @SukramJ, warum der HM-ES-TX-WM in der alten Core-Integration dann und wann neue RSSI-Werte in den Attributen der dortigen Entitäten energy_counter und low_bat erhält, in dieser Integration hier aber nie, d.h. dort stets unknown angezeigt wird?

[SukramJ]

Leider nicht.

[Baxxy13]

noch keine Daten

Ist natürlich "unschön" wenn gerade das "Hauptgerät" einer IP-Heizgruppe hier wieder ewig "default-Werte" anzeigt.
Das wirkt sich ja z.B. in der Visualisierung auch auf die Verlaufsanzeige aus.

Vereinfacht gesagt ist das Gruppengerät ja nur ein "Spiegel" des WTH von dem die Zentrale nach dem Reboot ja auch keine Daten hat und entsprechend "default-Werte" anzeigt. Daher verstehe ich nicht wieso das Verhalten unterschiedlich ist.

Du schriebst zuletzt:

d.h. der Zustand der Entitäten wird nach einem Neustart von HA aus dem letzten Zustand wieder hergestellt

Und weiter vorn bei den 3 Optionen:

3. Verwenden von RestoreEntity, RestoreSensor, RestoreNumber. Hierbei kann der letzte Wert vor dem Neustart wiederhergestellt werden.

Der Unterschied liegt hier zwischen "wird" und "kann".

Wie läuft das aktuell konkret?

Wenn "wird", warum dann nicht das Gruppengerät (das war ja vor dem Reboot "voll da")?
Wenn "kann", welche Bedingungen müssen erfüllt sein.

[SukramJ]

Default Werte werden nur bei boolschen Werten verwendet solange keine andere Wert verwendet werden kann.
Wenn man von Optionen spricht sollte man auch von "kann" sprechen.
Da es jetzt implementiert wurde passt also "wird" am Besten.
https://github.com/danielperna84/custom_homematic#noteworthy-about-entity-states

Ich kann hier nicht mehr erkennen wo das Problem liegt, also öffne am Besten ein neues Issue. Die Klärung macht in einer Diskussion keinen Sinn.