Item mit Zeitberechnung bspw für Verbrauchsauswertung als Systemitems bereitstellen

[Sisamiwe]

Hallo Onkelandy ,

- Das Item selbst, in dem das struct steckt, muss auch noch irgendwie aktualisiert werden, oder? Momentan gibt es für heute, gestern, etc. zwar ein eval und eval_trigger, aber das "Über-Item" hat kein cycle.

Bei mir werden die "Überitems" durch die neuen Werte bspw. der Leseköpfe aktualisiert. Immer wenn das "Überitem" einen neuen Wert bekommt, werden die entsprechenden "lebenden" Items (so die, auf die die neuen Werte direkten Einfluss haben wie "heute", "Woche", "Monat") aktualisiert.
Bespw so:

%YAML 1.1
---
stromzaehler:
    bezug:
        energie:
            name: Wirkarbeit Bezug total
            type: num
            sml_obis: 1-0:1.8.0*255
            sml_prop: valueReal
            eval: round(value / 1000, 2)
            database: init
            struct: wertehistorie_total

Die Items mit Werten, die nicht immer bei neuen Live-Werten aktualisiert werden müssen (wie gestern, vorgestern, letzte Woche, ...) habe ich den Crontab gesetzt, der wenigstmöglich (neue Woche, neuer Monat, ...) oder eben bei Neustart das Item triggert.

- Noch wichtiger: Die crontabs können zu extrem vielen Schedulern führen, wenn das struct in etlichen Items integriert wird. Es wäre deutlich effizienter, die Items über eine einzelne Logik, die z.B. alle 5 Minuten getriggert wird, zu aktualisieren.

Wie gesagt, den Crontab nutze ich nur für die Items, die selten aktualisiert werden müssen. Nichtsdestotrotz bin ich offen für den Vorschlag. Man brächte eine Logik, die in Abhängigkeit des letzten Teils des Item-Pfades unterschiedlich triggered. Bspw alle Items deren Pfad auf ".vorwoche" enden, immer Montag früh um 0.05 Uhr.
Geht das mit Wildcards?

Michael

[Msinn]

Du kannst in einer Logik das triggernde Item abfragen und dann abhängig von dem Item unterschiedlich reagieren.

Das was Du gebaut hast ist für einige Items ok. Es traten nur Probleme auf, weil in einer Installation mehrere hundert Items ein crontab Attribut hatten und damit mehrere hndert Scheduler Tasks aufgesetzt wurden. Damit wurden die internen Queues im Scheduler extrem lang und jedes dieser Items hat zum Update ein Worker-Thread im Scheduler initialisert.

[Onkelandy]

Danke für die Rückmeldung Sisamiwe bezüglich des Triggerns auf Basis des parent items. Macht Sinn. Und prinzipiell ist es genau so wie du geschrieben hattest. Da nun aber auch andere Items ein "gestern" haben könnten, hab ich bei mir das Struct in ein Unteritem "wertehistorie" gesteckt. Dann muss man die relativen Itemangaben mit einem weiteren Punkt bestücken, also zB sh....db statt sh...db

Wildcards funktionieren nicht wirklich, aber normale substring Vergleiche. Meine Logik sieht nun so aus, muss ich aber noch ne Zeit testen.

if not hasattr(logic, 'all_items'):
    logic.all_items = items.return_items()

for item in logic.all_items:
    if not "wertehistorie" in item.property.path:
        pass
    elif sh.now().strftime("%H") == "0" and sh.now().strftime("%M") == "0" and ("wertehistorie.gestern" in item.property.path or "wertehistorie.vorwoche" in item.property.path):
        item(1)
    elif sh.now().strftime("%d") == "1" and "wertehistorie.vormonat" in item.property.path:
        item(1)

logic.yaml:

wertehistorie:
    filename: wertehistorie.py
    crontab:
    -   init+200
    -   '0 0 * *'

[z1marco]

Hallo Michael,

ich versuche gerade in Deinem struct noch die Auswertung stündlich zu ergänzen. Das fällt mir echt schwer. Könntest Du mir dabei behilflich sein. Wie würdest Du die stündliche Auswertung über Dein Struct machen?
Ich würde den crontab auf stündlich setzen: crontab = 0 * * * = 1
Aber die Berechnung mit shtime macht mir Kopfzerbrechen.

Hast Du auch eine Visualisierung auf die Verbrauchswerte? Was nutzt Du da?

Gruß und Danke

P.S.: Deine restlichen Werte werden wunderbar in die DB geschrieben. Super Lösung.

[Sisamiwe]

Hallo z1marco,

mir ist noch nicht wirklich klar, was du machen willst.

Bei mir gibt es immer ein Item, dass mit dem Zählerstand oder ähnlichem versorgt wird. Bspw so:

%YAML 1.1
---
stromzaehler:
    bezug:
        energie:
            name: Wirkarbeit Bezug total
            type: num
            sml_obis: 1-0:1.8.0*255
            sml_prop: valueReal
            eval: round(value / 1000, 2)
            database: init
            struct: wertehistorie_total

Darin wird das struct auch angezogen.

Das struct von mir ist so angelegt, dass alle Items, die einen Verrauch bis JETZT haben, durch das Zählerstandsitem getriggert werden und somit neu berechnet werden. Dafür sorgt der

eval_trigger: ..

wertehistorie_total:
    name: Struct für Wertehistorie total
    heute:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.today(), 'im')) + 'i', str(shtime.time_since(shtime.today(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: yes

    woche:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: yes

    monat:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: yes

    jahr:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: yes

Somit werden diese Items immer aktualisiert, sobald der Zählerstand sich ändert. Warum sollen diese Items auch noch stündlich aktualisiert werden?

Die anderen Items, die einen ehemaligen Verbrauch anzeigen, ändern sich nur mit Wechsel der Tages-, Monats- oder Jahresgrenze. Auch diese Items müssen sich nicht alle Stunde aktualisieren. Denn der Verbrauch von gestern ist im 9.00 Uhr noch der gleiche wie im 10.00 Uhr oder 11.00 Uhr.

Was meinst Du mit

stündliche Auswertung

[z1marco]

Hallo Michael,

danke für Deine Geduld. So langsam verstehe ich Deinen Ansatz. Ich hatte vorher mit der Zeitlogik gearbeitet und auch die stündlichen Werte. Ich hatte ein Diagramm welches den Tagesverlauf zeigt und dort sieht man dann schön wann die Heizung oder andere Verbraucher am Tag angeschaltet wurden. Dafür wurden die stündlichen Werte verwendet. Das ganze hatte ich immer nur für die letzten 3 Tage. Ich muss da nochmal drüber nachdenken.

Wie hast Du Deine Werte visualisiert.

Gruß Marco

[z1marco]

Hi Michael, Onkelandy,

das mit stündlich hab ich verworfen. Ich hab aber das Gefühl, seit ich dieses struct eingeführt hab, läuft smarthomeng mit längerer Laufzeit nicht mehr. Schaltbefehle kommen nicht mehr auf dem KNX an. Nach einem Neustart geht es wieder. In der Smartvisu Monitor Smarthomeng gehen die Threads auf 33 und Systemload auf 0,58.
Habt Ihr eine Idee wie ich das eingrenzen kann und wo ich noch was prüfen kann? Bin nicht sicher ob es daran liegt, nur eine Vermutung.
Das struckt nutzte ich nur für die Verbrauchsitems.

vielen Dank Euch für die Unterstützung

[bmx]

Naja was erwartest Du? Jedes mal wenn der Zähler sich ändert, gibt es 4 Datenbankabfragen und die brauchen halt Zeit. Wenn Du dieses Struct mehrfach nutzt, dann vervielfacht sich das natürlich.

Wozu mußt Du jedesmal bei Zähleränderung den Jahresstand neu berechnen?
Vielleicht sollte man sich fragen wozu man diese Werte eigentlich braucht? Nur für die Visu? Wozu eine solche Genauigkeit? Reicht es da nicht einfach bei Bedarf die Werte neu zu berechnen?

[Onkelandy]

Die Lösung hab ich ja schon gepostet: https://knx-user-forum.de/forum/supp...55#post1516755

Dadurch gibt es nur einen Scheduler Task der zu Mitternacht ausgeführt wird.

[Sisamiwe]

Da nun aber auch andere Items ein "gestern" haben könnten, hab ich bei mir das Struct in ein Unteritem "wertehistorie" gesteckt. Dann muss man die relativen Itemangaben mit einem weiteren Punkt bestücken, also zB sh....db statt sh...db

Wildcards funktionieren nicht wirklich, aber normale substring Vergleiche. Meine Logik sieht nun so aus, muss ich aber noch ne Zeit testen.

Danke für den Vorschlag. Ich versuche das noch nachzuvollziehen, denke auch verstanden zu haben, wie es funktionieren soll. Aber so ganz bin ich noch nicht dabei.

Dein Item sieht bspw so aus:

%YAML 1.1
---
stromzaehler:
    bezug:
        energie:
            name: Wirkarbeit Bezug total
            type: num
            sml_obis: 1-0:1.8.0*255
            sml_prop: valueReal
            eval: round(value / 1000, 2)
            database: init

            wertehistorie:
                struct: wertehistorie_total

Richtig?

Mit der Logik machst du folgendes:

if not hasattr(logic, 'all_items'): logic.all_items = items.return_items()

Es wird für die Logik eine persistente Variable erstellt, in der alle Items sind.

for item in logic.all_items: if not "wertehistorie" in item.property.path: pass

Wenn "wertehistorie" (= Name des Unteritems mit dem struct) nicht im Pfad des Items vorkommt, dann fertig.

elif sh.now().strftime("%H") == "0" and sh.now().strftime("%M") == "0" and ("wertehistorie.gestern" in item.property.path or "wertehistorie.vorwoche" in item.property.path): item(1)

Wenn "wertehistorie" im Itempfad und Stunden und Minuten zur Zeit der Logikausführung = 0 und ("wertehistorie.gestern" oder "wertehistorie.vorwoche") im Itempfad, dann wird das Item auf "1" gesetzt, also getriggert.

Ist meine Interpretation korrekt?
Wenn ja, warum triggerst Du "vorwoche" um 0:00? das müsste doch "woche" sein, oder?

[Msinn]

Ohne das im Detail mitverfolgt zu haben. Eine Logik müsste eigentlich nur auf woche triggern und bei der Ausführung einfach die bisherigen Wochen-Werte auf die Vorwoche Items kopieren bevor sie ihre eigentlichen Berechnungen durchführt... oder habe ich die Diskussion misverstanden?

[Onkelandy]

Gemäß https://knx-user-forum.de/forum/supp...99#post1508399 ist es Vorwoche. Hab mir aber nicht übermäßig viel Gedanken dazu gemacht. Ansonsten Sisamiwe alles so wie du geschrieben hast. Ließe sich bestimmt noch optimieren.

Msinn hat auch Recht, dass man die Wochenwerte immer eine Ebene weiter nach unten kopieren könnte. Selbes natürlich auch mit mit den anderen "minusX" Werten.

[kaiwerner]

Hallo zusammen,

ich weiß nicht ob ich hier jetzt out of topic bin. Sorry.
Ich benutze auch einige Berechnungen an Items die, ähnlich wie die Verbrauchsauswertung, mit crontabs stündlich und / oder tageweise getriggert werden.
Wenn jetzt zum Stunden- oder Tageswechsel 60-70 Scheduler triggern reichen die aktuellen 5 Worker nicht aus und es wird ein neuer Worker erzeugt.
Da die Abarbeitung der getriggerten Scheduler aber innerhalb der 60 Sekunden von _worker_delta erfolgt wird jede Stunde, bei erneuten triggern, ein weiterer Worker erzeugt.
Durch die Änderung von msinn lib.scheduler: Implemented restart of SmartHomeNG if number of worker… werden die _restart_on_num_workers (30 Stück) nach einem Tag erreicht und ein Neustart ausgeführt.

Habe ich das richtig verstanden? Ist das so gewollt? Sind die ca. 70 Schedulern die zum Stundenwechsel triggern zuviel? Wäre es nicht besser die Worker zu begrenzen und die Queue weiter abzuarbeiten, wenn wieder einer frei ist? Oder habe ich da was nicht durchschaut?

Vielen Dank.

[Msinn]

die aktuellen 5 Worker

Wenn Du aktuell nur 5 Worker hast, Tut Dein Scheduler nicht viel (oder fast nichts). Die Erhöhung der Anzahl Worker-Threads ist seit jeher (smarthome.py) implementiert. Ab 20 Worker-Threads wurde gewarnt, dass es evtl. zu Problemen kommen kann (und evtl. auch tut. Siehe diverse Threads hier im Forum dazu, z.B. zum HUE Plugin). Neu ist nur, dass ab 30 Threads neu gestartet wird, statt zu warten bis SmartHomeNG sich "festfräst" und nicht mehr reagiert.

Durch die Änderung von msinn lib.scheduler: Implemented restart of SmartHomeNG if number of worker… werden die _restart_on_num_workers (30 Stück) nach einem Tag erreicht und ein Neustart ausgeführt.

falsch, sonst hättest Du bisher schon keine 5 Worker sondern Warnungen, dass Du die 20 Worker-Threads überschreitest.

Habe ich das richtig verstanden?

zum Teil

Ist das so gewollt?

Ja

Sind die ca. 70 Schedulern die zum Stundenwechsel triggern zuviel?

Nein, es sei denn Du hast einen Raspi 1 o.Ä. im Einsatz und/oder Deine Tasks brauchen Ewigkeiten um ihre Berechnungen durchzuführen.

Wäre es nicht besser die Worker zu begrenzen und die Queue weiter abzuarbeiten, wenn wieder einer frei ist?

Genau da passiert doch. Deshalb wird nur ein Worker-Thread je Minute erzeugt und nur, wenn keiner der existierenden Worker-Threads idle ist. (Das ist übrigens seit Urzeiten so).
Du läufst also nur in Probleme, wenn Deine durch crontab ausgelösten Berechnungen jeweils länger als eine Minute benötigen.

[kaiwerner]

Danke für die Erklärungen.

ich kenne diese Probleme und Beiträge "Needing more worker threads..."

Vor allem wollte ich Deine Schedule Commit's auf keinen Fall kritisieren.
Ich hatte vor den Änderungen immer so um die 60 Worker-Threads und keine Probleme damit. Diese haben sich genau wie jetzt, nach einem Neustart, einer nach dem anderen Aufgebaut. Aber halt da eingependelt.

Anfangs bin ich von einem Plugin-Problem ausgegangen. So wie das Verbindungsproblem bei HUE-Plugin. Doch Abhilfe schaft bei mir nur, die stündlichen Scheduler nicht zu starten.

Ich habe auf meinem Testsystem folgende Logeinträge.

smarthome-details.log:2020-06-23 00:00:00 INFO lib.scheduler Adding worker thread. Total: 20
smarthome-details.log:2020-06-23 00:00:00 INFO lib.scheduler Adding worker thread. Total: 20
smarthome-details.log:2020-06-23 01:00:00 INFO lib.scheduler Adding worker thread. Total: 21
smarthome-details.log:2020-06-23 01:00:00 INFO lib.scheduler Adding worker thread. Total: 21
smarthome-details.log:2020-06-23 02:00:00 INFO lib.scheduler Adding worker thread. Total: 22
smarthome-details.log:2020-06-23 02:00:00 INFO lib.scheduler Adding worker thread. Total: 22
smarthome-details.log:2020-06-23 03:00:00 INFO lib.scheduler Adding worker thread. Total: 23
smarthome-details.log:2020-06-23 03:00:00 INFO lib.scheduler Adding worker thread. Total: 23
smarthome-details.log:2020-06-23 04:00:01 INFO lib.scheduler Adding worker thread. Total: 24
smarthome-details.log:2020-06-23 04:00:01 INFO lib.scheduler Adding worker thread. Total: 24
smarthome-details.log:2020-06-23 04:56:23 INFO lib.scheduler Adding worker thread. Total: 25
smarthome-details.log:2020-06-23 04:56:23 INFO lib.scheduler Adding worker thread. Total: 25
smarthome-details.log:2020-06-23 05:00:00 INFO lib.scheduler Adding worker thread. Total: 26
smarthome-details.log:2020-06-23 05:00:00 INFO lib.scheduler Adding worker thread. Total: 26
smarthome-details.log:2020-06-23 06:00:00 INFO lib.scheduler Adding worker thread. Total: 27
smarthome-details.log:2020-06-23 06:00:00 INFO lib.scheduler Adding worker thread. Total: 27
smarthome-details.log:2020-06-23 07:00:00 INFO lib.scheduler Adding worker thread. Total: 28
smarthome-details.log:2020-06-23 07:00:00 INFO lib.scheduler Adding worker thread. Total: 28
smarthome-details.log:2020-06-23 08:00:00 INFO lib.scheduler Adding worker thread. Total: 29
smarthome-details.log:2020-06-23 08:00:00 INFO lib.scheduler Adding worker thread. Total: 29
smarthome-details.log:2020-06-23 09:00:00 INFO lib.scheduler Adding worker thread. Total: 30
smarthome-details.log:2020-06-23 09:00:00 INFO lib.scheduler Adding worker thread. Total: 30

Auffällig ist das es meist zum Stundenwechsel ist und danach sind die idle Threads immer eins mehr.
In der Tasks werden auch nur DB-Abfragen ausgewertet, das sollte keine Ewigkeiten brauchen.

Das Du für mich vielleicht noch einen Ansatzpunkt wie ich dem Problem zu leibe Rücken kann?

Danke