Händisches Eingreifen in den Zeitplan erkennen

Begonnen von hopgeq, 23 September 2017, 23:37:12

Vorheriges Thema - Nächstes Thema

hopgeq

Hallo,
ich möchte bei den Heizkörperthermostaten erkennen, wenn jemand den Drehknopf am Thermostat verwendet und damit die Solltemperatur ändert. Und das unterscheiden von zeitplan-gesteuerten Änderungen der Temperatur. Aus zwei Gründen: Händische Änderungen lassen auf Anwesenheit schließen und deuten außerdem darauf, dass die Automatik verbesserungswürdig ist. Jetzt scheint es aber schwierig, diese beiden Fälle zu unterscheiden.

Die Thermostate laufen normalerweise auf "Auto". Sie produzieren zeitplan-gesteuert z.B. folgenden Logeintrag:

2017-09-23_22:01:06 max_2_Fernseher mode: auto
2017-09-23_22:01:06 max_2_Fernseher battery: ok
2017-09-23_22:01:06 max_2_Fernseher desiredTemperature: 19.5
2017-09-23_22:01:06 max_2_Fernseher temperature: 22.8
2017-09-23_22:01:06 max_2_Fernseher valveposition: 0
2017-09-23_22:01:06 max_2_Fernseher 19.5 °C
2017-09-23_22:01:06 max_2_Fernseher RSSI: -73.5

Jetzt ändere ich die Solltemperatur durch händisches Drehen am Knopf des Thermostats (und bleibe auf auto). Ich bekomme im Log:

2017-09-23_23:24:52 max_2_Fernseher mode: auto
2017-09-23_23:24:52 max_2_Fernseher desiredTemperature: 17.0
2017-09-23_23:24:52 max_2_Fernseher 17.0 °C
2017-09-23_23:24:52 max_2_Fernseher RSSI: -73
2017-09-23_23:24:53 max_2_Fernseher mode: auto
2017-09-23_23:24:53 max_2_Fernseher desiredTemperature: 17.0
2017-09-23_23:24:53 max_2_Fernseher 17.0 °C
2017-09-23_23:24:53 max_2_Fernseher RSSI: -73

Mir fällt als Unterschied eigentlich nur auf, dass bei den händischen Änderungen stets Duplikate des Wertes von desiredTemperature erscheinen. Die sind aber auch nicht einheitlich.
Kann ich so ein händisches Eingreifen in den Zeitplan noch irgendwie anders erkennen?


hopgeq

Ist die Frage zu trivial (ich bin unerfahren in fhem)? Oder gibt es mit dem MAX-System die Möglichkeit schlicht nicht, den Absender einer Änderung in desiredTemperature mit fhem zu erfassen?


MadMax-FHEM

Kenne MAX! zu wenig, vermute aber dass es dort ähnlich wie bei Homematic ist (sein sollte, soweit mir bekannt ;)  ):

es gibt keine Unterscheidung...

Was du tun könntest ist ein Notify auf desired-temp und dann prüfen, ob die Automatik (sollte bzw. bei Homematic tut sie es) aktuell diese Schaltschwelle hat, dann war es wohl (sehr wahrscheinlich) die Automatik...
...wenn die Automatik etwas anderes sagt/sagen würde/gesagt hätte, dann hat wohl jemand manuell gedreht...

Was anderes fällt mir nicht ein...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Wzut

Zitat von: hopgeq am 24 September 2017, 22:10:42
Ist die Frage zu trivial
Weder die Frage ist trival noch die Lösung :)
Da du den Auto Modus ja nicht verlässt must du quasi bei jedem Event von desiredTemperature prüfen ob die gerade gemeldete Temperatur mit der Vorgabe des Wochenplan übereinstimmt oder nicht. Das ist mit Bordmittelen so direkt nicht machbar. Müsste ich das Problem für mich lösen würde ich folgenden Ansatz verfolgen:
a. sicherstellen das FHEM Zugriff auf alle Daten des Wochenplans hat. D.h. das Device hat alle 14 Readings des Wochenplans (weekprofile-[0-6]-<Tag>-temp & weekprofile-[0-6]-<Tag>-time )
Idealerweise den Wochenplan mittels des Moduls weekprofile erstellen/verwalten
b. eine neue Funktion in der 99_myUtils anlegen die als Übergabeparameter den Devicenamen und die aktuell gemeldete desiredTemperature hat und für den aktuellen Zeitpunkt die Einträgen des Wochenplans mit der Vorgabe vergleicht und entsprechend 0 oder 1 zurückgibt.
c. jedem betroffenen Device ein userReading spendieren das die Funktion aufruft und den Rückgabewert speichert.

Danach kannst du dann ein notify bauen das das userReading überwacht und ggf. Aktionen  auslöst bei Abweichung
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Sendet der Aktor eigentlich bei jedem automatischen Update vorneweg auch battery, nicht aber beim manuellen Wechsel?

(Darauf deutet der kurze Eventmonitor-Auszug hin).

Wenn es typisch für einen manuellen Wechsel ist, dass die ReadingsAge-Angaben von battery und desired unterschiedlich sind, wäre das (Prüfung der beiden ReadingAge) uU. ein Weg. Ggf. müßte man eine Denkpause von einigen Sekunden einbauen, und dann erst prüfen, sollte hin und wieder eine andere Verarbeitungsreihenfolge seitens FHEM erfolgen u. ähnliche Effekte ausgeschlossen werden.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files