Hauptmenü

Rechnen mit Readings

Begonnen von Gonzolo, 17 April 2017, 12:35:02

Vorheriges Thema - Nächstes Thema

Beta-User

#30
Zitat von: CoolTux am 12 Mai 2017, 13:03:25
Oder nicht verstanden. Aber dann hätte er fragen sollen

...ich hoffe nur, dass er nunmehr die essenzielle Frage verstanden hat, was ein Trigger (bzw. Event) ist ::) .

Danke, dass Du Dir die Mühe machst, das so geduldig zu erklären ;) .

@Gonzolo: Nix für ungut, ich weiß nur zu gut, wie einfach es ist, den Wald vor lauter Bäumen nicht mehr zu sehen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wuppi68

#31
Zitat von: CoolTux am 12 Mai 2017, 13:03:25
Naja fast. FHEM arbeitet Event basiert. Du kannst Dir alle Events welche Deine Devices auslösen im Eventmonitor anschauen.
Auf ein Event kann man triggern, das tun Notify oder DOIF und lösen dann aus. Das Fragezeichen vor dem Device im DOIF sorgt dafür das auf das Event nicht getriggert wird. Es macht wenig Sinn das Dein DOIF auslöst wenn Du den Dummy Tag Nacht änderst, auch macht es wenig Sinn wenn Dein DOIF auf verändern der Soll Temperaturen für Tag Nacht reagiert. Auslöser soll einzig und allein die gemessene IST Temperatur sein und nur die löst auch nur das DOIF aus. Also zu mindest was diesen DOELSEIF Zweig an geht.

Um den Begriff "Event" und Eventbasierte Steuerung noch ein wenig "anschaulicher" zu Beschreiben:

Event = Ereignis --> Der Kaffee ist fertig geworden (Zeitpunkt)
State = Zustand --> Der Kaffee ist fertig

Jedes Event wird von FHEM ausgewertet und dadurch Aktionen gestartet (intern von FHEM und vom Anwender definierte)

im obigen Beispiel wird der Event "Kaffee ist fertig geworden" getriggert und die FHEM interne Routine setzt den Status von Brühvorgang auf fertig.

Der Event ist dann vergessen und kann nicht mehr abgefragt werden! Übrig bleibt nur der neue Zustand als Ergebnis des getriggerten Events.

Konsequenz:
- Einen Status kann ich nur Abfragen (Pollen = zyklisch Abfragen)
- Einen Event bekomme ich mitgeteilt (notify als "Empfänger" Routine)
- Ein Statuswechsel muss einen (Informations) Event erzeugen, dass sich der Status geändert hat

Konsequenz innerhalb Deiner FHEM Automation:

Ein nacktes Basis FHEM kann nicht auf Zustände reagieren. DOIF ist ein Erweiterungsmodul, welches automatisch mit installiert ist und die "Brücke" zwischen Event und Zustandsbasierter Logik schlägt

@Leon und Beta-User: nehmt das nur als Zusatz und nicht als Kritik auf ;-) Ich habe das Gefühl die Saat könnte Früchte bringen
FHEM unter Proxmox als VM

Gonzolo

Zitat
Es macht wenig Sinn das Dein DOIF auslöst wenn Du den Dummy Tag Nacht änderst

Genau das will ich aber!

Der [Steuerung] wird morgens auf "TempTag" umgestellt und Abends auf "TempNacht" ... Daher soll FHEM genau dann auf das EVENT reagieren und fragen wie die Temperatur ist.

Ist die Temp < als 2C unter der Soll Temperatur, dann soll die Heizung BOOSTEN. Wenn nicht (also wenn die Temperatur nur ein bissen unter dem Soll Temperatur ist) soll er einfach "normal" heizen.

Also habe ich es richtig gemacht!

@Beate-Use: Events kenne ich!! ;-)

Beta-User

#33
@Gonzolo,

auch wenn Du Events kennst, hast Du die Doku nicht gelesen, weil sonst wüßtest Du, dass das "?" dafür steht, ob das Event nun triggern soll oder nicht.

Da Du triggern willst, muß also das "?" doch wieder raus.
Bloß ist damit noch nicht geklärt, wie der BOOST_MODE wieder ausgeschaltet werden soll. Also sollte in Deinen Code in den 2. Zweig noch ein BOOST_MODE false rein, oder machst Du das dann woanders?

gez.
Puh der Bär
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gonzolo

Ich kenne Events... habe aber dazu nicht explizit die Doku gelesen (ertappt... zufrieden??  ;) )

ABER jetzt hast du nicht richtig gelesen...

Wenn er BOOSTEN soll, dann


###### ------------------------Tag mit Boost
([Steuerung] eq "TempTag" and
   [TempWohnzimmer] < ([?Steuerung:TempTag]-2.0))
  (set Heizung_Wohnzimmer datapoint 1.SET_POINT_TEMPERATURE [Heizung_Wohnzimmer:TempTag])
  (set Heizung_Wohnzimmer datapoint 1.BOOST_MODE true)


wenn er nicht BOOSTEN soll dann


###### ------------------------Tag ohne Boost
DOELSEIF
([Steuerung] eq "TempTag" and
   [TempWohnzimmer] >= ([?Steuerung:TempTag]-2.0))
  (set Heizung_Wohnzimmer datapoint 1.SET_POINT_TEMPERATURE [Heizung_Wohnzimmer:TempTag])


Dem aufmerksamen Leser fällt auf, ... einmal  (set Heizung_Wohnzimmer datapoint 1.BOOST_MODE true) und einmal ohne...

Habe Homematic Heizungsthermostate. Mit  (set Heizung_Wohnzimmer datapoint 1.BOOST_MODE true) bringt man diese ein paar Minuten zum BOOSTEN ;-)

Beta-User

Jetzt bin ich zufrieden ;) , wenn man von dem Punkt absieht, ich hätte nicht richtig gelesen. Oder stand irgendwo, dass der Boost-Mode automatisch ausgeht (ok, das kann man vermuten, da HM, aber sicher ist das nicht (und viel bringen dürfte die Vorgehensweise auch nicht, weil die HM-Thermostate sowieso wissen, wie weit sie aufgehen sollen, damit es halbwegs zügig warm wird ::) . Das ist aber wieder ein ganz anderes Thema)).

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Zitat von: Wuppi68 am 12 Mai 2017, 13:32:52
Um den Begriff "Event" und Eventbasierte Steuerung noch ein wenig "anschaulicher" zu Beschreiben:

Event = Ereignis --> Der Kaffee ist fertig geworden (Zeitpunkt)
State = Zustand --> Der Kaffee ist fertig

Jedes Event wird von FHEM ausgewertet und dadurch Aktionen gestartet (intern von FHEM und vom Anwender definierte)

im obigen Beispiel wird der Event "Kaffee ist fertig geworden" getriggert und die FHEM interne Routine setzt den Status von Brühvorgang auf fertig.

Der Event ist dann vergessen und kann nicht mehr abgefragt werden! Übrig bleibt nur der neue Zustand als Ergebnis des getriggerten Events.

Konsequenz:
- Einen Status kann ich nur Abfragen (Pollen = zyklisch Abfragen)
- Einen Event bekomme ich mitgeteilt (notify als "Empfänger" Routine)
- Ein Statuswechsel muss einen (Informations) Event erzeugen, dass sich der Status geändert hat

Und was für ein aktuelles Beispiel. Wo doch das Kaffeemaschinen Modul gerade interessant diskutiert wird   ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Thorsten Pferdekaemper

Man könnte jetzt noch damit anfangen, dass in zeitgemäß gedämmten Häusern die Nachtabsenkung im besten Fall kosten- und CO2-neutral ist gegenüber "immer 22°". Es kann auch vorkommen, dass es teurer wird, da das Aufheizen mehr Energie verbrät als das Absenken.
Gruß,
   Thorsten
FUIP

CoolTux

Zitat von: Thorsten Pferdekaemper am 12 Mai 2017, 14:25:45
Man könnte jetzt noch damit anfangen, dass in zeitgemäß gedämmten Häusern die Nachtabsenkung im besten Fall kosten- und CO2-neutral ist gegenüber "immer 22°". Es kann auch vorkommen, dass es teurer wird, da das Aufheizen mehr Energie verbrät als das Absenken.
Gruß,
   Thorsten

Aber das Thema hatten wir ja nun schon des öfteren diskutiert. Am Ende muß jeder, auf Basis der gesammelten Daten und Fakten, selber wissen wie er seine Steuerung machen will.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Gonzolo

@Thorsten...
Zitat
in zeitgemäß gedämmten Häusern die Nachtabsenkung im besten Fall kosten- und CO2-neutral ist gegenüber "immer 22°". Es kann auch vorkommen, dass es teurer wird, da das Aufheizen mehr Energie verbrät als das Absenken.


GENAU deswegen mach ich ja den Mist!!! Wohne mit nur Rentner im Haus. Da herrscht die Meinung, dass wir nicht dämmen müssen, weil die Alten Leute garnicht mehr soviel Heizkosten sparen können in ihrem restlichen Leben, dass sich das lohnt! :-)

@Beta-User
Zitatweil die HM-Thermostate sowieso wissen, wie weit sie aufgehen sollen, damit es halbwegs zügig warm wird

Leider haben die HM-Thermostate genau da ihre Schwäche! Wenn ich 21C einstelle "ballern" die noch auch wenn es schon 23C in der Bude ist


@CoolTox
Kaffee ist ungesund! Grüner Tee ist da viel besser! :-)

DANKE IHR BUBEN!!! JETZT habe ich Euch alle wieder lieb!!! ;-)

Wuppi68

Zitat von: CoolTux am 12 Mai 2017, 14:25:25
Und was für ein aktuelles Beispiel. Wo doch das Kaffeemaschinen Modul gerade interessant diskutiert wird   ;D

wo Du ja auch im Thema bist :-)

Ich fand es halt einfacher plastischer als so abstrakte Begriffe wie Event, Trigger, Zustand so im Raum stehen zu lassen und dabei zu denken, dass der Empfänger der Botschaft dieses auch so wie ich versteht
FHEM unter Proxmox als VM

Beta-User

Zitat von: Gonzolo am 12 Mai 2017, 14:34:07
Leider haben die HM-Thermostate genau da ihre Schwäche! Wenn ich 21C einstelle "ballern" die noch auch wenn es schon 23C in der Bude ist
Das ist ein bekanntes Verhalten, aber läßt sich das mit dem BOOST-Mode überlisten ??? ?!?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gonzolo

Mit BOOST nicht... da bin ich einfach ungeduldig und der soll WARM machen. Und das geht tatsächlich.

Wuppi68

Zitat von: Gonzolo am 12 Mai 2017, 14:34:07
@Thorsten...

GENAU deswegen mach ich ja den Mist!!! Wohne mit nur Rentner im Haus. Da herrscht die Meinung, dass wir nicht dämmen müssen, weil die Alten Leute garnicht mehr soviel Heizkosten sparen können in ihrem restlichen Leben, dass sich das lohnt! :-)

@Beta-User
Leider haben die HM-Thermostate genau da ihre Schwäche! Wenn ich 21C einstelle "ballern" die noch auch wenn es schon 23C in der Bude ist


@CoolTox
Kaffee ist ungesund! Grüner Tee ist da viel besser! :-)

DANKE IHR BUBEN!!! JETZT habe ich Euch alle wieder lieb!!! ;-)

Coole Argumentation mit der Sanierung - nicht Diskussionsfördernd aber stimmig

Wenn der Vorlauf zu den HM Thermostaten  in Grenzen konstant bleibt lernen diese auch relativ schnell wie der Raum entsprechend reagiert und überheizen dann nicht mehr

und grüner Tee ist auch nur nicht fermentierter schwarzer Tee :-)
FHEM unter Proxmox als VM

Gonzolo

Danke Wuppi für Deinen Einwand!!  ;D