Fehler im Weekprofile

Begonnen von John, 07 Dezember 2013, 12:09:27

Vorheriges Thema - Nächstes Thema

John

Hallo Matthias,
möglicherweise gibt es ein Problem beim Anlegen der Wochenprofile.

Es ist doch richtig, dass ein
set HT.HW desiredTemperature auto
den AUTO Mode aktiviert und daraufhin das Thermostat den Sollwert aus dem Wochenprofil verwendet.

Der nachfolgend beschriebene Fehler ist gut reproduzierbar.

-------------------------------------------------------
Wir setzen das Wochenprofil so, dass wir uns im 2. Bereich von 3 Bereichen befinden. (jetzt=Samstag 11:40)

set HT.HW weekProfile Sat 16,06:00,16,11:50,16

EventMonitor:
Zitat
2013-12-07 11:42:35 MAX HT.HW weekProfile Sat 16,06:00,16,11:50,16
2013-12-07 11:42:36 MAX HT.HW mode: auto
2013-12-07 11:42:36 MAX HT.HW battery: ok
2013-12-07 11:42:36 MAX HT.HW desiredTemperature: 17.0
2013-12-07 11:42:36 MAX HT.HW valveposition: 15
2013-12-07 11:42:36 MAX HT.HW 17.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-0-Sat-time: 00:00-06:00 / 06:00-11:50 / 11:50-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-0-Sat-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-1-Sun-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-1-Sun-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-2-Mon-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-2-Mon-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-3-Tue-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-3-Tue-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-4-Wed-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-4-Wed-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-5-Thu-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-5-Thu-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-6-Fri-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-6-Fri-temp: 16.0 °C / 16.0 °C / 16.0 °C
[/font]

Ein
set HT.HW desiredTemperature auto
liefert nun im EventMonitor

Zitat
2013-12-07 11:43:42 MAX HT.HW desiredTemperature auto
2013-12-07 11:43:43 MAX HT.HW mode: auto
2013-12-07 11:43:43 MAX HT.HW battery: ok
2013-12-07 11:43:43 MAX HT.HW desiredTemperature: 16.0
2013-12-07 11:43:43 MAX HT.HW valveposition: 15
2013-12-07 11:43:43 MAX HT.HW 16.0 °C
[/font]

Dies ist korrekt
-------------------------------------------------------
Wir warten bis wir in den 3. Bereich gelangen und setzten den Befehl erneut ab. (nach 11:50 Uhr)

set HT.HW desiredTemperature auto

EventMonitor
Zitat
2013-12-07 11:53:28 MAX HT.HW desiredTemperature auto
2013-12-07 11:53:29 MAX HT.HW mode: auto
2013-12-07 11:53:29 MAX HT.HW battery: ok
2013-12-07 11:53:29 MAX HT.HW desiredTemperature: 17.0
2013-12-07 11:53:29 MAX HT.HW valveposition: 0
2013-12-07 11:53:29 MAX HT.HW 17.0 °C
[/font]

Hier wäre doch nun eigentlich wie zuvor 16 zu erwarten, aber es wird 17 gesetzt.

John

Nachtrag:
Bereich 1 und 2 funktionieren, Fehler tritt nur bei Bereich 3 auf.
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

#1
Hallo zusammen,

ich habe das gerade bei mir getestet. Auch mit Cube gibt es die gleiche Erscheinung. In der originalen MAX!-Software steht das Tagesprogramm durchgehend auf 16°C, aber nach dem programmierten Schaltpunkt steht auf der Übersichtsseite 17°C. Das Tagesprogramm bleibt bei 16°C.

Auch ein nochmaliges set desiredTemperature auto ändert nichts, es bleibt bei 17°C. Mir ist aufgefallen, dass nach dem aktivieren des normalen Tagesprogramms in den Internals STATE auf 17°C stand, obwohl desiredTemperature schon auf 20°C war. Vielleicht kommt die "falsche" Temperatur von dort?

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

John

Folgenden Workaround habe ich gefunden:

Man muss dafür sorgen, dass der letzte Bereich eines Tages möglichst kurz und am Ende des Tages ist.

Also statt
set HT.JOHN weekProfile Sat 16,09:00,19,22:00,16

nunmehr so
set HT.JOHN weekProfile Sat 16,09:00,19,22:00,16,23:55,16

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

Scheint mir also ein Problem der Firmware der Heizthermostate zu sein und kein Problem der MAX FHEM Software.
Man könnte bei set HZ desiredTemperature auto natürlich das aktuelle Wochenprofil anschauen und dann intern
den Befehl in
set HZ desiredTemperature auto aktuelleWochenProfilTemperatur
umwandeln.
Wenn mir jemand dafür einen Patch schickt, dann check ich das ein.

John

Hallo Matthias,
besten Dank für deine Antwort.

ZitatScheint mir also ein Problem der Firmware der Heizthermostate zu sein und kein Problem der MAX FHEM Software.

Das wäre ein dramatischer Fehler des Herstellers, es würde bedeuten, dass der Sollwert im letzten Bereich eines Tages stets 17 Grad ausgibt,
unabhängig von den Vorgaben des Anwenders.
Der Fehler ist zu offensichtlich, als dass ein Profi diesen beim Testen übersehen könnte.


@Harald oder andere, die mit CUBE arbeiten
Kannst du bitte, über die original Max-Software das Wochenprofil in einem Thermostat erzeugen.
Danach sobald die aktuelle Zeit im letzten Bereich des Tagesprofils liegt via
set xy desiredTemperature auto

den Sollwert aus dem Wochenprofil einstellen und das Ergebnis mitteilen.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

Hallo John,

das habe ich doch oben schon berichtet. Das ist die gleiche Erscheinung, wie Du sie beschriebst.
Falls Dir das noch nicht genügt, sage was ich noch testen soll. Mache ich natürlich gerne.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

John

Hallo Harald,

ich dachte an einen Test komplett ohne FHEM also nur mit original MAX-Software.

Wir müssen ausschliessen, dass FHEM in irgend einer Weise Einfluss nimmt.

Verstehe ich dich richtig:

a. du hast das Wochenprofil mit original MAX-Software erstellt

b. beim letzten  Schaltpunkt setzt Max den Sollwert fest auf  17 Grad,
   obwohl du einen anderen Sollwert angegeben hast.

Das alles ohne jedes Zutun von FHEM, richtig ?


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

Ja, genauso, Lediglich das "set xy desiredTemperature auto" habe ich in FHEM gemacht, da es das in der Orinalsoftware nicht gibt. Das muss man dann am Ventil machen.

ZurSicherheit werde ich das nochmal testen. Ich melde mich dann.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

pet22

#8
Hallo John,

ich verfolge den Thread nun schon eine ganze Weile.

Zitata. du hast das Wochenprofil mit original MAX-Software erstellt

b. beim letzten  Schaltpunkt setzt Max den Sollwert fest auf  17 Grad,
   obwohl du einen anderen Sollwert angegeben hast.

Das alles ohne jedes Zutun von FHEM, richtig ?

Bestätigt für WT+ und allen bisherigen Cube FWs.
Bei der Kombination HT+ (FW laut FHEM: 1.0) mit WT (FW laut FHEM: 1.6) konnte ich das Verhalten mit den magischen 17 °C nicht beobachten (evtl. auch mangels Gelegenheit).

Bisherige Abhilfe seit Einführung von weekProfile: die factory default Schaltzeiten des Cube habe ich in mein individuelles FHEM weekProfile übernommen und zusätzliche individuelle Schaltzeiten/ Temperaturen integriert.
Es verblieb ein "Loch" zwischen 22:00 - 0:00. Wurde in dieser Zeit am WT+ HT+ zwischen manuell/ auto umgestellt erschienen die magischen 17 °C wieder, obwohl ein anderer Wert im weekProfile vorgegeben wurde.

Mit deinem Workaround verbleiben somit 5 Min in denen die 17 °C auftauchen könnten. Gestern ist es mir aber nicht gelungen den Effekt zu provozieren.

Vermutung: die FW des WT+ HT+ hat ein Problem mit dem Tages-/ Datumswechsel

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

Hallo pet22,

besten Dank für deine Rückmeldung.


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

#10
So, hier meine Ergebnisse:

Tagesprogramm in MAX! 3x je 16°C, Schaltzeit 2->3 jeweils angepasst, dass die Beobachtung der Umschaltung möglich

1. FHEM gestoppt, in Der MAX!-Übersicht kontinuierliche Anzeige 16°C Auto vor und nach der Schaltzeit
2. FHEM gestartet, MaxScan gestoppt, gleiches Verhalten von MAX!, auch nach "set xy desiredTemperature auto" von der WEB-Oberfläche
3. FHEM und MaxScan in Modus Sollwertänderung gestartet, gleiches Verhalten wie unter 2.
4. FHEM und MaxScan in Modus auto/manual- Umschaltung,  gleiches Verhalten wie unter 2.

Mir ist es nicht gelungen, ein Fehlverhalten zu provozieren !?!?

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

pet22

Hallo Harald,

Zitatb. beim letzten  Schaltpunkt setzt Max den Sollwert fest auf  17 Grad,
   obwohl du einen anderen Sollwert angegeben hast.

Bei mir tritt dieser Effekt nicht genau nach dem letzten Schaltpunkt auf, sondern "irgendwann". Eine Systematik konnte ich in der bei mir konfigurierten Zeit von 2h nicht herausfinden.
Evtl. lässt auch bei dir der Effekt auch reproduzieren, wenn der WT(+) manuell auf "off" und dann nach ca. 10 min auf "auto" gestellt wird.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Harald

Tut mir leid, pet22, aber isch abe gar keinen WT!  ;) somit kann ich dazu auch nichts sagen. Meine obigen Tests sind deshalb auch alle ohne WT.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

pet22

#13
sorry - ich meinte HT+  :-[

Beitrag in der Zwischenzeit korrigiert

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

#14
Ich habe nun noch einen OFFLINE-Versuch mit meinem HT+ Thermostat durchgeführt.

FactoryReset am Thermostat.
Wochenprofile eingestellt.

Im letzten Bereich des Tages schaltet das Thermostat korrekt auf den eingestellten Sollwert.
Der beobachtet Fehler ist unter diesen Bedingungen nicht reproduzierbar.

Es ist also kein systematischer Fehler in der Firmware des Thermostats.

Der Zeitbereich eines Schaltpunktes lässt sich im 5- Minuten-Raster einstellen.

Lediglich die Endzeit des Tages lässt sich auf 23:59 einstellen.

Sobald das Thermostat angelernt wird, scheint es sein Wochenprofil auf die FactoryReset-Einstellung zurückzusetzen.
Laut FHEM Protokoll, wird hierbei vom Thermostat das Wochenprofil an FHEM übertragen.
Damit kann man leider die zuvor eingestellten Werte des Wochenprofils nicht mehr nachvollziehen.

Folgende Fragen:

Was sendet das WT an das Thermostat, wenn man dort das Wochenprofil ändert ?
Kann man dies aufzeichnen ?
Wenn ja, wie ?

Weiterhin müsste sich noch jemand finden der über die nötigen Komponenten verfügt und die Aufzeichnung zur Verfügung stellt.

John



CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP