HM-TC-IT-WM-W-EU - Frage zu den Readings

Begonnen von FHEm2005, 23 Juni 2015, 15:16:57

Vorheriges Thema - Nächstes Thema

FHEm2005

In den Readings des o.a. Wandthermostaten gibt es u.a. auch die drei folgenden Readings für unterschiedliche Tastensperren mit den Bezeichnungen: btnLock, modusBtnLock und globalBtnLock.

Im Gegensatz zu allen anderen Readings, die mit "get<device> param <Reading>" ausgelesen werden können, müssen diese mit "get<device> regVal <Reading>" ausgelesen werden. Das führt bei der Programmierung für das Frontend FTUI zu Problemen, da dort nur mit param gearbeitet wird. Meine Frage: Warum ist es bei diesen drei Readings zwingend notwendig mit regVal anstatt mit param zu arbeiten? Innerhalb der Readings wäre eine einheitliche Werteabfrage doch nur sinnvoll.

Hier der gestartete Thread im Bereich Frontends: http://forum.fhem.de/index.php/topic,38396.0.html   Es sind nur insgesamt drei Beiträge.

Ich weiß nicht was ich machen kann/soll.   

Wer kann helfen?
                 
Viele Grüße
Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

FHEm2005

In einem Punkt habe ich mir selbst geholfen:

Den Status aus btnLock kann aud zwei verschiedenen WEgen ausgelesen werden:
1. "get <device> regVal <Register>" also "get Th_Wz_Ez regval btnLock" 
2. "get <device> param <Reading>" also  "get Th_Wz_Ez param R-btnLock"

Jetzt habe ich noch ein Problem:

Das Reading steht auf set_off. Ich möchte nun die Tastensperre einschalten.
Befehl "set Th_Wz_Ez regSet btnLock off" im Eingabefeld absetzen. Im Eventmonitor rührt sich nichts aber auch überhaupt nichts.

Hier die Konfiguration:

IODev      CUL1 deleteattr 
actCycle   000:10 deleteattr 
actStatus     alive   deleteattr 
alias   Thermostat Wz/Ez   deleteattr 
autoReadReg   1   deleteattr 
burstAccess   1_auto    deleteattr 
expert   2_full   deleteattr 
firmware   1.1   deleteattr   
model   HM-TC-IT-WM-W-EU   deleteattr 
msgRepeat   1   deleteattr 
room   Testraum   deleteattr 
serialNr   LEQ0000000   deleteattr 
stateFormat   Raumtemperatur:  measured-temp °C,
                   Soll-Temperatur:  desired-temp °C,
                   Batterie:  batteryLevel V                   deleteattr 
subType       thermostat              deleteattr 
webCmd       1                 deleteattr


Das mit der Tabelle klappt nicht so richtig.

Wo habe ich einen (Denk)Fehler gemacht?

Gruß
Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

MarcelK

Zitat von: FHEm2005 am 23 Juni 2015, 21:53:32
Das Reading steht auf set_off. Ich möchte nun die Tastensperre einschalten.
Befehl "set Th_Wz_Ez regSet btnLock off" im Eingabefeld absetzen. Im Eventmonitor rührt sich nichts aber auch überhaupt nichts.

Meinst Du nicht "btnLock on" in dem Fall? Nach dem RegSet entweder 3 Minuten warten oder die mittlere Taste am Gerät drücken, dann sollten die Einstellungen übertragen werden (sofern das Pairing passt). Sollte danach weiterhin "set_" stehen dann stimmt was nicht.

Gruß Marcel

FHEm2005

#3
Hallo MarcelK,

selbstverständlich hast Du Recht. Ich habe den Befehl "set Th_Wz_Ez regSet btnLock on" abgesetzt und nach drei Tagen Abwesenheit steht immer noch "set_off" im Speicher. Das sieht nicht gut aus.

Zitat von: MarcelK am 23 Juni 2015, 23:47:14
Nach dem RegSet entweder 3 Minuten warten oder die mittlere Taste am Gerät drücken, dann sollten die Einstellungen übertragen werden (sofern das Pairing passt). Sollte danach weiterhin "set_" stehen dann stimmt was nicht.

Mittlere Taste gedrückt, abgewartet - alt geworden  :) - nichts tut sich. Wie kann ich überprüfen, ob das Pairing passt?

Hier das Listing:


Internals:
   CUL1_MSGCNT 94
   CUL1_RAWMSG A0E6D84102D4D540000000BACD60B40::-62:CUL1
   CUL1_RSSI  -62
   CUL1_TIME  2015-06-26 18:10:06
   DEF        2D4D54
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     94
   NAME       Th_Wz_Ez
   NR         433
   STATE      Raumtemperatur:  21.4 °C, Soll-Temperatur:  21.5 °C, Batterie:  2.6 V
   TYPE       CUL_HM
   channel_01 Th_Wz_Ez_Weather
   channel_02 Th_Wz_Ez_Climate
   channel_03 Th_Wz_Ez_WindowRec
   channel_06 Th_Wz_Ez_remote
   channel_07 Th_Wz_Ez_SwitchTr
   lastMsg    No:BF - t:70 s:2D4D54 d:000000 00D63B
   protCondBurst on
   protIOdly  2 last_at:2015-06-23 21:30:02
   protLastRcv 2015-06-26 18:15:59
   protSnd    27 last_at:2015-06-26 15:30:00
   protState  CMDs_done
   rssi_CUL1  avg:-52.85 min:-54 max:-52 lst:-53 cnt:7
   rssi_at_CUL1 avg:-62.22 min:-81.5 max:-58.5 lst:-63.5 cnt:3335
   Readings:
     2015-06-23 21:19:57   Activity        alive
     2015-06-26 15:30:00   CommandAccepted yes
     2015-06-20 11:46:04   D-firmware      1.1
     2015-06-20 11:46:04   D-serialNr      LEQ0594414
     2015-06-23 13:40:56   R-btnLock       set_off
     2015-06-22 14:49:50   R-globalBtnLock set_off
     2015-06-22 14:49:50   R-modusBtnLock  set_off
     2015-06-23 13:12:56   RegL_00:        0F:01
     2015-06-26 18:10:06   batteryLevel    2.6
     2015-06-26 18:10:06   desired-temp    21.5
     2015-06-26 18:10:06   measured-temp   21.4
     2015-06-26 15:30:00   state           CMDs_done
     2015-06-26 06:18:45   time-request    -
   Helper:
     HM_CMDNR   191
     cSnd       1141189E2D4D54860425,1141189E2D4D5486042B
     mId        00AD
     rxType     6
     Io:
       newChn     +2D4D54,00,01,00
       nextSend   1435335360.02858
       prefIO
       rxt        0
       vccu
       p:
         2D4D54
         00
         01
         00
     Mrssi:
       mNo        BF
       Io:
         CUL1       -61.5
     Prt:
       awake      0
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       Cul1:
         avg        -52.8571428571429
         cnt        7
         lst        -53
         max        -52
         min        -54
       At_cul1:
         avg        -62.2254872563717
         cnt        3335
         lst        -63.5
         max        -58.5
         min        -81.5
     Shregw:
       07         02
     Shadowreg:
       RegL_00:   0F:01
Attributes:
   IODev      CUL1
   actCycle   000:10
   actStatus  alive
   alias      Thermostat Wz/Ez
   autoReadReg 1
   burstAccess 1_auto
   expert     2_full
   firmware   1.1
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       Testraum
   serialNr   LEQ0594414
   stateFormat Raumtemperatur:  measured-temp °C, Soll-Temperatur:  desired-temp °C, Batterie:  batteryLevel V
   subType    thermostat
   webCmd     1



Gruß
Eberhard

Edit: Listing hinzugefügt
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

martinp876

Die register sind nicht gelesen. Ist schon gepairt ?

Otto123

Da ist nix gepairt:
ZitatlastMsg    No:BF - t:70 s:2D4D54 d:000000 00D63B
d:000000 bedeutet er sendet Broadcast und kennt keine Zentrale

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEm2005

Ich habe jetzt das Device gelöscht und neu mit der Zentrale verbunden. Vorher den Thermostaten in den Auslieferungszustand versetzt. PairedTo und R-pairCentral sind mit der CUL-Kennung vorhanden.  Allerdings wird immer noch erst nach "set <device> getConfig" der Wert im "R-btnLock" von "set_on" bzw. "set_off"  nach "on" bzw. "off" geändert. Eine automatische Aktualisierung passiert nicht.

Das Verhalten ist folgendes:.

Ausgangslage: R-btnLock: on   Display: Schloss ja
Eingabe: set <device> regSet btnLock off
Zustand: R-btnLock: set_off   Display: Schloss nein  Internals:lastMsg No:1E - t:70 s:2D4D54 d:000000 00E53B
Eingabe: set <device> regSet btnLock on 
Zustand: R-btnLock: set_off   Display: Schloss nein  (offensichtlich durch die nicht abgeschlossene vorherige Eingabe noch blockiert.)
Eingabe: set <device> getConfig 
Zustand: R-btnLock: off   Display: Schloss nein

Alle anderen Parameter (batteryLevel, desired-temp, measured-temp) werden ohne Probleme regelmäßig übertragen und aktualisiert.
Die Konfiguration des Devices habe ich momentan noch unverändert übernommen.

Ich stehe vor einem Rätsel.

Gruß
Eberhard

Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

Otto123

#7
Hallo Eberhard,

ich muss meine letzte Aussage revidieren. Bei dem Device sehen die Messages bei mir auch so aus (d:000000) Ich dachte immer da muss die hmid drin stehen.

Zu deinem Problem:
Ist das nicht so? Das nicht alles immer übertragen wird? Um Batterie zu sparen? Und das man die Änderung bestimmter Register anfragen (die Übertragung anstoßen) muss?

Schau mal hier ist das genau so umgesetzt.
Ich weiß im Wiki steht es so nicht 8)

Ich meine immerhin übertragt ja FHEM die Änderung sofort. Nur wenn es der Meinung ist, das geht jetzt nicht dann tut er nichts.


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEm2005

Ich werde das mal so versuchen. Das scheint dann bei mir gar nicht so falsch zu sein.

jetzt muss ich das Ganze noch in FTUI umsetzen.

Bis hierhin sag' mal herzlichen Dank für Deine Hilfe.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

Otto123

hmm, ich kann meinen Gedanken zumindest in meiner Umgebung nicht praktisch bestätigen.
wenn ich btnLock on sende wird nach kurzer Zeit das Schloss im Display angezeigt. In der Oberfläche von FHEM steht noch 3 CMDs pending
Aber ich kann noch kurzer Zeit ein btnLock off senden und es wird korrekt verarbeitet.

Nur die FHEM Oberfläche aktualisiert nicht alle Readings, man muss F5 drücken.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEm2005

Unabhängig von dem, was in der Anzeige gezeigt wird, erkenne ich durch die GUI FTUI welcher Status momentan vorherrscht. Das geht manchmal garnichts oder hin und wieder nach etlichen Minuten. Ich gebe es auf den wahren Grund zu finden, zumal andere das gleiche Problem haben.

Auf der GUI FTUI habe ich ein Workaround beschrieben http://forum.fhem.de/index.php/topic,38396.msg306079.html#msg306079  und kann damit eigentlich gut leben, weil ich den Zustand des Readings an der Farbe erkenne. Damit ist der Fall für mich wohl erledigt.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM