Neues Modul HMCCU für Homematic CCU

[chris1284]

Vielen Dank für die zusammen- und umfassende Rückmeldung. Hat mir sehr geholfen!

[zap]

BTW noch 3 Hinweise für den Einstieg:

• Der Befehl get devceinfo (verfügbar in HMCCUDEV und HMCCU) liefert eine Übersicht aller Datenpunkte inkl. Datentyp und Flags für Lesen/Schreiben. Erspart in und wieder den Blick in die EQ3 Doku
• Bei einigen Geräten ist es sinnvoll, das Attribut ccureadingfilter zu setzen um unnötige Readings zu vermeiden (z.B. bei Thermostaten
• Ich empfehle, grundsätzlich event-on-change-reading auf .* zu setzen

[chris1284]

wenn ich beim HMCCUCHN device statedatapoint TEMPERATURE setzte und ccureadingformat auf datapoint setze wwird zwar das reading auf TEMPERATURE  umgestellt aber der STATE ändersich nicht mehr.
ohne ccureadingformat ändert er sich mit der TEMPERATURE änderung. Bug oder eigenheit des CHN devices?

... da nun alles selbt aktualisiert werde ich auch mal ein thermostat auf die ccu2 umziehen 

[zap]

Könnte ein Bug sein. Schau ich mir an.

[chris1284]

ein get deviceinfo auf einen HM-LC-Sw4-Ba-PCB zeigt

CHN MEQ0165768:0 az_sw4:0
  DPT {b} BidCos-RF.MEQ0165768:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.MEQ0165768:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.MEQ0165768:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.MEQ0165768:0.LOWBAT = false [RE]
  DPT {b} BidCos-RF.MEQ0165768:0.DUTYCYCLE = false [RE]
  DPT {8} BidCos-RF.MEQ0165768:0.RSSI_DEVICE = 1 [RE]
  DPT {8} BidCos-RF.MEQ0165768:0.RSSI_PEER = 32 [RE]
  DPT {b} BidCos-RF.MEQ0165768:0.DEVICE_IN_BOOTLOADER = false [RE]
  DPT {b} BidCos-RF.MEQ0165768:0.UPDATE_PENDING = false [RE]
  DPT {8} BidCos-RF.MEQ0165768:0.AES_KEY = 0 [R]
CHN MEQ0165768:1 az_sw4:1
  DPT {b} BidCos-RF.MEQ0165768:1.STATE = true [RWE]
  DPT {f} BidCos-RF.MEQ0165768:1.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0165768:1.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0165768:1.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0165768:1.WORKING = false [RE]
CHN MEQ0165768:2 az_sw4:2
  DPT {b} BidCos-RF.MEQ0165768:2.STATE = true [RWE]
  DPT {f} BidCos-RF.MEQ0165768:2.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0165768:2.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0165768:2.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0165768:2.WORKING = false [RE]
CHN MEQ0165768:3 az_sw4:3
  DPT {b} BidCos-RF.MEQ0165768:3.STATE = false [RWE]
  DPT {f} BidCos-RF.MEQ0165768:3.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0165768:3.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0165768:3.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0165768:3.WORKING = false [RE]
CHN MEQ0165768:4 az_sw4:4
  DPT {b} BidCos-RF.MEQ0165768:4.STATE = false [RWE]
  DPT {f} BidCos-RF.MEQ0165768:4.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0165768:4.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0165768:4.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0165768:4.WORKING = false [RE]

ON_TIME writeable ? in jedem channel. in der set-list habe ich im channel-device aber nur on/off/toogle. kann ich das beinflussen? mit dem cul_hm modulen geht on for timer


noch etwas: bei den ganzen switchen ist der state zwischen zustand a (zb off) und zustand b (zb on) immer kurz OK , kann man das unterdrücken?

[zap]

Wenn in HMCCUCHN das Attribut ccureadingformat auf "datapoint" gesetzt wird, funktioniert die Aktualisierung von STATE nicht. Das ist ein Bug in der aktuellen Version, mittlerweile in 3.4 gefixt (kommt heute oder morgen).

Der Set-Befehl "toggle" schaltet zwischen den im Attribut statevals festgelegten Werten um. Das können auch mehr als 2 sein.

ON_TIME muss beschreibbar sein, da darüber die "Ein-Zeit" in Sekunden festgelegt wird. Das Einschalten besteht dann im Prinzip aus 2 aufeinanderfolgenden Set-Befehlen (hier soll ein Switch für 60 Sekunden eingeschaltet werden):

Code Auswählen Erweitern


set hmccudev_dev datapoint n.ONTIME 60
set hmccudev_dev datapoint n.STATE true


HMCCUDEV untersucht, ob ein CCU-Device einen Datenpunkt ON_TIME enthält. Falls ja, wird der Befehl on-for-timer angezeigt.

Derzeit unterstützt nur HMCCUDEV on-for-timer, nicht HMCCUCHN. Das liegt daran, dass ich eigentlich nur HMCCUDEV verwende, da ich grundsätzlich am Kanal 0 wegen LOWBAT, UNREACH usw. interessiert bin.

In Version 3.4 wird neben der ON_TIME auch die RAMP_TIME unterstützt.

[chris1284]

beim HM-PB-6-WM55 gibt es das problem das in den channels keine tastedruck events erscheinen (press_short / press_long)
EDIT: gelöscht , antwort kam ja schon

[Ralli]

Das ist kein "Problem" aka Fehler im Modul. Das liegt daran, dass die RPC-Schnittstelle darüber keinen Event produziert, wenn ein Taster(-Kanal) nicht mit einem (virtuellen) Gerät gepeered ist.

Also: Peere jeden der Kanäle, den Du vom Taster in fhem über CCU auswerten willst, mit einem virtuellen Kanal der CCU und schon kommt auch ein PRESS_SHORT usw. aus der RPC-Schnittstelle. Ist bekannt und wurde hier bereits thematisiert!

[chris1284]

danke für den hinweis. aber das ist wohl falsch!

wähle ich beim Verknüpfen erst den virtuellen Kanal, erscheint der Wandtaster nicht als möglicher Partner.
wähle ich beim Verknüpfen erst den Wandtaster, erschein dann kein virtueller Kanal als möglicher Partner.

das scheint mir auch ganz logisch weil es keinen sinn ergibt 2 sender zu peeren

Die Lösung ist ein Programm, danach kommt auch der 2016-07-31 09:37:31 HMCCUCHN whg_pb6_05 whg_pb6.5.PRESS_SHORT: 1 im eventmonitor!
anebi mal so ein Programm

name                                       Bedingung                                                                Aktivität
whg_pb6:5 pressshort       Kanalzustand: whg_pb6:5 bei Tastendruck kurz    Kanalauswahl: whg_rcv:1 sofort Tastendruck kurz

[zap]

Das ist kein "Problem" aka Fehler im Modul. Das liegt daran, dass die RPC-Schnittstelle darüber keinen Event produziert, wenn ein Taster(-Kanal) nicht mit einem (virtuellen) Gerät gepeered ist.

Hmm, bei dem neuen ePaper Display (das mir gerade den letzten Nerv raubt und der Grund ist, weshalb ich die 3.4 noch nicht eingecheckt habe) werden aber Tasten-Events geschickt, auch wenn es nicht gepeered ist.

@chris1284: die 3.4 unterstützt nun virtuelle CCU Kanäle. Grund für die Probleme in früheren Versionen ist, dass diese Kanäle ein anderes Adressierungsschema verwenden und HMCCU beim Check auf valide Adressen (mit Absicht) sehr penibel ist.

[chris1284]

siehe mein post über dir,  so ist aktuell meine lösung. das peeren eine virt. ccu button und einen sender geht bei mir zu mindest nicht!

[zap]

Jetzt haben sich die Antworten überschnitten ....

[chris1284]

Hat jemand erfahrung mit dem rauchmelder? wenn man ihn per cul_hm an fhempaired kann man ihn zu einem alarm bewegen. mit der hmccu habe ich da noch keinen weg gefunden.
das drückern des testbutton für 2 sek bringt auch kein event, auch nicht wenn ich ihn wiedermit einem programm verbinde.
das team dafür nutzen bringt leider auch nichts, der status wird leider nicht von ok auf gefahr gesetzt

[Ralli]

Das Peeren geht nicht unmittelbar - da habe ich mich falsch ausgedrückt.

Du musst in der CCU ein Programm erstellen, welches auf den Taster-Kanal reagiert, im Endeffekt aber nichts tut. Das führt dazu, dass die CCU intern ein Peering mit einem virtuellen Device durchführt und sodann werden die Events auch ausgegeben.

Edit: Wer alles liest, ist klar im Vorteil, ich sehe, Du bist mittlerweile auch selbst drauf gekommen .

[zap]

Ich habe gerade Version 3.3 im Contrib-Pfad eingecheckt (Link siehe 1. Beitrag). Geändert haben sich die Dateien 88_HMCCU.pm, 88_HMCCUCHN.pm und 88_HMCCUDEV.pm.
Da mit dem letzten CCU Firmware Update der Kanal 0 auch für HM-IP Geräte eingeführt wurde, sollte einmal ein get iodev devicelist ausgeführt werden, sofern HM-IP Geräte genutzt werden.
HMCCU startet ab sofort per Default den eingebauten RPC-Server und verwendet ccurpcd.pl nicht mehr (als Vorbereitung auf Version 3.4). Wer trotzdem weiterhin ccurpcd.pl nutzen möchte, muss die Datei in das FHEM Verzeichnis kopieren, die Execute Flags setzen und das Attribut ccuflags im IO-Device auf "extrpc" setzen.

Gefixte Bugs:

- Der State eines HMCCUCHN Devices wurde nicht aktualisiert.

Neue Funktionen:

1) Unterstützung für virtuelle Taster der CCU (50 Kanäle)

2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden. Beispiel: Skalierung des Levels eines Dimmers auf 0-100 (in der CCU 0-1):

attr devname ccuscaleval LEVEL:0.01

Durch diese Angabe wird beim Lesen und bei Events der Wert durch 0.01 geteilt, bevor das Reading geschrieben wird. Beim Schreiben per Set-Befehl wird der angegebene Wert mit 0.01 multipliziert.

3) Unterstützung von RAMP_TIME bei Set-Befehlen (on-for-timer, nur bei HMCCUDEV Devices), sofern das Gerät das unterstützt.

4) Unterstützung des neuen ePaper Displays. Wenn das Display als HMCCUDEV Device definiert ist, kann des wie folgt angesprochen werden:

Setzen der Zeilen 1+2: set devname config 2 TEXTLINE_1=Text TEXTLINE_2=Text
Setzen der Zeilen 4+5: set devname config 1 TEXTLINE_1=Text TEXTLINE_2=Text

Es kann dabei auch jeweils nur eine der Zeilen angesprochen werden.

Setzen der Zeilen 2-4 sowie Ausgabe von Tönen und Blinken der LED:

set devname datapoint 3.SUBMIT CommandString

Der CommandString besteht aus 1-n Zuweisungen der Form Parameter=Wert, die durch Komma getrennt werden. Folgende Parameter sind zulässig:

text1-3=Text|#1-9  Mit Raute werden 9 vordefinierte Texte angesprochen.
icon1-3=ico_off|ico_on|ico_open|ico_closed|ico_error|ico_ok|ico_info|ico_newmsg|ico_svcmsg
sound=snd_off|snd_longlong|snd_longshort|snd_long2short|snd_short|snd_shortshort|snd_long
signal=sig_off|sig_red|sig_green|sig_orange
repeat=0-15 0=unendlich
pause=1-160 Sekunden

Beispiel: set devname datapoint 3.SUBMIT text1=Zeile1,text2=Zeile2,sound=snd_short

Folgende Funktionen kommen erst mit der Version 3.4, die dann per FHEM Update verteilt wird:

- Verkürzte Readingnames
- CCU Heartbeat Mechanismus
- Erweiterung HMCCUCHN um on-for-timer