Temperatur-Scanner für MAX-Thermostate

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

Vorheriges Thema - Nächstes Thema

John

NEU:WIKI-Link  http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner

Der Scanner ermöglicht die kontinuierliche Aufzeichnung von Temperatur und Ventilposition eines MAX-Thermostats.

Seit dem 10.01.2016 liegt die Funktionalität als Modul vor (98_MaxScanner.pm)



Support-Anfragen zum Scanner:
Um häufige Nachragen zu vermeiden bitte folgendes berücksichtigen:

       
  • Signatur des eigenen Accounts pflegen, damit Grundinformationen zu deinem System bekannt sind
  • Wenn möglich, Auszug aus Log-Datei mit dem Fehlerbild einreichen
  • Immer ein "list <name deines Problem-Thermostats>" einreichen

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Niko

Hallo John,

zunächst erst einmal vielen Dank an Dich und auch an Jurij für die Möglichkeit den Max-Thermostaten doch noch eine vernünftige Temperatur Anzeige zu entlocken!

Eine Frage und eine Meldung von meiner Seite.

Ich nutze die Max-Komponenten mit dem Max-Cube. Funktioniert das Script auch mit dem Cube? In dem Script schreibst Du nur etwas vom CUL und ich bin mir daher hier nicht sicher.

Weiterhin betreibe ich FHEM auf einer Fritzbox 7390. Hier bekomme ich beim Laden im Log die Meldung:

Error:Modul 99_MaxScan deactivated: Can't locate Date/Parse.pm ...
BEGIN failed--compilation aborted at ./FHEM/99_MaxScan.pm line 9

In der Line 9 im Script steht "use Date::Parse;"

Anscheinend gibt es dieses Modul auf der / meiner Fritzbox nicht.

Aber auch wenn es bei mir mit Cube und Fritzbox ggf. nicht funktioniert, trotzdem nochmals vielen Dank für Deinen Einstz.

Viele Grüße
Niko


John

Hallo Niko,

ich selbst verwende einen CUL und habe keinerlei Erfahrung mit CUBEs.

Im Thread von Jurij

Link

wurde dieses Thema angesprochen, ebenso wie die Problematik mit der Fritz-Box.

Vielleicht hilft das weiter.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

langerhannes

Hallo Niko,

ich habe zwar auch nur einen CUL, aber Deine Fehlermeldung


Error:Modul 99_MaxScan deactivated: Can't locate Date/Parse.pm ...
BEGIN failed--compilation aborted at ./FHEM/99_MaxScan.pm line 9

habe ich auch!


Lösung:

use Date::Parse;   durch   use DateTime;   ersetzen!

Allerdings kommt hiernach gleich die nächste Meldung:

..MaxScan  =======  Thermostates defined:1 valid:1 UpdateInterval:15 vUpdateIval:15
Undefined subroutine &main::str2time called at ./FHEM/99_MaxScan.pm line 99.

in Zeile 99 steht:"my $ncurtime = str2time($curTime);"

Damit kann ich leider auch nichts anfangen! Vielleicht kann Jurij oder John dabei helfen!

Gruß

LH

FHEM CUL FS20 auf Fritz 7390

MAX Thermostat und Fensterkontakt
Alarmanlage mit MAX Fensterkontakten

Reinerlein

Hallo langerhannes,

allgemein ist es keine gute Idee, solche "use"-Anweisungen zu verändern. Die haben meistens (wenn sie nicht beim Aufräumen übersehen worden) ihren Sinn :-)

In deinem Fall ist die Subroutine "str2time" in dem Paket definiert, welches per "use" eingebunden werden sollte.

Hier ist also die Lösung, das Paket über die üblichen Wege nachzuinstallieren (z.B. per CPAN oder Debian Paketverwaltung)

Grüße Reinerlein

Niko

Hallo,

vielen Dank für die Hinweise. Sie haben mir betreff der Zeit (Date::Parse) weitergeholfen.

Mit einem Cube scheint es allerdings nicht zu gehen. Der Cube übermittelt keine Credits. Man müsste also aus dem Script alles mit Credits entfernen. Da dies aber ein Hauptvorteil des Scrpits ist macht es dann eigentlich auch keinen Sinn mehr.

Betreff der Zeit und der Fritzbox gab in in dem Thread von Jurij eine Lösung, allerdings nicht für "Date::Parse". Nach einiger Internetrecherche bin ich auf eine Lösung (?) gestoßen, die bei mir funktioniert hat. Ob dies bei anderen auch so ist kann ich nicht sagen und ist ggf. auch vom System und von den Systemeinstellungen für Datum/Zeit abhängig.

Ich habe folgendes gemacht:

1) Den Eintrag "use Date::Parse;" auskommentiert.

2) An den drei Stellen im Script wo auf die Funktion "str2time" von "Date::Parse" zugegriffen wird habe ich diesen Aufruf durch

"Time::Piece->strptime($curTime, '%a %b %d %T %Y')->epoch" (Zeile 100) bzw.
"Time::Piece->strptime($th_lastTX, '%Y-%m-%d %H:%M:%S')->epoch" (Zeile 101 u. 110) ersetzt.

In den ' ' steht das Format des übergebenen Datums-/Zeit-Eintrags. Dies könnte nach meinem Verständnis auf einem anderen System anders sein.

Es gibt sicherlich bessere Lösungen aber ich dachte, ich wollte Euch zumindest mitteilen wie weit ich gekommen bin.

Viele Grüße
Niko

c-o-m-m-a-n-d-e-r

Moin Moin,
hab den Scanner inkl den Anpassungen von Niko am laufen.

Funktioniert soweit super, allerdings passt sich meine Ventilstellung nicht mit an.
Hab ich irgendwas vergessen?

Soll und Ist Wert werden fein angezeigt ...

Vor dem Einbau des Scanners hat er die Kurve richtig angezeigt...
Ich glaube aber das das Ventil nur bei Änderung der Temperatur übergeben wird oder?

Danke für das tolle Skript.


//EDIT : Jetzt kommt auch der korrekte Plot des Ventils.... also alles gut!

John

Hallo c-o-m-m-a-n-d-e-r ,

vielen Dank für die Rückmeldung.

Es freut mich, wenn das Skript für dich nützlich ist.

Hast du FHEM auf der Fritzbox laufen ?

Wenn ja, dann würde ich dich gerne als Beta-Tester für die nächste Version vormerken,
da bei mir FHEM am Raspberry Pi läuft.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

c-o-m-m-a-n-d-e-r

Moin Moin,
ja habs auf einer 7390 am laufen ... darfst mich gern als Betatester vormerken.
Geb einfach bescheid :-)


John

Hallo Matthias,

ist es möglich in 10_MAX.pm das Attribut "scanTemp" zuzulassen ?

Dann könnte man direkt bei der Thermostat-Definition den Temperatur-Scanner freischalten.



  $hash->{AttrList}  = "IODev do_not_notify:1,0 ignore:0,1 dummy:0,1 " .
                       "showtime:1,0 loglevel:0,1,2,3,4,5,6 keepAuto scanTemp:0,1". #john



John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Zwer2k

Hallo John,

das mit den Credits, Round-Robin und auch Aufnahme von scanTemp-Attribut bzw. des kompletten Skripts ins Repository hört sich super an.
So wie ich es verstehe, passt du dein Script an Heating_Control an und hebelst damit das interne Wochenprofil von den Thermostaten aus. Ist dann noch überhaupt möglich die Temperatur und Modus (auto/manuell) am Thermostat einzustellen?
Das behalten von internem Wochenprofil, und Möglichkeit weiterhin am Thermostat direkt Verstellungen vornehmen zu können, inkl. WindowOpen war nämlich mein Ziel (WAF). Des weiteren sollte der Skript auch auf einer FritzBox laufen, dazu muss bei alle FB auf Date::Parse und bei FB 7570 auch auf DateTime verzichtet werden. Das einzige was die Boxen zu verstehen scheinen ist Time::Piece->strptime .
Es wäre super wenn wir Vorteile von beiden Skripten in eins zusammen packen könnte, d.h. funktionsfähig sowohl mit Heating_Control auch auch mit internem Wochenprofil, Möglichkeit weiterhin am Thermostat direkt Verstellungen vornehmen zu können, WindowOpen, Credits, Round-Robin, Aufnahme von scanTemp-Attribut und zumindest minimale CUBE-Unterstützung (alles wird mit CUBE vermutlich nicht gehen).

John

Hallo Jurij,

Deine Idee die eigentliche ungenutzte Temperatur im Thermostat durch Umschalten des Modes zu nutzen ist grandios.
Damit bekommen wir passable Temperaturprofile, die man gut für Auswertungen verwenden kann.
Mir ist z.B. dadurch schnell klar geworden, dass die Vorlauftemperatur des Kessels unnötig hoch ist.

Zu Deinen Anmerkungen:
ZitatSo wie ich es verstehe, passt du dein Script an Heating_Control an
Ich gehe davon aus, dass Heating_Control der "Chef" ist. Natürlich können die Nutzer manuell die Temperatur verstellen,
bis zum nächsten Schaltpunkt von Heating_Control.
Das Skript selbst weiss jedoch nichts von Heating_Control und es gibt auch keine Abhängigkeiten.

Zitathebelst damit das interne Wochenprofil von den Thermostaten aus
man muss dieses praktisch deaktivieren und alles dem Heating_Control überlassen. (wie im ersten Beitrag beschrieben)
Dafür gewinnen wir eine Verdopplung der Scan-Rate.

ZitatDas behalten von internem Wochenprofil, und Möglichkeit weiterhin am Thermostat direkt Verstellungen vornehmen zu können, inkl. WindowOpen war nämlich mein Ziel (WAF)
Solange das Heating_Control seinen Dienst tut, brauche ich das interne Wochenprofil nicht.
Als Fallback-Lösung wäre es natürlich gut, wenn das Profil des Heating-Controls im internen Profil abgebildet werden würde.

ZitatDes weiteren sollte der Skript auch auf einer FritzBox laufen, dazu muss bei alle FB auf Date::Parse und bei FB 7570 auch auf DateTime verzichtet werden. Das einzige was die Boxen zu verstehen scheinen ist Time::Piece->strptime .
Ich teste gerade die nächste Version des Skriptes, das ohne  Date::Parse und Time::Piece auskommt, sondern auf Time::HiRes basiert, das fhem.pl selbst verwendet. Somit sollte die FritzBox kein Problem mehr mit dem Skript haben.

ZitatEs wäre super wenn wir Vorteile von beiden Skripten in eins zusammen packen könnte, d.h. funktionsfähig sowohl mit Heating_Control auch auch mit internem Wochenprofil, Möglichkeit weiterhin am Thermostat direkt Verstellungen vornehmen zu können, WindowOpen, Credits, Round-Robin, Aufnahme von scanTemp-Attribut und zumindest minimale CUBE-Unterstützung (alles wird mit CUBE vermutlich nicht gehen).

Ich denke zur Zeit über eine Synchroniserung von Heating_Control und dem Thermostat-internen Wochenprofil nach.
Das wäre aus meiner Sicht eine akzeptable Fallback-Lösung sollte FHEM ausfallen. Ausserdem ist dann die Mode-Umschaltung völlig
problemlos, da beide Seiten ohnehin diesselben Sollwerte vorgeben würden.

Wenn wir vom Cube keine Credits erhalten, hat er schlechte Karten,
Das Skript sieht das Scannen der Temperatur als untergeordnete Aufgabe und lässt Luft für die übergeordneten Dinge, wie Sollwerte setzen.
Aber das hab ich ja am Ende deines Threads
Link
ausführlich erläutert.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Marcel_R

Salut John,

Ich melde mich auch als eventueller Beta-Tester für die nächste Version.

Ich habe aktuell 10 MAX Heizkörperthermostate am Laufen. Der CUL ist an einer FB7270, Firmware-Version: 54.05.23 (Austria/Schweiz Edition, d.h. ohne FHEM-Integration in die FB-FW -> FHEM auf einem USB-Stick).

Es scheint mir, dass das Aufspielen der jetzigen Version keinen grossen Sinn macht (Anzahl verfügbarer Time-Slots / 10 Thermostate ergibt keine höhere Datenrate, eventuell Zeitfunktion-Probleme wegen der FB7270). Deshalb warte ich gespannt auf die nächste Version ...

Gruss
Marcel
FHEM / Fritz!Box 7490 / CULv3 / Raspi / COC / MAX! / HomeMatic /

John

Das neue Skript läuft nun seit einigen Tagen erfolgreich auf meinem Raspberry Pi, so dass ich es guten Gewissens freigeben kann.

Ich möchte vor allem die FHEM-User mit Fritzbox bitten, das Skript zu testen und die Ergebnisse zurück zu melden.

Folgendes hat sich geändert:

Interner Timer
Ich verwende nun einen internen Timer so dass der bisherige At-Befehl in FHEM.cfg nicht mehr notwendig ist.

Kompatibel mit der Fritz-Box
Ich habe die verdächtigen Module entfernt und beschränke mich auf ein Minimum von Abhängigkeiten.
Die Datums/Zeitverarbeitung habe ich dafür komplett geändert und bin auf das serialisierte Format des HiRes Paketes gegangen.

Logging-Level hängt nun am Thermostat

Logging kann nun für jedes einzelnen Thermostat eingestellt werden.
Je kleiner der loglevel , um so gesprächiger wird das Skript.

Verbessertes Round Robin
Ich sortiere die Thermostate nach dem nächsten Abfragedatum, vorher war es schlicht die Reihenfolge der Definition,
die die Reihenfolge in der Schleife bestimmte.

Optimierte Wartezeit

Wenn dem Skript die Credits fehlen, wartet es nicht einfach nur 3 Minuten, sondern berechnet aus dem Credit-Bedarf heraus intelligent die optimale Wartezeit.
Damit reduzieren sich die Log-Einträge

Begrenzung auf 32 Thermostate
Mehr lasse ich nicht zu wegen der 32 Timeslots pro Stunde.

Neuer Parameter in der WEB-Darstellung beim Thermostat
Hier findet sich nun nach dem ersten Scan der Parameter "nextTemperatureScan". Der zeigt das an, was der Name vespricht den Zeitpunkt des nächsten geplanten Scans für das Thermostat.

Vorbereitet für die Integration in 10_MAX.pm
Wenn die Rückmeldungen positiv sind, wäre es ggf. sinnvoll das Skript direkt in 10_MAX.pm zu integrieren, so daß neue User es einfacher hätten diese Funktion zu nutzen.
Dann könnte man das schon vorbereitet Attribut "scanTemp" nutzen (derzeit auskommentiert), um über die Definition des Thermostats die Scan-Funktion freizuschalten.


Inbetriebsetzung:


Sollte der AT-Timer von der alten Version noch in FHEM.cfg vorhanden sein, dann diesen bitte löschen.
(define at_MaxScan at +*00:00:10 { MaxScan("HT_ZIMMER01 HT_ZIMMER01 HT_ZIMMER03",15 );;})

Im übrigen ist wie zuvor 99_MaxScan.pm ist in das Verzeichnis /opt/fhem/FHEM zu kopieren.

Ich freue mich auf zahlreiche Rückmeldungen.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Marcel_R

Das war ja eine extrem schnelle Antwort. Danke vielmals!

Ich habe auch sofort geschaut, ob ich einen MAX-Heizkörperthermostat zum Laufen kriege. But no such luck.

PuTTY meldet mir beim Versuch fhem zu starten:  
Undefined subroutine &main::timelocal called at ./FHEM/99_MaxScan.pm line 25.

Vermutlich habe ich bei der Inbetriebsetzung ein (oder mehrere) faulen Eier gelegt. Was ich gemacht habe:
Ich kopierte die Datei 99_MaxScan.pm in das Verzeichnis /.../fhem/FHEM.

In die Datei fhem.cfg fügte ich ein:
define HC_1_Buero Heating_Control HKT_1_Buero 07:00:19_22:00:16
ich setzte nachstehnden Befehle ab:
set HKT_1_Buero weekProfile Mon 15 Tue 15 Wed 15 Thu 15 Fri 15 Sat 15 Sun 15
shutdown

HTH
Marcel

FHEM / Fritz!Box 7490 / CULv3 / Raspi / COC / MAX! / HomeMatic /