Neues Modul HMCCU für Homematic CCU

[zap]

habe jetzt die Wetterstation noch mal angelegt
in den readings steht nur:
hmstate nitialized 2017-02-17 07:15:50
state Initialized 2017-02-17 06:59:12

nach get Update kam hinzu
Activity alive 2017-02-17 07:19:24
battery ok 2017-02-17 07:19:24

Drei Dinge, die Du prüfen kannst:

1. Hast Du noch andere HMCCUDEV oder HMCCUCHN Devices definiert und wenn ja, werden bei denen die Readings aktualisiert?

2. Hast Du bei der Wetterstation das Attribut "ccureadingfilter" gesetzt und/oder hast Du im IO Device das Attribut ccudef-readingfilter gesetzt? Wenn ja, wie sehen die beiden Attribute aus?

3. Läuft der RPC-Server?

[fini]

zap läuft wieder ...
nach
attr d_ccu ccudef-readingfilter .*
get Wetterstation update
ging es wieder.

[zap]

Version 3.9.003 dürfte morgen per Update verfügbar sein.

Änderungen:

Die Abarbeitungsreihenfolge von ccudef-readingfilter und ccureadingfilter wurde umgekehrt. Das globale Attribut ccudef-readingfilter wird nun zuerst ausgewertet.

Wenn beim Attribut ccureadingfilter eine Filterregel mit "N:" beginnt, wird die Bedingung umgekehrt. Wenn man z.B. alle Datenpunkte außer solche die PARTY enthalten als Readings haben möchte, kann man ccureadingfilter so setzen

N:PARTY

Um mehr Datenpunkte auszuschließen:

N:(PARTY|^RSSI)

Oder alle STATE Datenpunkte außer dem von Kanal "TASTE1":

N:TASTE1!STATE;STATE

N: bezieht sich also immer auf genau einen Filter. Das STATE nach dem Semikolon ist wieder ein "Include" Filter. Das funktioniert deshalb, weil bei negierten Filtern die Regelverarbeitung fortgesetzt wird, wenn der Filter nicht passt.

[Quant]

Hallo,

ich versuche gerade meine CCU2 über dieses Modul in FHEM einzubinden. Die Definition habe ich nach Wiki vorgenommen mit:

Code Auswählen Erweitern

define d_ccu2 HMCCU 192.168.0.200
attr d_ccu2 rpcinterfaces BidCos-RF,VirtualDevices
attr d_ccu2 rpcinterval 5
attr d_ccu2 rpcport 2001,9292
attr d_ccu2 rpcqueue /tmp/ccuqueue
attr d_ccu2 rpcserver on
attr d_ccu2 stateFormat rpcstate/state
Leider kommt das Device dann nicht aus dem Status "starting/busy" heraus. Ich bin mir nicht sicher, ob der RPC-Server wirklich startet, auch wenn es im Log erstmal danach aussieht:

Code Auswählen Erweitern

2017.02.19 15:25:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.02.19 15:25:24 0: HMCCU: Child process for server CB2001 started with PID 11631
2017.02.19 15:25:24 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001_1
2017.02.19 15:25:24 0: CCURPC: Initializing RPC server CB2001
2017.02.19 15:25:24 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2017.02.19 15:25:24 0: HMCCU: Child process for server CB9292 started with PID 11632
2017.02.19 15:25:24 0: CCURPC: CB9292 Creating file queue /tmp/ccuqueue_9292_1
2017.02.19 15:25:24 0: CCURPC: Initializing RPC server CB9292
2017.02.19 15:25:24 0: RPC server(s) starting
2017.02.19 15:25:24 0: CCURPC: Callback server created listening on port 14702
2017.02.19 15:25:24 0: CCURPC: Callback server created listening on port 7411
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for events
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for events
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for new devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for new devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for deleted devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for deleted devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for modified devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for modified devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for replaced devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for replaced devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for readded devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for readded devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for list devices
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for list devices
2017.02.19 15:25:24 1: CCURPC: CB9292 Adding callback for event query
2017.02.19 15:25:24 1: CCURPC: CB2001 Adding callback for event query
2017.02.19 15:25:24 0: CCURPC: CB9292 Entering server loop
2017.02.19 15:25:24 0: CCURPC: CB2001 Entering server loop
2017.02.19 15:25:29 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.02.19 15:25:36 1: HMCCU: Registering callback http://192.168.0.30:7411/fh2001 with ID CB2001 at http://192.168.0.200:2001/
2017.02.19 15:25:36 1: HMCCU: RPC callback with URL http://192.168.0.30:7411/fh2001 initialized
2017.02.19 15:25:41 0: HMCCU: Received SL event. RPC server CB9292 enters server loop
2017.02.19 15:25:48 1: HMCCU: Registering callback http://192.168.0.30:14702/fh9292 with ID CB9292 at http://192.168.0.200:9292/groups
2017.02.19 15:25:58 1: HMCCU: RPC callback with URL http://192.168.0.30:14702/fh9292 initialized
2017.02.19 15:30:43 2: HMCCU: Received no events from CCU since 300 seconds
Aber:

Code Auswählen Erweitern

[root@T20 fhem]# "ps -ef | grep ccurpcd.pl
>

Ich arbeite unter Centos 7.3, falls das relevant ist. Wo sollte ich weiter forschen?

Thomas

[zap]

schwierig. Bis einschließlich der Meldungen "RPC callback ... initialized" ist alles wie es sein soll. Aber danach kommt eben nichts mehr. Da fehlen noch einige Meldungen. Die CCU müsste auf die Registrierung mit Rückmeldungen reagieren.

Den Prozess ccurpcd wirst Du nicht finden. Der wird nicht mehr verwendet. Stattdessen starten 2 zusätzliche fhem.pl Prozesse. Das ist aber nicht das Problem. Ich denke, dass die korrekt gestartet werden.

Frage: Hat Dein System mehrere Netzwerk Interfaces oder eine Firewall?

Wie sieht die Ausgabe von "netstat -an | grep LISTEN" aus?

[Quant]

Super, das Stichwort "Firewall" war genau richtig. Ich habe jetzt die Ports 7411 und 14702, die ich im Logfile gefunden habe, geöffnet und nun wechselt der Status auch zu "running/OK".
Sind diese Ports fix? Kann und soll ich das mal in der Wiki ergänzen?

Viele Grüße
Thomas

[zap]

Super, das Stichwort "Firewall" war genau richtig. Ich habe jetzt die Ports 7411 und 14702, die ich im Logfile gefunden habe, geöffnet und nun wechselt der Status auch zu "running/OK".
Sind diese Ports fix? Kann und soll ich das mal in der Wiki ergänzen?

Viele Grüße
Thomas

Nein die sind nicht fix sondern werden nach einer Formel berechnet. Hier der Auszug aus der Online Doku zum Attribut 'rpcserverport':

rpcserverport <base-port>
Specify base port for RPC server. The real listening port of an RPC server is calculated by the formula: base-port + rpc-port + (10 * ccu-number). Default value for base-port is 5400.
The value ccu-number is only relevant if more than one CCU is connected to FHEM. Example: If base-port is 5400, protocol is BidCos (rpc-port 2001) and only one CCU is connected the resulting RPC server port is 5400+2001+(10*1) = 7411

[fini]

Moin,

habe mal wieder ein Problem.
Nachdem ich meine CCU2 neu gestartet habe, werden die Readings von allen Geräten nicht mehr aktualisiert.
Komisch nur, die Readings direkt unter MMCCU werden aktualisiert. Aber nicht die HMCCUDEV.
Bis zum Neustart der CCU2 lief alles ...
Nach get Update aktulisiert er die Gerätereadings einmal ... danach nicht mehr

RPCPRC internal
RPCState running
STATE running/OK

[zap]

Wenn Du die CCU neu startest, musst Du danach auch den RPC-Server neu starten. Leider merkt sich die CCU beim einem Neustart nicht die registrierten Event-Empfänger (z.B. FHEM/HMCCU).

[Mundus]

Hi,

ich muss hier noch eine Frage loswerden, damit ich mein HMIP-eTRV noch besser einbinden kann. Bei meinem Homematic Thermostat HM-CC-RT-DN habe ich mittels

Code Auswählen Erweitern

get KuecheThermostat configlist
über die Readings hinaus weitere Werte ermittelt. Mit

Code Auswählen Erweitern

attr KuecheThermostat userreading Gesperrt {fhem "get KuecheThermostat configlist LOCK"}
habe ich für mich relevante Readings gespeichert und alles funktioniert wunderbar. Das gleiche möchte ich mit dem HMIP-eTRV  auch erreichen. Wenn ich bei dem HMIP-eTRV den Befehl

Code Auswählen Erweitern

get FlurThermostat configlist
absetze, erhalte ich die Antwort

HMCCUDEV: FlurThermostat No response from CCU

Wo liegt mein Fehler? Bzw. wie kann ich den Zustand Gesperrt für das HMIP-eTRV abfragen und im nächsten Schritt sogar setzen? Bei dem HM-CC-RT-DN hat es so funktioniert:

Code Auswählen Erweitern

config BUTTON_LOCK=true:Sperren/config BUTTON_LOCK=false:Entsperren


Gruß

Mundus

[zap]

Viel zu kompliziert. Das Userreading brauchst Du nicht. Ich beziehe mich jetzt mal auf das alte Thermostat. Du machst einfach ein

Code Auswählen Erweitern


get KuecheThermostat config LOCK


Dabei darauf achten, dass das Attribut ccureadingfilter LOCK enthält. Damit werden dann Readings erzeugt, die alle mit "R-" beginnen (als Abgrenzung zu den normalen Datenpunkt Readings).

Der Befehl "get configlist" ist nur dafür gedacht, sich die möglichen Config-Parameter anzeigen zu lassen, da diese im Gegensatz zu den Datenpunkten nicht dokumentiert sind.

Ein weiterer Unterschied zu Datenpunkten ist, dass Config-Parameter nicht nur an den Kanälen eines Gerätes hängen sondern auch am Gerät selbst (Datenpunkte sind ausschließlich Kanälen zugeordnet. Um die Config-Parameter eines Hm-IP Thermostaten zu ermitteln, solltest Du also den Befehl "get configlist" sowohl für das Device als auch für die einzelnen Kanäle ausführen:

Code Auswählen Erweitern


get FlurThermostat configlist
get FlurThermostat 1 configlist
get FlurThermostat 2 configlist
usw.


Den 1. Befehl hast Du schon ausprobiert. Die Anzahl der Kanäle wird im Internal channels angezeigt. Wenn Du dann den richtigen Kanal mit dem entsprechenden Config-Parameter für den Lock gefunden hast, kannst Du die Readings wiederum so erzeugen:

Code Auswählen Erweitern


get FlurThermostat 1 config xxxx


[Mundus]

Viel zu kompliziert. Das Userreading brauchst Du nicht. Ich beziehe mich jetzt mal auf das alte Thermostat. Du machst einfach ein

Code Auswählen Erweitern


get KuecheThermostat config LOCK


Dabei darauf achten, dass das Attribut ccureadingfilter LOCK enthält. Damit werden dann Readings erzeugt, die alle mit "R-" beginnen (als Abgrenzung zu den normalen Datenpunkt Readings).

Da das bei mir zu einer sehr unübersichtlichen Liste geführt hat -alle R- - erscheinen auch als Readings, habe ich den anderen Weg gewählt. Außerdem hat die Ergänzung des ccureadingfilter um LOCK, zu dem nachfolgenden Phänomen geführt -Es wird nur noch das userreading angezeigt-. Zur besseren Visualisierung die beiden entsprechenden list (zuerst mit LOCK):

Code Auswählen Erweitern

Internals:
   CHANGED
   DEF        MEQ
   IODev      myHomeMatic
   NAME       KuecheThermostat
   NR         71
   STATE      Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Modus: 4.CONTROL_MODE
   TYPE       HMCCUDEV
   ccuaddr    MEQ
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    HM-RT-Kueche
   ccutype    HM-CC-RT-DN
   channels   7
   statevals  devstate
   Readings:
     2017-02-23 23:04:52   Gesperrt        BUTTON_LOCK=1
GLOBAL_BUTTON_LOCK=0
MODUS_BUTTON_LOCK=0

   Hmccu:
     Dp:
       0.aes_key:
         VAL        0
       0.config_pending:
         VAL        false
       0.device_in_bootloader:
         VAL        false
       0.inhibit:
         VAL        false
       0.lowbat:
         VAL        false
       0.rssi_device:
         VAL        1
       0.rssi_peer:
         VAL        161
       0.sticky_unreach:
         VAL        false
       0.unreach:
         VAL        false
       0.update_pending:
         VAL        false
       4.actual_temperature:
         VAL        21.300000
       4.battery_state:
         VAL        3.000000
       4.boost_state:
         VAL        0
       4.control_mode:
         VAL        0
       4.fault_reporting:
         VAL        0
       4.party_start_day:
         VAL        1
       4.party_start_month:
         VAL        1
       4.party_start_time:
         VAL        0
       4.party_start_year:
         VAL        0
       4.party_stop_day:
         VAL        1
       4.party_stop_month:
         VAL        1
       4.party_stop_time:
         VAL        0
       4.party_stop_year:
         VAL        0
       4.party_temperature:
         VAL        5.000000
       4.set_temperature:
         VAL        17.000000
       4.valve_state:
         VAL        0
Attributes:
   IODev      myHomeMatic
   ccureadingfilter N:(PARTY);LOCK
   ccureadingformat datapoint
   ccureadingname 4.BATTERY_STATE:Battery
   ccureadings 1
   cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus Sperren:secur_locked Entsperren:secur_open
   controldatapoint 4.SET_TEMPERATURE
   event-on-change-reading .*
   eventMap   /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/config BUTTON_LOCK=true:Sperren/config BUTTON_LOCK=false:Entsperren
   room       HomeMatic
   stateFormat Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Modus: 4.CONTROL_MODE
   statedatapoint 4.ACTUAL_TEMPERATURE
   stripnumber 1
   substexcl  control
   substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
   userReadings Gesperrt {fhem "get KuecheThermostat configlist LOCK"}
   webCmd     control:Auto:Manu:Boost:on:off:Sperren:Entsperren
   widgetOverride control:slider,4.5,0.5,30.5,1
und jetzt ohne LOCK im ccureadingfilter:

Code Auswählen Erweitern

Internals:
   DEF        MEQ
   IODev      myHomeMatic
   NAME       KuecheThermostat
   NR         71
   STATE      Temp: 21.3° | Gewünscht: 17.0° | Modus: AUTO
   TYPE       HMCCUDEV
   ccuaddr    MEQ
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    HM-RT-Kueche
   ccutype    HM-CC-RT-DN
   channels   7
   statevals  devstate
   Readings:
     2017-02-23 23:10:20   0.AES_KEY       0
     2017-02-23 23:10:20   0.CONFIG_PENDING false
     2017-02-23 23:10:20   0.DEVICE_IN_BOOTLOADER false
     2017-02-23 23:10:20   0.INHIBIT       false
     2017-02-23 23:10:20   0.LOWBAT        no
     2017-02-23 23:10:20   0.RSSI_DEVICE   1
     2017-02-23 23:10:20   0.RSSI_PEER     161
     2017-02-23 23:10:20   0.STICKY_UNREACH false
     2017-02-23 23:10:20   0.UNREACH       no
     2017-02-23 23:10:20   0.UPDATE_PENDING false
     2017-02-23 23:10:20   4.ACTUAL_TEMPERATURE 21.3
     2017-02-23 23:10:20   4.BOOST_STATE   0
     2017-02-23 23:10:20   4.CONTROL_MODE  AUTO
     2017-02-23 23:10:20   4.FAULT_REPORTING 0
     2017-02-23 23:10:20   4.SET_TEMPERATURE 17.0
     2017-02-23 23:10:20   4.VALVE_STATE   0
     2017-02-23 23:10:20   Battery         3.0
     2017-02-23 23:10:20   Gesperrt        BUTTON_LOCK=1
GLOBAL_BUTTON_LOCK=0
MODUS_BUTTON_LOCK=0

     2017-02-23 23:10:20   control         17.0
     2017-02-23 23:10:20   hmstate         21.3
     2017-02-23 23:10:20   state           21.3
   Hmccu:
     Dp:
       0.aes_key:
         VAL        0
       0.config_pending:
         VAL        false
       0.device_in_bootloader:
         VAL        false
       0.inhibit:
         VAL        false
       0.lowbat:
         VAL        false
       0.rssi_device:
         VAL        1
       0.rssi_peer:
         VAL        161
       0.sticky_unreach:
         VAL        false
       0.unreach:
         VAL        false
       0.update_pending:
         VAL        false
       4.actual_temperature:
         VAL        21.300000
       4.battery_state:
         VAL        3.000000
       4.boost_state:
         VAL        0
       4.control_mode:
         VAL        0
       4.fault_reporting:
         VAL        0
       4.party_start_day:
         VAL        1
       4.party_start_month:
         VAL        1
       4.party_start_time:
         VAL        0
       4.party_start_year:
         VAL        0
       4.party_stop_day:
         VAL        1
       4.party_stop_month:
         VAL        1
       4.party_stop_time:
         VAL        0
       4.party_stop_year:
         VAL        0
       4.party_temperature:
         VAL        5.000000
       4.set_temperature:
         VAL        17.000000
       4.valve_state:
         VAL        0
Attributes:
   IODev      myHomeMatic
   ccureadingfilter N:(PARTY)
   ccureadingformat datapoint
   ccureadingname 4.BATTERY_STATE:Battery
   ccureadings 1
   cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus Sperren:secur_locked Entsperren:secur_open
   controldatapoint 4.SET_TEMPERATURE
   event-on-change-reading .*
   eventMap   /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/config BUTTON_LOCK=true:Sperren/config BUTTON_LOCK=false:Entsperren
   room       HomeMatic
   stateFormat Temp: 4.ACTUAL_TEMPERATURE° | Gewünscht: 4.SET_TEMPERATURE° | Modus: 4.CONTROL_MODE
   statedatapoint 4.ACTUAL_TEMPERATURE
   stripnumber 1
   substexcl  control
   substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
   userReadings Gesperrt {fhem "get KuecheThermostat configlist LOCK"}
   webCmd     control:Auto:Manu:Boost:on:off:Sperren:Entsperren
   widgetOverride control:slider,4.5,0.5,30.5,1

Mit dem Hinweis

Ein weiterer Unterschied zu Datenpunkten ist, dass Config-Parameter nicht nur an den Kanälen eines Gerätes hängen sondern auch am Gerät selbst (Datenpunkte sind ausschließlich Kanälen zugeordnet. Um die Config-Parameter eines Hm-IP Thermostaten zu ermitteln, solltest Du also den Befehl "get configlist" sowohl für das Device als auch für die einzelnen Kanäle ausführen:

Code Auswählen Erweitern


get FlurThermostat configlist
get FlurThermostat 1 configlist
get FlurThermostat 2 configlist
usw.


Den 1. Befehl hast Du schon ausprobiert. Die Anzahl der Kanäle wird im Internal channels angezeigt. Wenn Du dann den richtigen Kanal mit dem entsprechenden Config-Parameter für den Lock gefunden hast, kannst Du die Readings wiederum so erzeugen:

habe ich dann den Befehl

Code Auswählen Erweitern

get FlurThermostat configlist 0 und somit das Merkmal GLOBAL_BUTTON_LOCK gefunden. Und jetzt wird es kurios bzw. ich verstehe immer weniger (dachte zwischenzeitlich wäre es teilweise andersrum  ). Wenn ich den Befehl

Code Auswählen Erweitern

set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=false absetze, dann wird im WEB-Inferface der CCU2 der entsprechende Haken entfernt und das war es. Das Thermostat selbst kriegt den Befehl nicht mitgeteilt. Es erscheint zwar im UI von der CCU2 noch eine Hinweis, es steht eine Servicemeldung auf dem Kanal 0 für das FlurThermostat bereit, aber es passiert nichts.

Wieso wird der Befehl nicht weitergegeben?


Gruß

Mundus

[zap]

Das mit den R- Readings und dem Readingfilter schaue ich mir an. So wie du es beschreibst soll es jedenfalls nicht sein. Möglicherweise noch ein Bug.

Beim Setzen von Config Parametern kann es sein, dass diese nur verzögert von der CCU an das Gerät gesendet werden bzw. dass der erste Versuch fehlschlägt. In dem Fall gibt es eine Service Meldung, dass Daten zur Übertragung anstehen. Irgendwann überträgt die CCU die Daten dann und die Meldung verschwindet automatisch.

Das gleiche Verhalten kann man feststellen, wenn man Parameter direkt im CCU WebUI ändert.

Da HMCCU nur indirekt über die CCU mit den Geräten kommunizieren kann, kann ich da Programm seitig nichts machen.

[Mundus]

Hmmm, alles komisch, hier ein Auszug des Eventmonitors, wenn ich den Befehl

Code Auswählen Erweitern

set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=false
absetze.

Code Auswählen Erweitern

2017.02.24 13:03:32 5 : Cmd: >set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=false<
2017.02.24 13:03:33 1 : HMCCU: Invalid parameter or value
2017.02.24 13:03:33 1 : HMCCUDEV: FlurThermostat Execution of CCU script or command failed
2017.02.24 13:03:33 4 : name: /fhem&fw_id=201&fwcsrf=fhem_372513837193697&cmd=set+FlurThermostat+config+0+GLOBAL_BUTTON_LOCK%3Dfalse / RL:1474 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2017.02.24 13:03:33 4 : WEB_192.168.130.8_56558 GET /fhem?XHR=1&inform=type=status;filter=;since=1487937812;fmt=JSON&fw_id=201&timestamp=1487937813733; BUFLEN:0
2017.02.24 13:03:35 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.02.24 13:03:36 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=false
2017.02.24 13:03:36 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017-02-24 13:03:36 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-02-24 13:03:36 HMCCUDEV FlurThermostat hmstate: 21.0
2017-02-24 13:03:36 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=false
2017.02.24 13:03:36 5 : End notify loop for FlurThermostat

Anschließend ändert sich das UI der CCU2. WIe beschrieben wird die Globale Bediensperre im UI entsperrt und die Servicemeldung erzeugt. Dann passiert, wie ebenfalls gesagt, gar nichts. Die Servicemeldung wird nicht abgesetzt. (Auch nach einer Stunde nicht).

Nun versuche ich mal eine SD-Karte zu finden und das LOG der CCU2 zu analysieren...

[zap]

Das Reading bzw. der Datenpunkt CONFIG_PENDING=1 deutet genau auf das hin, was ich oben. Geschrieben habe. Die CCU hat versucht, das Gerät zu konfigurieren, wird die Daten aber nicht los.

UPDATE: Weiter oben habe ich Blödsinn geschrieben. Beim Befehl "get config" wird das Attribut ccureadingfilter nicht berücksichtigt. Deshalb kann auch als Parameter ein regulärer Ausdruck als Filter angegeben werden.

Wenn ich bei einem meiner Thermostate (alt, kein HM-IP) den Befehl "get config LOCK" ausführe, erhalte ich 3 Readings:

Code Auswählen Erweitern


R-BUTTON_LOCK 0 2017-02-24 16:49:01
R-GLOBAL_BUTTON_LOCK 0 2017-02-24 16:49:01
R-MODUS_BUTTON_LOCK 0 2017-02-24 16:49:01


m.E. kannst Du also auf das Userreading verzichten. Der entsprechende Befehl für einen bestimmten Kanal (hier 0) lautet dann:

get config 0 LOCK