Temperatur-Scanner für MAX-Thermostate

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

Vorheriges Thema - Nächstes Thema

fhem_f

Hallo zusammen,

ich habe auch das Problem, dass die Solltemperatur manchmal nach unten abdriftet. Eingestellt ist z.B. die Solltemp 19°. Im Diagramm ist schön zu sehen, dass schön zwischen 19° und 18,5° getoggelt wird. Dann wird auf einmal zwischen 18,5° und 18° getoggelt, dann zwischen 17,5° und 18°... Und ehe man sich's versieht, ist die Solltemperatur auf 16°. Gibt es da eine Lösung? Kann ich irgendwelche Infos zur Verfügung stellen, damit ich dem Problem auf den Grund gehen kann?
Ich muss zugeben, dass ich mich schon in das eine oder andere eingelesen habe und auch schon ein paar Anpassungen gemacht habe. Aber manches ist mir doch ein Buch mit sieben Siegeln.

Ich habe übrigens den MAX Cube und pro Zimmer ein oder zwei Thermostate mit Fensterkontakt, die verknüpft sind. Das klappt auch wunderbar.

Danke für die Hilfe!

Christian

fhem_f

Ach so, ich weiß nicht, ob das relevant ist. Ich habe in Heating Control eingestellt, dass die Temperatur eco oder comfort eingestellt werden soll, damit ich Änderungen einfach im Thermostat hinterlegen kann. Ich habe allerdings auch schon mit festen Temperaturen in Heating Control gearbeitet, das hast leider auch nicht geholfen.

Christian.

Hallo zusammen,

ich versuche - bislang erfolglos - das Modul MaxScanner zu verwenden.

Meine Umgebung: Ich habe 1 Thermostat namens thermostat_01 definiert. Es hat kein Attribut scanTemp und auch keine Attribute, die mit scn beginnen. Die Datei 99_UtilsMaxScan.pm habe ich von fhem/FHEM nach fhem/contrib verschoben.

Problem #1
Die Definition des Scanner-Moduls
define thermostat_scanner MaxScanner
ändert am Thermostat-Modul nichts, es werden keine Attribute erzeugt. Der Aufruf von get thermostat_01 associateDevices liefert no devices. Auch der Aufruf von set thermostat_scanner run hat bis auf die Log-Meldung Set.244 hits: 1 needPara: keine Auswirkung.
Im Quellcode des Moduls 1.0.0.3 sehe ich, dass bei der Definition des Scanners ein Timer entfernt wird, sonst aber nichts passiert - der restliche Code ist auskommentiert. Ist das richtig so?

Problem #2
Nach dem Aufruf von delete thermostat_scanner liefert define thermostat_scanner MaxScanner nur die Ausgabe only one scanner instance is allowed. Es scheint, als würde der Scanner durch das delete nicht komplett entfernt. Ein Neustart von FHEM ist deshalb zwingend erforderlich.

Hat jemand die aktuelle Version 1.0.0.3 ohne eigene Quellcode-Anpassungen erfolgreich im Einsatz?
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Christian.

Ich habe weitere Erkenntnisse gewonnen.

Problem #1 tritt auf, wenn man den MaxScanner erst nach abgeschlossener FHEM-Initialisierung, also innerhalb eines laufenden FHEM, anlegt. Offenbar wird der initiale Timer-Aufruf durch das INITIALIZED-Event ausgelöst, das einmalig beim Starten von FHEM auftritt. Man kann das Problem durch Angabe der MaxScanner-Definition in der fhem.cfg und einen Neustart umgehen.

Allerdings bin ich dadurch auf ein weiteres Problem gestoßen:

Problem #3
In welcher Reihenfolge müssen der MaxScanner und die Thermostate angegeben werden, damit auch die Attribute scnProcessByDesiChange und scnModeHandling gesetzt werden können?
Scheinbar prüft der MaxScanner bei jedem Aufruf, ob das Attribut userAttr der Thermostate erweitert werden muss, sofern dort scanTemp = 1 gesetzt ist. Demnach müssten die Reihenfolge sein:

  • Thermostate anlegen mit scanTemp = 1
  • MaxScanner anlegen
  • MaxScanner run aufrufen (um userAttr zu erweitern)
  • Thermostate um die Attribute scnProcessByDesiChange und scnModeHandling erweitern
Der letzte Schritt klappt bei mir aber leider nicht, weil unmittelbar nach dem Aufruf von run das Attribut userAttr noch nicht angelegt wurde. Ich behelfe mir mit einer Verzögerung:

define init_thermostat_01 at +00:00:30\
attr thermostat_01 scnProcessByDesiChange 1;;\
attr thermostat_01 scnModeHandling NOCHANGE

aber hoffe, dass es auch eleganter geht. Hat jemand eine Idee?
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Merlin123

#784
Versuch gerade den Scanner zum laufen zu bekommen.
Hab den definiert und nach einem Neustart des Raspberry steht er auf processing.
Was fehlt: Bei den Termostaten fehlen die scn* attribute, ich kann diese nicht angeben. ScanTemp gibt es. Sie erscheinen nicht im Dropdown und manuell wirft FHEM ein Fehler aus nachdem ich "attr MAX_Thermostat_Wohnzimmer_rechts scnProcessByDesiChange 1" abgesetzt habe
Ich hab alles am Max Cube hängen.

Was kann das sein?
Etwas weiter vorne wird das ja schonmal beschrieben, da ging aber wohl das manuelle anlegen
Gruß,
Oliver

ManOki

Hallo,

ich habe aktuell MAX-Thermostate, die gekoppelt (associate und scnShutterList) mit MAX-Fensterkontakten sind. Die Funktion, das die Zieltemperatur nach dem Schließen wieder auf die ursprünglich gesetzte Temperatur gestellt wird, funktioniert tadellos. Ansonsten setze ich meine Temperatur über einen Online-Kalender, welchen ich mithilfe des CALENDAR-Moduls auslese.

Nun habe ich folgendes Problem: Aktuell wird die Zieltemperatur direkt über die Thermostate gesetzt "set MAX_abcdef desiredTemperature 21.0", sobald ein Kalender-Event auftritt. Dieser Befehl ignoriert aber leider, dass das gekoppelte Fenster geöffnet ist. Die Zieltemperatur wird bei geöffneten Fenster überschrieben.

Gibt es eine Möglichkeit, bei der ich dem MaxScanner die Zieltemperatur für ein Thermostat übergebe und er sozusagen entscheidet, ob diese sofort bei bereits geschlossenem Fenster oder, sobald das Fenster geschlossen wird, gesetzt wird? Z.B. "set Scanner desiredTemperature MAX_abcdef 21.0".

Vielen Dank schonmal für dieses großartige Modul!
ManOKi

riker1

Hallo
kann das Modul nicht laden.
kennt jemand den Fehler:


2017.10.16 20:50:26.407 1: PERL WARNING: Use of uninitialized value $datestr in pattern match (m//) at ./FHEM/99_MaxScan.pm line 23.
2017.10.16 20:50:26.407 1: PERL WARNING: Use of uninitialized value $mm in subtraction (-) at ./FHEM/99_MaxScan.pm line 25.
Undefined subroutine &main::timelocal called at ./FHEM/99_MaxScan.pm line 25.

wie kann ich die Fehler wegbekommen. Damit startet Fhem nicht.

Danke

FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

bismosa

#787
Hallo zusammen,

ich nutze auch seit ein paar Tagen den Scanner. Tolles feature. Danke für die Mühe!
Auch ich hatte immer wieder das Problem, das nach einem "rereadcfg" keinen scanner mehr hatte. Ein auslagern aus der fhem.cfg in eine andere Datei (und diese dann per include hinzufügen) hat es bei mir auch gebracht.
Da ich die Einstellung "keepAuto" auf 1 habe, muss ich die Einstellung "scnProcessByDesiChange" benutzen. Ist nur schade, das meine Log-Datei dann immer sich ändernde Soll-Werte meldet.
Nun habe ich einfach mal ausprobiert, wie man die Thermostate noch dazu bringen kann die Temperatur zu melden. Möglichkeiten gibt es zumindest bei meinen Heizkörperthermostaten Basic mit der Firmware 1.1 viele:
"groupid" neu setzen (auch bei gleichen Wert)
"maxValveSetting" neu setzen
"wakeup"
"windowOpenDuration"

jedes Mal antwortet der HT mit der aktuellen Temperatur und allen anderen wichtigen Daten.

Ich würde es begrüßen. wenn es die Möglichkeit geben würde so die Temperaturen zu scannen. Dann müsste auf die aktuelle Temperatur keine Rücksicht genommen werden. Auch manuelle Eingaben überschneiden sich dann nicht mehr etc.
Oder habe ich da was wichtiges übersehen?
[edit]
Ja...ich habe das wichtigste übersehen. Es werden zwar Daten gesendet, allerdings ist die aktuelle Temperatur nicht dabei. Schade.
Warum ist es eigentlich nur möglich bei "keepAuto" - "scnProcessByDesiChange" zu nutzen? Heute Nacht ist mein Thermostat die ganze Zeit hin- und hergefahren....
[/edit]
Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

John


@bismosa

In der  commandref zu Max ist zu lesen:

ZitatIf the keepAuto attribute is 1 and the device is currently in auto mode, 'desiredTemperature <value>' behaves as 'desiredTemperature auto <value>

Damit kann ModeChange nicht genutzt werden, da ja das MAX-Modul mit aktivem keepAuto den Mode immer auf AUTO zwingt.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

YellowBall

Der Scanner rennt.
Wie aktiviere ich die Plots?
Raspi 0,1,2,3,4 | HMUART | Broadlink | Harmony | Xiaomi | Milight | Homematic | Somfy | Sonos | Meross  | Sonoff  | Shelly | Comet DECT  | ioBroker


xploderpro

#791
Hallo zusammen,

das ist mein erster Beitrag in diesem Forum weil ich alleine nicht mehr weiterkomme und auch noch keine Lösung hierzu gefunden habe. Bisher konnte ich mich top in FHEM einfinden und bin soweit auch sehr zufrieden mit meinen Einstellungen. Deswegen meinen größten Dank an alle Entwickler/WIKI-Schreiber/Foren-Teilnehmer/und wer nicht noch alles dran beteiligt ist!

Ich habe FHEM mit Max-Komponenten und einem CUL im Einsatz und habe habe den Temperatur-Scanner wie folgt definiert:

define Scanner MaxScanner
attr Scanner verbose 1


Zusätzlich habe ich ein Heizthermostat mit folgenden Einstellungen ergänzt:
attr MAX_143a61 scanTemp 1
attr MAX_143a61 scnProcessByDesiChange 0


Der Scanner funktioniert auch wunderbar, aber in meinem FHEM Fakelog erscheinen nun trotz der Einstellung von verbose=1 unendlich viele dieser Einträge:

2018.03.01 14:58:53 3: MaxScanner MAX_143a61 Work.1228 <<set MAX_143a61 desiredTemperature  17.0>>
2018.03.01 14:59:53 3: MaxScanner MAX_143a61 Work.1236  Wait at least 180 sec . after last command
2018.03.01 15:00:29 3: MaxScanner MAX_143a61 Work.1014 TEMPERATURE received at 2018-03-01 15:00:28, ==> new ns:2018-03-01 15:03:11
2018.03.01 15:03:11 3: MaxScanner MAX_143a61 Work.1228 <<set MAX_143a61 desiredTemperature auto 17.0>>
2018.03.01 15:04:11 3: MaxScanner MAX_143a61 Work.1236  Wait at least 180 sec . after last command
2018.03.01 15:04:47 3: MaxScanner MAX_143a61 Work.1014 TEMPERATURE received at 2018-03-01 15:04:47, ==> new ns:2018-03-01 15:07:30



  • Ist das unabhängig vom verbose Level so gewollt oder funktioniert etwas nicht, denn selbst wenn ich verbose=0 setze, erhalte ich diese Einträge noch.
    Wie bekomme ich diese Einträge deaktiviert?

Danke und Grüße,
xploderpro

//Edit:Der Vollständigkeit halber noch eine vollständige list-Ausgabe des entsprechenden Thermostats:
Internals:
   DEF        HeatingThermostat 143a61
   IODev      cm
   LASTInputDev cm
   MSGCNT     1
   NAME       MAX_143a61
   NR         48
   RSSI       -64
   STATE      17.0 °C
   TYPE       MAX
   addr       143a61
   backend    cm
   cm_MSGCNT  1
   cm_TIME    2018-03-01 15:24:02
   dstsetting 1
   mode       0
   rferror    0
   type       HeatingThermostat
   READINGS:
     2018-03-01 15:24:02   RSSI            -64
     2017-06-04 14:25:33   TimeInformationHour 3
     2018-03-01 15:24:02   battery         ok
     2017-06-04 14:22:15   boostDuration   25
     2017-06-04 14:42:57   boostValveposition 100
     2017-06-04 14:22:15   comfortTemperature 21.0
     2017-06-04 14:22:15   decalcification Sat 12:00
     2018-03-01 15:24:02   desiredTemperature 17.0
     2017-06-04 14:22:15   ecoTemperature  17.0
     2017-10-10 19:01:21   firmware        1.0
     2017-10-10 19:01:21   groupid         0
     2017-06-04 14:22:15   maxValveSetting 100
     2017-06-04 14:22:15   maximumTemperature on
     2017-06-04 14:22:15   measurementOffset 0.0
     2017-06-04 14:22:15   minimumTemperature off
     2018-03-01 15:24:02   mode            auto
     2018-03-01 15:24:01   msgcnt          99
     2018-03-01 15:24:02   state           17.0 °C
     2018-03-01 15:17:42   temperature     22.0
     2017-10-10 19:01:21   testresult      160
     2017-06-04 14:22:15   valveOffset     0
     2018-03-01 15:24:02   valveposition   0
     2018-02-24 14:14:36   weekprofile-0-Sat-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-0-Sat-time 00:00-06:00  /  06:00-11:00  /  11:00-17:00  /  17:00-22:30  /  22:30-23:55  /  23:55-00:00
     2018-02-24 14:14:36   weekprofile-1-Sun-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-1-Sun-time 00:00-06:00  /  06:00-11:00  /  11:00-17:00  /  17:00-22:30  /  22:30-23:55  /  23:55-00:00
     2018-02-24 14:14:36   weekprofile-2-Mon-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-2-Mon-time 00:00-04:30  /  04:30-10:00  /  10:00-17:00  /  17:00-22:00  /  22:00-23:55  /  23:55-00:00
     2018-02-24 14:14:36   weekprofile-3-Tue-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-3-Tue-time 00:00-04:30  /  04:30-10:00  /  10:00-17:00  /  17:00-22:00  /  22:00-23:55  /  23:55-00:00
     2018-02-24 14:14:36   weekprofile-4-Wed-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-4-Wed-time 00:00-04:30  /  04:30-10:00  /  10:00-17:00  /  17:00-22:00  /  22:00-23:55  /  23:55-00:00
     2018-02-24 14:14:36   weekprofile-5-Thu-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-5-Thu-time 00:00-04:30  /  04:30-10:00  /  10:00-17:00  /  17:00-22:00  /  22:00-23:55  /  23:55-00:00
     2018-02-24 14:14:36   weekprofile-6-Fri-temp 15.0 °C  /  21.5 °C  /  17.0 °C  /  21.0 °C  /  15.0 °C  /  15.0 °C
     2018-02-24 14:14:36   weekprofile-6-Fri-time 00:00-04:30  /  04:30-10:00  /  10:00-17:00  /  17:00-22:00  /  22:00-23:55  /  23:55-00:00
     2017-06-04 14:22:15   windowOpenDuration 15
     2017-06-04 14:22:15   windowOpenTemperature 12.0
   helper:
     DesiTime   1519913862
     LastCmdDate 1519914241.61948
     NextScan   1519914301
     TempBeforeWindOpen 17.0
     TemperatureTime 1519913862
     WinWasOpen 0
     desiredOffset 0
     gotTempTS 
     leadDesiTemp 17.0
     switchDate 1519920000
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm
   alias      Heizung_Badezimmer
   icon       sani_heating
   room       Badezimmer
   scanTemp   1
   scnProcessByDesiChange 0
   userattr   scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL

John


ich vermute, daß der Verbose-Level von Max-Ventil MAX_143a61 >=3 ist.


Wenn du diesen <3 setzt, sollte die Log-Einträge verschwinden.


Bei den Ventil-nahen Befehlen übernimmt der Scanner den Verbose-Level der Ventile für die Log-Ausgabe.



CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

xploderpro

Tja ws soll ich sagen - es kann doch so einfach sein. Vielen Dank für die schnelle Hilfe!

Ein Eintrag in der Form
attr MAX_143a61 verbose 2
lässt die Einträge verschwinden  :)

Vorher hatte ich beim Ventil keinen verbose level explizit definiert . Stellt sich mir nur noch die Frage, welche Auswrikungen das jetzt für mich hat. Welche Meldungen vom Ventil(Modul) wären mir vorher angezeigt worden, die nun nicht mehr auftauchen?
Gibt es eine Definition der Nachrichten bei MAX je nach verbose Stufe?


pjakobs

Ich habe immer mal wieder das seltsame Phänomen, dass irgendein Heizkörper, entgegen des Tagesprogramms, partout darauf besteht, den Raum auf 12°C zu heizen. Gerade im Winter ist das natürlich nur so halb toll.

Im Log steht dann z.B. sowas:

2018.03.07 09:05:48 3: MaxScanner HT_Bu Work.1059 strMode:manual DesiTemp:19.0 TempBeforeWindOpen:12.0
2018.03.07 09:05:48 3: MaxScanner HT_Bu Work.1071 <<stage 2>>due window is closed: set HT_Bu desiredTemperature  12.0

Ich habe den Eindruck, der Scanner erwischt manchmal die Temperatur wenn das Fenster geöffnet ist und verwendet die, wenn er die Thermostateinstellung ändert, um ein Temperaturreading zu bekommen. Kann das jemand bestätigen?
Gefunden hab ich da leider nix zu .

Grüße

pj