Neues Modul HMCCU für Homematic CCU

[RainerG]

Bitte prüfe, ob am Anfang der Dateien 88_HMCCUDEV.pm und 88_HMCCUCHN.pm tatsächlich "use Time::HiRes;" steht (Zeilen 45 bzw. 42). Falls nicht, lade die beiden Dateien von Sourceforge und kopiere sie ins Modulverzeichnis.
Falls der Use-Befehl schon vorhanden ist: Hast Du die Module neu geladen, nachdem Du die Updates im Modulverzeichnis installiert hast (reload 88_HMCCUDEV und reload 88_HMCCUCHN) ?
Der Fehler in Deinem Fall ist definitiv, dass use Time::HiRes fehlt und damit usleep nicht bekannt ist.

Leider muß es noch eine Ursache geben:
Deine Dateien sind ok und Time::HiRes scheint auch richtig installiert zu sein:

cpan[1]> install Time::HiRes
Reading '/root/.cpan/Metadata'
  Database was generated on Sun, 27 Dec 2015 05:17:02 GMT
Time::HiRes is up to date (1.9728).

Und trotzdem schmiert FHEM weiter ab.
Habt Ihr noch Ideen? - Danke Rainer

[hometux]

Hallo Rainer,
Ich hatte das gleiche Problem. Die Perl Version ist zu alt und hat das Time::HiRes Modul noch nicht standardmäßig mitgeliefert.

Die einfachste Lösung besteht darin, die Anweisung usleep(100000) durch ein sleep (1) zu ersetzen.

[zap]

Hallo Rainer,
Ich hatte das gleiche Problem. Die Perl Version ist zu alt und hat das Time::HiRes Modul noch nicht standardmäßig mitgeliefert.

Die einfachste Lösung besteht darin, die Anweisung usleep(100000) durch ein sleep (1) zu ersetzen.

Das geht natürlich und ich überlege, das auch so in die offiziellen Module aufzunehmen. Allerdings wird damit die Wartezeit zwischen set und nachfolgendem get verzehnfacht (100 ms => 1 s). Im Prinzip ist das usleep() und das get nur erforderlich, wenn kein RPC-Server verwendet wird, denn der RPC-Server wird durch das Set sowieso ein Event mit dem geänderten Wert von der CCU bekommen.

Die Fehlermeldung bei RainerG besagt eindeutig, dass usleep nicht gefunden wurde. Deshalb schmiert FHEM ab. Ich vermute immer noch, dass hier zwar die aktuellen Module und auch Time::HiRes installiert wurden, die Module aber mangels Reload bzw. FHEM-Neustart (Reload genügt normalerweise) nicht verwendet werden.

Aufpassen beim Neustart von FHEM bei aktivem RPC-Server: Nicht mit /etc/init.d/fhem restart neu starten. Dabei wird zwischen Stop und Start nicht lange genug gewartet und der RPC-Server wird versucht zu starten, bevor er richtig beendet wurde. Also immer erst Stop, warten bis der RPC-Server nicht mehr läuft und dann Start.

UPDATE: Neue Version von 88_HMCCU.pm eingecheckt. In allen Reading Names, die auf CCU Geräten oder Kanälen basieren werden alle Zeichen ersetzt, die keine gültigen Zeichen für FHEM Reading Names sind. Konkret: Doppelpunkte werden durch Punkte ersetzt. Alle Zeichen, die nicht zum Ausdruck [A-Za-z\d_\.-] passen, werden durch Unterstriche ersetzt.

[hometux]

Hallo zap,

Erst einmal ganz vielen Dank für die schon super gute Funktionalität. HMCCU schließt m.E. die entscheidende Lücke in der HM-Unterstützung.

Ich nutze neben den drahtlosen Komponten auch verschiedene Wired Komponenten. Dafür stellt die CCU eine zweite RPC Schnittstelle unter der Portnummer 2000 zur Verfügung.

Ich habe einmal probehalber die Portnummer für den RPC Port auf 2000 gesetzt. Das funktioniert auch grundsätzlich, natürlich nun ohne die Wireless Komponenten. Probleme scheint es beim HM-Input Modul mit vielen Kanälen zu geben. Diese werden offenbar nicht einzeln ausgewertet und aktualisieren immer gemeinsam- das muss ich allerdings noch genauer untersuchen.

Meine konkrete Frage: spricht etwas prinzipiell dagegen, 2 RPC-Prozesse gleichzeitig laufen zu lassen (gegen Port 2000 und 2001 der ccu)? Im Moment ist das ja offenkundig programmtechnisch geblockt.

[lukasbastelpeter]

Hallo zusammen, zunächst einmal meine Variante aus der CCU heraus Fhem-Befehle auszuführen, für alle die es interessiert:
-> Für "komplexere" Dinge wie z.B. Wetterberichte, die ich nicht unbedingt via http aufrufen will...

1. In der CCU gibt es zwei Systemvariablen,
Fhem.A.value und Fhem.A.state

Das A steht für einen Index und ist einfach nur falls ich mal mehrere "interfaces" brauche, genau wie Fhem.A.state
(Die Überlegung ist halt, wenn ein CCU-Programm abläuft checkt es: ist ...A.state=readyToReceive? Wenn ja, dann Befehl in Fhem.A.value, ansonsten versuche es entsprechend mit Fhem.B)

2. Mein Fhem holt sich sekündlich via RCP die Variablen aus der CCU ab, darunter auch Fhem.A.value, und speichert mir das in den Fhem-Dummy CCU.CMD.A
-> Auf Änderungen des States von A reagiert ein notify, dies führt dann "doCmd("A")" aus.

das sieht so aus:

sub
doCmd($){
   my ($i) =@_;
   my $cmd=Value("CCU.CMD.".$i);
   fhem ($cmd);
   fhem ("set CCU var Fhem.".$i."state 1");

}

Es guckt also in den Dummy Befehl A, nimmt den Inhalt, führt ihn aus und setzt in der CCU das Interfaces A wieder auf readyToReceive(1).


Das wäre vielleicht noch etwas für das Modul?


Ansonsten vielen Dank für den Nerv, zap! +1

Ich habe jetzt mal scharf nachgedacht was da lost ist, und mein Problem ist glaube ich folgendes:
CCU und Raspberry hängen am gleichen Netzteil, wenn ich nun das Netzteil rausziehe, der Raspberry hochfährt ist der deutlich vor der CCU fertig, die CCU kann dem Raspberry also nicht antworten und der get devicelist wartet vergeblich auf eine Antwort...

Vielleicht könnte man in das Modul noch einbauen, dass es den start so lange verzögert bis die CCU hochgefahren ist? Keine Ahnung was man da als Indikator nimmt, bzw. wie man dann ALLES umbauen müsste, damit die CCU-Geschichten erst "defined" werden wenn die CCU am start ist?

VG

Bei mir läuft der Spaß jetzt eigentlich ganz gut! Noch mal +1
Super, Super, Super, Danke!





PS: Ich habe einen 4-Fach Aktor, und einige 2-Fach Aktoren definiert, da funktioniert der Status per RCP nicht so schön, alle Devices des Aktors bekommen den gleichen State, das statechannel-Attribut habe ich gesetzt... ?! -> Anscheinend bekommen alle Kanäle des Aktors den State der letzten "Schaltung"

[zap]

Probleme scheint es beim HM-Input Modul mit vielen Kanälen zu geben. Diese werden offenbar nicht einzeln ausgewertet und aktualisieren immer gemeinsam- das muss ich allerdings noch genauer untersuchen.

Du meinst das HMCCU Modul? Die Auswertung der Events von der CCU läuft ja zeitgesteuert in dem mit rpcinterval festgelegten Intervall. Dabei werden immer bis zu 20(?) Events aus der Queue gleichzeitig ausgewertet. Diese Limitierung habe ich drin, um FHEM nicht auszubremsen. Das kann bei sehr vielen Kanälen aber dazu führen, dass Events erst beim 2. Intervall ausgewertet werden. Ich denke, ich kann den Wert etwas nach oben korrigieren. An der Gleichzeitigkeit vieler Events aufgrund der zeitgesteuerten Auswertung wird sich dadurch aber nicht viel ändern.

Meine konkrete Frage: spricht etwas prinzipiell dagegen, 2 RPC-Prozesse gleichzeitig laufen zu lassen (gegen Port 2000 und 2001 der ccu)? Im Moment ist das ja offenkundig programmtechnisch geblockt.

Prinzipiell spricht nichts gegen 2 Prozesse. Habe das nicht berücksichtigt, da ich keine wired Komponenten habe. Die CCU2 unterstützt seit kurzem aber auch Homematic IP (noch in Beta). Ich vermute mal, dass hierfür auch ein separater Port verwendet werden wird. Ich ziehe also die Unterstützung mehrerer RPC-Server in Erwägung, da ich plane, einige IP-Komponenten einzusetzten (z.B. die schicken Steckdosen) ... 

[zap]

Hallo zusammen, zunächst einmal meine Variante aus der CCU heraus Fhem-Befehle auszuführen, für alle die es interessiert:
-> Für "komplexere" Dinge wie z.B. Wetterberichte, die ich nicht unbedingt via http aufrufen will...

Eine alternative Möglichkeit zum Ausführen beliebiger FHEM Befehle aus der CCU heraus habe ich in HMCCU_Readme.txt in Abschnitt 6.2 beschrieben. Aber Deine Variante geht natürlich auch.

Vielleicht könnte man in das Modul noch einbauen, dass es den start so lange verzögert bis die CCU hochgefahren ist? Keine Ahnung was man da als Indikator nimmt, bzw. wie man dann ALLES umbauen müsste, damit die CCU-Geschichten erst "defined" werden wenn die CCU am start ist?

Eine Wartefunktion wäre keine große Sache. Allerdings wird das natürlich den Start von FHEM ausbremsen. Die Frage ist, wie lange man FHEM warten lässt. Das könnte man über einen weiteren Parameter im define von HMCCU bestimmen mit Default = 0, d.h. gar nicht warten. Ich denke mal drüber nach. Du könntest auch das fhem Startscript /etc/init.d/fhem anpassen und dort in einer Schleife per ping checken, ob die CCU da ist.

PS: Ich habe einen 4-Fach Aktor, und einige 2-Fach Aktoren definiert, da funktioniert der Status per RCP nicht so schön, alle Devices des Aktors bekommen den gleichen State, das statechannel-Attribut habe ich gesetzt... ?! -> Anscheinend bekommen alle Kanäle des Aktors den State der letzten "Schaltung"

Poste mal bitte die Definitionen. Sollte nicht so sein.

[lukasbastelpeter]

zunächst hier die defs:

define CCU HMCCU 192.168.XXX.XXX
attr CCU alias CCU-IO
attr CCU event-on-change-reading state
attr CCU group IOs
attr CCU loglevel 6
attr CCU room System
attr CCU rpcinterval 1
attr CCU rpcserver on

2-Fach Aktor
define F.DeckenLampe.Tuer HMCCUDEV XXXXX 1
attr F.DeckenLampe.Tuer userattr Licht Licht_map structexclude
attr F.DeckenLampe.Tuer IODev CCU
attr F.DeckenLampe.Tuer Licht F.Licht
attr F.DeckenLampe.Tuer alias Deckenlampe Tür
attr F.DeckenLampe.Tuer group Licht
attr F.DeckenLampe.Tuer room Flur
attr F.DeckenLampe.Tuer statechannel 1
attr F.DeckenLampe.Tuer statevals on:true,off:false
attr F.DeckenLampe.Tuer substitute true:on,false:off,1:on,0:off
define F.DeckenLampe.Innen HMCCUDEV XXXXX 2
attr F.DeckenLampe.Innen userattr Licht Licht_map structexclude
attr F.DeckenLampe.Innen IODev CCU
attr F.DeckenLampe.Innen Licht F.Licht
attr F.DeckenLampe.Innen alias Deckenlampe Innen
attr F.DeckenLampe.Innen group Licht
attr F.DeckenLampe.Innen room Flur
attr F.DeckenLampe.Innen statechannel 2
attr F.DeckenLampe.Innen statevals on:true,off:false
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off


4-Fach Aktor:
define SZ.BettLampe.Tuer HMCCUDEV XXX 4
attr SZ.BettLampe.Tuer userattr Licht Licht_map structexclude
attr SZ.BettLampe.Tuer IODev CCU
attr SZ.BettLampe.Tuer Licht SZ.Licht
attr SZ.BettLampe.Tuer alias Bettlampe Tür
attr SZ.BettLampe.Tuer group Licht
attr SZ.BettLampe.Tuer room Schlafzimmer
attr SZ.BettLampe.Tuer statechannel 4
attr SZ.BettLampe.Tuer statevals on:true,off:false
attr SZ.BettLampe.Tuer substitute true:on,false:off,1:on,0:off
define SZ.BettLampe.Fenster HMCCUDEV XXX 3
attr SZ.BettLampe.Fenster userattr Licht Licht_map structexclude
attr SZ.BettLampe.Fenster IODev CCU
attr SZ.BettLampe.Fenster Licht SZ.Licht
attr SZ.BettLampe.Fenster alias Bettlampe Fenster
attr SZ.BettLampe.Fenster group Licht
attr SZ.BettLampe.Fenster room Schlafzimmer
attr SZ.BettLampe.Fenster statechannel 3
attr SZ.BettLampe.Fenster statevals on:true,off:false
attr SZ.BettLampe.Fenster substitute true:on,false:off,1:on,0:off
define SZ.Standby.Tag HMCCUDEV XXX 1
attr SZ.Standby.Tag IODev CCU
attr SZ.Standby.Tag alias Standby: Ladegeräte Wecker
attr SZ.Standby.Tag group Energie Management
attr SZ.Standby.Tag room Schlafzimmer
attr SZ.Standby.Tag statechannel 1
attr SZ.Standby.Tag statevals on:true,off:false
attr SZ.Standby.Tag substitute true:on,false:off,1:on,0:off
define SZ.Standby.Nacht HMCCUDEV XXX 2
attr SZ.Standby.Nacht IODev CCU
attr SZ.Standby.Nacht alias Standby: Sonos
attr SZ.Standby.Nacht group Energie Management
attr SZ.Standby.Nacht room Schlafzimmer
attr SZ.Standby.Nacht statechannel 2
attr SZ.Standby.Nacht statevals on:true,off:false
attr SZ.Standby.Nacht substitute true:on,false:off,1:on,0:off

Der Timer wäre als Reading ganz nett, ich hatte zwischenzeitlich überlegt den FHEM start abhängig vom Ping der CCU zu machen, bis jetzt bin ich in der Phase, in der mich ein Stromausfall nicht interessiert, aber wenn das mal passiert und alles gleichzeitig wieder an geht, steht man da ...

[zap]

zunächst hier die defs:

2-Fach Aktor
define F.DeckenLampe.Tuer HMCCUDEV XXXXX 1
attr F.DeckenLampe.Tuer statechannel 1
attr F.DeckenLampe.Tuer statevals on:true,off:false
attr F.DeckenLampe.Tuer substitute true:on,false:off,1:on,0:off
define F.DeckenLampe.Innen HMCCUDEV XXXXX 2
attr F.DeckenLampe.Innen statechannel 2
attr F.DeckenLampe.Innen statevals on:true,off:false
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off

Alles klar, ich nehme an, die beiden XXXXX beim ersten und zweiten Device sind identisch, oder? In dem Fall hast Du zwar 2 Client Devices definiert, allerdings mit der gleichen CCU Geräteadresse, d.h. es handelt sich um das gleiche Gerät. Die Aktualisierung der Readings erfolgt bei Client Devices vom Typ HMCCUDEV über die Geräteadresse, nicht über die Kanaladresse. Daher überschreiben sich die STATEs gegenseitig.

Wie heißen denn die Datenpunkte bei den beiden Kanälen, die jeweils in STATE landen sollen? Ggf. geht was über das Attribut statedatapoint.

Ansonsten: Versuche es mal bitte mit HMCCUCHN. Die Defines sehen dann so aus:

Code Auswählen Erweitern


define F.DeckenLampe.Tuer HMCCUCHN Name/Adresse_Channel1
define F.DeckenLampe.Innen HMCCUCHN Name/Adresse_Channel2


Dann werden die Client-Devices bei der Aktualisierung getrennt betrachtet (hoffentlich, sonst ist es ein Bug).

BTW: Statt

Code Auswählen Erweitern


attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off


geht auch

Code Auswählen Erweitern


attr F.DeckenLampe.Innen substitute (true|1):on,(false|0):off


[ToM_ToM]

Hallo Zap,

sorry dass ich mich jetzt erst wieder melde.

Du könntest im Frontend Forum im Tablet-UI Thread mal die Frage stellen, ob Tablet-UI Probleme hat, wenn in Reading-Names Leerzeichen vorkommen bzw. wie man damit umgehen muss. Oder Du könntest bei Deinen CCU Geräten auf Leerzeichen verzichten. Oder Du benutzt das Attribut "ccureadingformat" und setzt es auf address. Dann haben die Readings grundsätzlich die Adresse der CCU-Geräte als Name. Das sollte dann funktionieren.

Ich hatte die Umstellung auf "address" vorgenommen und es hat super funktioniert. Was leider nicht funktioniert hatte, war das Schalten des Thermostates. Mein TabletUI hat zwar die Schaltung abesetzt (sieht man ja an der kurzen Toast message) aber direkt darauf kam als Toast message "Error: error". Das Thermostat hat die Daten trotzdem empfangen und die Wunschtemperatur geändert, aber FHEM ist danach komplett abgestürzt. Allerdings hatte ich keine Fehlermeldung im Log. Da ich selbst keine CCU2 habe, kann ich das erst in ein paar Monaten wieder weiter basteln und testen. Bis dahin hast du sicher wieder ein paar neue Versionen eingecheckt.
Finde das Modul aber bisher echt klasse. 
VG, Thomas

[hometux]

Hallo tux,

Meine Beobachtung bei HMWired (es handelt sich übrigens um das 12-fach Input-Modul HMW-Sen-SC-12-DR, bei dem die einzelnen Kanäle :1 bis :12 ausgelesen werden) und die von lukasbastelpeter laufen wohl in dieselbe Richtung.

Ich habe die einzelnen Kanäle aktuell als einzelne HMCCUDEV Devices definiert und beobachte eine gemeinsame Aktualisierung, sobald ein Eingang aktualisiert wird. Allerdings ist dann jeweils auch der gelesene Status für die betroffenen Geräte identisch. Das Verhalten tritt vermutlich nur bei Ereignissen auf, die über den RPC Prozess einlaufen. Aktualisiere ich die Werte manuell über getstate, sehe ich keinen Fehler.

Du hattest ja zu HMCCUCHN geschrieben:

"Dann werden die Client-Devices bei der Aktualisierung getrennt betrachtet (hoffentlich, sonst ist es ein Bug)."

Ich hatte das schon versucht, und die Ports als HMCCUCHN oder auch probehalber als HMCCUDEV readonly definiert, das hat bisher jedoch nicht funktioniert. Möglicherweise gibt es hier noch ein Problem mit dem statedatapoint SENSOR. Darauf deutet für mich der folgende Eintrag aus dem Logfile hin:

(bei Definition als HMCCUCHN)

2015.12.29 20:23:54 1: HMCCU: Error URL = http://xxx.168.178.5:8181/do.exe?r1=dom.GetObject("BidCos-Wired.LEQXXX4691:1.SENSOR").State()
2015.12.29 20:23:54 1: HMCCUCHN: Fenster_OG_Schlafzimmer Execution of CCU script failed

---
(bei Definition als HMCCUDEV readonly)

2015.12.29 20:27:52 1: HMCCU: Error URL = http://xxx.168.178.5:8181/do.exe?r1=dom.GetObject("BidCos-Wired.LEQXXX4691:1.SENSOR").State()
2015.12.29 20:27:52 1: HMCCUDEV: Fenster_OG_Schlafzimmer Execution of CCU script failed

Das abweichende Verhalten zwischen den Einstellungen HMCCUDEV und HMCCUCHN deutet für mich in Richtung Bug hin.

[mw77]

Hallo hometux,
ich verwende das selbe Homematic wired Modul.

(bei Definition als HMCCUCHN)
Zitat
2015.12.29 20:23:54 1: HMCCUCHN: Fenster_OG_Schlafzimmer Execution of CCU script failed

Den gleichen Fehler hatte ich auch, habe jetzt bei attr substitute 0:closed,1:open,false:closed,true:open, seit dem läuft es.

[zap]

Hallo hometux,
ich verwende das selbe Homematic wired Modul.Den gleichen Fehler hatte ich auch, habe jetzt bei attr substitute 0:closed,1:open,false:closed,true:open, seit dem läuft es.

Das kann nicht die Lösung des Fehlers sein. Die Ersetzung per substitute greift erst nach der erfolgreichen Ausführung des GET Befehls.

@hometux: Reden wir hier von einem GET oder SET? Bitte führe mal den Befehl "get deviceinfo" bei dem HMCCUDEV Device aus. Funktioniert der? Wie sieht die Ausgaben aus?

Gibt es eine Fehlermeldung in /var/log/messages der CCU?

Für die korrekte Aktualisierung eines Aktors mit mehreren Schaltkanälen müssen auf jeden Fall für jeden Schaltkanal HMCCUCHN Devices definiert werden, da diese vom RPC-Server über ihre Kanaladresse aktualisiert werden. HMCCUDEV Devices werden hingegeben über die Geräteadresse aktualisiert. Da diese für alle Schaltkanäle identisch ist, überschreiben sich die Statusänderungen gegenseitig.

[hometux]

Das Problem ist gelöst und funktioniert jetzt einwandfrei, vielen Dank an alle.

Wie zap schon geschrieben hat, muss bei Geräten die mehrere Kanäle verwenden, jeder Kanal als HMCCUCHN definiert werden. Verwendet man stattdessen (fälschlich) HMCCUDEV, so werden die Kanäle nicht separat ausgewertet. Bei den HM-Wired Geräten mit 12 Eingängen z.B. führt dies zu falschen Auslesewerten und unbefriedigenden Ergebnissen.

Mein zwischenzeitlicher Fehler war, dass ich Geräte einfach von HMCCUDEV auf HMCCUCHN umdefiniert habe. Das funktioniert aber nicht sofort (stattdessen tritt die oben beschriebene Fehlermeldung im Log auf), sondern erst nachdem die Geräteinfo der CCU neu gelesen wurde. Für das HMCCUCHN Device gibt es dazu allerdings keinen Befehl get deviceinfo. Man muss über HMCCU aktualisieren.

Ergänzend ist vielleicht der Hinweis interessant, dass es (natürlich) für HMCCUCHN kein statechannel attribut mehr gibt. Definiert man zusätzlich die Geräte als readonly gibt es auch kein attribut statevals.

Insgesamt jedenfalls eine tolle Sache. Das einzige was ich mir im Moment noch vorstellen könnte, ist eine bequemere Art, beim Start von fhem alle aktuellen Gerätestati auf einmal einzulesen.

[zap]

Das Problem ist gelöst und funktioniert jetzt einwandfrei, vielen Dank an alle.

Wie zap schon geschrieben hat, muss bei Geräten die mehrere Kanäle verwenden, jeder Kanal als HMCCUCHN definiert werden. Verwendet man stattdessen (fälschlich) HMCCUDEV, so werden die Kanäle nicht separat ausgewertet. Bei den HM-Wired Geräten mit 12 Eingängen z.B. führt dies zu falschen Auslesewerten und unbefriedigenden Ergebnissen.

Das führt nur dann zu Problemen, wenn mehrere Kanäle die gleichen Datenpunkte verwenden. Leider ist das bei praktisch allen Homematic Geräten mit mehreren Ein- oder Ausgängen so. Ein Schließerkontakt hat z.B. 3 Kanäle, wobei jeder einen STATE Datenpunkt hat. In dem Fall kann in HMCCUDEV eben nicht entschieden werden, welcher jetzt der ist, der in das FHEM Device STATE übernommen werden soll.

Mein zwischenzeitlicher Fehler war, dass ich Geräte einfach von HMCCUDEV auf HMCCUCHN umdefiniert habe. Das funktioniert aber nicht sofort (stattdessen tritt die oben beschriebene Fehlermeldung im Log auf), sondern erst nachdem die Geräteinfo der CCU neu gelesen wurde. Für das HMCCUCHN Device gibt es dazu allerdings keinen Befehl get deviceinfo. Man muss über HMCCU aktualisieren.

Das muss was anderes gewesen sein. Der Befehl get deviceinfo listet einfach nur alle Kanäle und Datenpunkte eines CCU Gerätes auf. Da passiert sonst nix, nur reine Bildschirmausgabe. Da HMCCUCHN sich nur auf einen Kanal bezieht, gibt es natürlich keine DeviceInfo.

Insgesamt jedenfalls eine tolle Sache. Das einzige was ich mir im Moment noch vorstellen könnte, ist eine bequemere Art, beim Start von fhem alle aktuellen Gerätestati auf einmal einzulesen.

Das geht derzeit nur per "get parfile" im HMCCU Modul. Zugegeben, das ist umständlich und man muss immer das Parfile aktuell halten. Muss ich mal drüber nachdenken. Das Problem ist, dass die Module beim Starten von FHEM nicht wissen, wann alles korrekt definiert und initialisiert ist (z.B. wann alle Attribute definiert sind).