Neues Modul HMCCU für Homematic CCU

[ph4]

Hallo zusammen,

habe plötzlich ein sehr seltsames Problem mit dem Modul. Seit heute werden mir keinerlei devices mehr angezeigt und im log sehe ich auch eine Meldung, dass diese alle nicht definiert werden konnten. Kenne das wenn die CCU offline ist aber aktuell ist sie erreichbar. Wenn ich fhem neu starte sehe ich, dass HMCCU noch nicht initialisiert ist, erst ein paar Sekunden später. Habe dann mal testweise ein Gerät manuell hinzugefügt und alles funktioniert damit (Status/Schalten usw). Irgendetwas scheint hier mit der Verbindung nicht zu stimmen bzw. scheint etwas geblockt zu werden. Aufgetreten ist dies alles heute nachdem ich mein komplettes Netzwerk auf UniFi umgestellt habe (Router, Switch, APs etc.)

Hat jemand schon so etwas vergleichbares gesehen?

[Init]

Die CCU verbindet sich nur mit HMCCU, wenn Daten anstehen. Daher kann HMCCU nicht auf einen Verbindungsabbau reagieren. Ich werde (sobald ich wieder arbeitsfähig bin) einen Mechanismus einbauen, der ein FHEM Event triggert, wenn für eine bestimmte Zeit kein Event von der CCU kam. Da kann man dann drauf reagieren.

Das hört sich super an. Kenne mich mit der CCU leider noch nicht wirklich gut aus, aber könnte man da nicht ein virtualDevice erstellen, welches alle 5 Minuten einen Zeitstempel schickt?

[doessbaddel]

Hi zusammen,
Danke für eure Hilfe.
Es scheinen wirklich WLAN Probleme gewesen zu sein.
Nach dem ersten Tipp habe ich mal im Router nachgeschaut und gesehen dass der Raspi sich permanent anmeldet obwohl ich WLAN Sleep aus habe.
Ich habe den Raspi jetzt per LAN angeschlossen, seitdem funktioniert alles einwandfrei.

Danke nochmal

Viele Grüße

[Init]

Hallo zusammen,

ich habe nun mein erstes HMIP-Gerät () in Betrieb genommen.

Aber leider kommen die Werte nur manuell wenn ich "get SMO_BUERO update" ausführe.

Hier mein define

Code Auswählen Erweitern

define SMO_BUERO HMCCUDEV 000BD5699DBD94
attr SMO_BUERO IODev d_ccu
attr SMO_BUERO room HMCCU
attr SMO_BUERO ccureadingfilter (LOW_BAT|ILLUMINATION|MOTION)
attr SMO_BUERO hmstatevals ERROR!1:sabotage
attr SMO_BUERO statedatapoint MOTION
attr SMO_BUERO substitute MOTION!(0|false):no,(1|true):yes;ERROR!0:no,1:sabotage;LOWBAT,LOW_BAT!(1|true):low,(0|false):ok

Hat jemand eine Idee, was mir hier fehlt?

VG
Marc

[zap]

Vermutlich läuft der RPC Server nicht oder du hast beim Attribut rpcinterface hmip nicht angehakt.

[Init]

Letzteres war mein Fehler!

Ich habe das rpcinterfaces "HmIP-RF" hinzugefügt und alles funktioniert 

Kleine Anmerkung: Im Wiki steht "HmIP-RF" und in CommandRef steht "HmIP"

Danke!

[ph4]

Hallo zusammen,

habe plötzlich ein sehr seltsames Problem mit dem Modul. Seit heute werden mir keinerlei devices mehr angezeigt und im log sehe ich auch eine Meldung, dass diese alle nicht definiert werden konnten. Kenne das wenn die CCU offline ist aber aktuell ist sie erreichbar. Wenn ich fhem neu starte sehe ich, dass HMCCU noch nicht initialisiert ist, erst ein paar Sekunden später. Habe dann mal testweise ein Gerät manuell hinzugefügt und alles funktioniert damit (Status/Schalten usw). Irgendetwas scheint hier mit der Verbindung nicht zu stimmen bzw. scheint etwas geblockt zu werden. Aufgetreten ist dies alles heute nachdem ich mein komplettes Netzwerk auf UniFi umgestellt habe (Router, Switch, APs etc.)

Hat jemand schon so etwas vergleichbares gesehen?

Kann mir hier irgendwer helfen? Das Modul funktioniert seit dem nicht mehr bei mir.

[zap]

Ich nehme an, dass HMCCU die CCU nicht erreichen kann. Das kann an deinem Netz liegen oder an den Firewall Einstellungen auf der CCU. unifi kenne ich nicht.

Interessant wäre, welche Meldungen beim Laden von HMCCU kommen, wenn FHEM startet. Dabei interessieren mich weniger die Folgefehler bei der Definition. Der Devices. Normalerweise meldet HMCCU, wie viele Geräte von der CCUgelesenwurden

[Init]

Hallo zusammen,

ich habe in meiner CCU2 ein HMW_IO_12_Sw7_DR eingebunden und in FHEM über "get d_ccu devicelist create ^HMW.* t=dev f=%n room=HMCCU" geholt.

Es wurde jetzt ein Device erstellt, aber das Gerät hat 12 Taster und 7 Schalter.

Kann mir jemand sagen, wie ich diese Taster und Schalter einlesen kann?

VG
Marc

[kjmEjfu]

ich habe in meiner CCU2 ein HMW_IO_12_Sw7_DR eingebunden und in FHEM über "get d_ccu devicelist create ^HMW.* t=dev f=%n room=HMCCU" geholt.

Es wurde jetzt ein Device erstellt, aber das Gerät hat 12 Taster und 7 Schalter.

Kann mir jemand sagen, wie ich diese Taster und Schalter einlesen kann?

t=chn statt t=dev sollte das beheben.

[Init]

Vielen Dank! So habe ich alles bekommen.

Wie würde man am besten vorgehen?

Geräte mit Channel 0+1 bsp. (0=Gerät / 1=Temperatur) als HMCCUDEV erstellen lassen

Und Geräte mit mehr Channel als HMCCUCHN erstellen lassen? Wären hierbei die Readings von HMCCUCHN mit Channel=0 identisch mit den Readings aus HMCCUDEV?

Viele Grüße
Marc

[mrfloppy]

Habe einen optischen Fensterkontakt angelernt.
Wenn ich im Eventmanager mitschaue bekomme ich mehrmals den State open oder closed sie angehängtem Code
Vorallem bei der Statusänderung wird vorher nochmal der aktuelle Stand auch mitgeschickt.

Code Auswählen Erweitern


Magnet Kontakt wird geöffnet:
2017-05-31 15:57:30 HMCCUCHN HM_FK battery: ok
2017-05-31 15:57:30 HMCCUCHN HM_FK 1.STATE: open
2017-05-31 15:57:30 HMCCUCHN HM_FK open
2017-05-31 15:57:30 HMCCUCHN HM_FK hmstate: open
Magnet Kontakt wird geschlossen:
2017-05-31 15:57:32 HMCCUCHN HM_FK 1.STATE: closed
2017-05-31 15:57:32 HMCCUCHN HM_FK closed
2017-05-31 15:57:32 HMCCUCHN HM_FK battery: ok
2017-05-31 15:57:32 HMCCUCHN HM_FK hmstate: closed

Optischer Kontakt wird geöffnet:
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 1.STATE: open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 hmstate: open

optischer Kontakt wird geschlossen:
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 1.STATE: closed
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 closed
2017-05-31 16:01:50 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:51 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:51 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:53 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:53 HMCCUCHN HM_FK_OPT2 hmstate: closed

Ist das so gewünscht das mehrmals der Status gesendet wird?

LG

[zap]

Vielen Dank! So habe ich alles bekommen.

Das hätte auch mit HMCCUDEV funktionieren müssen.

Wie würde man am besten vorgehen?

Geräte mit Channel 0+1 bsp. (0=Gerät / 1=Temperatur) als HMCCUDEV erstellen lassen

Und Geräte mit mehr Channel als HMCCUCHN erstellen lassen? Wären hierbei die Readings von HMCCUCHN mit Channel=0 identisch mit den Readings aus HMCCUDEV?

Viele Grüße
Marc

Jedes Gerät in der CCU hat einen Statuskanal 0 und mindestens 1 normalen Kanal für die Nutzdaten. Ein mit HMCCUDEV definiertes Device enthält alle Kanäle des CCU Gerätes. Ein mit HMCCUCHN definiertes Device enthält den entsprechenden Datenkanal plus den Kanal 0.

HMCCUCHN nimmt man, wenn man auf einen Datenkanal zugreifen möchte. HMCCUDEV wenn man auf mehrere Datenkanäle zugreifen will.

Ein Sonderfall sind Mehrfachschalter. Diese haben üblicherweise mehrere Datenkanäle, die alle einen Datenpunkt STATE oder PRESS_SHORT haben. Hier kann es von Vorteil sein, jeden Datenkanal als HMCCUCHN zu definieren, wenn man die einzelnen Schaltkanäle separat betrachten möchte.

[zap]

Habe einen optischen Fensterkontakt angelernt.
Wenn ich im Eventmanager mitschaue bekomme ich mehrmals den State open oder closed sie angehängtem Code
Vorallem bei der Statusänderung wird vorher nochmal der aktuelle Stand auch mitgeschickt.

Code Auswählen Erweitern


Optischer Kontakt wird geöffnet:
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:05 HMCCUCHN HM_FK_OPT2 hmstate: closed
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 1.STATE: open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 open
2017-05-31 16:01:06 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:07 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:09 HMCCUCHN HM_FK_OPT2 hmstate: open
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 battery: ok
2017-05-31 16:01:12 HMCCUCHN HM_FK_OPT2 hmstate: open


Ist das so gewünscht das mehrmals der Status gesendet wird?

LG

Ich nehme mal an, das liegt daran, dass bei jedem Update eines Datenpunktes "hmstate" neu berechnet wird. Diesen Overhead sollte man natürlich vermeiden. Da muss ich nochmal Hand anlegen.

Du kannst die nutzlosen Events vorerst mit event-on-change-reading = .* unterbinden.

Kannst Du bitte mal ein list des magnetischen und des optischen Sensors posten?

[mrfloppy]

Bitte hier die beiden listings

Der magnetische Kontakt:

Code Auswählen Erweitern

Internals:
   DEF        MEQ1592858:1 defaults
   IODev      CCU2
   NAME       HM_FK
   NR         691
   STATE      open
   TYPE       HMCCUCHN
   ccuaddr    MEQ1592858:1
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    HM_Kontakt:1
   ccutype    HM-Sec-SC-2
   channels   1
   chntype    SHUTTER_CONTACT
   firmware   2.4
   statevals  devstate
   Readings:
     2017-05-31 15:57:50   1.STATE         open
     2017-05-29 11:39:04   Activity        alive
     2017-05-31 15:57:50   battery         ok
     2017-05-31 15:57:50   hmstate         open
     2017-05-31 15:57:50   state           open
   Hmccu:
     Dp:
       0.aes_key:
         VAL        1
       0.config_pending:
         VAL        false
       0.lowbat:
         VAL        false
       0.rssi_device:
         VAL        1
       0.rssi_peer:
         VAL        1
       0.sticky_unreach:
         VAL        false
       0.unreach:
         VAL        false
       1.error:
         VAL        0
       1.lowbat:
         VAL        0
       1.state:
         VAL        1
Attributes:
   IODev      CCU2
   ccureadingfilter STATE
   group      Fensterkontakte
   hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
   room       HM_CCU2
   statedatapoint STATE
   substitute STATE!(0|false):closed,(1|true):open

der optische Fensterkontakt:

Code Auswählen Erweitern

Internals:
   DEF        OEQ0226088:1 defaults
   IODev      CCU2
   NAME       HM_FK_OPT1
   NR         708
   STATE      closed
   TYPE       HMCCUCHN
   ccuaddr    OEQ0226088:1
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    FK-OPT1:1
   ccutype    HM-Sec-SCo
   channels   1
   chntype    SHUTTER_CONTACT
   firmware   1.0
   statevals  devstate
   Readings:
     2017-05-31 19:13:14   1.STATE         closed
     2017-05-29 11:39:04   Activity        alive
     2017-05-31 19:13:14   battery         ok
     2017-05-31 19:13:14   hmstate         closed
     2017-05-31 19:13:14   state           closed
   Hmccu:
     Dp:
       0.aes_key:
         VAL        1
       0.config_pending:
         VAL        false
       0.device_in_bootloader:
         VAL        false
       0.lowbat:
         VAL        false
       0.rssi_device:
         VAL        1
       0.rssi_peer:
         VAL        200
       0.sticky_unreach:
         VAL        false
       0.unreach:
         VAL        false
       0.update_pending:
         VAL        false
       1.error:
         VAL        0
       1.lowbat:
         VAL        0
       1.state:
         VAL        0
Attributes:
   IODev      CCU2
   ccureadingfilter STATE
   group      Fensterkontakte
   hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
   room       HM_CCU2
   statedatapoint STATE
   substitute STATE!(0|false):closed,(1|true):open


Habe gerade noch beim ThreeState Sensor geschaut da sieht es ähnlich aus.

Code Auswählen Erweitern

   
von closed auf tilted:
2017-05-31 19:45:28 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:28 HMCCUCHN HM_WZ_EG_FK3 hmstate: closed
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 1.STATE: open
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 open
2017-05-31 19:45:30 HMCCUCHN HM_WZ_EG_FK3 hmstate: open

tiltet auf open:
2017-05-31 19:45:46 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:46 HMCCUCHN HM_WZ_EG_FK3 hmstate: open
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 1.STATE: tilted
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 tilted
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:45:48 HMCCUCHN HM_WZ_EG_FK3 hmstate: tilted

von tilted auf closed
2017-05-31 19:46:04 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:46:04 HMCCUCHN HM_WZ_EG_FK3 hmstate: tilted
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 1.STATE: open
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 open
2017-05-31 19:46:06 HMCCUCHN HM_WZ_EG_FK3 hmstate: open
2017-05-31 19:46:07 HMCCUCHN HM_WZ_EG_FK3 battery: ok
2017-05-31 19:46:07 HMCCUCHN HM_WZ_EG_FK3 hmstate: open

auch noch das listing zum ThreeStateKontakt:

Code Auswählen Erweitern

Internals:
   DEF        NEQ1477782:1 defaults
   IODev      CCU2
   NAME       HM_WZ_EG_FK3
   NR         706
   STATE      closed
   TYPE       HMCCUCHN
   ccuaddr    NEQ1477782:1
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    WZ-EG-FK3:1
   ccutype    HM-Sec-RHS
   channels   1
   chntype    ROTARY_HANDLE_SENSOR
   firmware   2.4
   statevals  devstate
   Readings:
     2017-05-31 19:46:08   1.STATE         closed
     2017-05-29 11:39:05   Activity        alive
     2017-05-31 19:46:07   battery         ok
     2017-05-31 19:46:08   hmstate         closed
     2017-05-31 19:46:08   state           closed
   Hmccu:
     Dp:
       0.aes_key:
         VAL        1
       0.config_pending:
         VAL        false
       0.lowbat:
         VAL        false
       0.rssi_device:
         VAL        1
       0.rssi_peer:
         VAL        212
       0.sticky_unreach:
         VAL        false
       0.unreach:
         VAL        false
       1.error:
         VAL        0
       1.lowbat:
         VAL        0
       1.state:
         VAL        0
Attributes:
   IODev      CCU2
   alias      FK_Balkontuer3
   ccureadingfilter STATE
   devStateIcon tilted:fts_window_2w_tilt_l@yellow open:fts_window_2w_open_l@yellow closed:fts_window_2w@grey
   group      Fensterkontakte
   hmstatevals ERROR!1:sabotage
   room       HM_CCU2
   statedatapoint STATE
   substitute STATE!0:closed,1:tilted,2:open;ERROR!0:no,1:sabotage