HM-CC-TC: controlMode laesst sich nicht mehr umstellen!

[Billy]

Hallo Martin,
wie bereits im Thread bezüglich Sommerzeitumstellung angedeutet, habe ich Probleme bei der controlMode Umstellung
vom TC.
Habe ich mal an 2 TC's getestet sowohl mit 10_CUL_HM.pm 3001 und 10_CUL_HM.pm 3017
Log in der Anlage! für 1D8D69 und 1A7985

Ausgangspunkt, ich wollte den 1D8D69 von Cent auf manual und 1A7985 von auto auf manual umstellen!

Hat nie funktioniert! Was mich auch wunderte, dass die Anzeige im Webfrontend immer sofort den
gewünschten Mode angezeigt hat. Früher war das erst nach bestätigtem Modewechsel der Fall.
Die Anzeigen am TC haben nach wie vor natürlich Cent bzw. Auto angezeigt.
Hoffentlich kannst du mit dem Log in Anlage etwas anfangen!
Gruss Billy

[martinp876]

Hallo Billy,

den internen Ablauf beim 'pseudoRegister' kommandos habe ich geaendert um eine Vereinheitlichung zu erreichen. Hat interne Vorteile...
letztendendes ist sind die Kommendos zu mode nichts anderes als registersetzen und identisch
So zum Beispiel R-controlMode zu controlMode

Ich habe die Registernamen den 'alten' pseudo-register kommandos angeglichen (Besitzstandawahrung)

Soweit der Hintergrund, jetzt zu deinen Problemen:
Die Kommandos zu deinem TC werden im 2. Teil sofort gesendet anstatt auf das Aufwachen zu warten. Ich denke das Betrifft alle Kommandos zu diesem Bauteil. Somit sollte nichts funktionieren.
Bei meinem geht es aber, somit scheint der Mechanismus ok.
Kannst du ein list deines TC machen?
Helper->rxType sollte 12 sein
Helper->mId sollte 0039 sein
model und subType sollten stimmen

Siehst du hier merkwuerdigkeiten?
Gruss
Martin

[Billy]

Hallo Martin,
danke für deine Erklärung.

Mein Problem beschränkt sich nicht auf einen einzelnen TC!
Anbei die List von 2 TC's.
Ich kann keine Merkwürdigkeiten erkennen.
Werde heute Abend noch einen Test mit der 10_CUL_HM.pm.2997 und älter durchführen!
Bin mir sicher, dass z.B. das Absetzten von set UG_WS controlMode manual; set UG_WS desired-temp 18.0
noch vor ca. 3 tagen astrein funktioniert hat und jetzt nicht mehr geht!

Gruss Billy

[martinp876]

Hallo Billy,

ich habe einen fix eingestellt 3020

Das setzen sollte funktionieren, klappt bei mir.

Dass controlMode immer gleich gesetzt wird ist erst einmal so. Genau genommen sollte es auf set_manual stehen und nach dem Lesen korrigiert werden. Diesen 'service' stelleich bei den Registern zu Verfügung. controlMode ist ein exot, wie die anderen 'pseudo-register'
Werde einmal sehen, wie ich es hin bekomme.
Korrekt und komplett sind immer die Werte der eigentlichen Register im Climate-Channel. Eigentlich sollte diese verwendet werden.

Neu ist dafuer, dass die aktuellen Werte aus dem device mit getConfig gelesen werden und nicht mehr alle eingegeben werden muessen

Gib bescheid, ob das setzen mit 3020 funktioniert, das war dann ein anderes Problem

Gruss
Martin

[Billy]

Hallo Martin,
mit dem FIX geht es jetz wieder!

Wann hat sich denn dieses Problem eingeschlichen?

Hier Auszug aus dem Log.

2013-04-02_12:49:04 UG_WS controlMode: manual
2013-04-02_12:49:04 UG_WS set_desired-temp 18.0
2013-04-02_12:50:04 UG_WS T: 21.4 H: 53
2013-04-02_12:50:04 UG_WS measured-temp: 21.4
2013-04-02_12:50:04 UG_WS humidity: 53
2013-04-02_12:50:05 UG_WS desired-temp: 18.0

Dass controlMode immer gleich gesetzt wird ist erst einmal so. Genau genommen sollte es auf set_manual stehen und nach dem Lesen korrigiert werden.

Richtig! 2013-04-02_12:49:04 UG_WS controlMode: manual --> 2013-04-02_12:49:04 UG_WS set_controlMode: manual  --> sein?

Gruss und Danke Billy

[martinp876]

Hi Billy,

ich wollte zu viel sparen. Beim wakeup-mode muss man nach dem aufwachen senden. Das haben wir auch bei anderne Devices (RHS) probiert und es hat soweit funktioniert. Beim TC wurde immer noch eine zusaetzliche wakeupmessage nachgesendet, die habe ich weggelassen. Habe ich natuerlich auch am TC getestet, ich habe den Temperaturwert geaendert, hat funktioniert. Also weg damit.
Durch deine Tests habe ich erkennen muessen, dass mein test zu schmal war. Der TC reagiert nach seinem erwachen wohl nur auf eine Message. Wenn dass nicht die spezielle wachhalte-message ist schlaeft er nach der ersten wieder ein.

Register setzen dauert min 3 messages.

Habe es zurückgedreht und gehe nun davon aus, dass auch andere Wakeup devices damit Leben koennen.

controllMode mit "set_" wird etwas kompliziert, da es nicht so ins Konzept passt. Ich werde etwas basteln...
Zukünftige Devices werden mit der Register-schreibweise leben müssen. Die ist durchgängig und komplett. Aber der TC hat eben eine Sonderstellung ;-)

Gruss
Martin

[Billy]

Danke, hatte schon an mir gezweifelt.
Vom Nexus
Gruss Billy

[martinp876]

Hi Billy,

mit 3025 ist jetzt "set_" auch fuer die spezial-kommandos aktiv.

Es ist jetzt nur noch eine Kopie des Registers und nur eine Fasade.
Probiers mal

Gruss Martin

[Billy]

Hallo Martin,

soeben die 3025 getestet!
Mit Befehl
set UG_WS controlMode manual; set UG_WS desired-temp 18.0

ergibt sich folgende Situation.

TC ändert Mode wie erwartet in Manu, und desired 18.0

Allerdings bleibt die Anzeige in FHEM auf controlMode: set_manual --> desired ändert sich

(siehe Anhang / see attachement)
LOG:
2013-04-02_18:31:15 UG_WS displayMode: set_temp-hum
2013-04-02_18:31:15 UG_WS displayTemp: set_setpoint
2013-04-02_18:31:15 UG_WS controlMode: set_manual
2013-04-02_18:31:15 UG_WS decalcDay: set_Sat
2013-04-02_18:31:15 UG_WS displayTempUnit: set_celsius
2013-04-02_18:31:15 UG_WS day-temp: 21 C
2013-04-02_18:31:15 UG_WS night-temp: 17 C
2013-04-02_18:31:15 UG_WS party-temp: 20 C
2013-04-02_18:31:15 UG_WS set_desired-temp 18.0
2013-04-02_18:32:11 UG_WS T: 22.5 H: 53
2013-04-02_18:32:11 UG_WS measured-temp: 22.5
2013-04-02_18:32:11 UG_WS humidity: 53
2013-04-02_18:32:12 UG_WS desired-temp: 18.0

Ich hätte erwartet, dass nach Auführung des Befehls set_manual auf manual geändert wird.
Wenn ich jetzt wieder
set UG_WS controlMode central; set UG_WS desired-temp off   --> absetze
fehlt bei controlMode: central das set !
kommt
2013-04-02_18:51:36 UG_WS displayMode: temp-hum
2013-04-02_18:51:36 UG_WS displayTemp: setpoint
2013-04-02_18:51:36 UG_WS controlMode: central
2013-04-02_18:51:36 UG_WS decalcDay: Sat
2013-04-02_18:51:36 UG_WS displayTempUnit: celsius
2013-04-02_18:51:36 UG_WS day-temp: 21 C
2013-04-02_18:51:36 UG_WS night-temp: 17 C
2013-04-02_18:51:36 UG_WS party-temp: 20 C
2013-04-02_18:51:36 UG_WS set_desired-temp off

Hoffe ich nerve dich nicht, ist wohl noch nicht ganz rund?

Gruss und Danke
Billy

[martinp876]

Hallo Billy.

die kurze Geschichte:
bei Registern verschwindet set_ immer wenn der Wert durch Lesen bestaetigt wurde, also nach einem getConfig. Daher solltest du im TC device ein autoReadReg 3_onChange setzen. Das empfehle ich bei allen Devices ausser die, welche nur 'configmode' unterstützen.

desired-temp ist kein 'registerwert'. Hier bekomme ich ein Ack mit der neuen Temp. damit kann ich getrost set_ entfernen.

Die lange Geschichte:
Das Setzen von Registern und deren Bestaetigung komplex - also wenigstens ein bisschen. Beispiel TC: Du kannst mehrere Aenderungen eingeben, die kommen alle in die Queue und ich weiss nicht mehr, welches Kommando welchen Wert aendern soll. So wird es bei allen Kommandos gehalten. Jetzt kann ich eine bestaetigung fuer alle oder einige Kommandos und Registeraenderungen erhalten.
Bei 'normalen' Kommandos werte ich immer den Rückgabewert aus, nie das Kommando. Im Ack muss der neue Lichtwert stehen.
Bei Registern funktioniert das nicht, da ich nur ein ack bekommen. Da die Acks, wie vor beschrieben tiefengestapelt sein koennen ist dies komplex. Im commandStack koennen kommandos zum mehrfachen aendern des gleichen Registers auf Verarbeitung warten, habe ich nicht im Griff. Daher mache ich es wie bei allen readings: nur was das Device meldet ist 'gültig'. Also: Lesen der Register.

Ich empfehle daher nach Register setzen ein getConfig. Da dies lästig ist kann man es automatisieren, mit autoReadReg 3_onChange.
Damit werden die Register gelesen nach einem Setzen.
Zu beachten ist, dass es zeitverzögert und entzerrt ist. Grund der Zeitverzögerung ist, bei mehreren Registeraktionen nur einmal zu lesen. Entzerrung bedeutet, dass alle mit autoReadReg gestarteten getConfig ALLER devices in einen queue kommen und immer nur einer alle 15 sec gestartet wird. Das entzerrt die HMLAN Last.
Bei einem TC ist natürlich zu beachten, dass nach auslösen des getConfig noch einmal zeit vergeht bis der TC seine tempWerte abliefert, erst dann wird gesendet.

Gruss
Martin
 

[Billy]

Hallo Martin,

vielen Dank für deine ausführliche Erläuterung.
Ich habe jetzt für mich eine befriedigende Lösung gefunden die auf FHEM Möglichkeit basiert.
Das wichtigste für mich war eigentlich die Rückmeldung von MISSING ACK im Web Frontend.

2013-04-03_18:19:04 UG_WS MISSING ACK  so sieht das ja im Log aus.

Das ist relativ einfach zu realisieren, wenn man im attr stateFormat den state selbst reinpackt!

 Bisher hatte ich:
stateFormatT:measured-temp, H:humidity, VD:actuator, controlModeT:measured-temp, H:humidity, VD:actuator, controlMode

jetzt mit
stateFormat state, VD:actuator, controlMode

(siehe Anhang / see attachement)

bekomme ich die übliche Anzeige aber auch das gewünschte MISSING ACK.

Das klappt wunderbar mit der Version 3020.
Ich schlage vor die Änderungen aus der 3025 bezüglich dieser Problematik wieder zurückzudrehen.
Ich hatte nämlich verschiedene andere Probleme bekommen mit der dauerhaften Anzeige von set_manual, set_auto etc.

FHEM ist immer für Überraschungen gut.

Grüsse und Dankeschön

Billy

[martinp876]

hm,
in 3020 sind ein paar Kleinigkeiten , die sowieso korrigiert werden mussten.

Was dir nicht gefällt ist also das Detail, dass beispielsweise bei controlMode ein set_auto steht...

Es gibt hier also 2 Möglichkeiten
- die Pseudo-register erhalten immer den Wert, der gesetzt wurde, nie einen set_ prefix
- die PsuedoRegister werden wie allen anderen auch mit set_ behandelt.

Im ersten Fall kann man nicht unterscheiden, ob der Wert vom Device bestätigt ist oder nicht.
Mit autoReadReg verschwindet das set_ automatisch

Dein state sollte mit 3025 auch funktionieren, oder nicht?
Klar ist mir nicht, warum du es zurück drehen willst
Gruss
Martin

Du bist für die 1. Variante?

[Billy]

hm,
Was dir nicht gefällt ist also das Detail, dass beispielsweise bei controlMode ein set_auto steht...

Und dann stehen bleibt.

Mit autoReadReg verschwindet das set_ automatisch

Habe verstanden, dass das auch mit "attr autoReadReg 3_onChange" beim device automatisch gehen müsste?
Wenn das so wäre und z.B. set_auto wieder verschwinden würde wäre alles ok.
Das habe ich bisher aber nie hinbekommen und werde deshalb intensiv testen.
Nach welcher max. zeitspanne sollte eigentlich das z.B. set_auto verschwinden?

Du bist für die 1. Variante?

Ich könnte auch mit der 2. leben wenn sie sauber funktioniert.
Test werde ich mit 3025 durchführen!
Nun gleich zu meinem ersten Test (alle mit meinem Test-TC): --> nach set UG_WS controlMode auto
bekomme ich die Meldung  "cannot read current value for Bitfield - retrieve Data first"
Habe ich noch nie gesehen, was ist da los?

Gruss
Billy

[Billy]

Hallo Martin,
wie versprochen detailliertes Test Ergebnis.
--------------------------------------------------------------------------------------
Ausgangspunkt für Device
UG_GZ T: 15.4 H: 48, VD:0 %, auto 21

Absetzen von
set UG_GZ controlMode central; set UG_GZ desired-temp off

--> Anzeige  UG_GZ set_desired-temp off, VD:66 %, set_central 21.0

--> Änderung quitiert --> Anzeige am Device cent off
 
Anzeige im WEB Frontend

wechselt zuerst auf  UG_GZ T: 15.4 H: 48, VD:66 %, set_central off

dann auf             UG_GZ T: 15.4 H: 48, VD:0 %, set_central 21.0

set_central bleibt und 21.0 ist falsch!!!

Und da ändert sich auch nichts mehr!
Im Log sieht das so aus!

2013-04-04_09:13:23 UG_GZ displayMode: set_temp-hum
2013-04-04_09:13:23 UG_GZ displayTemp: set_setpoint
2013-04-04_09:13:23 UG_GZ controlMode: set_central
2013-04-04_09:13:23 UG_GZ decalcDay: set_Sat
2013-04-04_09:13:23 UG_GZ displayTempUnit: set_celsius
2013-04-04_09:13:23 UG_GZ day-temp: 21 C
2013-04-04_09:13:23 UG_GZ night-temp: 17 C
2013-04-04_09:13:23 UG_GZ party-temp: 20 C
2013-04-04_09:13:23 UG_GZ set_desired-temp off
2013-04-04_09:13:48 UG_GZ T: 15.4 H: 48
2013-04-04_09:13:48 UG_GZ measured-temp: 15.4
2013-04-04_09:13:48 UG_GZ humidity: 48
2013-04-04_09:13:50 UG_GZ desired-temp: off


09:26 absetzten von getConfig an UG_GZ --> aktiviert richtiges Ergebnis im WebFrontend.

UG_GZ T: 15.4 H: 48, VD:0 %, central off

Wenn das durch "autoReadReg 3_onChange" automatisch passieren würde wäre eigentlich alles ok.

Hoffe das hilft weiter.

Gruss Billy

[Billy]

Hallo Martin,

zusaätzlich zu den Testergebnissen im Beitrag vorher kann ich für die Version 3025
noch melden!

set UG_GZ getConfig --> RESPONSE TIMEOUT:PeerList, VD:0 %, set_central
--> Log 2013-04-04_16:50:22 UG_GZ RESPONSE TIMEOUT:PeerList

set UG_WS getConfig --> UG_WS MISSING ACK, VD:0 %, manual
--> Log 2013-04-04_17:06:44 UG_WS MISSING ACK

set UG_WS controlMode auto --> cannot read current value for Bitfield - retrieve Data first

In der Version 3020 werden die Befehle sauber ausgeführt ohne Fehlermeldungen.

Gruss
Billy