Ankündigung

Einklappen
Keine Ankündigung bisher.

Item mit Zeitberechnung bspw für Verbrauchsauswertung als Systemitems bereitstellen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Onkelandy
    antwortet
    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.

    Einen Kommentar schreiben:


  • bmx
    antwortet
    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?
    Zuletzt geändert von bmx; 15.06.2020, 13:20.

    Einen Kommentar schreiben:

  • z1marco
    Forums-Einsteiger

  • z1marco
    antwortet
    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

    Einen Kommentar schreiben:

  • z1marco
    Forums-Einsteiger

  • z1marco
    antwortet
    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

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Hallo
    z1marco
    Forums-Einsteiger
    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:
    Code:
    %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
    Code:
    eval_trigger: ..
    Code:
    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
    Zitat von z1marco Beitrag anzeigen
    stündliche Auswertung

    Einen Kommentar schreiben:

  • z1marco
    Forums-Einsteiger

  • z1marco
    antwortet
    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.

    Einen Kommentar schreiben:


  • Onkelandy
    antwortet
    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.
    Code:
    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:
    Code:
    wertehistorie:
        filename: wertehistorie.py
        crontab:
        -   init+200
        -   '0 0 * *'

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    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.

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Hallo
    Onkelandy ,

    Zitat von Onkelandy Beitrag anzeigen
    - 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:
    Code:
    %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.

    Zitat von Onkelandy Beitrag anzeigen
    - 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

    Einen Kommentar schreiben:


  • Onkelandy
    antwortet
    Zwei wichtige Hinweise noch zum struct oben:
    - 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.
    - 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.

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Zitat von Onkelandy Beitrag anzeigen
    Ich hab jetzt alles auf develop gezogen und passt.
    Dann passt es ja.

    Einen Kommentar schreiben:


  • Onkelandy
    antwortet
    Das einfache Ersetzen der shtime hat zu diesem Fehler geführt:
    Code:
    File "bin/smarthome.py", line 1322, in <module>
    sh = SmartHome(extern_conf_dir=extern_conf_dir)
    File "bin/smarthome.py", line 358, in __init__
    self.shtime._initialize_holidays()
    File "/usr/local/smarthome/lib/shtime.py", line 986, in _initialize_holidays
    c_logtext = self.translate('not defined')
    File "/usr/local/smarthome/lib/shtime.py", line 118, in translate
    return lib_translate(txt, vars, additional_translations='lib/shtime')
    TypeError: translate() got multiple values for argument 'additional_translations'
    Ich hab jetzt alles auf develop gezogen und passt.

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Zitat von Onkelandy Beitrag anzeigen
    Irgendeine Idee warum ich diese Fehler bei "woche" und "vorwoche" erhalte? Hab mal periphär mitbekommen, dass in der Wochenzählung einen Bug gab - kann der schuld sein?
    Ja, es gab einen Bug, der ist schon gefixed. Siehe hier

    Dann sollte es gehen.

    Einen Kommentar schreiben:


  • Onkelandy
    antwortet
    Irgendeine Idee warum ich diese Fehler bei "woche" und "vorwoche" erhalte? Hab mal periphär mitbekommen, dass in der Wochenzählung einen Bug gab - kann der schuld sein?
    Code:
    2020-05-26 14:10:37 WARNING plugins.database Database: Unknown time frame '(0, 0)'
    2020-05-26 14:10:37 WARNING plugins.database Database: Unknown time frame '(0, 0)'
    2020-05-26 14:10:38 ERROR lib.shtime time_since: Aufgerufen mit Zeitpunkt in der Zukunft
    2020-05-26 14:10:38 ERROR lib.shtime time_since: Aufgerufen mit Zeitpunkt in der Zukunft

    Einen Kommentar schreiben:

  • z1marco
    Forums-Einsteiger

  • z1marco
    antwortet
    Oh sorry Du hast Recht. Ich hab heute Nacht die Items geändert und davon sind natürlich keine von gestern in der Datenbank. Dann werde ich mal ein paar Tage warten. Danke für den Tip mit der Evaluierung in der Admin Oberfläche.

    Einen Kommentar schreiben:

Lädt...
X