Diverse Fragen und Rückmeldung nach erstem Test

[emufan]

So, nun habe ich mir mal auch ein Test-HA aufgesetzt um diese Integration zu testen.

Vorab: Ein frohes neues Jahr und ins.: Fantastisch. Und wenn ich mir die letzten Tagen, Versionen, usw. angucke, frage ich mich, wann ihr das alles macht. Also erst mal Danke!

Hier in loser Folge ein paar Dinge, die mir aufgefallen sind oder unklar waren. Vielleicht ist ja was Interessantes dabei und einige Antworten interessieren mich selbst.

1. Bei der Einrichtung ist optional Callback Hostname, Callback XML-Port, TLS, TLS überprüfen, JSON Port und TLS für JSON anzugeben. Hab (dann SSL nicht an) erst mal alles ausgelassen, wüsste aber mit den Ports nichts anzufangen und auch nicht warum getrennt für JSON und auch nicht was TLS überprüfen dann bewirken würde.

2. In den nächsten Optionen weiß ich nicht, ob ich noch Bidcos anmachen muss, um die CCU-Host (Sysvars, etc.)-werte zu bekommen. Sah danach nicht so aus, könnte später mE aber in die Doku.

3. Dann Neustart und nichts. Zweimal. Einmal gab es keine Meldungen, einmal einige davon
   create_devices: Skipping interface HMIP-HmIP-RF, missing paramsets.
   create_devices: Skipping interface HMIP-VirtualDevices, missing paramsets.
   Sagte mir alles nicht, nach drittem Neustart hatte ich dann Geräte und Entitäten.

4. Das neue Naming aus der anderen Diskussion ist super.
   
   Jedoch wird das an den Geräten nicht so angezeigt, sondern dort nur "4"
   
   Weiß nicht warum. Oder muss das so?

5. Gibt es eine Möglichkeit in die Optionen aufzunehmen, welche Zusatzattribute mit aktiviert werden? Das würde mir nun bestimmt 100 Klicks ersparen.
   
   Z.B. Duty Cycle möchte ich immer. Oder RSSI auch oder Level am Heizventil. Wenn ich das irgendwie mit drei Checkboxen statt jetzt alles manuell setzen könnte, wäre das schon irgendwie gut. Auch wenn neue Geräte bei mir dazukommen und damit ich das dann nicht "vergesse". Gut, ich kann es mit ein paar Hundert Klicks weniger auch im Batch in der Entittäten-Sicht machen, sondern aber immer noch einige Hundert. ;-)

6. Wofür ist der Dienst:
   

7. Zur Info. Bei mir waren es mit der alten Integration ca. 310 Entitäten, nun sind es 765. Nur, weil es die Diskussion ja auch schon gab. Tendenziell sind mir das auch zu viel, allerdings will ich die nicht missen. Ist halt sicher das Problem mit der Direktive "von oben", alle möglichen Attribute warum in Entitäten zu wandeln.

8. Bei den Systemvariablen sind die generierten Namen und IDs für die Standard-CCU3 Variablen und eigene anders. Dies vielleicht angleichen?

9. Ein Logo auf der Integrationsseite wäre prima.

10. Auch hier irgendwo in der Diskussion. Sollte der BSM nicht jetzt als Lampe statt Schalter auftauchen. Sind bei mir weiterhin Schalter. Und heißt auch weiter für mich für jeden eine Light-Template-Entität anzulegen, die dann aber leider vom Gerät entkoppelt ist.

So. Das waren die ersten Eindrücke. Die Nummerierung soll nur helfen, besser Bezug nehmen zu können und kein energisches Erstens, Zweitens, Drittens, usw. sein. 😂

Nochmals vielen Dank für den Einsatz und Eure Zeit, die ihr hier investiert.

[SukramJ]

Danke fürs Testen.

1. Die Werte wurden erst mal so von pyhomematic übernommen und weiter reduziert. Doku ist noch offen. Um ehrlich zu sein hatte ich dazu noch keine Lust. Unterstützung wäre hier hilfreich. Basis ist die pyhomematic bzw. Doku bei HA.
2. SysVars werden unabhängig vom Interface geholt. Bei einer CCU wird Json verwendet.
3. Wäre natürlich wichtig zu wissen was für ein System du verwendest. CCU, HW, Version,… (siehe Issue Template in GitHub)
4. Klick auf die Entität, dann siehts du das der Name richtig gesetzt wurde. Die verkürze Anzeige liegt an der verwendeten HA Card.
5. NEIN. Geh auf die Entitätenübersicht filtere z.Bsp nach duty_cycle markiere deine Entitäten, und dann kannst du auf aktivieren klicken.
6. Das ist das Zentrale Gerät, über das alle deine Geräte verbunden sind. Heisst bei die wohl HMIP. Von Dort gibt es auch einen Link zur CCU. Warum das Ding Service heisst kann ich auch nicht beantworten.
7. Die Diskussion über eine Entitätsanzahl halte ich nicht für zielführend, weil dabei Äpfel(PyHomematic) mit Birnen(HaHomematic) verglichen werden. Früher gab er weniger Entitäten und dafür mehrere Attribute pro Entität. In HaHomematic gibt es eigentlich nur noch Entitäten. Werteänderungen bei Entitäten und Attributen führen zu Änderungen in der HA-Statemachine. Da ich mal schätze das eine durchschnittliche pyhomematic Entität 2-4 Attribute hat komme ich bei pyhomematic auf ca. 1000 mögliche State-Änderungen und bei HaHomematic sind es ca. 750 mögliche State-Änderungen. Änderungen im Duty_Cycle oder low_bat führen bei mehreren Entitäten pro Gerät also zu mehreren Änderungen bei PyHomematic und zu jeweils einer by HaHomematic. Ich finde Entitäten viel besser. Man kann Entitäten aktivieren /deaktivieren, und direkt in den HA-Cards verwenden.
8. Systemvariablen werden einfach übernommen (keine Logik). Anpassungen kannst du am Besten in HA vornehmen.
9. Gute Idee. Dann such doch mal Logos raus.Hierfür gibt es da Brands Repository, das auch custom components aufnimmt. Dort gibt es bereits homematic bzw. homematic_ip cloud. Vielleicht gibt es aber auch neuere Logos bei eQ-3. Ich freue mich über Zulieferungen.
10. der BSM ist ein Switch. Nur Dimmer sind noch Lights. Warum brauch du dafür ein Template?

Ich hoffe die Antworten sind in aller kürze verständlich.

[emufan]

Alles verständlich. Wirkt aber so, dass Du Dich nun doch angegriffen fühlst, wegen meiner Fragen? 😯 Wie gesagt, sollte das Gegenteil sein.

zu 3. Original CCU3.

zu 4. Ist aber gar keine verwendete Karte, sondern die Standard-Geräte-View.

zu 5. Das energische NEIN bedeutet was? Wie gesagt, selbst mit dem schnellen Weg, den ich ja auch schon in meinem Punkt hatte, muss ich öfter klicken und daran denken muss (bei neuen Geräten) als im mMn besseren Fall, das in den Optionen zu haben. RSSI, ja nein, Duty, ja/nein, Valve-Level/State, ...

BTW: 5b. ist am HmIP-eTRV-C-2 das Level ein deaktiviertes Konfigurationselement und am HmIP-BWTH eine aktiviertes Sensorelement.

zu 7. Haben wir halt unterschiedliche Meinung. Ich gucke sehe halt gern mal in der Entität in den Attributen (im Fall HA) welcher RSSI-Wert da ist, o.Ä. Geht nun nicht mehr und ich muss eine anderen Entität suchen und aufrufen. Und das direkte verwenden in HA-Cards ginge ja auch in 90% aller Cards inzwischen. Früher, wo das nicht ging, hätte ich den Ansatz ja noch verstanden. Aber heutzutage nicht mehr. Aber herrje, ist ja so.

zu 10. Ich weiß. Aber hier hast Du doch selbst das Gegenteil geschrieben: #84 und ich hatte mich gefreut, das dann auch so zu haben. Ist nun aber nun doch nicht so. Daher meine Frage nach dem Grund des Umschwungs.
Templates? Um die Lichter in Lichtgruppen zu nehmen, um ohne Anpassung von Klassen und Icons Lampen zu haben, usw.

Was mir inzwischen noch eingefallen ist:
11. Sollte/Könnte man nicht IPs, und Config-Flow Fragen auch in die Konfiguration nehmen? Machen mE viel zu wenig Integrationen. Kann sich ja immer mal die CCU-IP ändern, ein Protokoll dazukommen oder wegfallen, usw. Und ein Löschen/Neuhinzufügen geht sicher schnell im aktuellen Testmodus, aber im Livebetrieb mit angepassten Namen, IDs, evtl. Icons, usw. doch schon eine Sachen von Stunden und Tagen bei solch großen Plattform-Integrationen.

[emufan]

P.S. zu 9

Vielleicht so was hier? Ist von der HMIP-Seite, jedoch ohne IP, da diese Integration ja nicht nur das kann. Und das ganze in den Formaten die die anderen brands-Dateien auch haben.

[SukramJ]

Schon mal nicht schlecht. Mach hierzu doch mal eine eigenständige
Diskussion zum Logo auf.
Entsprechen die Logos der im Brands Repo geforderten Qualität und Auflösung?

[emufan]

Ja. Habe ich so entsprechend den vorhanden Auflösungen generiert und benannt.

[SukramJ]

Sehr gut.

[SukramJ]

Keine Angst ich fühle mich nicht angegriffen. Ich schreibe (und spreche) meist kurz und direkt.
zu 4. ist eine Karte.
zu 5. NEIN bedeutet du must nicht einzeln klicken, dafür gibt es die Entitäten-Übersichtsseite.
zu. 5b mach doch mal Screenshots. Der BWTH hat kein LEVEL
zu 10 Der Grund ist ganz einfach: Konsistenz. Der BSM wäre das einige On/Off Licht. Ich verwende meine BSM zusammen mit anderen Lichten in Gruppen und habe nur das Icon auf mdi:lightbulb geändert.
zu. 11 Hört sich sinnvoll an, ist aber in der Umsetzung aufwendig. Alternativ kann man den config_entry auch manuell ändern.

[emufan]

zu 4. Ja. klar. Aber keine die ich ändern oder beeinflussen kann.

zu 5b. Ist das hier

nicht der Ventilstatus?

O.k. Im engsten Sinne des Wortes kein Level, aber im Grunde das Gleiche. Halt 0:1 statt 0-1. Aber beides zeigt den Ventilstand und ist einmal ein deaktiviertes Konfigurationselement und einmal ein aktiviertes Sensorelement.

zu 10. Wenn man einen Switch in eine lightgroup einbinden will, kommt direkt

Invalid config for [light.group]: Entity ID 'switch.buro_aktor' does not belong to domain 'light' for dictionary value @ data['entities']. Got ['switch.buro_aktor'].

In eine Gruppe, ja. In eine Lightgroup https://www.home-assistant.io/integrations/light.group/ nein. Dafür macht man dann ja wie ich https://www.home-assistant.io/integrations/light.switch/. Und das könnte man sich ersparen, wenn man das BSM (wie Du im anderen Thread ja auch geschrieben hast und auch bei IPCloud machst) ein Licht wäre. Insb. jetzt, wo man die Geräte hat und danach dann aber die einzig verwendete Light Switch Entität dann nicht "am Gerät" hat.

Klar, war vorher auch so und ist ja auch theoretisch ein dummer Schalter. Aber wie Du auch geschrieben hast, werden 95% die Dinger als Lichter verwenden und das würde dann obigen Verrenkungen ersparen, um es im Sinne HA danach wieder konsistent zu haben, als Licht.

zu 11. Habe ich schon zweimal irgendwann irgendwo probiert. Wenn dann was schief geht, braucht man aber ja gar nicht versuchen Hilfe zu erfragen und ist sicher auch nicht jedermanns Sache, der gar nicht weiß, dass es versteckte Ordner gibt oder so. Daher mag ich es lieber wie bei HP Printer oder ShellyforHass, wenn man solch Sachen direkt ändern kann. Wie gesagt, wenn es eine Integration mit einem Gerät ist, wurscht. Bei einer Plattform schon besser. Insb. weil man es aktuell ja im yaml kann.

[SukramJ]

zu 4. gibt dem Channel in der CCU einen Namen der dem Device Namen entspricht, oder der nicht mit dem Devicenamen beginnt, oder einen Namen der keinen Doppelpunkt : enthält (und nicht mit dem Devicenamen beginnt). Hat aber nichts mit der Integration zu tuen, sondern ist reine HA Logik.

zu 5b bei mir sind beide aktiviert.

zu 10 . ich benutze eine group und keine light group. Warum braucht man eine light group? Ich nutze die nur zum ein und ausschalten. Wenn es individueller sein soll verwende ich Szenen.
Bei meiner HA Instanz ist es mir eigentlich egal ob es ein switch oder light ist.
Switch bedeutet keine Sonderlocke für ein Gerät im Code, und eine klare Regel: nur Dimmer sind lights

zu 11. Das Problem ist mit bekannt, aber ich erstelle vor Konfigurationsänderungen immer ein Backup. Die Möglichkeiten im HA ConfigFlow sind da leider begrenzt. Vielleicht gibt es ja demnächst mal Neuerungen.

[eikowagenknecht]

Zu 10: Ich finde es vollkommen korrekt, dass ein Gerät (-BSM), das einfach nur den Strom schaltet als Switch eingebunden wird. Beim -BSM ist vermutlich aufgrund des Verbaus in Schalterdosen der Anteil der Nutzer, die es zum Schalten von Lichtern nutzen, sehr hoch. Aber es ist dennoch in erster Linie ein Strom Ein/Aus Schalter. Um daraus ein Licht zu machen gibt es ja die einfache Möglichkeit mit der light.switch Integration. Andersherum (Licht zu Schalter) fällt mir kein so einfacher Weg ein.

[emufan]

zu 4. Ja ich weiß. Das wollte ich aber ja vermeiden. Und ist mir aber auch nicht wichtig. Dachte, dass es evtl. noch eine weitere interne Config-Stelle gibt, wo 4 drinsteht und nicht dass es von der Lovelacekarte selbst verkürzt wird. Wenn dem so ist, suche ich dort mal für eine Erklärung oder so.

zu 5b. bei mir nicht. Daher mein Hinweis. 😅 Und wie gesagt, einmal ist es ein Konfigurationselement und einmal ein Sensorelement. Mind. das sollte man mE noch angleichen.

zu 10. Lightgroups haben einige Vorteile. So haben die Farben der Birnen im UI Abstufungen passend zum Status der einzelnen Lichter (Mittelwert oder so). Auch kannst Du dann Lichtgruppen z.B. per Stimme nach Helligkeit und Farben ändern und die nicht-farbigen Lichter oder nicht-dimmbaren Lichter gehen dann dennoch passend mit a und aus. Gleiches auch in den UI-Bedienelementen. Das macht aus diesen Gründen schon Sinn lightgroups statt groups zu nutzen. Und dafür sind sie ja auch da. 😉

zu 11. o.k. Aber wieso können das dann z.B. die genannten Integrationen

[SukramJ]

zu 11 keine Ahnung. Ich kenne leider auch nicht alle. Werde ich mit irgendwann mal anschauen.

[Lemocin]

Zu 4, habe ich etwas herumprobiert. HA entfernt in der Geräteansicht den Gerätenamen, sobald der mit dem Gerätenamen beginnt. So wird bei meinem Smart Plug einer anderen Integration auch der Name entfernt sobald das Gerät z.B. Fernseher heißt und die Entität Fernseher Stecker. Angezeigt wird dann nur noch Stecker. Also rein von HA das ganze:

[emufan]

Ja, konnte ich auch nachstellen. Wenn es exakt gleich ist, wird es angezeigt, wenn es nur damit startet, wird der Prefix entfernt. Ich würde vorschlagen, das dann weiter in der parallel-Diskussion #92 weiterzubesprechen. Persönlich würde ich eine andere Namensgebung präferieren.

[emufan]

zu 11 keine Ahnung. Ich kenne leider auch nicht alle. Werde ich mit irgendwann mal anschauen.

Mega, dass Du das so schnell doch und überhaupt eingebaut hast. Echt fantastisch! Danke!

[emufan]

6. Wofür ist der Dienst:

Inzwischen habe ich zwei Dienste.

Klicke ich auf den Link, bekomme ich nur die komplette Entitäten-Liste. Und außer in der CCU finde ich auch keine Link zu einem anderen Dienst.

Woher kommt, wo ist und wofür ist der neue Dienst? Oder ein Fehler? Ich habe zur Sicherheit auch nochmal die komplette Integration entfernt und neu aufgesetzt (wegen Problemem im Bug-Report nach Update ), bleibt dabei.

[SukramJ]

Services sind der Hub, also eine CCU, und die virtuellen Fernbedienungen.
Warum HA die als Service tituliert werden erschliesst sich mir auch noch nicht.
Vielleicht kommt in einer späteren HA Version noch die Erleuchtung.

[emufan]

Aaaah. d.h. der hier unten ist der zweite Dienst und das hast Du seit meinem ersten Test hinzugefügt, bzw. das ist nun als Dienst kategorisiert?

Dann wäre der HAP für mich auch einer. Aber so what. Egal. Wunderte mich nur, weil dort kein Dienst-Link ist und mir das aher nicht als Dienst aufgefallen ist.

vs.

wo übrigend oft keine FW angezeigt wird. Werde ich weiter beobachten.

Aber danke für die Erläuterung.