Temperatur-Scanner für MAX-Thermostate

[Risiko]

Hallo John,

könntest du bitte die Logausgaben kontrollieren. Scheinbar wird in MaxScanner_Log nicht der hash vom Scanner sondern vom Device übergeben.
Das Ändern des Loglevels im Scanner hat keine Auswirkung.

Danke.

[John]

Das ist durchaus gewollt so.

Nur übergeordnete Logs werden dem Scanner-Modul zugeordnet. Logausgaben die zu den Thermostaten gehören, werden über dessen Verbose-Level gesteuert.

Das kann sonst sehr viel werden.

John

[Risiko]

Ok. Danke für die Erläuterung.
Die Aktion die zum Log führt wird doch aber vom Scanner durchgeführt\ausgelöst.
Das ist wohl wieder Ansichtssache.

[Risiko]

Hatte heute den Fall, dass trotz geöffnetem Shutterkontakt zurück auf Temperatur laut Wochenprofil gestellt wurde nicht die Window-Open-Temperatur gehalten wurde.
Habe leider keine Logausgaben.  Habe Loglevel jetzt wieder verstellt um da beim nächsten mal was Zuliefern zu können.

[Jackson]

Hallo John,

ich habe jetzt mal das Modul ausprobiert (MAX - CUBE). Und es läuft tadellos.... Die Administrierung vom Scanner war auch schnell klar (-> steht ja im Wiki). Auch sehr schön sind die einzelnen Log-Levels und die variable ScanZeit. Da sieht man die Mühe am Modul. Respekt!! 

Mir ist aber aufgefallen, dass du anscheinend nur die Temperaturen aus dem hinterlegten Wochenprogramm nimmst (Mode AUTO). Somit werden die Temperaturen, die manuell am Thermostat wieder einstellt überschrieben. Hab das richtig gesehen (hab da in dein Modul gelinst )? Oder muss ich hier nur die ScanZeit hochschrauben um nicht im 3 min - Fenster zulanden?

Gruss

[John]

Hallo Jackson,
besten Dank für deien Rückmeldung. Als Anfänger (1. Beitrag im Forum)  bringst du schon eine Menge Expertise mit.

Was der Scanner hier macht, war vom  Hersteller nie angedacht.
Daraus ergeben sich einige Probleme, die sich kaum lösen lassen.

Somit werden die Temperaturen, die manuell am Thermostat wieder einstellt überschrieben

Genau das versucht der Scanner zu erkennen, wenn es ihm gelingt.
Er verwaltet hierzu einen Führungssollwert, der zunächst vom Wochenprogramm abgeleitet wird.
Ändert sich der Sollwert vor dem nächsten Schaltpunkt des Wochenprogramms, so geht der Scanner davon aus, daß der Sollwert
von Hand verändert wurde. Es erscheint der Log-Eintrag. "change leadDesiTemp due manipulation:"

Siehe auch http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner#Was_passiert.2C_wenn_der_Sollwert_am_Thermostat_manuell_verstellt_wird.3F

Nun kann aber folgendes passieren: Der Sollwert wird durch das Handrad geändert. Im ungünstigesten Fall wird diese Änderung
erst nach 3 Minuten zu FHEM gesendet. Wenn nun gleichzeitig der Trigger seitens des Scanners ansteht, wird diese den zuvor
geänderten Sollwert wieder überschreiben.

Die Wahrscheinlichkeit reduziert sich, wenn die ScanZeit höher gewählt wird.

John

[John]

Ich habe nun die Modul-Variante eingecheckt.

Änderunge zur Beta-Version
* MAXSCANNER.COMMON.EVENT wird nicht mehr benötigt, bitte löschen falls vorhanden
* Startup-Szenario nach dem Laden des Moduls wurde verbessert
* scnEnabled wird nicht mehr verwendet, statt dessen kommt das schon vorhandene Attribut  scanTemp zum Einsatz
  * nur wenn scanTemp=1, werden die zusätzlichen UserAttribute angelegt
  Bitte Attribute userattr der alten Version löschen, diese werden automatisch neu angelegt
* der Timer der Script-Version wird gelöscht, sobald die Modul-Version aktiviert wird (disable=0)
* es ist aktuell nur 1 Instanz von MaxScanner möglich

John

[Risiko]

Hallo John,

danke für die Aufnahme als "offizielles Modul".

Bei geöffnetem Kontakt kommt alle 5s eine Eintrag im Log hinzu

Code Auswählen Erweitern


<<stage 1>> no action due open window; desi-temp before window open:

Gewollt? Ggf. Loglevel hierfür herab setzen? Erschwert meiner Meinung evtl. Fehlersuche

Nachtrag:
Ist es möglich den Scanner dahingehend zu erweitern, dass er auch bei geöffnetem Kontakt arbeitet. Dann eben mit der windowOpenTemperature?

[Jackson]

Was der Scanner hier macht, war vom  Hersteller nie angedacht.
Daraus ergeben sich einige Probleme, die sich kaum lösen lassen.
Genau das versucht der Scanner zu erkennen, wenn es ihm gelingt.
Er verwaltet hierzu einen Führungssollwert, der zunächst vom Wochenprogramm abgeleitet wird.
Ändert sich der Sollwert vor dem nächsten Schaltpunkt des Wochenprogramms, so geht der Scanner davon aus, daß der Sollwert
von Hand verändert wurde. Es erscheint der Log-Eintrag. "change leadDesiTemp due manipulation:"

Siehe auch http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner#Was_passiert.2C_wenn_der_Sollwert_am_Thermostat_manuell_verstellt_wird.3F

Nun kann aber folgendes passieren: Der Sollwert wird durch das Handrad geändert. Im ungünstigesten Fall wird diese Änderung
erst nach 3 Minuten zu FHEM gesendet. Wenn nun gleichzeitig der Trigger seitens des Scanners ansteht, wird diese den zuvor
geänderten Sollwert wieder überschreiben.

Die Wahrscheinlichkeit reduziert sich, wenn die ScanZeit höher gewählt wird.

John

Ok... dann habe ich es verstanden.

Allerdings muss der Scanner nicht bei geöffneten Fenster andauert die log message absetzen. Könnte man diese nicht unterdrücken nach dem 3 mal oder so..., da sonst der log zu gemüllt wird.

Code Auswählen Erweitern

<<stage 1>> no action due open window; desi-temp before window open:

@Risiko

Das der Fensterkontakt vom Scanner nicht betrachtet wird, ist gewollt. Man findet auch im diesem Thread die Geschichte dazu, glaube ich ...  Du kannst es aber auch im Wiki finden.

http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner#Ber.C3.BCcksichtigt_der_Scanner_die_Temperatur-Sturz-Erkennung.3F

Wenn du auch weiter im Forum für MAX schaust, findest du auch eine Scannerlösung die die Fenstertemperatur ignoriert und weiter scannt. Ist letzlich aber Geschmackssache

[Risiko]

Verstehe ehrlich gesagt die Begründung im Wiki nicht.
Natürlich ist es Geschmackssache. Wäre nur supi, wenn man es am Scanner optional umstellen könnte.

[John]

Bei geöffnetem Kontakt kommt alle 5s eine Eintrag im Log hinzu
Code: <<stage 1>> no action due open window; desi-temp before window open:
Gewollt? Ggf. Loglevel hierfür herab setzen? Erschwert meiner Meinung evtl. Fehlersuche

Gefixt und engecheckt.

John

[John]

Das der Fensterkontakt vom Scanner nicht betrachtet wird, ist gewollt. Man findet auch im diesem Thread die Geschichte dazu, glaube ich .

Verstehe ehrlich gesagt die Begründung im Wiki nicht.
Natürlich ist es Geschmackssache. Wäre nur supi, wenn man es am Scanner optional umstellen könnte.

Ich werde das sicher nicht brauchen und habe dafür auch keine Zeit mehr übrig.

Aber man kann mir jederzeit funktionierende und getestet Patches zukommen lassen.

John

[dieda]

Hallo in der Runde,

klasse Modul. Doch leider habe ich eine Fehlermeldung in meinem Log und weiß nicht, wie ich diese in Griff bekommen kann.

MaxScanner Scanner Find.433 missing basic property for device: 0231a6

Das sieht für mich wie ein Geister Fensterkontakt aus. Wie bekomme ich den raus?

[tobby]

Hi

Wenn ich meine Fensterkontakte in der Config angebe, bekomme ich folgendes

2016.01.13 00:30:10 3: MAX_Kueche_Heizung: unknown attribute scnShutterList. Type 'attr MAX_Kueche_Heizung ?' for a detailed list.

scanTemp wird dagegen "geschluckt"...

[John]

@Dieda
ein "list <name deines Thermostats>" sollte nachfolgende Eigenschaften liefern

Internals:
   CULMAX0_MSGCNT 388
   CULMAX0_TIME 2016-01-13 08:00:26
   DEF        HeatingThermostat 063cce
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     388
   NAME       HT.JOHN
   NR         171
   RSSI       -66
   STATE      19.0 °C
   TYPE       MAX
   addr       063cce
   backend    CULMAX0
   dstsetting 1
   mode       0
   rferror    0
   type       HeatingThermostat

eine der markierten Eigenschaften fehlt bei deinem Thermostat.


John