Die Liste der ignorierten Parameter... ist für "Power-User" viel zu lang...

[Baxxy13]

Vorwort:

Nachdem nun die Zombi-Inits ausgemerzt und die Reconnect-Probleme behoben sind muss ich sagen das die Integration schon wirklich gut ist. Ich könnte mir vorstellen die ganze Logik (WebUI-Programme) irgendwann komplett nach HA auszulagern und auf der Zentrale (RM / CCUx) nur noch die Geräteverwaltung / Geräteeinstellungen und Direktverknüpfungen zu machen.

Mir ist klar das man mit HA die Dinge anders angehen kann, letztlich ist aber auch HA genau wie RM / CCUx primär eventbasiert.
In Event tritt ein, meine Automatisierungen / Scripte / WebUI-Programme reagieren darauf.
Zyklische Polling bestimmter Parameter, wie an anderer Stelle vorgeschlagen wurde, halte ich nicht für sinnvoll. Zum einen stellt die RM / CCUx ja quasi alles als Event bereit und zum anderen hinkt man den realen Werten (je nach Polling-Intervall) hinterher. Will ich also instant auf etwas reagieren kann ich nicht bspw. 30s bis zum nächsten Polling warten.

Die Diskussionen bezüglich mehr/weniger Entitäten habe ich gelesen und mein Standpunkt dazu wäre... umso mehr umso besser.
Es muss natürlich längst nicht jeder Datenpunkt in HA verfügbar sein, aber ein paar die mir wichtig wären liste ich nun mal auf.

Liste mir wichtiger Datenpunkte:

A: "DECISION_VALUE"

• der "Waschmaschine ist fertig" Datenpunkt, sendet auch zwischen dem regulären Sendeintervall von ~3Min und ist daher schneller und präziser als bspw. ein Abfrage ala "Leistung < x"

B: "INHIBIT"

• die totale Bediensperre für HM-Aktoren. Das Kind hat den Taster zur Rollladenbedienung entdeckt und will nicht mehr aufhören? Mit INHIBIT=true ist man zwar der Spielverderber, aber wenigstens ist Ruhe und der DC nicht in Gefahr

C: "WORKING"

• das Zahnrad in der WebUI, zeigt bei HM-Aktoren z.B. an ob der Aktor mit EINschaltdauer läuft oder ob der Rollladen gerade fährt

D: "PROCESS"

• ähnlich wie "WORKING" bei den HM-Aktoren, man erkennt z.B. ob der Kanal von IP-Schaltaktoren mit EINschaltdauer läuft

E: "DIRECTION" & "ACTIVITY_STATE"

• Fahrtrichtungsanzeige-Event bei HM / IP Rollladenaktoren

F: Sonderwunsch "ACTUAL_TEMPERATURE" aus Kanal:0 von IP-Aktoren

• die zeichne ich tatsächlich von DRSIx Aktoren in der Unterverteilung auf und würde im Falle eines Falles bei Wert > x eine Push-Warnmeldung generieren.

Es gibt sicher noch den ein oder anderen Parameter der nützlich oder auch nur "nice-to-have" wäre.
Vielleicht hat @AlexaMiller noch ein paar Beispiele parat. ;-)

[AlexaMiller]

Servus liebes Entwicklerteam, servus Baxxy!

wir (Peter und ich) haben die Entwicklung der neuen Integration mehr als begrüßt, sah es doch so aus als würden sehr viele langgehegte Wünsche endlich erfüllt.
Kurze Zeit später kristallisierte sich allerdings heraus, dass das Konzept für Poweruser und Leute welche mehr aus ihrem System herausholen möchten nicht flexibel genug ist. Als noch die Probleme mit der Anbindung zur debmatic (ist immer noch nicht möglich, Geräte/Entities werden nicht gefunden) dazu kamen haben wir uns dazu entschieden das Projekt nicht weiter aktiv zu verfolgen sondern alternative Ansätze selbst zu entwickeln.
Zielrichtung und Konzept sind festgelegt, proof-of-concept ist erstellt und auch die Umsetzung macht erfreulich gute Fortschritte. Da wir hier sicherlich sehr spezifische und tiefgehende Anforderungen an uns selber und die uns umgebenden Systeme stellen ist die Integration bis auf weiters nicht public.
Wir ziehen uns hiermit aus der aktiven Diskussion zurück um unsere Energie in unsere eigene Vision zu fokussieren.

Liebe Grüße aus Baden, Peter und Alexa

[SukramJ]

Vielen Dank für den konstruktiven Beitrag.

Grundsätzlich ist es natürlich kein Problem die Blacklist weiter zu reduzieren, um so weitere Entitäten im HA anzuzeigen.
Aber genauso wie Poweruser immer mehr Entitäten wollen, gibt es andere Benutzer, die mit der Flut an Entitäten nicht so begeistert sind, wie auch hier im Forum bereits zu lesen ist. Fazit: Man kann es nicht allen recht machen.

Bei Änderungen wünsche ich mir eine klare argumentative Unterstützung warum diese Parameter sinnvoll sind. Eventuell macht es auch hierzu Sinn eine Seite in der Dokumentation anzulegen.

Vom technischen Standpunkt ein paar Dinge meinerseits:

• wir reden nur über Entitäten aus den VALUES Paramsets, da nur diese über den XmlRPC Callback aktualisiert werden
• zusätzliche Entitäten werden im default deaktiviert erstellt.
  Warum: nur aktive Entitäten erzeugen in HA Last und müssen initial mit Daten gefüllt werden. Man kann deaktivierte Entitäten in Übersichten ausblenden!

Der Aufwand entsteht, wenn Parameter nicht nur freigeschaltet, sondern im HA auch hübsch dargestellt werden, d.h. die Definition von device_class, state_class, icon und Übersetzung von Werten. Hier wünsche ich mir eine Zuarbeitung, und wenn eine Umsetzung erfolgt ist natürlich auch ein Feedback, ob die Umsetzung denn soweit funktioniert. Die Umsetzung kann ich gerne machen, aber eine Rückmeldung gehört schon zum guten Ton.

Warum keine Umsetzung mit einer Konfigurationsoption für Poweruser:

• Ich glaube es gibt nicht einen Typ Poweruser.
• Die Freischaltung aller Parameter in so einer Option ist der Overkill. Wer mir nicht glaubt kann sich ja mal so eine Version bauen.
• Optionen erfordern immer zusätzlichen Testaufwand
• Expertenoptionen, das weiss ich aus eigener Erfahrung, sind bei den HA-Core Entwicklern nicht gern gesehen.

Umsetzungsoption:

• Im hahm Ordner liegt optional eine Datei, die eine Liste mit Whitelist Parametern enthält, die von der backend-lib hahomematic eingelesen wird.
• Parameter können so erst mal getestet werden.
• Nachteil, diese Parameter sind erst mal nicht hübsch. Hierzu muss ggf. die EntityDefinition in custom_homematic erweitert werden.(-> Zulieferung, bzw. eigene Customization in HA)
• Es wird keine Blacklist Datei geben.
• Die Nutzung der Datei erfolgt auf eigenes Risiko!

@danielperna84 Vielleicht kannst Du aus deiner langjährigen Erfahrung mit pyhomematic absehen, ob die Umsetzungsoption zu techniklästig gedacht ist.
Ich denke eigentlich nicht, das dadurch ein späterer Übergang in das HA Projekt verhindert wird.

[SukramJ]

@Baxxy13 Ich bin jetzt nicht auf deine konkrete Parameterliste eingegangen, die ich gut verargumentiert finde, und bei deren konkreter Umsetzung ich persönlich kein Problem sehe. Mir war es hier nochmal wichtig auf grundsätzliche Punkte der Zusammenarbeit einzugehen, und ggf. ein Umsetzungsoption für Sonderwünsche ins Spiel zu bringen.

[danielperna84]

Also ich finde das ok so.

Warum etwas in HA abgelehnt oder akzeptiert wird kann ich selbst manchmal nicht nachvollziehen. Ich würde mich bei so einem Detail aber auch nicht künstlich einschränken lassen wollen. Den Ansatz mit dem custom_unignore von unten finde ich nämlich völlig ok. Per default passiert da ja nix, und die Poweruser haben etwas womit sie arbeiten können.

HA nutzt ja auch so genug externe libraries die ggf. mehr können als von HA genutzt wird, eben weil sie gar nicht spezifisch für HA gemacht sind. Dann ist sowas zur Not ein Feature, was nur bei uns im Wiki dokumentiert wird.

Oder anders gesagt: wir wollen keine HA-Diktatur bei Features die für manche User echten Nutzen mit sich bringen. Sollten die das ablehnen, dann bleibt's halt für immer ein custom component. Ist deren Entscheidung wenn die integrierte HomeMatic Integration dann Mist ist.

[SukramJ]

Ich könne mir eine Umsetzung der von @Baxxy13 gewünschten Parameter wie folgt vorstellen:

A: DECISION_VALUE nur HM / Sensor mit INT Werten —> Aktivierung über custom_unignore

B: INHIBIT nur HM / Umsetzung als Switch —> Parameter von der ignore Liste entfernen

C: WORKING nur HM / Umsetzung als Binary_Sensor. Aktivierung über custom_unignore. WORKING als Parameter für custom_homematic aufhübschen. device_class = running(?)

D: PROCESS nur HmIP-Aktor / Umsetzung als Binary_Sensor. Aktivierung über custom_unignore. PROCESS als Parameter für custom_homematic aufhübschen. device_class = running(?)

E: DIRECTION & ACTIVITY_STATE Umsetzung bei cover in is_opening/is_closing wird über den cover state abgebildet. Darüber hinaus: Aktivierung über custom_unignore DIRECTION & ACTIVITY_STATE als Parameter für custom_homematic aufhübschen. Übersetzung für Sensor States erstellen.

F: ACTUAL_TEMPERATURE nur HmIP / Umsetzung bei Schaltschrank Geräten -> machen. Darüber hinaus: Aktivierung über custom_unignore

A, C und D finde ich persönlich sehr speziell und erzeugen auch sehr Entitäten, daher würde ich eine Aktivierung über custom_unignore vorschlagen.
Das hängt natürlich davon ab, ob eine Umsetzung von custom_unignore für sinnvoll erachtet wird.

Und wer es sich nicht schon gedacht hat: Mit custom_unignore meine ich die Umsetzungsoption (siehe oben)

Bei E halte ich eine Integration in den Cover State für ausreichend.

[Lemocin]

Im speziellen würde mich bei Cover interessieren ob der Status is_closing/is_opening angezeigt wird.

Geht.

Springt auch korrekt auf close wenn fertig.

[Waschdel]

Erstmal danke für eure tolle Arbeit.
Ich hätte eine vielleicht dumme Frage:
Warum ist INHIBIT nur bei HM Geräten möglich? Bei meinen HmIP Thermostaten (HmIP-eTRV-B) lässt sich die Bediensperre auch in der WebUI de-/aktivieren. Es wäre bequemer, wenn das mittels custom_unignore auch direkt in HA möglich wäre.

[danielperna84]

Weil zumindest das HmIP-eTRV-B kein INHIBIT im paramset hat. Kann natürlich sein, dass die Funktion bei HmIP unter einem anderen Parameter erreichbar ist. Das müsste man mal in Erfahrung bringen.

[Waschdel]

Wow, das ging fix. Ich denke der Parameter heißt beim HmIP-eTRV-B GLOBAL_BUTTON_LOCK.

[Baxxy13]

INHIBIT gibt's nur bei HM Geräten und ist dort ein ganz normaler Datenpunkt.
Das hat aber nichts mit den "Bediensperren" die man konfigurieren kann (Globale / Modus Bediensperre) zu tun.

GLOBAL_BUTTON_LOCK bei IP-Geräten (Globale Bediensperre) ist ein Parameter im MASTER-PARAMSET von Kanal:0.
Sowas kommt ja nicht in die Integration.
Der Wert sollte sich aber mit dem Dienst Homematic(IP) Local: Put paramset ändern lassen.

[Baxxy13]

Zunächst mal danke für das Feedback!
Ich hatte tatsächlich viel "Gegenwind" erwartet und freue mich umso mehr das das Thema so gut aufgenommen wurde.

Dann natürlich Danke für die gelungene Umsetzung. Hier möchte ich mich entschuldigen das Zuarbeit und Ideengebung ausblieben. Es lag zwar alles hier auf dem Tisch, nur fehlte mir am WE die Zeit das vernünftig rüberzubringen.

Erste Tests habe ich nun auch gemacht (0.31.0.beta), hier mal die PMSw1-PL:

Funktioniert alles wie gewünscht, super!

Hinweise:
INHIBIT=true sperrt nur die lokale Bedienung am Gerät bzw. Bedienung per DV. Über die WebUI / HA-Oberfläche lässt sich das Gerät weiterhin bedienen. Ist auch gut so, so kann man sich nicht komplett aussperren. Der Parameter ist flüchtig, stromlos machen des Gerätes setzt ihn auf false zurück.

DECISION_VALUE braucht für die "Aktivierung" reportValueUsage(). Das kann man mit dem Homematic-Manager erledigen oder ein simples WebUI-Programm erstellen. Das WebUI-Programm muss bestehen bleiben, denn beim löschen wird ReportValueUsage() sonst wieder auf 0 gesetzt.

Weitere Tests:
PROCESS bei den IP-Schaltkanälen zeigt korrekt an ob eine Einschaltdauer läuft.
ACTUAL_TEMPERATURE von Kanal:0 der DRSIx wird angezeigt.

Fehlende Tests:
DIRECTION kann ich aktuell (noch) nicht testen. Aber das sah ja bei Lemocin gut aus.
ACTIVITY_STATE hier fehlt mir ein passendes Testgerät.

[SukramJ]

Moin,
vielen Dank für die Rückmeldung. Schön das die Umsetzung so weit passt.
Ich denke das @Lemocin seinen Test mit einem HmIP-Broll gemacht hat, also mit ACTIVITY_STATE
Ausstehend ist also noch DIRECTION. Beide haben zwar die gleichen Werte, aber manchmal ist die Umsetzung zwischen HM und HmIP merkwürdigerweise unterschiedlich.

Mit "Gegenwind" oder "Diskussionen" muss man rechnen, wenn die Anforderungen den Interessen der diversen Nutzergruppen widersprechen, oder zu einseitig dargestellt werden.
Ich bin immer für pragmatische Lösungen und freue mich über Anregungen.

Danke, dass Du das Projekt mit deinem tiefen CCU Hintergrundwissen unterstützt.

[emufan]

Ich hatte tatsächlich viel "Gegenwind" erwartet und freue mich umso mehr das das Thema so gut aufgenommen wurde.

Ich hatte das ja auch noch nicht gelesen. 😂

Spaß bei Seite. Bekannt ist ja, mehr Optionen sind immer besser. 😉 Da die meisten nun wieder neuen Entitäten per custom_unignore mein System oder die Systeme von denen, die das nicht brauchen, nicht vollschreiben, mag ich diese Entitäten natürlich sogar viel lieber als die virtuellen Kanäle, usw. Ich hoffe nur, dass nicht irgendwann Lemocin wieder mit dem Vorschlag kommt, die Option zu tilgen, nachdem das mit der anderen Expertenfunktion ja schonmal gelungen ist 😜

@Baxxy13: Was mich aber wirklich interessieren würde - vielleicht ergibt das ja sogar Anwendungsfälle für mich - ist, was die Parameter denn wirklich machen oder Aussagen den ersten Post habe ich (mangels CCU Erfahrung) tatsächlich nicht verstanden. Was machen DECISION_VALUE, WORKING und PROCESS genau (Werte, Aktualisierungen wie oft und bis wann, usw.) und insb. was wären die Ideen was man dann innerhalb HA damit machen würde?

[Baxxy13]

Ich versuch's mal...

DECISION_VALUE = Entscheidungswert:

Der Entscheidungswert ist eigentlich eher für Direktverknüpfungen gedacht und lässt sich am Beispiel HM-ES-PMSw1-Pl in den Geräteeinstellungen einstellen und aktivieren.

Hier sieht man auch gut das dieser Wert nur 2 Zustände haben kann, nämlich "0" und "200".

Einfacher Use-Case wäre eine Master-Slave Schaltung.
An der HM-ES-PMSw1-Pl hängt ein TV. Wird der in den Standby geschickt wird der untere Grenzwert (10W aus dem Screenshot) unterschritten und der Entscheidungswert wird an einen direktverknüpften HM-Aktor (z.B. Ambientebeleuchtung) gesendet so das dieser auch instant AUS geht (oder auch AN wenn man will).

Der Vorteil den Entscheidungswert zu nutzen, also statt z.B. WENN "Leistungsaufnahme < 10.0W" DANN "mach irgendwas" liegt darin das der Entscheidungswert sofort gesendet wird. Hat man jetzt für die Ambiente-Beleuchtung z.B. einen IP-Aktor geht ja keine DV und da die HM-Aktoren im 3Minuten Raster ihre Messwerte senden würde somit im schlechtesten Fall das Ambiente-Licht erst nach 3 Minuten AUSgehen.
Nutze ich den Entscheidungswert ist die Verzögerung zwar trotzdem etwas größer als bei einer DV, aber immer noch viel kleiner als bei der "WENN "Leistungsaufnahme < 10.0W" DANN "mach irgendwas"" Lösung, und vor allem recht konstant.

Gesendet wird der Entscheidungswert bei jedem Über-/Unterschreiten der definierten Werte.

WORKING bei HM-Rollladenaktoren:

Wenn HM-Rollladenaktoren "in Bewegung" sind geht dieser Parameter auf true. Endet die "Bewegung" geht er auf false.
Einen konkreten Use-Case habe ich nicht. Man könnte aber z.B. visualisieren das sich da was bewegt. Oder eine Rundumleuchte aktivieren wenn das Kind mit dem Rollladen spielt.

WORKING / PROCESS bei HM / IP Schaltaktoren.

Eine Faustregel besagt, wenn möglich schalte die Aktoren mit definierter Einschaltdauer EIN. So ist sichergestellt das die Aktoren auch wieder AUSgehen wenn der Funk gestört oder die Zentrale unpässlich ist.
WORKING / PROCESS zeigen das an. So könnte man z.B. visualisieren wie lange die Gartenpumpe noch läuft. (Aktor wird mit 6h Einschaltdauer EINgeschalten, WORKING geht auf true, Countdown zählt herunter.

[emufan]

Danke Dir. War erfolgreich für alle Punkte.

Ist halt immer der Punkt von dem man guckt. Z.B. habe ich Working/Process ja auch schon im HA, d.h. wann angeschaltet oder schalte ab, wenn x lange an, usw. Aber ja, wenn man Sicherheitsnetze schon im HM hat und diese weiternutzen will, verstehe ich das.