Neues Modul HMCCU für Homematic CCU

[Yil]

Die Logfile Einträge weisen nicht auf einen Fehler hin. Sieht aus als würde der RPC-Server normal gestoppt werden. Wenn Du das cfg File editierst, wirst Du vermutlich FHEM neu starten oder? Beim Shutdown von FHEM wird der RPC-Server natürlich auch gestoppt. Wenn dann beim Starten nicht das Attribut rpcserver = on ist, wird er auch nicht automatisch gestartet.

Folgendes konnte ich nachstellen:

• Sobald ich die fhem.cfg öffne und anschließend speichere, wird der RPCServer beendet. Typischerweise starte ich dann FHEM nicht neu, so dass es auch zu keinem Shutdown kommt. Das Atrtribut rpcserver on ist gesetzt.
• Folgende Werte ergeben sich: Interner Wert RPCPID: <nicht mehr vorhanden>; interner Wert RPCPRC: <nicht mehr vorhanden>; interner Wert RPCState = stopped; internern Wert STATE = Initialized; reading rpcstate = running (und nicht: stopped); reading state = Initialized (der RPCServer verliert also die internen Werte RPCPID und RPCPRC)
• Der Befehl set HMCCU2 rpcserver on führt in den normalen Zustand zurück

Wenn ich hingegen den RPCServer manuell stoppe, dann lauten die internen Werte anders:

Interner Wert RPCPID: 0; interner Wert RPCPRC: none; interner Wert RPCState = stopped; internern Wert STATE = busy; reading rpcstate = running; reading state = busy

Ich hab mal 2 Screenshots angehängt. Dieses Verhalten ist beliebig oft reproduzierbar. Hilft das weiter bei der Fehlersuche?

[zap]

Hört sich fast so an als würde das  Modul neu geladen werden wenn die cfg gespeichert wird. Muss ich bei mir mal ausprobieren. Vielleicht weiss ja jemand, ob das ein Feature von FHEM ist.

[aski71]

Hi,

ich habe da mal ein Problem, wo ich nicht weiß, ob ich mich einfach nur zu dämlich anstelle:

Ich benutze einen Homematic Dimmer und zwei Aufputz-Rolladenaktoren.
Die Readings, die da kommen (z.B. 1.LEVEL) sind immer Real-Zahlen: also von 0.000000 bis 1.000000.

Nun ist es so, dass Steuerelemente, wie knob gerne mit den Prozenten arbeiten würden: also 0 - 100.
Das kann man wiederum ganz gut parametrieren, indem man min, max und step-Werte angibt.
Allerdings führt das immer wieder zu Klimmzügen.

Bei der Siri-Anbindung über Homebridge bin ich nun leider vollends gescheitert, weil die intern CurrentPosition und TargetPosition als Integers fahren. Also nur 0-100 möglich ist. Oder auch 0 und 1. Also Markise auf oder zu. Was auch nicht im Sinne des Erfinders ist. 

Ich habe nirgends gesehen, dass das Problem sonst einer hätte.
Mach ich ggf. irgendwas falsch, dass bei mir 0.00 bis 1.00 verwendet wird, statt 0-100 Prozent?

Schlau wäre tatsächlich, wenn man Dimmer und Rolladenaktoren mit Prozentwerten ansteuern könnte und die Readings (1.LEVEL) auch Prozentwerte (also 0-100) zurück liefern würden.

Hoffe auf Hilfe.

VG Alex

[zap]

Ich verstehe Dein Problem, habe allerdings derzeit keine Lösung dafür. HMCCU reicht momentan numerische Werte der Datenpunkte 1:1 an die Readings weiter (ok, bei Bedarf kann man die Nachkommastellen abschneiden lassen).

Da müsste ich was implementieren, so eine Art "scale" Attribut, das in beide Richtungen (Get/Set) arbeitet. Ich schreibe es auf die Liste.

Wenn es nur um die Darstellung in den Readings ginge, könntest Du einfach ein Userreading definieren, das den Wert eines Datenpunktes mit 100 multipliziert. Das hilft aber nicht beim Setzen der Werte.

Ich könnte mir in der nächsten Version folgendes vorstellen:

attr <dev> scale 1.LEVEL:100,1.TEMPERATURE:10

[Ralli]

Das geht über eventMap. Sowohl hin als auch zurück.

[aski71]

Das geht über eventMap. Sowohl hin als auch zurück.

Und wie?

[Ralli]

https://forum.fhem.de/index.php/topic,43023.msg350289.html#msg350289

[zap]

Hi Ralli,

ich hatte auch daran gedacht, wollte es aber nicht vorschlagen, weil es schon irgendwie hässlich ist

Aber ok, als Workaround funktioniert es bis ich eine etwas elegantere Lösung in HMCCU eingebaut habe.

[Yil]

Das ist jetzt bestimmt eine dumme Frage, aber hat jemand mal ein komplettes define-Statement für einen Dimmer mit dem Modul HMCCU? Meiner will nicht ...

VG Yil

[zap]

Ich glaube ein Dimmer wurde irgendwo in diesem Thread schon mal behandelt. Langsam wird der Beitrag hier auch etwas unübersichtlich.

Jedenfalls hier erst mal die Erklärung für das Stoppen des RPC Servers beim Editieren der fhem.cfg

https://forum.fhem.de/index.php/topic,54890.0.html

Was will denn nicht beim Dimmer? Poste doch mal ein list Devname , wenn zumindest der Define klappt. Auch ein " get devname deviceinfo " ist manchmal aufschlussreich

[Yil]

Hi zap,

danke für's Recherchieren - jetzt ist's mir klar, warum das so dermaßen deutlich zu reproduzieren war. Ich weiß, dass es viele unverständige Blicke gibt, wenn man preisgibt, dass man die fhem.cfg von Hand editiert. Schlechte Angewohnheit, die jedoch viel Flexibilität beinhaltet. Ich versuche "umzulernen"

Dimmer mache ich in einem separaten Post. Ggf. könnte man aber Geräte, die als HMCCUDEV definiert werden, auch hier behandeln: https://forum.fhem.de/index.php/topic,51339.0.html - was meinst Du?

Meiner Meinung nach ist das HMCCU-Modul eines der ganz wichtigen Module der Zukunft in Sachen Homematic, wenn der klassische und weit verbreitete HMLAN ausstirbt (was zwangsläufig der Fall sein wird, nachdem die Produktion eingestellt und das Gerät "end-of-life" ist (alles sehr aktuell lt. Hersteller EQ3). Hier lohnt es sich früh, Knowhow aufzubauen und breit zu streuen. An der Stelle ein Danke, dass Du Dich darum kümmerst!

VG Yil

[aski71]

Was daran verwerflich sein soll, die fhem.cfg von Hand zu editieren (wenn man weiß, was man tut und auch ein Backup hat), weiß ich nicht.
Ich mache das auch oft. Vor allem, wenn ich ein neues Gerät in Betrieb nehme und dafür ein vorhandenes einfach klonen kann. 

Dimmer: Ich poste mal mein Beispiel in den von Yil angegebenen anderen Thread.

Skalierung der Prozentwerte: Da gibt es jetzt eine Lösung für die homebridge, das die 0..1 Werte auf 0..100 aufbläst und umgekehrt wieder die Luft rauslässt. (Ich poste das in dem Dimmerbeispiel gleich mit.)
Wäre dennoch schön, wenn man das auch in HMCCUDEV/HMCCUCHN machen könnte. 

[Yil]

Hi aski71, danke für Deine moralische Unterstützung. Ich habe von einigen sehr erfahrenen fhem-Anwendern fast schon böse und abfällige Kommentare geerntet, als ich mich als fhem-Editor geoutet habe. Ich bin so "aufgewachsen", einen ordentlich lesbaren und strukturierten Code zu haben und es seit vielen Jahren gewohnt, direkt im Code zu arbeiten.

Vorteil, wenn man das NICHT tut, ist wohl, dass die Änderungen sofort greifen, denn beim Speichern der fhem.cfg wird ein rereadcfg ausgelöst, dass temporäre Verbindungen kappt (hat zap für mich recherchiert). Im Ergebnis verliere ich z.B. immer die Verbindung zur HMCCU und muss diese neu starten (RPCServer). Ein anderer Vorteil ist, dass auch Änderung in aus der fhem.cfg ausgelagerten Dateien, die dann über include eingebunden werden, sofort greifen. Ändert man diese include-Datein manuell, muss fhem komplett neu gestartet werden.

Dimmer-Beispiel: sehr cool, vielen Dank.

Ich könnte außerdem noch Hilfe bei der Definition der 3 Rauchmelder und des TeamLeaders gebrauchen, denn diese Geräte hängen bei mir noch am (mittlerweile außer Betrieb genommenen, da defekten) HMLAN-Adapter und müssen ebenfalls auf die neue HMCCU umgebaut werden. Aber dazu melde ich mich im anderen Post separat.

VG Yil

[aski71]

Ja, das ist mir auch schon aufgefallen mit dem PRCServer. Aber wenn man das weiß ist es ja kein Beinbruch. Muss man halt einen "set ccu2 rpcserver on" nach dem Speichern und neu laden hinterher schicken und alles ist gut.

Prima, wenn das Dimmer-Beispiel hilft. Bei Rauchmeldern und TeamLeader (was ist letzteres überhaupt  ) kann ich leider nicht weiter helfen. Hab noch keine Rauchmelder...  In Bayern erst Nachrüstepflicht bis Anfang 2018. 

VG Alex

[Yil]

Tja, in Sachen Rauchmeldern hat BW da die Nase vorn