HMCCU 5.0 Beta verfügbar

Begonnen von zap, 05 Januar 2020, 19:49:52

Vorheriges Thema - Nächstes Thema

zap

Zitat von: martinp876 am 18 Januar 2020, 12:04:34
Super!
Warum sind die Kommandos in HMCCURPCPROC  zu finden? Mein Wunsch wäre, mich im die "PROC" nicht zu kümmern. Ich will HMCCU und HMCCUCHN als bedin-interfaces. "PROC" sollten aus meiner Sicht "hidden" sein. Wenn du sie benötigt, ok. Aber muss mich (als Anwender) das interessieren?

OK

Zitat
Du - mit der CCU im Hintergrund - kannst jede Menge "Services"  wie Kommandos und Readings automatisch generieren. Die CCU bietet dir alle Optionen. Wenn in der CCU ein neues Device erscheint DARF es KEINER Aktion deinerseits benötigen, das Device per default zu unterstützen. Und das geht!!!

In 90% der Fälle ja. Aber es gibt eine Reihe von Geräten/Datenpunkten, die eine Sonderbehandlung benötigen (kennst Du sicher, E-Paper Display, Rollladen mit Lamellenverstellung => LEVEL_COMBINED und was sich EQ-3 sonst noch an hässlichen Lösungen ausdenkt)

Zitat
Operational parameter sind alle Parameter im Set "VALUES". Welche ein Kanal besitzt und welche Readable sind bekommst du von der CCU mitgeteilt. Diese parameter sollten (müssen) alle in Readings dargestellt werden. Immer und gnadenlos.

ccureadingfilter wird es weiterhin geben, allerdings mit .* als Default. Hintergrund: Sonst entstehen bei einigen Geräten, die z.B. Wochenprogramme als Values anbieten, gigantische Reading Listen.


Zitat
Der User könnte den Verdacht haben, dass etwas nicht stimmt. Dann braucht er die Möglichkeit, einen Update anzustossen. Das will er nicht reading-für-reading machen. Macht auch keinen Sinn, da du die Werte mit einem einzigen Kommando en-bloc geliefert bekommst.

=> "get update", gibts bereits für das I/O Device sowie HMCCUCHN und HMCCUDEV.

Zitat
Schön wäre es, sich an die Kommandos der CUL_HM zu halten. In FHEM gibt es immer wieder (sinnvolle) Bestrebungen den Wildwuchs der Kommandos einzudämmen. CUL_HM nutzt hier "set <entity> statusRequest". Es ist ein "set" kommanod, da Rudi festgelegt hat dass ein "get" einen direkten Return-wert liefert.

Mit dieser seltsamen Logik werde ich mich nie anfreunden können. Aber wenn es Dich glücklich macht, lasse ich jeden get BEfehl eben etwas anzeigen und/oder baue auch noch ein set statusRequest ein, das intern einen "get update" macht.
Was ich nicht machen werde: Alle BEfehle von CUL_HM nachbauen. Es gibt durchaus einige User, die sich an die HMCCU Befehle gewöhnt haben. Etwas geistige Flexibilität der CUL_HM User kann ich hoffentlich erwarten.

Zitat
4) System-start
startet FHEM oder startet die CCU nach FHEM sind diese nicht Synchron. Ach wenn es andere Stimmen gibt ist es in meiner Welt ZWINGEND notwendig, die Systeme zu Synchronisieren!!!.

Das ist schon seit x Versionen in HMCCU integriert. HMCCU wartet, bis die CCU fertig ist. Danach werden die RPC-Server gestartet und danach wird alles synchronisiert.

Zitat
Nur Readings mit nach bestem wissen gültigen Werten werden angezeit. Der "Ersteller" des Readings trägt die Verantwortung. In der Konsequenz heist dies, wenn eine Option angeboten wird die Readings lower-case oder upper-case darzustellen dann muss (MUSS) mit der Umstellung auf die neuen Werte der alte Bestand gelöscht werden.

OK

Zitat
6) Device-readings
im Kanal macht es Sinn, den Operationellen Zustand des Device (Kanal-0) darzustellen. Allerdings nur als Zusammenfassung.
Ich stelle mir das so vor:
Reading deviceState [ok|dead|unreachable|configPending|...]
Hierbei gibt es eine Prio, welche du festlegst. Ist bspw dass Device unreachable dann wird ein config-pending unterdrückt.
Welche Werte es gibt ist offen. Sollte und kann für alle aber gleich sein. Die abstrakten Darstellungen sind einfach. Das Reading sagt dem Anwender, dass es notwendig ist, im Device sich im Maintenance zu kümmern.

Im Prinzip hast Du das heute schon im "hmstate" Reading. Blöderweise hat EQ-3 bei einigen Geräten LOW_BAT in Kanal 1 gepackt. Aber mit solchen Querschlägern muss man halt leben.

Zitat
Noch eines zum Channel0: eq3 fasst kanal0 und "das Device" in einer Entity zusammen. Habe ich gerade noch einmal nachgesehen. Ich spreche vom User-Interface. Damit liege ich mit eq3 auf einer Line.

Da werden wir uns wohl nie einig. Beispiel:

CCU Menü Start > Geräte: Die Geräte gruppieren die Kanäle, über die dann die Steuerung erfolgt.

CCU Menü Einstellungen > Geräte: Parameter (=MASTER) gibt es für das Gerät (manchmal) und für Kanäle (auch manchmal), manchmal auch für beide.

Mit der automatischen Erkennung, ob ein Parameter zum Device oder einem Kanal gehört, wird es auch nicht klappen. Niemand wird Dir garantieren, dass EQ-3 nicht irgendwann einen Parameter MASTER.FLAGS für das Device UND einen Kanal einführt (nur als Beispiel). Was dann? Soll das Modul dann beide setzen oder einen auswürfeln?

Also: den Kanal 0 in ein zusammengefasstes Reading legen: von mir aus. Die Trennung von Device und Kanal bei konfigurativen Parametern (MASTER) muss es aber weiter geben.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Hört sich schon gut an. Ich werde das epaper ein mal im Hinblick auf den service Kanal inspizieren. Klar ist sowie: sollte weitergehende info enthalten sein muss sie verarbeitet werden. Allerdings ist es kein Grund, unnötige und doppelte Werte im Kanal darzustellen.

Bei "get" stimme ich dir zu. Ich wollte es auch do implementieren. Allerdings habe ich mich dem chef Architekten Rudi untergeordnet. In der Hoffnung dass fhem im userinterface einer einheitlichen Semantik folgt. Nun ja.....

Und ja, es gibt ein paar kuriose details von eq3... Das ist dann so. Ausrutscher vermute ich.

Zu MASTER: hat eine entity register welche nicht zu einem link gehören sind sie in MASTER zu finden. Bei Gerätetypen mit definitiv einem Kanal hatte eq3 die wahl die config im kanal oder im device zu platzieren. Ein Dimmer oder rolloaktor könnte auch mehrere Kanäle haben. So ist also driveup und down im Kanal zu finden. Einstellungen zu statusmsgs im device.
Grundsâtzlich sind VALUES operationell und MASTER sowie LINK config. Das ist immer so. LINK gibt er nur beim peeren. Auch bei den Device internen peerings, logisch. LINK  ist also eine dynamische Menge an Daten.
Hier ist zur Darstellung derselben ein frontend zu gestalten. Mit einer endlos langen Ausgabe ist keinem gedient.

Das mit den readings updates ist prima!!!

Leider erst wieder am Wochenende. Wegen den Brötchen.

zap

@Martin: Im Moment machen weitere Tests keinen Sinn. Morgen gibt es (hoffentlich) ein Update
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

frank

moin,

ist es über hmccu eigentlich möglich für ein "beliebiges" device registerbeschreibungen aus der ccu zu bekommen, ohne dass das device in der ccu angelernt ist?

also ein get cmd dem ich model und firmware version übergebe und als antwort eine liste sämtlicher parameter beschreibungen aller channel erhalte.

theoretisch müsste es doch machbar sein, oder nicht?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

zap

Ja das geht, da das IO Device (in der 4.4) sowieso alle Infos hat. Es gibt nur noch nicht die entsprechenden Befehle. Aber demnächst.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Nun, testen kann man immer. Und  noch habe ich kein Wochenende.
Aber bspw die internals sind sinnlos:
Channels ist immer 1 bei hmccuchn
Ccuaddr  ist immer identisch  der DEF.
Beide sind  also obsolet.

Weiter wünsche ich mir das in der hmccu das abgleichen der entities wie schon angesprochen in 3 level:
Verify: zeigt Unterschiede  zwischen ccu und fhem
Update: legt alle Kanäle an, welche fehlen. Kein löschen.
Force: legt an und löscht . Master ist die ccu.

Das kommando sollte keinen weiteren Optionen haben damit es per pulldown Liste ausgeführt werden kann.
Bei verify werden  natürlich alle notwendigen Definitionen und values nachgeladen.

zap

#36
hmm, mein Anspruch ist eigentlich, dass FHEM und CCU jederzeit synchron sind, und zwar ohne Eingriff des Nutzers. Das bezieht sich jetzt auf

- das I/O Device, das alle Geräte mit ihren Kanälen und Parametern kennt
- die FHEM Devices, die die in ihren Readings die aktuellen Zustände der Geräte/Kanäle in der CCU widerspiegeln

ich vermute, Deine Überlegungen gehen noch einen Schritt weiter: In FHEM sollen auch für alle Geräte/Kanäle in der CCU Instanzen - sprich Devices - existieren (also "autocreate"). Kann man drüber nachdenken, sollte es aber konfigurierbar machen.

Ich persönlich brauche nicht alle CCU Kanäle auch in FHEM.

ccuaddr ist essentiell und wird an vielen Stellen in den Modulen (auch im I/O Device) verwendet. Hintergrund: Der define Befehl akzeptiert auch einen CCU-Device oder Kanalnamen. channels ist tatsächlich obsolet.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Zitatmein Anspruch ist eigentlich, dass FHEM und CCU jederzeit synchron sind, und zwar ohne Eingriff des Nutzers.
uneingeschränkte Zustimmung.
Ich fühle mich wohler wenn der User ein Kommando hat, die Synchronität zu prüfen/ einen manuellen, kompletten sync starten kann. Aber typisch (98% der Fälle) muss es laufen.

ZitatDeine Überlegungen gehen noch einen Schritt weiter: In FHEM sollen auch für alle Geräte/Kanäle in der CCU Instanzen - sprich Devices - existieren (also "autocreate")
Logisch - die natüliche konsequenz.
Allerdings ist "autocreate" zu definieren. So würde ich es machen
a) autocreate ist keine Einstellung. Ohne Kommando werden keine FHEM entities erzeugt oder gelöscht
b) Der Anwender kann per Kommando eine Prüfung anstossen, welche devices in der CCU und in FHEM existieren
c) Der Anwender kann per Kommando fehlende Entites in FHEM erzeugen
d) Der Anwender kann per Kommando fehlende Entites in FHEM erzeugen UND "überschüssige" löschen

Da der User evtl lieber die CHN oder die DEV implementierung wünscht kann man das auch anbieten.

Somit habe ich ein Kommando syncDevices [verifyCHN,updateCHN,forceCHN,verifyDEV,updateDEV,forceDEV]

Default ist verify - CHN oder DEV, deine Entscheidung.

Ein Verfiy gibt eine Liste zurück
1) "fehlende" entites: in der ccu, nicht in FHEM. (wir arbeiten in FHEM. Fehlend ist also fehlt in FHEM)
2) "obsolet" entites: nicht der ccu, in FHEM.
3) "in-Sync" entites: existieren in beiden Welten

I) Der User kann diese Liste nutzen, wenn er einzelne Entites manuell instanziieren oder löschen will.

Verify kann man noch smart gestalten. Dann kann DEV/CHN hier entfallen. Du zeigt, in welcher welt (CHN/DEV) das Element existiert. Oder in beiden. Nur wenn es komplett fehlt kommt es in die "missing" Liste. => smart ist die eigentliche Anforderung!

Dein aktuelles pendant ist "get HMccu devicelist create". Allerdings ist das Kommando bei weitem zu sperrig. Zu viele
(unnötige) parameter. Default output ist die Anzahl der Devices - nicht hilfreich/unnötig.

Ob das Kommando "get devicelist" oder "get syncDevices" oder "set syncDevices" genannt wird ist mir an Ende des Tages egal.

Ich habe gerade 3 neue Geräte installiert - mein "syncDevices create" funktioniert schon. Implementierung ist (wem sage ich das) denkbar einfach. Natürlich funktioniert auch das verify schon. Schliesslich will ich bei solchen Kommandos gerne eine simlation vor ausführung haben.

Und klar ist mir die Bedeutung von ccuaddr klar - auch dei Verwendung. Es ist eben nur doppelt. Und der Platz in "internals" ist kostbar - bitte nicht zu-müllen. Bei Devices sollte auch die Addresse in der Definition stehen. Wird bei jeden Kanal um dessen nummer ergänzet - alles klar.

=> Der Anwender braucht die Addresse quasi nie. Er kann sie bei Bedarf sehen - logisch. Aber alles (ALLES) was das Frontend anbietet wird auf Basis der Namen der entites gemacht. In CUL_HM ist die Adresse die RF-Addr der Devices - und dessen Kanalnummern. Könnte jeder lesen. Anwenden muss es NIEMAND.

zap

#38
Es gibt eine neue Version von der Beta in contrib/HMCCU/FHEM

Neu:

  • Nach dem Start von FHEM wird eine Synchronisation mit der CCU getriggert. Bei dieser Synchronisation werden alle Device Descriptions, Parameterset Descriptions und Peerings aller Geräte und Gerätetypen gelesen.
  • Nach der Synchronisation werden die Peerings in allen existierenden FHEM Devices eingetragen. In den Internals gibt es je Sender einen Eintrag mit allen Empfängern sowie je Empfänger einen Eintrag mit allen Sendern. Wenn möglich und vorhanden werden die Namen der verknüpften FHEM Devices eingetragen, ansonsten die Namen in der CCU oder als letzten Fallback die Adressen. Der Status der Peering wird in den Readings eingetragen. Hier gibt es ein Reading je Sender/Empfänger Paar. Readingsvalue ist dann OK, oder BROKEN oder whatever. Wichtig: Derzeit werden die Peeringinfos nur einmal beim Start aktualisiert. Ist also noch nicht ganz fertig.

Die Get-Befehle in HMCCUCHN Devices wurden weiter vereinfacht und liefern nun - wie es sich für Get-Befehle gehört - immer auch eine Bildschirmausgabe. Reine Ausgabebefehle (ohne Speicherung der Infos in Readings) gibt es nicht mehr.

Im I/O Device kann eine neue Synchronisation der CCU Konfiguration mit dem Befehl "get ccuConfig" ausgelöst werden (dabei werden auch die Peerings aktualisiert, allerdings werden dabei veraltete Infos nicht gelöscht > Baustelle).

Nach wie vor bleibt CUxD außen vor. Auch HMCCUDEV ist noch nicht auf dem Level von HMCCUCHN angekommen.

Hier mal ein Beispiel für Peering Infos eines Fensterkontakts, der in einer Heizungsgruppe ist:

Internal (Name: L=Link, S=Sender, 1=Kanalnummer):

L-S-1 = HM_KL_BO_TH,HM_KL_BO_HZ

Die Devices HM_... sind die Empfänger (Wand- und Heizkörperthermostat)

Readings: (Name: L=Link, S=Sender, 1=Kanalnumer + Zieldevice

L-S-1-HM_KL_BO_HZ = OK
L-S-1-HM_KL_BO_TH = OK
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Hört sich gut an. Leider stürtzt es be mir ab. Somit kein Test.

Verdächtig ist erst einmal die sub HMCCU_FindClientDevices ($$$$) routine welche in Zeile 6188 einen Fehler bringt. Ich habe einmal begonnen zu debuggen und habe festgestellt, dass diese Routine offenbar endlos oft aufgerufen wird. Und ich meine endlos oft.
Ich habe noch nicht regründet, was das machen soll - aber das scheint wirklich nicht effizient. Vergleicht  hier jeder Kanal sich mit jedem Kanal?
Kennst du die Funktion devspec2array? Diese sollte man zum Suchen von Entites verwenden.

Beachte, dass ich peerings mit Devices habe, welche in der CCU unbekannt sind. Die CCU gibt dann die RFID aus.
Wenn du wissen willst, was gepeert ist musst du nicht suchen, die Liste gibt dir die CCU. Und diese solltest du nutzen! keine eigenen!
Die von der CCU ausgegebenene Adressen sind dann einfach auf Namen zu mappen. Mehr ist nicht zutun.
Schneller und sicherer.

Jetzt muss ich repaieren ;)


zap

#40
Zitat von: martinp876 am 26 Januar 2020, 18:39:55
Beachte, dass ich peerings mit Devices habe, welche in der CCU unbekannt sind. Die CCU gibt dann die RFID aus.
Wenn du wissen willst, was gepeert ist musst du nicht suchen, die Liste gibt dir die CCU. Und diese solltest du nutzen! keine eigenen!
Die von der CCU ausgegebenene Adressen sind dann einfach auf Namen zu mappen. Mehr ist nicht zutun.
Schneller und sicherer.

Jetzt muss ich repaieren ;)

Selbstverständlich nutze ich getLinks()

Mir scheint, Du nutzt eine alte Version von 88_HMCCU.pm. Zeile 6188 ist die erste Kommentarzeile der Funktion HMCCU_GetRPCDevice.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Ok, schaue ich mir an. Hatte frisch geladen...
Ah, nee. Sind ein paar zeilen von mir die es gerutscht haben.
Siehe zeile 6176.
Ich habe die funktion still gelegt, jetzt stürzt es nicht mehr ab.

Scheinbar hat $v keinen Inhalt was das m/ nicht verträgt.
& exists ($ch->{$i}) & wird 2 mal abgefragt. Kostet unnötige Performance.

Wenn die abfrage so oft benötigt wird (code review habe ich nicht gemacht) solltest du einen hash bauen.
Allerdings scheint internals ccuaddr gesucht zu werden. Xzig Mal. Sollte das nicht performanter gehen? Unter Nutzung von DEF{}?

zap

Das wird für jede Device Description aufgerufen. Leider verlasse ich mich darauf, dass die CCU keinen Müll liefert. Macht sie aber doch, zumindest für einen Kanal. Aber gut. Ich baue das um.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Ok. Infos von Fremdsystemen muss man leider immer anzweifeln.

Das mit der devicedescription habe ich nicht verstanden. Hier scheint jede entity mit allen abgeglichen zu werden. Das würde dann exponentiell ansteigen. Wenn das so ist muss es geändert werden -logisch!
Inhaltlich hat mich das nun neugierig genacht. Die ccu gibt alle abhängigkeiten der kanäle eines device vor. Fängt man am device an muss nichts gesucht werden, man weiss es einfach.
Gleiches gilt für peers.
Sucht man nicht nach ccuaddr in internals sondern nutzt einfach die definition hat man das ergebnis sofort. Wieder keine suchschleifen.
Vielleicht habe ich die Notwendigkeit noch nicht erkannt.

zap

Ich habe es jetzt über ne simple lookup Tabelle gelöst. Nun weiß das iO Device jederzeit, welche FHEM Devices zu einer Adresse gehören. Update gibt es morgen.
Die DEFs kann ich nicht verwenden, da ich auch den CCU Geräte- oder Kanalnamen beim Define zulasse. Das will ich auch beibehalten für die, die nur einzelne Geräte der CCU in FHEM definieren möchten. Namen kann man sich leichter merken als Adressen.
Außerdem ist es möglich, für ein CCU Gerät mehrere FHEM Devices zu definieren, z.B. um Werte unterschiedlich darzustellen oder einfach nur zum Testen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB