Temperatur-Scanner für MAX-Thermostate

Begonnen von John, 12 März 2013, 09:44:59

Vorheriges Thema - Nächstes Thema

Harald

#630
Habe mir soeben die neue Firm/Software 1.4.2 von eQ-3 installiert in der Hoffnung, dass nun endlich auch die Isttemperatur zyklisch aktualisiert wird. Das ist leider nicht der Fall. Also benötigen wir weiterhin John's tolles Modul nicht nur für CUL- sondern auch für Cube-Systeme, wenn man eine brauchbaren Verlauf der Isttemperaturkurven haben möchte.

Wie ich schon Mal geschrieben habe, würde ich gerne bei den Tests des Moduls beim Einsatz eines Cubes mitwirken, aber leider reichen meine Kenntnisse und Fähigkeiten nicht aus, einen der beiden noch offenen Punkte zu betreuen.

Wäre schön, wenn sich dafür jemand bereit erklären würde, damit der MaxScanner weiter entwickelt werden kann.

Viele Güße und schönes Wochenende

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

der-Lolo

Hallo John,
nach der heutigen Änderung im Zusammenhang mit unsaved siehe "Wunschliste" ergibt sich nach FHEM neustart eine unschöne Kleinigkeit - nach dem neustart wird MAXSCAN.SHUTTER.EVENT angezeigt.

ZitatLast 10 structural changes:
  delete MAXSCAN.SHUTTER.EVENT
  define MAXSCAN.SHUTTER.EVENT notify (sc_Buero|s...
Hast Du eine Idee wie man das verhindern kann?

Mr.Heat

Hallo,
Bug gefunden!

habe testweise den Thermostat auf Manuell,"on" gehabt, da ich andere entlüftungsventile montiert habe und Wasser durch den Heizkörper wollte. Fazit: MaxScanner erkennt das, und stellt im Nächsten Moment  folgendes ein:

2015.01.27 18:44:45 1: PERL WARNING: Argument "on" isn't numeric in numeric ne (!=) at ./FHEM/99_UtilsMaxScan.pm line 612.
2015.01.27 18:44:45 3: MAX MA_Thermostat_Fenster: MaxScanRun.615 change leadDesiTemp due manipulation:on
2015.01.27 18:49:55 3: MAX MA_Thermostat_Fenster: MaxScanRun.753 <<set MA_Thermostat_Fenster desiredTemperature auto 0.5>>




-> Effekt: Thermostat geht auf 17°C.

Harald

#633
Hallo John,

schade dass sich niemand findet, die beiden noch offenen Aufgaben zu übernehmen. Deshalb habe ich mich mal intensiver mit der Funktion von MAXLAN und dem Scanner auseinander gesetzt.

Folgende Gegebenheiten liegen bei mir vor:

99_UtilsMaxScanner.pm  V 1.05c
MAXLAN Pollinterval 180 Sekunden
1 MAX-Cube
7 MAX-Heizkörperventile mit return "1"
5 mit scantemp 1, weil
3 im Wohnzimmer in einer Gruppe
1 ECO-Taster

Ich habe beobachtet, dass beim MAXLAN Polling die Readings nur einmal ins Gerätelog geschrieben werden. Wenn aber der Scanner den nächsten Scan startet, wird das Script mehrfach durchlaufen. Dabei werden jedesmal Readings in die Logs geschrieben und auch die DutyCycles bei jedem Durchgang erhöht.
Habe ich vielleicht irgend etwas falsch gemacht?

Ich würde mich freuen, wenn der MaxScanner weiter entwickelt würde und dabei auch besser auf die Gegebenheiten bei der Zusammnarbeit mit MAXLAN/Cube abgestimmt werden könnte.

Einen Auszug aus den verschiedenen Logs hänge ich als Datei an.

Viele Grüße und schönen Sonntag noch

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

Mr.Heat

Zitat von: Mr.Heat am 27 Januar 2015, 18:54:26
Hallo,
Bug gefunden!

habe testweise den Thermostat auf Manuell,"on" gehabt, da ich andere entlüftungsventile montiert habe und Wasser durch den Heizkörper wollte. Fazit: MaxScanner erkennt das, und stellt im Nächsten Moment  folgendes ein:

2015.01.27 18:44:45 1: PERL WARNING: Argument "on" isn't numeric in numeric ne (!=) at ./FHEM/99_UtilsMaxScan.pm line 612.
2015.01.27 18:44:45 3: MAX MA_Thermostat_Fenster: MaxScanRun.615 change leadDesiTemp due manipulation:on
2015.01.27 18:49:55 3: MAX MA_Thermostat_Fenster: MaxScanRun.753 <<set MA_Thermostat_Fenster desiredTemperature auto 0.5>>




-> Effekt: Thermostat geht auf 17°C.

Diesen Bug bitte nicht vergessen und fixen....


und noch zweiter Bug:

der Thermostat wird am Rädchen verstellt. Alles gut. Thermostat steht immernoch auf Auto. Nun fhem.cfg geänder (warum auch immer) und die Config wird neu eingelesen (Editiert über Webinterface).
-> Effekt: offensichtlich stellt der MaxScanner beim ersten Durchlauf den Thermostaten wieder auf die Temperatur des Wochenprofils um, ohne die manuell geänderte Solltemperatur zu beachten!

Beides nicht besonders schlimme Bugs, und wahrscheinlich schnell zu beheben...

Mr.Heat

#635
und noch ein dritter Bug... Fenster geöffnet (mit Fensterkontakt). Dann kommt ein Schaltpunkt im Wochenprogramm.
Fenster wird geschlossen -> Max Scanner setzt absichtlich die vorige Temperatur!
015.02.05 22:57:54 3: MAX MA_Thermostat_Fenster: MaxScanRun.643 no action due open window; desi-temp by HC before/while window open:20.5
2015.02.05 23:00:46 3: MAX BA_Thermostat_Fenster: MaxScanRun.590 reset leadDesiTemp:10.0
2015.02.05 23:00:46 3: MAX KU_Thermostat_Fenster: MaxScanRun.590 reset leadDesiTemp:16.0
2015.02.05 23:00:46 3: MAX MA_Thermostat_Fenster: MaxScanRun.590 reset leadDesiTemp:16.0
2015.02.05 23:00:51 3: MAX MA_Thermostat_Fenster: MaxScanRun.615 change leadDesiTemp due manipulation:12.0
2015.02.05 23:02:29 3: MAX MA_Thermostat_Fenster: MaxScanRun.615 change leadDesiTemp due manipulation:17.0
2015.02.05 23:02:29 3: MAX MA_Thermostat_Fenster: MaxScanRun.654 strMode:auto EcoTemp:17.0 DesiTemp:17.0 TempBeforeWindOpen:20.5
2015.02.05 23:02:29 3: MAX MA_Thermostat_Fenster: MaxScanRun.665 due window is closed: set MA_Thermostat_Fenster desiredTemperature 20.5


nicht nur das, es wird auch noch im manuellen Modus gesetzt (s. letzte log-zeile).... nicht sehr schön. Hätte ich es nicht gemerkt, wäre damit dauerhaft 20,5 °C.


willyk

Hallo John,

manchmal habe ich auch Probleme mit dem Scanner. Heute hat er sich wieder verschluckt, ich konnte es erstmals auch richtig schön lokalisieren.

Das folgende Profil ist im HT gespeichert (die interessanten Stellen sind rot):

weekprofile-6-Fri-temp   19.0 °C / 21.0 °C / 22.0 °C / 19.0 °C / 17.5 °C                         2015-01-05 22:59:46
weekprofile-6-Fri-time   00:00-05:30 / 05:30-05:45 / 05:45-22:00 / 22:00-23:55 / 23:55-00:00     2015-01-05 22:59:46


Im Logfile ist folgendes zu lesen:


2015.02.06 05:30:45 3: MAX EG_Eingang_H: MaxScanRun.753 <<set EG_Eingang_H desiredTemperature auto 17.0>>
2015.02.06 05:30:45 3: MAX OG_Buegelz_H: MaxScanRun.590 reset leadDesiTemp:21.0
2015.02.06 05:30:45 3: MAX OG_Buegelz_H: MaxScanRun.597 switchTime: set OG_Buegelz_H desiredTemperature auto
2015.02.06 05:30:45 3: MAX UG_Treppenh_H: MaxScanRun.590 reset leadDesiTemp:21.0
2015.02.06 05:34:57 3: MAX UG_Sauna_H: MaxScanRun.753 <<set UG_Sauna_H desiredTemperature  18.0>>
2015.02.06 05:35:36 3: MAX UG_Hobby_H: MaxScanRun.753 <<set UG_Hobby_H desiredTemperature  18.0>>
2015.02.06 05:41:39 3: MAX UG_Gast_H: MaxScanRun.753 <<set UG_Gast_H desiredTemperature auto 18.0>>
2015.02.06 05:42:50 3: MAX EG_Spielz_H: MaxScanRun.753 <<set EG_Spielz_H desiredTemperature auto 18.0>>
2015.02.06 05:45:29 3: MAX UG_Treppenh_H: MaxScanRun.590 reset leadDesiTemp:22.0
2015.02.06 05:46:46 3: MAX UG_Treppenh_H: MaxScanRun.615 change leadDesiTemp due manipulation:21.0

2015.02.06 05:46:46 3: MAX UG_Treppenh_H: MaxScanRun.753 <<set UG_Treppenh_H desiredTemperature  21.0>>
2015.02.06 05:46:51 3: MAX EG_Eingang_H: MaxScanRun.753 <<set EG_Eingang_H desiredTemperature  17.0>>


Und nein, um 05:46 habe ich nichts an dem HT gefummelt. Dazu war ich viel zu müde  :)

Vielleicht hilft das, das Problem ein wenig einzugrenzen?

Für Tests oder weitere Infos stehe ich gerne zur Verfügung.

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

John

Hi Mr.Heat,
du bist ja ein echter BUG-Hunter.

Wenn du eine Patch für mich hast spiele ich ihn gerne ein.
John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Mr.Heat

#638
Zitat von: John am 06 Februar 2015, 11:52:19
Hi Mr.Heat,
du bist ja ein echter BUG-Hunter.

Wenn du eine Patch für mich hast spiele ich ihn gerne ein.
John

Kein Patch (habe das mit SVn nicht eingerichtet hier... sorry) aber zumindest eine angepasst Version, ausgehend von 1.05c; schau dir die Änderungen mit diff am Besten nochmal an.
Habe es nicht ausgiebig getestet, das müsste noch geschehen. Es läuft so jetzt aber erstmal bei mir. Folgendes geändert:

ÄNDERUNGEN seit 1.05c:
- die drei von mir genannten Bugs:
-beim Setzen der Temperatur nach Fenster schließen wird der aktuelle Modus nicht geändert
-Wenn das Wochenprofil die Temperatur ändert, wird auch sofort TempBeforeWindowOpen geändert
-wenn desiredTemperature on oder off ist, wird der Thermostat übersprungen

zusätzlich:

wenn der Modus Temperaturumschaltung ist (keepAuto=1), so FUNKTIONIERT DER MANUELLE MODUS IMMERNOCH! der Scanner wechselt nicht mehr zu Automatisch, sondern behält die Manuelle Temperatur und den manuellen Modus bei. Damit kann man den Modus Manuell wieder wie gedacht benutzen!

Have Fun.

EDIT: Es gibt ein  Problem: wenn manueller Modus, dann funktioniert es nicht, da er jedes mal denkt,  die Temperatur wurde verändert... das hat irgend was mit dem Offset zu tun... leider verstehe ich das gerade nicht ganz. Wieso wird bei onlyAuto=1 das Offset mit DesiredTemp-Wochenprofiltemperatur initialisiert statt mit 0??

John

Hallo Mr.Heat,

du hast ein gutes Verständnis für den Code.

Kann ich dich Co-Entwickler für die neue Modul-Version gewinnen ?

Da du nicht wie ich mit Linux arbeitest, habe ich alle Umlaute ersetzt (ö=oe.. ),
damit der Diff in Zukunft einfacher wird.

Die Bug-Fixes habe ich alle übernommen, jedoch nicht den zusätzlichen Punkt mit KeepAuto.

Damit haben wir die neuen version  V1.05d.


1. Bug (comitted, checked)
wenn desiredTemperature on oder off ist, wird der Thermostat übersprungen.

2. Bug (comitted, not checked)
Wenn das Wochenprofil die Temperatur ändert, wird auch sofort TempBeforeWindowOpen geändert

3. Bug (comitted, not checked)
beim Setzen der Temperatur nach Fenster schließen wird der aktuelle Modus nicht geändert


Vielleicht können andere User den Fix von Bug 2 und Bug 3 überprüfen.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Mr.Heat

Hallo john,
ich weiß nicht, ob ich dafür die Zeit finde. Aber ich werde gerne mal die ein-oder andere Änderung vorschlagen, wenn es sich anbietet.
Es wäre schön, den manuellen Modus weiterhin benutzen zu können, z.B. für einen Urlaubsmodus o.Ä., zumindest wenn keepAuto=1.
Eigentlich dachte ich, der Modus darf dann einfach nicht mehr geändert werden vom Skript, und die Umstellung durch Wochenprofil wird übersprungen.
Leider hat das ja nicht funktioniert, da der Scanner dann aus irgend einem Grund bei jedem Durchlauf gedacht hat, die Temperatur wäre neu (leadDesiTemp change)...
ich glaube das hat mit dem Offset zu tun, aber ich habe den Sinn  noch nicht ganz erfasst; das Offset enthält doch einfach nur die 0,5°C Verschiebung, oder? Wieso wird es mit der Differenz zum Wochenprofil initialisiert, anstatt einfach mit 0?

LG

Zitat von: John am 08 Februar 2015, 11:45:22
Hallo Mr.Heat,

du hast ein gutes Verständnis für den Code.

Kann ich dich Co-Entwickler für die neue Modul-Version gewinnen ?

Da du nicht wie ich mit Linux arbeitest, habe ich alle Umlaute ersetzt (ö=oe.. ),
damit der Diff in Zukunft einfacher wird.

Die Bug-Fixes habe ich alle übernommen, jedoch nicht den zusätzlichen Punkt mit KeepAuto.

Damit haben wir die neuen version  V1.05d.


1. Bug (comitted, checked)
wenn desiredTemperature on oder off ist, wird der Thermostat übersprungen.

2. Bug (comitted, not checked)
Wenn das Wochenprofil die Temperatur ändert, wird auch sofort TempBeforeWindowOpen geändert

3. Bug (comitted, not checked)
beim Setzen der Temperatur nach Fenster schließen wird der aktuelle Modus nicht geändert


Vielleicht können andere User den Fix von Bug 2 und Bug 3 überprüfen.

John

chapelhill

Hi all.

I am trying to get this working but struggling;
Using latest FHEM 5.6

I have copied latest version of file 99_UtilsMaxScan.pm version 1.05d into FHEM along with other utils files and saved.

I have added two lines to one of my radiator thermostats in fhem.cfg as folllows:

define MAX_1042d1 MAX HeatingThermostatPlus 1042d1
attr MAX_1042d1 IODev Mainrooms
attr MAX_1042d1 alias DiningSunnyRadiator
attr MAX_1042d1 event-on-change-reading .*
attr MAX_1042d1 room Dining
attr MAX_1042d1 scanTemp 1                                                      #########1st line added
attr MAX_1042d1 userReadings onlyAutoMode { return "1";;}    #########2nd line added
define FileLog_MAX_1042d1 FileLog ./log/MAX_1042d1-%Y.log MAX_1042d1
attr FileLog_MAX_1042d1 logtype text
attr FileLog_MAX_1042d1 room Dining
#### v2 graphing   Diningroom MAX_1042d1 Plot
define wl_MAX_1042d1 SVG FileLog_MAX_1042d1:my_max_temp_DR_SunRad:CURRENT
attr wl_MAX_1042d1 label "DinningRadiator Temperature Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr wl_MAX_1042d1 room Dining,RadiatorPlots
attr wl_MAX_1042d1 title "DiningRadiatorSunny temperature Min $data{min1}, Max $data{max1}, Last $data{currval1}, Curr $data{currval2}°C, Valve $data{currval3}%"


How can I tell if it is working, cannot seem to find any log file generated?
Do we have to specify a logfile. if so where?
Do we have to specify a timer interval?

I presume we need to specify this for each radiator thermostat that does not have a separate room thermostat.

I have two problems,
1. in the UK the thermostat is installed vertically which seems to interfere with getting a free air temperature(More like radiator temperature). I have two which have been installed horizontally and seem to have much more accurate air temperature. I plan to get the rest of my radiator valves switched to install others horizontally.
2. I use Heating control for one of the Max 240v switches based from demand (either total or any individual radiator above a threshhold), but some of the demand readings are too old to be used, I would like to use this module to reduce the maximum age for readings.

Many thanks in anticipation
Regards
Chapelhill

John

Hi chapelhill,

because there is no english documentation, it is certainly difficult for you to install the scanner.

Here are some comments.

attr MAX_1042d1 eve[quote][/quote]nt-on-change-reading .*

This is ok, but I propose the following additional

attr MAX_1042d1 event-min-interval temperature:0,.*:3600

ZitatI have copied latest version of file 99_UtilsMaxScan.pm version 1.05d into FHEM along with other utils files and saved.
Then a reboot of FHEM is necessary.

ZitatDo we have to specify a logfile. if so where?
No. Everything will be logged to then FHEM-Logfile, which you can see after a Click to the Item "Logfile" at the left
Menu of FHEM.

The amount of logging-Infos can be set by the verbose attribute.
attr MAX_1042d1 verbose 5

ZitatI presume we need to specify this for each radiator thermostat that does not have a separate room thermostat.
Right.

ZitatDo we have to specify a timer interval?
No, it is automatically calculated

Zitat
1. in the UK the thermostat is installed vertically which seems to interfere with getting a free air temperature(More like radiator temperature). I have two which have been installed horizontally and seem to have much more accurate air temperature. I plan to get the rest of my radiator valves switched to install others horizontally.
It is possible to adjust the reading "temperature" by following command:
set  MAX_1042d1 measurementOffset 1.0
Adjust the offset as needed. The offset will be uploaded to the thermostat.

Zitat2. I use Heating control for one of the Max 240v switches based from demand (either total or any individual radiator above a threshhold),but some of the demand readings are too old to be used,
I would like to use this module to reduce the maximum age for readings.
That's a good plan.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

chapelhill

Hi all.
many thanks for the reply, error was that I had managed to save " 99_UtilsMaxScan.pm" with a space in front of the name when creating the file using FHEM web interface. The we interface reported this as an error indicating I thought that it was not going to save it, so I saved it correctly. On using linux commands to list the files I could see both versions there, deleting the one with the space in front of the name cured the issue.

All working now.
I have 20 radiators, but when working at home I only have a couple switched on , so my heating control has to use the highest value of any individual valve setting as an additional control. I have to (total demand > 140 or any individual valve above 25) for on and (Total demnand <100  and max valve < 17 ) for off. I have not rally tuned these numbers, just taken initial guess, but they seem to be working ok for my set up.

Issue was that these devices are also trying to save battery, the valves could be left in the above 17% range for quite some time without heating control system being aware room was not really requiring any heat.

if maxscan is working you will get entries in the main log file like the following (Any lines with ip addresses deleted):

2015.02.23 08:36:06 3: Mainrooms device opened
2015.02.23 08:36:11 3: MAX MAX_104533: MaxScanRun.764 <<set MAX_104533 desiredTemperature auto 15>>

2015.02.23 08:36:14 3: Mainrooms device opened

2015.02.23 08:36:19 3: Otherrooms device opened

2015.02.23 08:36:29 3: Mainrooms device opened
2015.02.23 08:36:34 3: MAX MAX_10442a: MaxScanRun.764 <<set MAX_10442a desiredTemperature auto 14.5>>

2015.02.23 08:36:37 3: Mainrooms device opened

2015.02.23 08:36:47 3: Mainrooms device opened
2015.02.23 08:36:52 3: Heating UNCHANGED: on, Valves: 4 16 0 0 0 0 9 0 73 0 0 0 0 0 0 0 0 9 0 0, Total: 111, ThresholdON: 140, MaxRad: 73
2015.02.23 08:36:52 3: MAX MAX_104728: MaxScanRun.764 <<set MAX_104728 desiredTemperature auto 15>>



Not quite sure why scantemp will not work with  keepAuto=1 in device configuration, but I presume it replaces it with its own version of necessity.

Will keep reading, experimenting and developing.

Many thanks

John

Hi chapelhill

ZitatNot quite sure why scantemp will not work with  keepAuto=1 in device configuration, but I presume it replaces it with its own version of necessity.
You are right.
This is a bug in conjunction with onlyAutoMode=1.
Using this mode an active keepAuto=1 should be allowed.

This will be corrected for the next release.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP