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
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
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
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
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
ZitatDass 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
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
Danke, hatte schon an mir gezweifelt.
Vom Nexus
Gruss Billy
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
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
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
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
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?
Zitat von: martinp876 schrieb am Do, 04 April 2013 08:14hm,
Was dir nicht gefällt ist also das Detail, dass beispielsweise bei controlMode ein set_auto steht...
Und dann stehen bleibt.
ZitatMit 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?
ZitatDu 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
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
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
Hi Billy,
der reihe nach
- hatte einen Bug wenn channels einen Wert aendern. Da wurde nicht gelesen. Ist behoben
- "cannot read current value for Bitfield - retrieve Data first"
bedeuted, dass der Wert nicht ermittelt werden kann, da es sich um ein Bitfeld handelt und die Daten nicht gelesen wurden. Die Meldung ist schlecht. Werde es umschreiben in
"cannot evaluate value- please issue getConfig first"
sorry, war knapp daneben. 3034 sollte es beheben
Zu den Zeiten:
5sec nach dem Kommando wird ein autoreadreg gescheduled. Die Liste wird mit einem Abstand von 15sec je eintrag abgearbeitet.
Der eigentlich begrenzende Faktor beim TC sollte der TC selbst sein. Nach spätestens 2mal weather sollte es erledigt sein, also max 8min?
Gruss Martin
Hallo Martin,
bevor ich teste eine Frage.
Handle ich mir mit der 00_HMLAN.pm.3034 wieder das Problem mit der 00_HMLAN.pm.3033 ein,
dass meine HMLAN Config gelöscht wird?
Ich hoffe du verstehst dass ich vorsichtig geworden bin?
Gruss Billy
Hallo Billy,
3033 und 3034 sind quasi gleich,also ja.
Ich habe keine Ahnung, warum die Config gelöscht wurde, habe ich bei mir nicht gesehen. Ich brauche auch die genaue Fehlermeldung aus dem Logfile um etwas machen zu koennen.
In HMLAN wurde quasi nichts geaendert, was gefährlich sein koennte, auch schon in 3033 nicht....
Den Test kannst du auch ohne HMLAN aenderung machen, das ist dazu nicht notwendig
Gruss
Martin
Hallo Martin,
ich kann mit der 3034 keine Verbesserung feststellen.
In Anlage ein Logfile vielleicht hilft es.
Ausgangspunkt!
autoReadReg 3_onChange
UG_WS controlMode central; UG_WS desired-temp off
--> set UG_WS controlMode manual; set UG_WS desired-temp 18.0
Meldung: cannot calculate value. Please issue set UG_WS getConfig first
set UG_WS getConfig
--> state MISSING ACK
2013-04-05_11:22:49 UG_WS MISSING ACK
2013-04-05_11:22:58 UG_WS actuator: 0 %
2013-04-05_11:23:47 UG_WS Activity:: alive
2013-04-05_11:24:59 UG_WS T: 21.1 H: 52
2013-04-05_11:24:59 UG_WS measured-temp: 21.1
2013-04-05_11:24:59 UG_WS humidity: 52
2013-04-05_11:25:08 UG_WS desired-temp: 5.5
2013-04-05_11:25:08 UG_WS desired-temp: 5.5
2013-04-05_11:25:09 UG_WS desired-temp: 5.5
2013-04-05_11:25:18 UG_WS actuator: 0 %
2013-04-05_11:25:38 UG_WS Activity:: alive
2013-04-05_11:26:34 UG_WS set_desired-temp 18.0
2013-04-05_11:27:04 UG_WS T: 21.1 H: 52
2013-04-05_11:27:04 UG_WS measured-temp: 21.1
2013-04-05_11:27:04 UG_WS humidity: 52
2013-04-05_11:27:12 UG_WS MISSING ACK
2013.04.05 11:33:22 --> Log siehe Anlage ein
das ganze wiederholt!
11:34 set UG_WS getConfig --> akzeptiert
11:36 set UG_WS controlMode manual; set UG_WS desired-temp 18.0 --> keine Meldung
--> Anzeige UG_WS --> set_desired-temp 18.0, VD:0 %, set_manual
11:37 --> Anzeige UG_WS RESPONSE TIMEOUT:RegisterRead, VD:0 %, set_manua
TC Display richtige Anzeige Manu 18.0°C
11:40 --> Web Frontend UG_WS T: 21.1 H: 52, VD:0 %, set_manual 18.0 --> ändert sich nicht mehr
Logauszug Device
2013-04-05_11:32:40 UG_WS humidity: 52
2013-04-05_11:32:49 UG_WS desired-temp: 5.5
2013-04-05_11:32:50 UG_WS desired-temp: 5.5
2013-04-05_11:32:50 UG_WS desired-temp: 5.5
2013-04-05_11:33:00 UG_WS actuator: 0 %
2013-04-05_11:33:27 UG_WS Activity:: alive
2013-04-05_11:35:06 UG_WS T: 21.1 H: 52
2013-04-05_11:35:06 UG_WS measured-temp: 21.1
2013-04-05_11:35:06 UG_WS humidity: 52
2013-04-05_11:35:15 UG_WS desired-temp: 5.5
2013-04-05_11:35:16 UG_WS desired-temp: 5.5
2013-04-05_11:35:16 UG_WS desired-temp: 5.5
2013-04-05_11:35:26 UG_WS actuator: 0 %
2013-04-05_11:36:21 UG_WS displayMode: set_temp-only
2013-04-05_11:36:21 UG_WS displayTemp: set_setpoint
2013-04-05_11:36:21 UG_WS controlMode: set_manual
2013-04-05_11:36:21 UG_WS decalcDay: set_Sat
2013-04-05_11:36:21 UG_WS displayTempUnit: set_celsius
2013-04-05_11:36:21 UG_WS day-temp: 21 C
2013-04-05_11:36:21 UG_WS night-temp: 17 C
2013-04-05_11:36:21 UG_WS party-temp: 20 C
2013-04-05_11:36:21 UG_WS set_desired-temp 18.0
2013-04-05_11:37:18 UG_WS T: 21.1 H: 52
2013-04-05_11:37:18 UG_WS measured-temp: 21.1
2013-04-05_11:37:18 UG_WS humidity: 52
2013-04-05_11:37:20 UG_WS desired-temp: 18.0
2013-04-05_11:37:25 UG_WS RESPONSE TIMEOUT:RegisterRead
2013-04-05_11:37:38 UG_WS actuator: 0 %
2013-04-05_11:40:19 UG_WS T: 21.1 H: 52
2013-04-05_11:40:19 UG_WS measured-temp: 21.1
2013-04-05_11:40:19 UG_WS humidity: 52
2013-04-05_11:40:39 UG_WS actuator: 0 %
In Anlage HMLOG.
Gruss
Billy
Hallo Billy,
Bitte korrigieren:
- Geaendert hast du den mode deines UG_WS_Climate um 11:36
- um 11:37:18 werden die werte geaendert
- 11:37:20 werden die Daten abgeholt (also in der gleiche TC Sequenz)
- um 11:37:24 bricht der Übertragung ab.
=> der Mechanismus hat funktioniert, aber es hat übertragungsfehler gegeben
=> du solltest entsprechende Meldungen haben, siehe prot... variablen im web-interface
=> du hast hmProtocolEvents mindestens auf 1 stehen. Das koennte zu verzögerungen führen, die einen Abbruch der Übertragung - besonders bei den "wakeup" devices zur Folge haben können
=> Da kein kompletter Datensatz gelesen wurde wird auch das Reaging nicht upgedated.
Kannst du es noch einmal testen, vorher hmProtokolEvents löschen?
Gruss
Martin
Hallo Martin,
Danke, ich kann jetzt für 00_HMLAN.pm.3034 und 10_CUL_HM.pm.3034 Entwarnung geben.
hmProtocolEvents für den HMLAN1 hatte ich vermutlich durch den Absturz heute Nacht auf auf 1 stehen. Sorry.
Habe jetzt nach delete hmProtocolEvents folgendes gemacht:
getConfig auf das device (autoReadReg 3_onChange) war gesetzt.
Die Mode Änderungen werden jetzt sauber angezeigt, nach Bestätigung bleibt noch für ca. 4 Min das set_XXXX
stehen. Dann z.B. Anzeige wie gewünschte
UG_GZ T: 15.6 H: 49, VD:0 %, auto
Damit kann ich gut leben.
Gruss Billy
Hallo Martin
Zu früh gefreut?
Befehl --> set UG_GZ controlMode central; set UG_GZ desired-temp off
Quittung Anzeige UG_GZ set_desired-temp off, VD:0 %, set_central
Zugehöriges Log
2013-04-05_15:46:05 UG_GZ displayMode: set_temp-hum
2013-04-05_15:46:05 UG_GZ displayTemp: set_actual
2013-04-05_15:46:05 UG_GZ controlMode: set_central
2013-04-05_15:46:05 UG_GZ decalcDay: set_Sat
2013-04-05_15:46:05 UG_GZ displayTempUnit: set_celsius
2013-04-05_15:46:05 UG_GZ day-temp: 21 C
2013-04-05_15:46:05 UG_GZ night-temp: 17 C
2013-04-05_15:46:05 UG_GZ party-temp: 20 C
2013-04-05_15:46:05 UG_GZ set_desired-temp off
2013-04-05_15:46:52 UG_GZ T: 15.6 H: 49
2013-04-05_15:46:52 UG_GZ measured-temp: 15.6
2013-04-05_15:46:52 UG_GZ humidity: 49
2013-04-05_15:46:54 UG_GZ desired-temp: off
2013-04-05_15:47:01 UG_GZ desired-temp: 5.5 --> wo kommen die her?
Im TC wird richtgerweise Mode Cent + OFF angezeigt!!!
Endgültige Anzeige in FHEM ändert sich auch nach getConfig nicht!
UG_GZ T: 15.6 H: 49, VD:0 %, central on set --> steht auf on!
dass in Wirklichkeit off sieht man auch am VD:0%
In den Readings werden die desired-temp 5.5 angezeigt, obwohl off angefordert war und im TC gesetzt wurde.
Ich glaube ich gebe jetzt auf?
Gruss Billy
Billy,
verstehe nicht, wo dein Problem jetzt ist.
Eins nach dem anderen:
das Setzen des controlModes (sowie der RegisterWerte) sollte jetzt funktionieren. Auch das handling mit dem prefix.
desired_temp ist kein register, ist also von alledem nicht betroffen, eine eigene Baustelle.
Bin gerade am Testen - wie war es den vorher?
Aus dem device lese ich 5,5 wenn ich 'off' eingebe. Am Rad kann ich 'off' garnicht eingeben.
5.5 ist sicher der Frostschutz, wie bei jeden normalen Thermostat, also 'off'
meinen TC bekomme ich nicht auf 'off' ausser im manuell mode.
ZitatUG_GZ T: 15.6 H: 49, VD:0 %, central on set --> steht auf on!
wie soll ich das lesen?
ZitatIn den Readings werden die desired-temp 5.5 angezeigt, obwohl off angefordert war und im TC gesetzt wurde.
das ist unterschiedlich, je nach mode
ZitatIch glaube ich gebe jetzt auf?
sollte ich? Vielleicht schon, habe ja keinen eigenen TC
Gruss
Martin
Zitat von: martinp876 schrieb am Fr, 05 April 2013 17:31Billy,
verstehe nicht, wo dein Problem jetzt ist.
Aus dem device lese ich 5,5 wenn ich 'off' eingebe. Am Rad kann ich 'off' garnicht eingeben.
5.5 ist sicher der Frostschutz, wie bei jeden normalen Thermostat, also 'off'
Eigentlich ganz einfach, früher hatte ich das was der TC angezeigt hat auch auf dem WEB.
Display beider TC's zeigt OFF --> das WEB zeigt hier einmal on und einmal off! Das ist mein Problem
(siehe Anhang / see attachement)
I
n beiden Fällen müsste off gezeigt werden!sieht man ja auch am VD --> so war es noch vor ca. 2 Wochen.
Trotzdem vielen Dank für deine Mühe.
Gruss Billy
...ich hab hier einen komischen Effekt.
Ich habe meine Konfiguration aus etlichen TCs und VDs um einen TC und einen VD erweitert.
Wie gehabt: erste den VD und den TC gepairt und dann den TC mit fhem gepairt. Hat alles augenscheinlich funktioniert.
Ich hab heute via fhem die templist für alle Tage programmiert -> geht einwandfrei
Dann hab ich versucht den controlMode von manual auf auto zu stellen -> geht NICHT
Es kommt die Meldung "cannot calculate value. Please issue set Bad_Justus getConfig first"
Also sende ich ein "set Bad_Justus getConfig" -> ACK
Danach probiere ich es nochmal... aber weiterhin kein Erfolg.
Was mache ich falsch? (Update habe ich heute Mittag gemacht, sollte also die aktuelle Version sein).
VG
Ralf
Hi,
das
set Bad_Justus getConfig
hat ohne Probleme funktioniert? Und der Fehler ist immer noch der gleiche?
Welches Kommando schickst du ab und kannst du die Daten des climate-channels einmal posten?
Gruss
Martin