Temperatur-Scanner für MAX-Thermostate

Harald · 01 Februar 2014, 16:13:20

Hallo John,

die Meldung "change leadDesiTemp due manipulation" habe ich bisher nicht gefunden. Allerdings ist seit heute Mittag der Fehler auch noch nicht aufgetreten, obwohl ich div. Sollwertänderungen in die Wochenprogramme eingefügt habe. Da müssen wir wohl warten, bis wieder so ein Ereignis auftaucht.

Was das Timing zwischen Cube und FHEM angeht, habe ich mir mal Gedanken gemacht.

Wenn der Scanner einem Ventil sagen will, dass der Sollwert geändert werden soll, geht der Befehl von FHEM über MAXLAN (Ethernet) an den Cube und von dort zum Ventil. Dieses hat eine best. Reaktionszeit und meldet dann dem Cube den Vollzug. Dieser übermittelt das über MAXLAN (wie wirkt sich hier der Pollintervall von MAXLAN aus?) an FHEM und somit kann erst jetzt der Scanner "wissen", dass die neue Temperatur eingestellt ist. Ist das so, oder bin ich da "on the woodway"? $:-\$

Viele Grüße

Harald

John · 01 Februar 2014, 16:50:21

ZitatDieser übermittelt das über MAXLAN (wie wirkt sich hier der Pollintervall von MAXLAN aus?) an FHEM und somit kann erst jetzt der Scanner "wissen", dass die neue Temperatur eingestellt ist

Beim CUL ist es so, dass der Sollwert an das Thermostat übertragen wird und mit der Empfangsquittierung auch der neue Sollwert praktisch sofort bestätigt wird.

Wenn sich das beim Cube anders verhält und dieser vielleicht sogar nach der Übetragung nochmal den alten Sollwert meldet, ist klar
warum wir hier ein Problem haben.

Aber lass und die Logs abwarten.
John

Harald · 02 Februar 2014, 16:50:29

Hallo John,

ich habe Jürgen I. per PN angeschrieben, da er sich mit den Eigenschaften des MAX!-Systems offensichtlich recht gut auskennt. Der hat meine Annahmen bez. des Ablaufs der Datenübertragung von FHEM nach MAX und zurück soweit bestätigt.

Heute Morgen ist wieder so ein Ereignis beim Thermostat Bad aufgetreten. Ich habe Dir mal die Logs des Ventils, des FHEM und des MAXLAN in eine Datei geschrieben und diese sowie den Screenshoot angehängt.

Ich werde Mal sehen, ob ich noch mehr Infos in die MAXLAN-Datei bringen kann. Vielleicht hilft uns das ein wenig weiter (zwar jetzt nicht aber evtl. beim nächsten Mal).

Viele Grüße

Harald
PS: Log von MAXLAN erweitern bringt außer dutycycle: xx nur noch firmware: 0.1 und testresult: 0

John · 02 Februar 2014, 19:30:09

Hallo Harald,

folgende Analyse (bitte um Korrektur, wenn meine Annahmen falsch sind)

Schaltpunkt im Wochenprogram Bad bei 06:00 Uhr (?)

Zitat
2014.02.02 05:48:48 3: [Bad] MaxScanRun.753 <<set Bad desiredTemperature auto 17.0>>

!!! hier wird das Wochenprogramm um 06:00 im Thermostat auf 21 Schalten, was gelingt, da mode auf auto steht
man erkennt dies an der grossen valveposition in den folgenden log-Einträgen

!!! scanner bügelt Änderung nieder, muss vorher auf 21 gewesen sein, sieht man an grosser valvePosition !!!

Zitat2014.02.02 06:00:01 3: [Bad] MaxScanRun.753 <<set Bad desiredTemperature 17.0>> !! das ist der Fehler
2014-02-02_06:00:11 Bad desiredTemperature: 17.0
2014-02-02_06:00:11 Bad valveposition: 87

# hier wird Fehler vom Scanner korrigiert (das ist kein Hand-Eingriff oder ?)
2014.02.02 06:05:47 3: [Bad] MaxScanRun.604 switchTime: set Bad desiredTemperature auto
2014.02.02 06:14:14 3: [Bad] MaxScanRun.753 <<set Bad desiredTemperature 21>>

Lösungs-Ansatz (liegt sehr nahe an deiner intuitiven Vermutung)

Liegt der Triggerpunkt im Bereich von +/- 60 Sekunden um einen Wochenschaltpunkt, so führt der Scanner diesen nicht aus.

John

Harald · 02 Februar 2014, 19:55:03

richtig John, um 6:00 war lt. Wochenprogramm die Zeit, zu der auf 21°C geschaltet werden sollte, was ja auch später passierte und es hat kein Handeingriff stattgefunden. So eine Korrektur wie hier habe ich bisher noch nicht gesehen. In der Vergangenheit gab es nur so etwas wie im vorherigem Diagramm Computer oder die Sollwertumschaltung fand garnicht statt.

Vermutlich könnte Dein Lösungsansatz Erfolg bringen. Vielleich muss man ein wenig mit der Karenzzeit experimentieren?

Viele Grüße und schönen Sonntag noch

Harald

Harald · 07 Februar 2014, 13:51:01

Hallo John,

ist es möglich, dass das Timingproblem Scanner/Maxgeräte mit dieser Erscheinung in Verbindung steht? Ob Matthias etwas dazu sagen kann?

Viele Grüße

Harald

John · 07 Februar 2014, 13:57:24

Hallo Harald,
mit dem CUL habe ich das Problem nicht.

Da wird man wohl eher auf der MAXLAN Seite fünding.
Offensichtlich wird beim "set desiredTemperature" das Device geöffnet.
Wieso muss es den wieder geschlossen werden ?

CUL ist dauernd offen.

John

west2107 · 12 Februar 2014, 20:12:23

Hallo,

ich habe jetzt auch mal den Scanner ausprobiert. Ich setzte den Max-Cube ein. Ich erhalte im Log:

2014.02.12 19:58:12 3: [MAX_068361] MaxScanRun.444 TYPE:MAXLAN IOName:ml
2014.02.12 19:58:12 1: [MAX_068361] MaxScanRun.488 !! READINGS:credit10ms is not defined

Ich verwende die 99_UtilsMaxScan V 1.05a. Habe bei: my $strCreditTime="" ; testweise 50 eingetragen. Ändert aber nichts.

Woran liegt es?

John · 12 Februar 2014, 20:33:15

Hallo west2107,

die Fehlermeldung ist auf den CUL abgestimmt und ist bei Cube gleichbedeutend mit dutycycle.

Ich vermute, dass das Reading dutycycle im MaxLan-Device fehlt.

Kannst du bitte ein

Code Auswählen

list <maxlan-device>
schicken.

John

west2107 · 12 Februar 2014, 20:40:06

Internals:
DEF 192.168.40.7 180 ondemand
DeviceName 192.168.40.7:62910
INTERVAL 180
NAME ml
NR 4
PARTIAL
STATE opened
TYPE MAXLAN
cubeTimeDifference 0
fwversion 0113
pairmode 0
persistent 0
rfaddr 05cf48
serial JEQ0340420
devices:
HASH(0xfcba10)
HASH(0x74d680)
HASH(0xfcb980)
HASH(0x74d788)
HASH(0x74d860)
HASH(0x74cc60)
HASH(0x74d968)
HASH(0x74ce28)
HASH(0x74cdc8)
HASH(0x74ce88)
HASH(0x74cf60)
HASH(0x74d008)
HASH(0x74d0b0)
HASH(0xfcba70)
HASH(0xfcbb18)
HASH(0xfcc700)
HASH(0xfcc7a8)
HASH(0xfd1c20)
HASH(0xfd1cc8)
groups:
HASH(0xfc8308)
HASH(0xcd7f10)
HASH(0x74d1b8)
HASH(0x74d548)
HASH(0x74d5c0)
HASH(0x74d440)
HASH(0x74d4b8)
Attributes:

Das ging ja fix!

John · 12 Februar 2014, 21:04:03

Hi west2107

der Scanner benötigt unbedingt das Reading dutycycle im Device ml, sonst bricht er ab.
Das ist eine Voraussetzung.

Ich denke das Problem hatten wir schon mal.
Such doch mal den Thread nach dutycycle ab.

Es ist definitiv kein Problem des Scanners.

John

west2107 · 12 Februar 2014, 21:11:47

Danke, das war es.
Habe die 00_MaxLan aktualisiert. dutycycle im MaxLan vorhanden.
scheint zu laufen.

Danke nochmals.

west2107 · 13 Februar 2014, 21:41:51

Hallo,

Es gibt doch noch ein Problem.
Ich hatte die 00_MAXLAN.pm v3446 2013-07-18
auf 00_MAXLAN.pm v4512 2013-12-30 geuppt.
Jetzt funkt der Scanner aber die Wochenprofile der Heizkörperthermostate (HT) werden nicht mehr korrekt ausgelesen und mit Standardprofilen befüllt.
Die Profile der Wandthermostate(WT) werden korrekt ausgelesen.
Schaltet der Scanner wieder in den Auto-Mode, wird am HT die Temp nach den Standartprofil gesetzt.
Setzte ich die v3446 wieder ein, so werden die Profile der HT korrekt eingelesen, nur die WT nicht. Für WT ist der Scanner ja auch nicht erforderlich.
Das sollte sich doch machen lassen, das von beiden Geräten die Profile korrekt gelesen werden vönnen.

Liebe Grüße aus Thüringen

John · 13 Februar 2014, 21:52:39

http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner#Was_ist_zu_tun_wenn.2C_Thermostate_zusammen_mit_einem_Wandthermostat_eingesetzt_werden_.3F

Das betrifft alle Thermostate die mit einem Wandthermostat verknüpft sind.
Spar dir hier den Scanner.

John

west2107 · 13 Februar 2014, 22:10:13

Ich habe zwei Räume in den jeweils nur ein Heizkörper mit HT ausgrüstet ist.
Hier Kommt der Scanner zum Einsatz um die Temperaturverläufe aufzuzeichenen. Alle andern Räume laufen über WT.
Mit der neuen MAXLAN kann FHEM das im HT gespeichterte Weekprofil nicht lesen und setzt das Standartprofil. Die Temperaturen und Uhrzeiten von Profil im Cube weichen vom Standardprofil stark ab. Der Scanner setzt beim Wechsel von manu auf auto die Temperatur aus dem gesetzten Standardprofil und
verändert die gewünschte Temperaturführung.
MAXLAN müsste also din dieser Beziehung auf den älteren Releasstand gebracht werden. Die liest die HT-Profile richtig ein. Dan graift auch der Scanner auf die richtigen Uhrzeiten und Temeraturen zu.