Neues Modul HMCCU für Homematic CCU

[zap]

Wenn ich ein devicelist mache werden alle devices gelesen, leider kann ich sie nicht sehen. Sie stehen in helper, also unsichtbar. Warum werden sie nicht ausgegeben wenn ich ein get absetze?

"get devicelist dump" gibt eine Liste der Geräte und Kanäle aus. Leider nicht sehr sprechend. Habe die Ausgabe gerade für die nächste Version etwas aufgehübscht.

Leerzeichen halte ich für kritisch. Nun, ccu nutzt es. Ich würde diese strikt durch ein _ ersetzen. Aus die Maus. Das wird immer zu Problemen führen.

Das passiert bei "get devicelist create" jetzt schon. Bringt nur leider nix, weil ich da einen grundsätzlichen Fehler drin habe (verwendet Name statt Adresse beim Define).

Der Kanal 0 existiert im device. Das ist schon korrekt, nur kann man diesen gut handeln, muss man den User nicht mit belasten. CUL_HM geht damit entsprechend um.

Was meinst Du damit? Wäre es besser, die Datenpunkte von Kanal 0 anders darzustellen?

Aber, kein falscher Eindruck: gute Arbeit!! Ich werde weiter meine Ideen vorbringen, was immer du damit machst.

Jede Anregung ist willkommen!

[wuast94]

Wie kann ich ein Wochenprogramm erstellen für thermostate ?

Ich würde am liebsten drei verschiedene Programme haben. Eins für dei früh eins für die Spät und eins für freie wochen.

für jedes programm sollte eine woche abgedeckt sein für die verschiedenen wochentage von wann bis wann welche temperatur sein soll.
am besten so das es am ende der woche automatisch das programm wechselt (früh und spätschicht im wechsel) bzw manuell deaktivieren das dritte programm laufen lassen wenn ich ne woche frei habe. habe nach langem suchen nichts gefundne wie ich daas umsetzten kann.

bin für jede antwort dankbar

[chris1284]

ich fürchte ccu script. einmalig kann man sie in der ccu setzen, um sie dynamisch zu wechseln  kenn ich aktuell nichts. würde mich aber auch interessieren

[zap]

Wie kann ich ein Wochenprogramm erstellen für thermostate ?

Ich würde am liebsten drei verschiedene Programme haben. Eins für dei früh eins für die Spät und eins für freie wochen.

für jedes programm sollte eine woche abgedeckt sein für die verschiedenen wochentage von wann bis wann welche temperatur sein soll.
am besten so das es am ende der woche automatisch das programm wechselt (früh und spätschicht im wechsel) bzw manuell deaktivieren das dritte programm laufen lassen wenn ich ne woche frei habe. habe nach langem suchen nichts gefundne wie ich daas umsetzten kann.

Grundsätzlich gibt es 2 Ebenen der CCU Gerätesteuerung: Über Datenpunkte (set/get datapoint) und über Konfig-Parameter (set/get config). Mit letzterer Methode erreicht man die Parameter, die man in der CCU unter "Einstellungen/Geräte" und dann Button "Einstellungen" findet.

Da die Definition von Zeitprogrammen über HMCCU sehr aufwändig und umständlich ist, würde ich Dir raten, das in der CCU zu definieren. Mit dem "set config" Befehl kannst Du in FHEM dann zwischen den Programmen wechseln.

Für ein Wandthermostat sieht der Befehl so aus:

Code Auswählen Erweitern


set mytherm config WEEK_PROGRAM_POINTER=Programm


Wobei "Programm" 0,1,2 sein kann (für das zu aktivierende Programm).

Das Problem: Bei dem Heizkörperthermostat scheint es nur ein Wochenprogramm zu geben (oder kannst Du bei Dir in der CCU unter Einstellungen - Geräte und dann über den Button "Einstellen" hinter dem Thermostaten zwischen 3 Programmen wählen?).
Bei mir wird jedenfalls nur ein Programm angezeigt. Ich habe jedoch die Heizkörperthermostate mit Wandthermostaten verknüpft. Dann erfolgt die Steuerung über das Wandthermostat.

[Yil]

Apropos Performance - ich hab da mal ne Frage:

ich habe mir heute einen HM Funk-Taster (HM-PB-2-WM55 namens EG.LichtSchalter) kommen lassen und steuere über den einen dummy (EZ.Licht). Die Schaltzeit zum dummy beträgt dabei gut 3 Sekunden.

Code Auswählen Erweitern

define LichttasterEGEin notify EG.LichtSchalter.1.PRESS_SHORT:.*|EG.LichtSchalter.1.PRESS_LONG:.* set EZ.Licht on

Woran liegt die Verzögerung? Gibt es Möglichkeiten, das zu beschleunigen?

[zap]

ch habe mir heute einen HM Funk-Taster (HM-PB-2-WM55 namens EG.LichtSchalter) kommen lassen und steuere über den einen dummy (EZ.Licht). Die Schaltzeit zum dummy beträgt dabei gut 3 Sekunden.

Code Auswählen Erweitern

define LichttasterEGEin notify EG.LichtSchalter.1.PRESS_SHORT:.*|EG.LichtSchalter.1.PRESS_LONG:.* set EZ.Licht on

Woran liegt die Verzögerung? Gibt es Möglichkeiten, das zu beschleunigen?

Die Kommunikation läuft so:

1. Du drückst die Taste
2. CCU schickt dem RPC-Server von HMCCU ein Event, dass die Taste gedrückt wurde.
3. RPC-Server schreibt das Event in die File-Queue
4. HMCCU liest die Filequeue alle x Sekunden und verteilt die Events an die zuständigen FHEM Devices.

Bedeutet: Die Verzögerung zwischen Tastendruck und Notification ist maximal x Sekunden. Der Wert x wird über das HMCCU Attribut rpcinterval eingestellt. Default ist 5 Sekunden. Auf meinem Raspi habe ich das auf 3 Sekunden gesetzt, wobei 2 auch noch performant läuft. Musst Du ausprobieren.

Ich hatte auch mal eine direkte Notification ohne Queues getestet. Scheitert daran, dass FHEM die Daten nicht schnell genug verarbeiten kann. Dann gehen Events verloren.

[Yil]

Ok, verstanden. rpcinterval 3 hab ich ausprobiert - subjektiv habe ich den Eindruck, dass nicht immer alle Schaltbefehle ausgeführt werden, insbesondere wenn man den Schalter zu oft betätigt (wobei ich immer eine Pause von 5 sec. hatte wg. des Herunterdimmens der Leuchten).

rpcinterval 2 gibt es nicht, wird im Auswahlmenü nicht angeboten. 

[zap]

Ok, verstanden. rpcinterval 3 hab ich ausprobiert - subjektiv habe ich den Eindruck, dass nicht immer alle Schaltbefehle ausgeführt werden, insbesondere wenn man den Schalter zu oft betätigt (wobei ich immer eine Pause von 5 sec. hatte wg. des Herunterdimmens der Leuchten).

rpcinterval 2 gibt es nicht, wird im Auswahlmenü nicht angeboten.

Kannst Du einfach per Kommandozeile einstellen:

attr xy rpcinterval 2

Events sollten eigentlich nicht verloren gehen. Bei Tastern würde ich auf jeden Fall event-on-update-reading auf .* setzen und auf event-on-change-reading verzichten.

[Yil]

Ok, vielen Dank - hab ich mal so eingestellt und werde es morgen testen

[zap]

Die Version 3.6 ist nun per FHEM Update verfügbar. Folgende Änderungen gibt es:

• Modul HMCCU: Der Befehl get devicelist create für das automatische Erstellen von CCU Devices in FHEM wurde um den Parameter "t={dev|chn}" erweitert. Die Angabe t=dev (Default) legt nur Devices für Homematic Geräte an (mit HMCCUDEV), während t=chn nur Devices für Homematic Kanäle anlegt. Außerdem wurde ein Bug behoben, der das Anlegen von Devices verhindert hat, die in der CCU ein Leerzeichen im Namen haben.
• Modul HMCCU: Das neue Attribut rpcserveraddr ermöglicht die Angabe einer IP-Adresse oder eines DNS-Namens, an den die CCU Events schicken soll. Dadurch ist es möglich, eine CCU über eine Internetverbindung mit FHEM zu verbinden. In diesem Fall würde man bei rpcserveraddr die öffentliche IP bzw. den DynDNS-Eintrag des Routers angeben, über das FHEM aus dem Internet erreichbar ist. Zusätzlich muss auf dem Router ein Portforwarding eingerichtet werden (s.u. Attribut rpcserverport).
• Modul HMCCU: Das neue Attribut rpcserverport ermöglicht die Änderung der Ports, auf die die CCU Events an den RPC-Server schickt. Der hier angegebene Port ist lediglich ein Basisport, aus dem die tatsächlich genutzten Ports berechnet werden. Dazu wird folgende Formel verwendet: Port = rpcserverport + rpcport + (ccunumber * 10). Dabei entspricht rpcport dem Inhalt des Attributs rpcport, also 2000, 2001, 2010 oder 9292. Der Wert ccunumber ist bei einer CCU immer 0 (Vorbereitung für die nächste Version, die mehrere CCUs unterstützen wird). Beispiel: Bei einer Installation mit BidCos-RF und HM-IP (rpcport=2001,2010) und mit rpcserverport=5400 ergeben sich somit folgende tatsächlich genutzten Ports: 5400+2001+(0*10)=7401, 5400+2010+(0*10)=7410. Bei einer Verbindung CCU - FHEM über das Internet müsste entsprechend für diese beiden Ports auf dem Router ein Portforwarding eingerichtet werden.
• Modul HMCCU: Einführung einer CCU-Nummer als Vorbereitung für die Unterstützung mehrerer CCUs in der nächsten Version. Dateinamen der Queue-Files des RPC-Servers enhalten nun auch die CCU-Nummer. Die erste CCU hat die Nummer 0.
• Modul HMCCU: Einführung von Aggregationsregeln, Attribut ccuaggregate und Befehl get aggregation. Mit diesen Regeln können Fragen beantwortet werden wie z.B. "Sind gerade Fenster geöffnet und wenn ja, welche?", "Wieviele und welche Devices haben ein Batterieproblem?". Weitere Erläuterungen siehe Online-Hilfe oder im FHEM Wiki

[mrfloppy]

Habe gerade ein Update gemacht.
Meine CCUNum wurde auf 1 gesetzt. Habe auch nur eine CCU. 
Im Beitrag oberhalb steht aber bei einer CCU CCUnum 0.

Was mir jedoch aufgefallen ist.
Bei einem "Shutdown restart", ist die CCU bisher immer recht flott selbstständig auf OK gegangen. Sprich der RPC wurde automatisch gestartet.
Jetzt nach dem Update bleibt "RPCState-stopped" und "STATE auf Initialized".
Auch wenn ich mehrere Minuten warte.
Muss händisch den RPC wieder starten dann geht wieder alles.

[zap]

Vielen Dank für den Hinweis! Habe das korrigiert und 88_HMCCU.pm neu eingecheckt.

[tagedieb]

Hallo zusammen

ich bekomme nach dem heutigen Update die CCU2 nicht "zum Laufen" nach dem Versuch den RPC Server zu starten, kam die Meldung

Code Auswählen Erweitern

HMCCU: CCU2 Start of RPC server failed ,
auch sind die Clients "weg" (Update gegen 17 Uhr)
die log "sagte" auch nur RPC server nicht gestartet
Nach der Rücksetzung auf die gestrige version funktioniert alles wieder ?

FHEM ist auf dem neuesten Stand
Cubieboard wird auch 1 mal in der Woche geupdatet

was habe ich beim update übersehen?

Gruss tagedieb

[cho]

Hi zap,
ich habe gerade auf Version 3.6 aktualisiert, da ich die Aggregationsregeln gut gebrauchen kann.
Vier Sachen sind mir aufgefallen:

Zum einen funktioniert der automatische Start nach dem Fhem reboot bei mir auch nicht. Aber dafür hast Du ja schon ein weiteres Update für morgen eingestellt.

Dann komme ich mit dem Namen und dem Prefix nicht klar. Bei mir verwendet er immer nur den Namen als Prefix, aber nicht den Wert, den ich als Prefix definiere?

Die Aktualisierung der neuen Attribute funktioniert bei mir nicht automatisch. Aktualisiert wird nur, wenn ich manuell get ... aggregation ... auslöse.

Und als letztes eine praktisch Frage zu den Fensterkontakten. Ich habe sowohl die optischen (offen, geschlossen) als auch die mechanischen an den Griffen (offen, gekippt, geschlossen) im Einsatz. Wenn ich es richtig verstanden habe, kann das if aber nur einen Wert abfragen, z.B. offen. Ich würde aber auch gerne im if offen und gekippt gleichzeitig abfragen. Geht das irgendwie?

Viele Grüße
Christian

[zap]

Hallo zusammen

ich bekomme nach dem heutigen Update die CCU2 nicht "zum Laufen" nach dem Versuch den RPC Server zu starten, kam die Meldung

Code Auswählen Erweitern

HMCCU: CCU2 Start of RPC server failed ,
auch sind die Clients "weg" (Update gegen 17 Uhr)
die log "sagte" auch nur RPC server nicht gestartet
Nach der Rücksetzung auf die gestrige version funktioniert alles wieder ?

Mm, dazu 3 Fragen:
1. gibt es noch weitere Meldungen im Log?
2. Steht im Internal CCUNum eine 0 oder 1?
3. Hast Du das Attribut rpcport gesetzt?