HMCCU 5.0 im SVN verfügbar

zap · 03 April 2022, 15:09:36

Ja, hätte ich vielleicht machen können. Andererseits dauerte die Beta-Phase von HMCCU 5.0 mehr als ein Jahr und ich hatte hier im Homematic Bereich sehr oft darauf hingewiesen und auch gebeten, die Beta-Version zu testen.

Ich bin davon ausgegangen, dass Homematic/HMCCU Nutzer zumindest gelegentlich mal in dieses Unterforum reinschauen. Ich persönlich lese "Ankündigungen" so gut wie nie.

frank · 04 April 2022, 21:30:41

Zitat von: Obi-Wan am 03 April 2022, 00:37:35
da ich nach einem FHEM update plötzlich Probleme mit notify auf HMCCU Geräte hatte begab ich mich auf die Suche hier im Forum und fand die Hinweise zum Release 5.0 also quasi "posthum".

Daher hätte ich mal eine Frage bzw. Bitte: Könnten derartige Umstellungen ggf. zukünftig bitte vorab im Forum "FHEM:Ankündigungen" gepostet werden?

1. wenn jedes update aller module im angesprochenen thread angekündigt wird, ergibt sich sicherlich das selbe problem.
2. für wirklich interessierte gibt es extra "update check".
dort wird verlässlich informiert.
3. was hätte es gebracht, wenn du es gewusst hättest?
das ergebnis wäre doch wahrscheinlich das selbe gewesen, oder?
4. über restore ist alles schnell wieder hergestellt.
5. zap hat sowieso keine chance, es allen recht zu machen.

ich finde, dass zap die umstellung mehr als vorbildlich umgesetzt und ewig darauf hingewiesen hat.

fhemfrederik · 05 April 2022, 12:19:54

Liebe alle,

ich bin auch etwas vom Update überrascht worden und musste einige DOIFs anpassen, die auf die "alten" Datenpunkte zugegriffen haben.
Wie komme ich denn wieder an die alten Werten? Z.B. möchte im beim Wassermelder (HmIP-SWD) wissen ob der flach liegt (0.ERROR_NON_FLAT_POSITIONING). Wie kann ich den Datenpunkt einbinden?

Viele Grüße
Frederik

zap · 05 April 2022, 14:05:40

Zitat von: fhemfrederik am 05 April 2022, 12:19:54
Liebe alle,

ich bin auch etwas vom Update überrascht worden und musste einige DOIFs anpassen, die auf die "alten" Datenpunkte zugegriffen haben.
Wie komme ich denn wieder an die alten Werten? Z.B. möchte im beim Wassermelder (HmIP-SWD) wissen ob der flach liegt (0.ERROR_NON_FLAT_POSITIONING). Wie kann ich den Datenpunkt einbinden?

Viele Grüße
Frederik

Das Flag "showDeviceReadings" im Attribut ccuflags setzen.

fhemfrederik · 05 April 2022, 19:50:44

ich bin gerettet! Danke für die Hilfe!

Borkk · 07 Mai 2022, 14:41:17

Hallo zap,

ich brauche mal deine Hilfe. Ich habe eine recht umfangreiche FHEM Installation die im Grunde wie ein Uhrwerk arbeitet. Seit ein paar Wochen haben ich allerdings ein 3-4 sec Delay beim Schalten von HMIP Geräten (Schalter, Rollos usw). Dazu habe ich bereits einen eigenen Threat aufgemacht, aber bisher noch keine Antwort bekommen.

Da ich (wie wir vermutlich alle

) kontinuierlich an unserem System rumbasteln, kann ich natürlich nicht ausschließen das ich irgendwas verändert habe, das zu dem Delay führt. Grundlegende Änderungen an meiner Architektur habe ich aber nicht vorgenommen und "vorher" hatte ich keinerlei spürbares Delay.

Verdächtige Module habe ich bereits auf ein 2. System ausgelagert, alle erdenklichen Updates gemacht, die Container recreated uvm. Aber irgendwie stochere ich noch immer im Dunkeln.

Kurz zusammengefasst: Ich habe 2x FHEM Instanzen mit ConfigDB & DBLog, Homebridge, mariaDB, Deconz, PiHole und einen NGINX ReverseProxy verteilt auf 2 RPI4 Dockerhosts laufen. Wo es geht nutze ich (auch intern) bereits IPV6.

Homematic lauft jedoch auf einem separaten RPI3 mit Raspberrymatic. Ich habe mittlerweile komplett auf HMIP umgestellt und nutze auch nur dieses RPC Interface.

Mit Freezemon und APPTIME komme ich nicht weiter, im Log habe ich auch nichts wirklich brauchbares gefunden.

Nach einen Restart aus FHEM heraus bleibt FHEM an dieser Stelle hängen:

Code Auswählen

2022.05.07 14:06:31 2: HMCCU [CCU] Reading Paramset Descriptions for interface HmIP-RF

Es dauert dann mit Unter sehr lang (> 10 min) bis es weiter geht. Manchmal geht es aber auch gar nicht weiter.

Kannst du mich mal in eine Richtung lenken wo ich suchen muss?

Vielen Dank.

Borkk · 08 Mai 2022, 00:27:44

Habs gefunden... scheinbar war meine ConfigDB zu groß, einmal "configdb reorg" und alles ist wieder gut.

limats · 11 Mai 2022, 22:46:03

Hallo zusammen,
ich bin gerade dabei, meine CUL_HM Installation in eine CCU3 mit HMCCU 5 umzuziehen.
Wenn ich die Devices in FHEM mit createDev anlege, fasst er ja alle Kanäle in einem Device zusammen. Bei einer Heizungsgruppe ja sogar mehrere Geräte.
Ich hatte in der alten Installation z.B. den Weather-Channel der Thermostaten so konfiguriert, dass er schön Temperatur und Luftfeuchtigkeit im Status hatte und ihn der Group Temperatur zugewiesen. Während der Climate Channel zur Steuerung der Heizung genutzt wurde.
Was ist denn die empfohlene Best Practice für so etwas mit HMCCU?
Ich dachte zuerst, ich könnte einen ReadingProxy verwenden, um Temperature und Luftfeuchtigkeit in ein neues Device zu kopieren. Aber der kann scheinbar nur ein Reading.
Ich könnte natürlich auch nicht die createDev nutzen, sondern den Channel manuell mappen. Aber das ist laut Doc ja nicht mehr empfohlen.
Wie löst ihr sowas?

Viele Grüße
Leo

zap · 12 Mai 2022, 13:29:57

Ich würde das mit der Empfehlung für "createDev" nicht so eng sehen

Es ist halt einfacher, gerade für Einsteiger in die HMCCU/CCU Thematik.

Du kannst gerne z.B. für den Statuskanal mit Temperatur und Luftfeuchte ein Device per "define xy HMCCUCHN Kanaladresse" anlegen.

Wichtig: Du kannst für ein Device und/oder einen Kanal mehrere Devices in FHEM anlegen! Also zusätzlich zum HMCCUDEV für jeden Kanal ein HMCCUCHN.

limats · 12 Mai 2022, 22:41:26

Alles klar.
Eine Frage hab ich noch: den STATE des HMCCUCHN zeigt FHEM in der Raumübersicht als Link formatiert an.
Kann ich das irgendwie verhindern?

zap · 13 Mai 2022, 09:28:36

Das ist seltsam. Kannst Du mal bitte ein list vom Device machen ?

PatrickR · 07 Juni 2022, 11:59:03

Guten Morgen!

Nachdem ich das Projekt HMCCU5-Migration vorübergehend auf Eis gelegt hatte, versuche ich nun eine Test-FHEM-Instanz so weit zu konfigurieren, dass die Funktionalität wieder hergestellt wird.

Das erste zu lösende Problem ist das Deaktivieren der Readings-Umbenennung. Wenn ich HMCCU_GetReadingName in 88_HMCCU.pm richtig verstehe, gibt es aktuell keine Möglichkeit, die Umbenennung vollständig zu deaktivieren, da z. B. die Umbennenung der Channel-0-Readings (AES_KEY...) hartkodiert ist.

@zap:
Wie würde ich hier vorgehen, ohne 88_HMCCU zu patchen?
Falls es ohne Patch nicht geht: Würdest Du ein neues ccuflag in Erwägung ziehen, das die Umbenennung deaktiviert bzw. die Readingnamen auf <channel>.<datapoint> belässt?

Patrick

zap · 07 Juni 2022, 19:31:37

Wenn Du in ccuflags "showDeviceReadings" setzt, sollten zusätzlich(!) zu den umbenannten Readings auch die Readings im Format Channel.Datenpunkt angezeigt werden. Reicht das, oder müssen die umbenannten Readings ganz verschwinden?

PatrickR · 07 Juni 2022, 19:57:04

Hi!

Zitat von: zap am 07 Juni 2022, 19:31:37
Wenn Du in ccuflags "showDeviceReadings" setzt, sollten zusätzlich(!) zu den umbenannten Readings auch die Readings im Format Channel.Datenpunkt angezeigt werden. Reicht das, oder müssen die umbenannten Readings ganz verschwinden?

Habe es auf dem HMCCUDEV-Device gesetzt, was gut aussieht und Events wirft. Die zusätzlichen Readings sind kein Problem. Die kann ich notfalls mit FHEM-Bordmitteln beseitigen. Danke erstmal!

Patrick

PatrickR · 07 Juni 2022, 20:16:17

Hi!

Ich antworte mal, da ich ebenfalls betroffen war.

Um es mal plastisch zu machen. Alles sah nach dem Update gut aus, aber eine Reihe von Notifys/DOIFs sind wegen der gemappten Values ins Leere gelaufen, was natürlich nicht sofort auffällt. Das Ganze bewegt sich dann irgendwo zwischen ärgerlich (Auslösen von Aktionen von Fernbedienungen) bis zu gefährlich (Steuerung von Tauchpumpen). Und ja, ich bin mir bewusst, dass Letzteres mein (alleiniges) Risiko ist aber ich möchte nur illustrieren, welche Auswirkungen Änderungen haben können.

Zitat von: frank am 04 April 2022, 21:30:41
1. wenn jedes update aller module im angesprochenen thread angekündigt wird, ergibt sich sicherlich das selbe problem.

Das wäre in der Tat albern und war klar erkennbar auch nicht gemeint. Aber breaking Changes, insbesondere solche, die silent failen, könnte man dort ankündigen. Das war bei HMCCU nach meiner Wahrnehmung über mehrere Jahre einer, nämlich der, um den es hier geht.

Zitat von: frank am 04 April 2022, 21:30:41
2. für wirklich interessierte gibt es extra "update check".
dort wird verlässlich informiert.

Ja, im konkreten Fall mit

Code Auswählen


- change:  88_HMCCU: Update to version 5.0

was wohl ein perfekter Euphemismus für das Erlebte ist.

Zitat von: frank am 04 April 2022, 21:30:41
3. was hätte es gebracht, wenn du es gewusst hättest?
das ergebnis wäre doch wahrscheinlich das selbe gewesen, oder?

S. o. - Man hätte sich Zeit für die Migration nehmen können und wäre nicht von "toten" Automatisierungen überrascht worden.

Zitat von: frank am 04 April 2022, 21:30:41
4. über restore ist alles schnell wieder hergestellt.

... was einerseits ein Totschlagargument ist und andererseits ausblendet, dass man das Problem ggf. nicht sofort bemerkt.

Zitat von: frank am 04 April 2022, 21:30:41
5. zap hat sowieso keine chance, es allen recht zu machen.
ich finde, dass zap die umstellung mehr als vorbildlich umgesetzt und ewig darauf hingewiesen hat.

Eine Rückwärtskompatibilität wäre schon schön gewesen, ähnlich vielleicht den FHEM-Featurelevels. Aber es ist natürlich nachvollziehbar, wenn Zap sich dagegen entscheidet, gerade bei einem motivationsgetriebenen Hobbyprojekt. Ich meine Hobbyprojekt explizit nicht abwertend sondern möchte unterstreichen, dass man bei freien Projekten - und gerade bei den Freiheiten der FHEM-Modulautoren - doch einen größeren Gestaltungsspielraum hat.

Prinzipiell ist der Vorschlag mit den Ankündigungen nur eine Krücke. Eigentlich bräuchte man eine Lösung, mit der ein Update beim Checkin als "breaking" oder "zustimmungspflichtig" markiert werden kann, so dass es zwar angezeigt aber nur auf expliziten Wunsch eingespielt wird.

Patrick