HMCCU 5.0 Beta verfügbar

[zap]

Ein neues Update für HMCCU 4.4 ist in contrib/HMCCU/FHEM verfügbar.

@Martin: Bitte Dein IP-Thermostat nochmal neu anlegen (nach dem Update). Es sollte jetzt erkannt werden.

Um alle Readings zu bekommen:

Code Auswählen Erweitern

attr xy ccuflags showMasterReadings,showLinkReadings,showDeviceReadings
get xy values oder get xy update
get xy config

[martinp876]

@Zap: ist eingeabut, sieht schon einmal gut aus

@Thomas: Mir ist nicht klar, was du erreichen willst. Erst einmal schliesse ich mich dem Dank an zap für die unermüdliche Arbeit an. Allerdings fehlen mir noch einige Details (es ist also noch viel zu tun und wird einiges an Zeit kosten).

auf welche Events, die von der CCU geliefert werden, die regex der ccureadingffilter angewendet werden

in FHEM ist es üblich, alle Events in Readings abzubilden. Die uralten Attribute event-on-change-reading und event-on-update-reading sind für die Steuerung verantwortlich, welches Reading ein event auslösen soll und welches nicht. "ccureadingffilter"  sollte entweder eine wichtige Erweiterung liefern welche nicht zentral realisiert werden kann/sollte - oder es sollte entfernt werden. Wir arbeiten hier an der FHEM platform und nicht in einer HMCCU-internen Lösung.

@zap: Wir gesagt, noch einmal danke. Ich werden (natürlich) weiter testen und versuchen konstruktiv zu kommentieren.

Die Heizung - set kommandos
- control/desired-temp: Diese sind doppelt. Kann man "control" entfernen?
- auto/holiday/boost: Das sollte m.E. ein Kommando sein. Set entity coltrolMode [auto|boost|holiday]. Eine Drop-down liste ist angebracht. Es fehlen day/night/manu
- manu: passt fast zu controlMode. Hier sollte es aber ein weiteres kommando geben, in dem man die Temperatur gleich angeben kann. Das ist der typische fall (set entity controlManu 21)
- on/off: Das ist wohl ein Überbleibsel von etwas altem. noArg ist nicht korrekt implementiert - wenn es aber komplett gelöscht wird ist es wurscht.
- control: das ist das setzen der Register. Die Syntax sollte a) in der Fehlermeldung kommen wenn man keine Parameter angibt und b) empfehle ich ein get entity cmdList welche die komplette Liste der möglchen Kommandos incl parameter listet. Sollte m.E. jedes modul implementieren

Weiter:
Readings sollten per default immer automatisch aktualisiert werden. Wenn FHEM die Zentrale ist (das ist m.E. das Ziel) sind alle Events immer abzuholen. Ich kann mir keinen anderen Betrieb vorstellen.

Was natürlich noch fehlt ist die Peering-Struktur, wochenplan und Wochenplan-auswahl. Hier ist einiges zutun - und hier muss man über eq3 hinaus erweitern. Ein Wochenplan bspw darf nicht nur eine Nummer sein, ich brauche einen Namen hierzu. Heating ist ein recht komplexes Thema - mit vielen Usern.

[martinp876]

Noch ein kommentar:
Ccureadingnames: das duplizieren von readings in fhem macht man mit userreading.
Das renamen von readings um sie den fhem Systemgepflogenheiten anzupassen sollte intern geschehen.

Warum also brauche ich diese Einträge? Das attribut ist überflüssig incl der funktionen welche du sicher intern implementiert hast ( duplicate) und die default umsetzung sollte immer und intern passieren, so wie es alle anderen module auch machen.

[zap]

Die Heizung - set kommandos
- control/desired-temp: Diese sind doppelt. Kann man "control" entfernen?

control ist noch so ein Relikt, das ich mich noch nicht getraut habe zu entfernen. Muss erst prüfen, ob es Seiteneffekte hat.

- auto/holiday/boost: Das sollte m.E. ein Kommando sein. Set entity coltrolMode [auto|boost|holiday]. Eine Drop-down liste ist angebracht. Es fehlen day/night/manu

Das liegt an der Implementierung dieser Controlmodes in den IP-Thermostaten. Bei den alten BidCos-Thermostaten gab es einen Datenpunkt CONTROL_MODE, über den man die Modi gesteuert hat. Bei IP hat jeder Modus seinen eigenen Datenpunkt zur Steuerung und CONTROL_MODE hält lediglich den (readonly) Status.

- manu: passt fast zu controlMode. Hier sollte es aber ein weiteres kommando geben, in dem man die Temperatur gleich angeben kann. Das ist der typische fall (set entity controlManu 21)

Sollte eigentlich so sein (mit Termperaturangabe). Vermutlich ein Fehler in der Befehlsdefinition.

- on/off: Das ist wohl ein Überbleibsel von etwas altem. noArg ist nicht korrekt implementiert - wenn es aber komplett gelöscht wird ist es wurscht.

Wird weiter gebraucht. Schaltet die Heizung dauerhaft aus (Setzen der Temperatur auf 4.5 Grad) oder dauerhaft ein (Temperatur = 30.5, quasi boost ohne Berücksichtigung der boost-Dauer).

Weiter:
Readings sollten per default immer automatisch aktualisiert werden. Wenn FHEM die Zentrale ist (das ist m.E. das Ziel) sind alle Events immer abzuholen. Ich kann mir keinen anderen Betrieb vorstellen.

Die get-Befehle im Beitrag oben waren nur für Dich zum schnellen Testen gedacht. Die Readings der VALUES Parametersets werden automatisch aktualisiert, wenn der RPC-Server gestartet ist. Bei den MASTER Parametersets aktualisiert die CCU das leider nicht automatisch. Bin noch unschlüssig, ob ich einen internen Timer implementiere, der das erledigt oder es dem Nutzer überlasse (per at Befehl).

Was natürlich noch fehlt ist die Peering-Struktur, wochenplan und Wochenplan-auswahl. Hier ist einiges zutun - und hier muss man über eq3 hinaus erweitern. Ein Wochenplan bspw darf nicht nur eine Nummer sein, ich brauche einen Namen hierzu. Heating ist ein recht komplexes Thema - mit vielen Usern.

Wochenplan ist in Arbeit. Hat jetzt zwar nochmal etwas Zeit gekostet, aber ich habe jetzt in HMCCUConf.pm recht flexible Datenstrukturen implementiert, um Befehle, Attribute, Konvertierungen von Werten abhängig von der Kanal-Rolle definieren zu können. Das erleichtert die Implementierung Gerätetyp abhängiger Befehle ungemein, da ich nichts am Code von HMCCUCHN oder HMCCUDEV ändern muss.

Bei Interesse kannst Du Dir ja mal die ersten 4 oder 5 Hashes in HMCCUConf.pm anschauen.

[zap]

genau umgekehrt: bei IP-Thermostaten erfolgt die Steuerung über CONTROL_MODE, bei BidCos über einzelne Datenpunkte.

Zumindest bei IP wird es dann eine Auswahlliste geben. Die Enums sind noch nicht implementiert, aber gerade in Arbeit (s.a. Wochenprogramme). Enums sind dann die Einträge der Auswahlliste

[martinp876]

Code Auswählen Erweitern

Das liegt an der Implementierung dieser Controlmodes in den IP-Thermostaten.
ok, die Entscheidung ist nicht ganz einfach. Soll man sich strikt an die Kommandos von EQ3 halten oder hier händisch ein "neues" Kommando implementieren.
De-Factor ist es auch in der HMIp  nur ein Value der durch mehrere Kommandos verädert wird.
Ich sehe, hier, dass man (du) es manuell a implementieren solltest, analog wie es bei BidCos war.
Das Frontend der HMCCU (eq3) sieht für beiden identisch aus. Ich sehe hier, dass ein gleiches Frontend vorrang vor der strikten Einhaltung der Schnittstellendefinition hat.
Also mit anderen Worten: Alles was bei BidCos und HMIP gleich ist sollte es auch gleich aussehen. Ich als User will mir am Ende nicht Gedanke machen "wie ist das nun bei HMIP? anderes Kommando?"
Gleiches gilt für die Module welche die beiden RTs bedienen wollen.

Wird weiter gebraucht. Schaltet die Heizung dauerhaft aus

Sehe ich nicht so. Alle andere machen es über das Setzen der Temperatur auf off. Das ist sowieso nicht dauerhaft sondern hängt vom Controlmode ab. Neben desired-temp ist dies also nicht notwendig und nicht üblich.

(Temperatur = 30.5, quasi boost ohne Berücksichtigung der boost-Dauer).

Würde ich so nicht ausdrücken. Boost hat eigene Einstellungen wie boost-valve-position. Also vorsicht, so etwas "offentlich" gleich zu setzen. Ähnlich ist ok.

Die Readings der VALUES Parametersets werden automatisch aktualisiert, wenn der RPC-Server gestartet ist.

klappt bei mir nicht. Was muss ich einstellen? Hoffetlich nichts

Wochenplan ist in Arbeit. ...
Bei Interesse kannst Du Dir ja mal die ersten 4 oder 5 Hashes in HMCCUConf.pm anschauen.

super - schaue ich mir an.

[thomas.z]

@matinp876

auf welche Events, die von der CCU geliefert werden, die regex der ccureadingffilter angewendet werden (bzw. wie man die für ein Gerät ermitteln kann).

Ja, Du hast recht, das habe ich sehr schlecht formuliert. Es ist definitiv unverständlich, sorry.
Wenn ich z. B. mit dem vi einen Text bearbeite, kann ich z. B. erkennen, ob das, was ich suche, immer am Anfang einer Zeile beginnt, und kann dann das regex pattern mit einem ^ versehen. Bei den ccureadingfiltern kann ich nur annehmen, wie der Text aussieht, die die CCU per rpcproc an HMCCU liefert, und was dann von HMMCU davon tatsächlich verwendet wird. Ich muss die regex quasi "blind" formulieren in der Hoffnung, dass es schon zu den richtigen Readings führen wird.
Meine Annahme war, dass 1. nur genau die events auf updates von den Kanalparametern, die im deviceinfo auf das HMCCUDEV Gerät gelistet werden, auch für das mapping mit den ccrureadingfiltern auf dies Gerät herangezogen werden, und das 2. dann z. B. (LEVEL|...) genau mit dem einem Level, der in Kanal 1 des virtuellen CCU-Gerätes gesendet wird, zu einem Update des Readings benutzt wird. Dem ist aber nicht so. Es werden anscheinend die Events zu allen Kanalparametern aller Geräte der Gruppe auf die regex gemappt (die, die bei "list <virtual-dev>" angezeigt werden).

Und nun komme ich zu dem, was ich möchte. Ich habe 2 Räume, in denen jeweils 2 eTRV-B mit einem WTH eine Heatinggroup bilden.
Alle 3 Geräte haben einen Temperatursensor und jeder der beiden eTRV ihren "eigenen" Öffnungslevel. Das virtuelle Gerät der CCU konsolidiert die Werte so, dass als Raumtemperatur immer die Temperatur des WTH gilt, und dass als LEVEL der eTRV immer der Öffnungsgrad des eTRV genommen wird, der den größeren LEVEL hat. Kann man mit z. B. TinyMatic gut sehen, weil die App das sauber separiert bekommt.

Diese Konsolidierung wollte ich nicht in FHEM machen, wenn sie schon im virtuellen Gerät gemacht wid. Mit HMCCUDEV bekam ich aber gelegentlich in kurzer Folge 3 unterschiedliche Temperaturen und 2 unterschiedliche Levels in meine Readings, so dass die Plots etwas zickzackartig verliefen. Was nicht wirklich gut ist, wenn ich später mal das An- und Abschalten der Heizung auf der Basis dieser Daten steuern möchte.

Ich hoffe, das ist nun etwas verständlicher formuliert. Falls nicht, bitte fragen.
Danke und Gruß
Thomas

[zap]

Derzeit ist es so gelöst, dass ein Device einer virtuellen Gruppe nicht nur die Readings der Gruppe sondern auch die der Gruppenmitglieder enthält. Das ist tatsächlich verwirrend. Früher dachte ich mal, dass das nützliche Infos sind.
In der 4.4 werde ich das beerdigen. Macht den Code auch deutlich einfacher.

[zap]

Ich habe gerade eine neue Version der Beta in contrib/HMCCU/FHEM eingecheckt. Änderungen:

- Fehler in HMCCURPCPROC behoben, der die automatische Aktualisierung der HmIP Devices verhindert hat (danke EQ3 )

Folgende Kanaltypen sollten nun automatisch erkannt werden, sofern das Modul HMCCUCHN verwendet wird:

'SHUTTER_CONTACT'
'SHUTTER_CONTACT_TRANSCEIVER'
'ROTARY_HANDLE_TRANSCEIVER'
'ALARM_SWITCH_VIRTUAL_RECEIVER'
'SMOKE_DETECTOR'
'LUXMETER'
'MOTIONDETECTOR_TRANSCEIVER'
'KEY'
'KEY_TRANSCEIVER'
'BLIND'
'BLIND_VIRTUAL_RECEIVER'
'SWITCH'
'SWITCH_VIRTUAL_RECEIVER'
'DIMMER'
'DIMMER_VIRTUAL_RECEIVER'
'WEATHER_TRANSMIT'
'THERMALCONTROL_TRANSMIT'
'CLIMATECONTROL_RT_TRANSCEIVER'
'HEATING_CLIMATECONTROL_TRANSCEIVER'

Die Kanäle mit _TRANSCEIVER oder _RECEIVER am Ende gehören zu HmIP Geräten.

[martinp876]

@Thomas

Bei den ccureadingfiltern kann ich nur annehmen, wie der Text aussieht,....

keine Frage: regexp ist eindeutig definiert und ccureadingfiltern  sollte sich an die Syntax halten. Die "rohwerte" auf welche der/ein Filter angewendet wird müssen 1:1 in der entsprechenden "Beschreibung", also get ... ausgegeben werden. Dann (und nur dann) kann man arbeiten.
Dann musst du nicht mehr "blind" arbeiten.

Ich habe 2 Räume, in denen jeweils 2 eTRV-B mit einem WTH eine Heatinggroup bilden.

ok, heizung und deren Gruppierungen. Da gibt es einiges zu sagen .... und noch zu tun.
1) Ist-Temperatur

Das virtuelle Gerät der CCU konsolidiert die Werte so...

nicht (ganz) korrekt.
a) man kann RTs unterschiedlich peeren - z.B. nur die Ist-temperatur. Anwendung ist, wenn man einen RT-externen Temperaturfühler hat. Das kann ein einfaches Thermometer sein oder ein "IT". Sobald der Temperatur-kanal des RT gepeert (und aktiv) ist schaltet der RT seine interne Temperaturmessung ab. Man kommt an die Temperatur des RT nicht mehr heran. Das macht nicht die Zentrale sondern der RT selbst. Sollte der RT nichts mehr empfangen (externer Sensor tot) schaltet er seine interne Messung wieder ein.
b) Öffnungsgrad
natürlich hat jedes Ventil einen eigenen Öffnungsgrad und diesen will ich sehen - von jeden Device separat - unbedingt
c) RT teaming
Sind 2 RTs in einem Team wird die soll-temperatur von einem zum anderen übertragen. D.h. wenn ich am Stellrad eines RTs die soll-temp einstelle wird es an den 2. übertragen. Setze ich nun die Solltemp eines RTs in der Zentrale muss ich sicherstellen, dass es an alle Team-mitglieder übertagen wird. Das muss die Zentrale sicherstellen. Aktuell ist mir noch nicht klar, ob das die CCU automatisch erkennt und ausführt oder ob das FHEM machen muss. In CUL_HM habe ich das so realisiert (keine CCU im Spiel).
Sollte man einen "IT" nutzen verteilt dieser nach spätestens 3 min die neue soll-temp.

Mit virtuellen Teams in der CCU habe ich keinerlei erfahrungen - habe ich aktuell auch nicht vor.
FHEM sollte in DEV oder CHN sauber die Werte der entsprechenden entites darstellen - das muss primäres Ziel sein.
3 unterschiedliche Raumtemperaturen kann ich mir nicht vorstellen - das muss ein bug sein. Oder ich habe die Konfiguration nicht verstanden.
falls eine Akkumulation der Ventile gewünscht ist sollte das das in einem übergeordneten Device machen - in DEV der CHN hat es m.E. nichts verloren. Ich akkumuliere unterschiedliche Werte für meine Auswertung - nach meinen Wünschen. Auch Ventile zu einer Gesamtübersicht im Haus... im Verhältniss zur Heizung. Das sollte DEV und CHN nicht machen, das macht der Anwender separat.

[zap]

Unterschiedliche Temperaturen in virtuellen Gruppen kommen dadurch zustande, dass hier die Werte aller Devices der Gruppe (HK Thermostat, Wandthermostat) dargestellt werden. Das ist eine Erweiterung in HMCCUDEV. Da das mehr verwirrt als hilft, werde ich das entfernen, wenn ich demnächst HMCCUDEV angehe.
Habe jetzt etwas mehr Zeit, da dank Dauer-Homeoffice die täglichen 90 Stauminuten wegfallen 

[thomas.z]

@martinp876

Die "rohwerte" auf welche der/ein Filter angewendet wird müssen 1:1 in der entsprechenden "Beschreibung", also get ... ausgegeben werden. Dann (und nur dann) kann man arbeiten.
Dann musst du nicht mehr "blind" arbeiten.

Ja, genau da lag mein Problem. HMCCUDEV zeigte bei get deviceinfo nur die Werte des virtuellen Gerätes, der HmIP-Heizungsgruppe an. Aber der ccureadingfilter wurde im Hintergrund nicht nur auf diesen "get deviceinfo" Text angewendet, sondern zusätzlich auf das, was die "echten" Geräte liefern. Da Filter auf ACTUAL_TEMPERATURE z. B. hat also von allen Geräten die Temperatur extrahiert und in ein einziges reading geschrieben. Dito bei den LEVELs.

Mit virtuellen Teams in der CCU habe ich keinerlei erfahrungen - habe ich aktuell auch nicht vor.
FHEM sollte in DEV oder CHN sauber die Werte der entsprechenden entites darstellen - das muss primäres Ziel sein.

Das funktioniert für mich nun auch gut, wenn ich statt mit HMCCUDEV  mit HMCCUCHN ein Gerät für Kanal 1 des virtuellen HmIP-Gerätes definiere. Und natürlich kann ich auch für die physikalischen HmIP-Geräte der Gruppe ein fhem device erzeugen, um an deren Werte zu gelangen.

Ein potentieller Nachteil der Verwendung von HMCCUCHN ist, dass ich im zugehörigen fhem device die Daten der anderen Kanäle, also z. B. 0 für den Status, nicht habe. Ich bin mir aber nicht sicher, ob dass tatsächlich ein Nachteil ist.

Mit virtuellen Teams in der CCU habe ich keinerlei erfahrungen - habe ich aktuell auch nicht vor.
FHEM sollte in DEV oder CHN sauber die Werte der entsprechenden entites darstellen - das muss primäres Ziel sein.
3 unterschiedliche Raumtemperaturen kann ich mir nicht vorstellen - das muss ein bug sein. Oder ich habe die Konfiguration nicht verstanden.
falls eine Akkumulation der Ventile gewünscht ist sollte das das in einem übergeordneten Device machen - in DEV der CHN hat es m.E. nichts verloren.

In der aktuellen CCU3 gibt es nur die Heizungsgruppe als mögliches, virtuelles Gerät. Dies in zwei Varianten abhängig von der HW - Hm oder HmIP. Die Aufgabe, per virtuellem Gerät bestehend aus z. B. einem Wandthermostat und zwei Heizkörperthermostaten die Erwärmung des Raumes zu steuern, scheint mir für die HmIP-Geräte gut gelungen. Beim Anlegen der Heizungsgruppe werden die direkten Verknüpfungen zwischen den Geräten automatisch erzeugt, da muss ich nichts zusätzlich machen. Das oder die Wochenprogramme definiere ich nur für das virtuelle Gerät, und die CCU überträgt das dann automatisch an alle Gruppengeräte.
Wird ein Gerät defekt, lösche ich es aus der Gruppe, lösche seine direkten Verknüpfungen und dann das Gerät selbst. Danach kann ich ein neues Gerät anlernen und zur Gruppe hinzufügen. Mit diesem Hinzufügen wird es automatisch mit den Programmen der Gruppe versorgt.

Man kann auch eine virtuelles Gerät Heizungsgruppe definieren mit nur einem zugeordneten Heizkörperthermostaten. Ich habe allerdings noch nicht probiert, ob die Gruppe verschwinden würde, wenn man den einzigen Thermostaten darin herauslöscht.

Zu den unterschiedlichen Werten habe ich mal einen screenshot von der TinyMatic-App gemacht. Heizung-Wohnzimmer-1 ist das virtuelle Gerät (die HmIP-Heizungsgruppe), TH die Heizkörperthermostaten und WTH der Wandthermostat. Das virtuelle Gerät verwendet für die Konsolidierung die Temperatur und Luftfeuchte des WTH, und den jeweils größeren Öffnungs-LEVEL der TH.
Nach weiterer Beobachtung scheint diese Aussage doch nicht richtig zu sein. Aktuell sieht es so aus, als würde einfach der zuletzt von einem eTRV gesendete Wert als aktueller LEVEL in das virtuelle Gerät übernommen. Ich werde das weiter untersuchen und berichten. Eine erste Anfrage bei eQ-3 brachte leider keine Antwort dazu.

Ich akkumuliere unterschiedliche Werte für meine Auswertung - nach meinen Wünschen. Auch Ventile zu einer Gesamtübersicht im Haus... im Verhältniss zur Heizung. Das sollte DEV und CHN nicht machen, das macht der Anwender separat.

DEV bzw. CHN akkumulieren nicht. Sie greifen nur auf die fertigen Daten des virtuellen Gerätes zu (bei DEV leider noch nicht richtig, aber zap hat das ja schon auf dem Zettel). Und der TinyMatic screenshot zeigt auch, dass keinerlei Detailinformationen durch das virtuelle Gerät verloren gehen, da alle echten Geräte vollständig zugreifbar sind.

Gruß
Thomas

[thomas.z]

Moin,
es hat etwas gedauert, aber nun kann ich die Analyse liefern, ob die "virtuellen" HmIP-Heizunggruppen die LEVEL-Datenpunkte konsolidieren oder nicht.
Sie tun es nicht.
Im Bild Themostat-LEVEL sieht man die Level der einzelnen Thermostaten als Punktdarstellung in grün und rot, die blaue Linie verbindet die Level-Werte, die das  virtuelle Gerät liefert. Der Level des virtuellen Gerätes ist also nur der Level desjenigen Thermostaten, der zuletzt einen Wert geliefert hat.

Für die Temperatur habe ich es mal ähnlich gemacht. Im Bild Thermostate-Temperatur sind die Punkte die Temperaturwerte der Heizkörperthermostaten, die braue  Linie verbindet die Werte des Wandthermostaten, und die rote Linie verbindet die vom virtuellen Gerät gesendeten Temperaturen. Man kann erkennen, dass das virtuelle Gerät nur die Temperatur des WTH heranzieht, aber zusätzlich noch Temperatur-Werte generiert (zuletzt gesnedete Temperatur), wenn der WTH länger nichts gesendet hat. Das ist aus meiner Sicht völlig sinnfrei.

Mein Fazit: Die Datenpunkte des virtuellen Geräts, zumindest die für LEVEL und ACTUAL_TEMPERATURE, sind nicht zur Auswertung geeignet.
Gruß
Thomas

[zap]

Wäre cool, wenn mal jemand außer Martin die 4.4 testen würde. Gerne Nutzer, die BidCos und HmIP Geräte in einer CCU/HMCCU Umgebung haben. Dazu muss aber mit Bedacht vorgegangen werden:

Angenommen, das FHEM Verzeichnis ist /opt/fhem, dann:
1. FHEM anhalten (shutdown)
2. cd /opt/fhem
3. cp fhem.cfg fhem.cfg.43
4. cd FHEM
5. for i in 88_HMCCU*pm HMCCU*pm; do cp $i $i.43; done
3. Alle Module der Version 4.4 manuell aus https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/FHEM runterladen und in das FHEM Modulverzeichnis /opt/fhem/FHEM kopieren
4. FHEM wieder starten und hoffen, dass alles läuft

Achtung! Wenn Ihr in FHEM ein Update ausführt, werden die Beta-Module wieder durch die Version 4.3 überschrieben!

Wenn irgendwas nicht läuft:
1. Fehlermeldungen im FHEM Logfile notieren
2. FHEM anhalten, falls es noch läuft
3. cd /opt/fhem
4. cp fhem.cfg.43 fhem.cfg
5. cd FHEM
6. for i in *pm.43; do mv $i ${i%.43}; done
7. FHEM starten

Wichtige Änderungen von Version 4.3 nach Version 4.4:

- Der interne RPC Server wird nicht mehr unterstützt. Das Attribut ccuflags=procrpc ist damit hinfällig
- Je CCU Device-Channel kann nur noch 1 HMCCUCHN Device definiert werden. Mehrere HMCCUDEV-Devices je CCU Device sind nach wie vor möglich. Das ist insbesondere für HmIP-Wired wichtig
- Bei der interaktiven Definition von Devices (HMCCUCHN und HMCCUDEV) versucht HMCCU nun, anhand der Kanalrolle Default-Attribute zu setzen. Wenn das nicht funktioniert, werden wie bisher die Defaults aus HMCCUConf.pm verwendet. Das Setzen der Defaultattribute kann mit der Option 'noDefaults' beim define Befehl verhindert werden.
- Per Default werden nun alle Datenpunkte gelesen und als Reading dargestellt. Der Readingfilter (ccureadingfilter) ist per Default = .*
- Bei virtuellen Devices (z.B. Heizungsgruppen) werden nun nicht mehr die Readings der Gruppen-Devices gespeichert, sondern nur noch die des virtuellen Devices. Das alter Verhalten kann man mit dem Attribute ccuflags=updGroupMembers im IO-Device wieder aktivieren
- Allgemein: Die Module arbeiten nun wesentlich "intelligenter", indem sie bestimmte Befehle und Parameter aus den Parameterdefinitionen der CCU ermitteln. Dadurch sind in vielen Fällen Attribute wie 'substitute', 'ccuscaleval', 'ccureadingname' u.a. nicht mehr erforderlich.

[thomas.z]

Hallo zap,

gerade habe ich mal den Update von 4.3 auf 4.4 gemacht. FHEM ließ sich anstandslos wieder starten. Hier das logfile:

Code Auswählen Erweitern

2020.04.09 11:36:45 1: HMCCU: [d_ccu : 7697] Graceful shutdown in 8 seconds
2020.04.09 11:36:45 3: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] StopRPCServer()
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Stopping RPC server CB2001000001000001
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Deregistering RPC server http://127.0.0.1:7411/fh2001 with ID CB2001000001000001 at http://127.0.0.1:2001
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Callback for RPC server CB2001000001000001 deregistered
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Sending signal INT to RPC server process CB2001000001000001 with PID=7706
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Cleaning up immediately
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Housekeeping called. Cleaning up RPC environment
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] CB2001000001000001 received signal INT
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] CB2001000001000001 received signal INT
2020.04.09 11:36:45 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] RPC server CB2001000001000001 stopped handling connections. PID=7706
2020.04.09 11:36:45 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7706] Number of I/O errors = 0
2020.04.09 11:36:47 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] RPC server process CB2001000001000001 deleted
2020.04.09 11:36:47 1: HMCCU: [d_ccu : 7697] All RPC servers inactive
2020.04.09 11:36:47 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Stop I/O handling
2020.04.09 11:36:47 3: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Close child socket
2020.04.09 11:36:47 3: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] Close parent socket
2020.04.09 11:36:47 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 7697] RPC server stopped. Cancel delayed shutdown.
2020.04.09 11:36:48 3: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] StopRPCServer()
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Stopping RPC server CB2010000001000001
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Deregistering RPC server http://127.0.0.1:7420/fh2010 with ID CB2010000001000001 at http://127.0.0.1:2010
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Callback for RPC server CB2010000001000001 deregistered
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Sending signal INT to RPC server process CB2010000001000001 with PID=7707
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Cleaning up immediately
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Housekeeping called. Cleaning up RPC environment
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] CB2010000001000001 received signal INT
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] CB2010000001000001 received signal INT
2020.04.09 11:36:48 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] RPC server CB2010000001000001 stopped handling connections. PID=7707
2020.04.09 11:36:48 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7707] Number of I/O errors = 0
2020.04.09 11:36:50 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] RPC server process CB2010000001000001 deleted
2020.04.09 11:36:50 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Stop I/O handling
2020.04.09 11:36:50 3: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Close child socket
2020.04.09 11:36:50 3: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] Close parent socket
2020.04.09 11:36:50 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 7697] RPC server stopped. Cancel delayed shutdown.
2020.04.09 11:36:51 3: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] StopRPCServer()
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Stopping RPC server CB9292000001000001
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Deregistering RPC server http://127.0.0.1:14702/fh9292 with ID CB9292000001000001 at http://127.0.0.1:9292/groups
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Callback for RPC server CB9292000001000001 deregistered
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Sending signal INT to RPC server process CB9292000001000001 with PID=7708
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Cleaning up immediately
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Housekeeping called. Cleaning up RPC environment
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] CB9292000001000001 received signal INT
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] CB9292000001000001 received signal INT
2020.04.09 11:36:51 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] RPC server CB9292000001000001 stopped handling connections. PID=7708
2020.04.09 11:36:51 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7708] Number of I/O errors = 0
2020.04.09 11:36:53 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] RPC server process CB9292000001000001 deleted
2020.04.09 11:36:53 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Stop I/O handling
2020.04.09 11:36:53 3: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Close child socket
2020.04.09 11:36:53 3: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] Close parent socket
2020.04.09 11:36:53 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 7697] RPC server stopped. Cancel delayed shutdown.
Select error -1 (3)
2020.04.09 11:44:35 0: HMCCU: [d_ccu : 13128] Scheduling post FHEM initialization tasks in 12 seconds
2020.04.09 11:44:35 0: Featurelevel: 5.9
2020.04.09 11:44:35 0: Server started with 39 defined entities (fhem.pl:21044/2020-01-24 perl:5.028001 os:linux user:fhem pid:13128)
2020.04.09 11:44:47 1: HMCCU: [d_ccu : 13128] Reading device config from CCU. This may take a couple of seconds ...
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Read device configuration: devices/channels=258 parametersets=153 links=27
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Get RPC device for interface BidCos-RF
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Get RPC device for interface HmIP-RF
2020.04.09 11:44:57 2: HMCCU: [d_ccu : 13128] Get RPC device for interface VirtualDevices
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server process started for interface BidCos-RF with PID=13149
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] Initializing RPC server CB2001000001000001 for interface BidCos-RF
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server starting
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server process started for interface HmIP-RF with PID=13150
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] Initializing RPC server CB2010000001000001 for interface HmIP-RF
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server starting
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server process started for interface VirtualDevices with PID=13151
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] Initializing RPC server CB9292000001000001 for interface VirtualDevices
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server starting
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] Callback server CB2001000001000001 created. Listening on port 7411
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] CB2001000001000001 accepting connections. PID=13149
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server CB2001000001000001 enters server loop
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] Registering callback http://127.0.0.1:7411/fh2001 of type A with ID CB2001000001000001 at http://127.0.0.1:2001
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] Callback server CB2010000001000001 created. Listening on port 7420
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] CB2010000001000001 accepting connections. PID=13150
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] RPC server CB2001000001000001 running
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13128] Scheduled CCU ping every 300 seconds
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] Callback server CB9292000001000001 created. Listening on port 14702
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] CB9292000001000001 accepting connections. PID=13151
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server CB2010000001000001 enters server loop
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] Registering callback http://127.0.0.1:7420/fh2010 of type A with ID CB2010000001000001 at http://127.0.0.1:2010
2020.04.09 11:44:57 1: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13128] RPC server CB2010000001000001 running
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server CB9292000001000001 enters server loop
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] Registering callback http://127.0.0.1:14702/fh9292 of type A with ID CB9292000001000001 at http://127.0.0.1:9292/groups
2020.04.09 11:44:57 2: HMCCURPCPROC: [d_rpc000001BidCos_RF : 13149] CB2001000001000001 NewDevice received 52 device and channel specifications
2020.04.09 11:44:58 2: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13151] CB9292000001000001 NewDevice received 35 device and channel specifications
2020.04.09 11:44:58 2: HMCCURPCPROC: [d_rpc000001HmIP_RF : 13150] CB2010000001000001 NewDevice received 171 device and channel specifications
2020.04.09 11:45:07 1: HMCCURPCPROC: [d_rpc000001VirtualDevices : 13128] RPC server CB9292000001000001 running
2020.04.09 11:45:07 1: HMCCU: [d_ccu : 13128] All RPC servers running
2020.04.09 11:45:07 2: HMCCU: [d_ccu : 13128] Updating 5 of 5 client devices matching devexp=.* filter=ccudevstate=active,ccuif=BidCos-RF|HmIP-RF|VirtualDevices
2020.04.09 11:45:08 2: HMCCU: [d_ccu : 13128] Update success=5 failed=0


Seltsamerweise ist aber nun ein device "verschwunden". Es wird per webui nicht mehr angezeigt, auch nicht in everything. Die Definition ist aber im fhme.cfg noch enthalten:

Code Auswählen Erweitern

define wz_hzg HMCCUCHN Heizung-Wohnzimmer-1 defaults
setuuid wz_hzg 5e62461f-f33f-f867-319e-fecd2c08abf0ffe7
attr wz_hzg IODev d_ccu
attr wz_hzg ccureadingfilter (ACTUAL_TEMPERATURE|SET_POINT_TEMPERATURE|LEVEL|HUMIDITY)
attr wz_hzg room Wohnzimmer

Heizung-Wohnzimmer-1 ist Kanal 1 des virtuellen HmIP-Heizungsgruppe Gerätes. Alle 4 für anderen Räume identisch definierten devices sind nach wie vor sichtbar.
Der Austausch der pm-Module war die einzige Änderung, die ich gemacht habe. Stop und start von FHEM erfolgte über systemctl <command> FHEM (unter debmatic.

Falls Du eine Idee hast, was ich prüfen könnte, würde ich das gerne tun.

Gruß
Thomas