Sommer / Winterumschaltung nach DIN

[TRex]

Guten Morgen an die Schwarmintelligenz...
Hat einer von Euch bereits ein fertiges Skript / Plugin in dem er Sommer / Winter nach DIN berechnet? Würde mir den Tag Arbeit sparen.

Will damit
1.) MDT Heizungsaktoren ansteuern
2.) Klimaanlage Heizufunktion / Kühlfunktion umschalten

Danke Peter

[Msinn]

Meinst Du mit "Sommer / Winter nach DIN" folgendes?

Auch dafür gibt es eine DIN-Norm, und zwar "Winter-Sommer-Umschaltung nach DIN". Funktioniert so:

Temperatur messen:
um 7 Uhr T1
um 14 uhr T2
um 22 uhr. T3

T= T1+T2+T3+T3 / 4

T ist dann die grenze bei 16°C.

Wobei mir dabei nicht klar ist, ob die Uhrzeitangaben nach CET oder CEST gemeint sind.

[smai]

Ich habe eine Lösung im Einsatz, welche das mit 2 Items und einem eval macht.

Frei aus dem Kopf wiedergegeben sieht das etwa so aus:

sommer:
    type: bool
    eval_trigger: .werte
    eval: sum(value) / float(len(value)) > 16 if len(value) == 4 else None

        werte:
            type: list
            init: []
            eval: (sh..() + value * [sh.temperatur()])[-4:]
            crontab:
                - 0 7 * * = 1
                - 0 14 * * = 1
                - 0 22 * * = 2

temperatur:
    type: num
    ...

Zur Erklärung:
In sommer.werte wird eine Liste mit den letzten 4 Temperaturen gespeichert (jeweils um 7 Uhr, 14 Uhr und 22 Uhr doppelt).
Die Speicherung wird durch crontab ausgelöst, welche die Gewichtung als Wert mitgibt.
Das eval fügt den aktuellen Temperaturwert in der Anzahl der Gewichtung an und reduziert die Liste auf die letzten 4 Einträge.

Das Item sommer errechnet dann den Durchschnitt.
Dies geschieht nur, wenn 4 Werte vorliegen, weil andernfalls keine vernünftige Aussage möglich ist.
Nach einem Neustart muss man also wieder einen Tag warten, bis ein Wert vorliegt. Um dies zu verhindern, kann man in sommer.werte noch ein cache: 'Yes' einfügen mit dem Risiko, dass man bei einem verpassten Speicherzeitpunkt vorübergehend eine falsches Resultat haben kann.

[mumpf]

Hi,

das ist cool, viel kompakter als meine Lösung, ich habe das mit 5 Items gelöst, quasi Dein "sommer" mit "eval: avg" und 4 Kinder-Items, sie sich um 7, 14 und 22 Uhr mit Temperatur aktualisieren (das 22 Uhr-Item ist dann doppelt da).
Einzelne Kinder-Items deswegen, damit ich cache: Yes machen kann, damals ging es noch nicht, eine Liste in den cache zu schreiben. Der Tag Wartezeit kommt für mich nicht in Frage, dazu ändere ich zu oft was und dann hätte ich nur selten einen gültigen Wert...

Hast Du das mit cache: Yes für die Liste ausprobiert oder ist das nur eine Annahme, dass es inzwischen geht?

Gruß, Waldemar

[smai]

Hast Du das mit cache: Yes für die Liste ausprobiert oder ist das nur eine Annahme, dass es inzwischen geht?

War nur eine Annahme, ich hatte selbst auch Zweifel. Ich habe aber nicht gewusst, dass es nicht geht und auch keine entsprechenden Informationen gefunden. Es gibt auch keinen Issue dazu.

Alternativ könnte man auch einfach "sommer" selbst cachen. Normalerweise ändert sich dieses ja nicht täglich.

Nachtrag:
Ich habe mal den Code angeschaut. Der Cache wird mit pickle.dump beschrieben.

The following types can be pickled:

• None, True, and False
• integers, floating point numbers, complex numbers
• strings, bytes, bytearrays
• tuples, lists, sets, and dictionaries containing only picklable objects

Von daher müssten Listen gecached werden können.
Diese Implementierung ist aber gemäss GitHub schon 5 Jahre alt. Irre ich mich oder ist dein Wissen so veraltet?

[mumpf]

Irre ich mich oder ist dein Wissen so veraltet?

Da ist was wahres dran. Nacht meiner Odyssee von FHEM, linknx, sh.py über callidomus bin ich immer noch dabei, wieder zurück auf shNG.py umzustellen, dann eben gleich auf yaml. Da sh.py, shNG.py und callidomus konzeptionell ähnlich sind, verhalten sie sich sehr ähnlich und man kann Fragen zu allen 3 normalerweise beantworten. Allerdings habe ich praktische Erfahrung nur mit sh.py (da von Anfang an) und mit callidomus. shNG.py habe ich noch nicht wirklich produktiv genutzt. Und im Detail unterscheiden sie sich ja doch alle etwas...

callidomus kann keine Listen im cache speichern, das habe ich verwechselt. Bei so vielen Tools schmeißt man das doch irgendwann durcheinander.

Danke für die Infos oben,
Gruß,Waldemar

[smai]

mumpf Ich möchte mich noch entschuldigen, jetzt wo ich meinen eigenen Satz nochmal lese, merke ich, dass dieser falsch verstanden werden kann.
Er soll eigentlich aussagen "Entweder ich irre mich bei meiner Codeanalyse oder dein Wissen ist veraltet". Vielleicht hast du ja sogar recht, testen konnte ich es noch nicht.

[TRex]

so, danke...
smai, kannst du den genauen Code / Schnipsel mal posten?
Ich finde das hat einen Charme wenn man das als type=list reinbaut
Dann mit crontab einen Skript aufrufen der die Liste pflegt.....
Ich meine es ist dann auch ein 3-Tagesdurchschnitt ?? > 14 grad Cels dann ist sommer.

[mumpf]

Ich möchte mich noch entschuldigen

Nicht nötig, ich habe das nicht als Vorwurf verstanden. Ich habe es ja auch nicht ausprobiert, hatte nur im Hinterkopf, dass da was war...

TRex Das Beispiel von smai berechnet nur den genormten Tagesmittelwert. Das Dreitagesmittel muss man dann noch bestimmen. Und DIN-Sommer ist eigentlich nur bei Dreitagesmittel > 16°C.

Gruß, Waldemar

[smai]

kannst du den genauen Code / Schnipsel mal posten?

Ich kann das am Wochenende überprüfen, das oben könnte aber auch schon alles sein und sogar funktionieren.
Wahrscheinlich ist das hier sogar schöner, mein eingesetztes stammt wahrscheinlich noch aus der Zeit ohne relative Referenzen.

Den 3-Tagesdurchschnitt kann man wahrscheinlich in derselben Art mit einer Liste bilden.
Oder noch einfacher: Die Liste wird einfach auf 12 Werte erweitert, da müsste doch dasselbe raus kommen.

(∑T1 / 4 + ∑T2 / 4 + ∑T3 / 4) / 3  [MARKIEREN] 4 ausklammern [/MARKIEREN]
= (∑T1 + ∑T2 + ∑T3) / 4 / 3  [MARKIEREN] x/4/3 = x/(4*3) = x/12 [/MARKIEREN]
= (∑T1 + ∑T2 + ∑T3) / 12  [MARKIEREN] q.e.d. [/MARKIEREN]

[TRex]

OK, habe mir mal die Mühe gemacht das zu definieren.
1.) 2 GA definiert,

[sommer]
    type = bool
    cache = True
    knx_dpt=1
    visu_ack=rw
    [[digits]]
        #werte von 7.00|14.00|22|gestern|vorgestern
        type = list
        value=
        visu_acl = rw

dann der Aufruf in logic.conf:

[sommer]
filename=sommer.py
crontab= 0 7 * *|0 14 * *|0 22 * *

dann noch der python-skript sommer

#!/usr/bin/env python
import random, math,time, datetime, re

logger.info('sommer.py Logik triggered by {}, source {}, value {}, dest {}'.format(trigger['by'],trigger['source'],trigger['value'],trigger['dest']))

source='{}'.format(trigger['source'])
value ='{}'.format(trigger['value'])
by = '{}'.format(trigger['by'])

lvar=[]
aktual=round(float(sh.quadra.temperatur()),1)

#einlesen der list
for i in range(5):
    if sh.sommer.digits()[i]=='':
        lvar.append(aktual)
    else:
        lvar.append(float(sh.sommer.digits()[i]))


if time.strftime('%H') == '7':
   lvar[0]=aktual
   lvar[4]=lvar[3]
   lvar[3]=round((lvar[0]+lvar[1]+lvar[2]+lvar[2])/4,1)

if time.strftime('%H') == '14':
   lvar[2]=aktual

if time.strftime('%H') == '22':
   lvar[3]=aktual

avg= round((((lvar[0]+lvar[1]+lvar[2]+lvar[2])/4) + lvar[3] + lvar[4]) / 3,1)

lval= [str(lvar[0]) ,str(lvar[1]),str(lvar[2]) ,str(lvar[3]) ,str(lvar[4])]
sh.sommer.digits(lval)

if avg>14:
    sh.sommer(1)
else:
    sh.sommer(0)

der Vorteil dabei, die WErte beim ersten start oder nach neustart werden mit den aktuellen gefüllt, dann steht immer was zur Verfügung.
Verbesserungsvorschläge willkommen....

[heckmannju]

Warum will man diese nährung der Durchschnittstemperatur? Wenn man den Durchschnittstemperatur mit den Funktionen berechnen kann?
sh.quadra.temperatur.db( 'avg', '1')
es geht doch letztendlich um die Berechnung einer heizgrenze dabei?

[TRex]

ziemlich einfach,
ich weiss nicht woher ich quadra.temperatur.db nehmen soll, denn ich schreibe ja keine .db
wenn du mir erklärst wie das geht nehme ich das gerne

[heckmannju]

Hi,
dazu mußt du das sqlite Plugin aktivieren.
https://www.smarthomeng.de/user/plug..._8/README.html
VG Jürgen

[psilo]

heckmannju Besser das Database Plugin https://github.com/smarthomeNG/plugi...aster/database sonst setzt er auf Pferde, die es bald nicht mehr gibt...