[TIPP] Zähler Universalbaustein

[Robosoc]

Bevor wir weiter in Code abdriften und den vergleichen. Lass uns einmal defininiere (und dazu ist jeder eingeladen mitzumachen), was wir in den Baustein drin haben wollen.

Mein Ansatz war
- Wert wird immer am Ender eine Persiode gesendet
- Es vier relevante Perioden (TAG, WOCHE, MONAT, JAHR)
- Je vollständig abgelaufener Periode wünsche ich mir den Zählerendstand und den Verbauch
- von der aktuellen Periode, die noch nicht abgelaufen ist, möchte ich jederzeit den aktuellen Verbrauch haben.

Alles andere würde ich entweder in Grafana oder in nachgeschalteten Logiken lösen wollen.
Robert hält in seiner Logik beispielsweise die letzten drei Zählerstände bereit. Verutlich matched er diese auf KNX-Adressen um sie in der CV darzustellen(korrekt Robert).

Das wäre aus meiner Sicht nicht Aufgabe dieser Logik und gehört für mich in eine eigene Logik.
Denn es bläht die Logik unnötig auf. Der nächst möchte anstelle der letzten drei Zählerstände 5...der nächste lieber gleich 12 und der wieder nächste möchte nicht die Zählerstände, sondern Verbräuche...Das alles ist über einen einfachen Multiplexer schnell und individuell gelöst. Dafür könnten wir ja auch Ergänzungsvorschlag erarbeiten.

[Robosoc]

Noch was zum mehrfachen, gleichzeitigen Triggern am Ende einer längeren Periode. Das Ganze taucht in folgenden Konstellationen auf:

1. Jahresende (3xtrigger)
2. Monatsende (2xtrigger)
3. Wochen-Ende (2Xtrigger)
4. Special: Monatsende fällt zusammen mit Ende der Wochen(3x trigger)
5. Superspecial: Monatsende fällt zusammen mit Ende der Woche auf das Ende des Jahres (4x trigger)

Eventuell könnte man durch Schwellwert-Module und Operationen basierend auf der Localtime herausfiltern, welches Ereigenis betroffen ist. Aber dadurch entstehen eine Menge zusätzliche Logikzeilen, die bei jeder Logikausführung durchlaufen werden. Ich frage mich, was schlimmer ist. Ab und an häufiger triggern, aber dafür einen recht einfachen und schnellen Logikdurchlauf. Oder kein paralleles Triggern und dafür aber jedes Mal einen recht aufwändigen Logikprozess durchlaufen.

Ich glaube es nimmt sich Beides nichts. Eventuel sollten wir das Triggern einfach um eine Sekunde versetzen:
tägliches um 23:59:56
wöchtenliche um 23:59:57
monatlich um 23:59:58
jährlich um 23:59:59.

Was meint Ihr?

[Robert_Mini]

Hallo Sven!

Zum Scope: soweit einverstanden, Vortag ist bei mir nichts anderes, als die Zählerwerte bei dir für die Zeitserien.
Der Unterschied ist nur 1sec => bei dir „end of day“ / bei mir 2s später der „Vortag“…

Was ich noch möchte:
Die Möglichkeit, werte zyklisch zu senden. Zumindest Wochen/Monats/Jahreswerte möchte ich 1x/Tag am Bus, sonst sieht man sie nach einem Reboot den Rest des Monats/Jahres nicht. Ich hab da auch in der Zeitserie kein Problem damit…

Lg
Robert

[Robert_Mini]

Zur Mehrfachausführung:
Ich würde die 2 ersten Fälle abfangen, der Rest wär mir zu kompliziert.
Zusätzlich ein paar sec verteilen-fertig.

Robert

[Robert_Mini]

Fange gerade an zu verstehen, was Du damit alles machst und bekomme beim Anlegen der Logikzelle einen Fehler:
c[k.name] is undefined

Läuft der Code so wirklich bei Dir?

Sehe zwar keinen Fehler, hab den Code trotzdem oben nochmal neu eingefügt.

Lg
Robert

[Robosoc]

Die letzten 4 Ausgänge in meiner Logik hatte ich in einer zwischenzeitliche Bastelversion auf ct stehen und dann habe ich einfach einen trigger Eingang aktiviert um zyklisch aktuelle Werte auszugeben.

Würde das nicht reichen?

[Robert_Mini]

Aus meiner Sicht ja, wenn zusätzlich intern ein Latch sicherstellt, dass nur nach Ablauf von min_interval der Wert auf den Aufgang geschrieben wird. Sonst spricht das „c“ zu oft an.
Wir reden von den Eingängen 1-8, oder?

[Robosoc]

Hallo Robert

Code: Alles auswählen

  ["Multiplexer",["$ZaehlerWoche2","$ZaehlerWoche3"],"$ZaehlerWoche3","$New1"],  
    ["Multiplexer",["$ZaehlerMonat2","$ZaehlerMonat3"],"$ZaehlerMonat3","$New1"],  
    ["Multiplexer",["$ZaehlerJahr2","$ZaehlerJahr3"],"$ZaehlerJahr3","$New1"],  
    ["Multiplexer",["$ZaehlerGes2","$ZaehlerGes3"],"$ZaehlerGes3","$New1"]

Den Block meinte ich. Also von dem würde ich sagen, dass er nicht unbedingt in die Universallogik sollte.

[Robosoc]

Wir reden von den Eingängen 1-8, oder?

Du meintest hier sicher Ausgängen statt Eingängen, oder?
Aber ich meinte in meiner Logik in Beitrag #1 die Ausgänge 9-12.
Das sind Werte, die sich innerhalb der Periode stetig ändern. Die könnte man mit dem Verhalten 't' (defintiv besser als ct) und einem Triggereingang zyklisch schreiben, allerdings werden sie dann bei jedem internen Cron- Timer- Ablauf auch geschrieben ( also im Moment zu Sylverster 3x).

Die Ausgänge 1-8 würde ich persönlich bewusst nicht zyklisch schreiben wollen. Da würde ich jetzt keinen Sinn drinnen sehen.

[Robert_Mini]

Nein ich meine schon die Ausgänge 1-8.
Hintergrund: nach einem Neustart liegen die Werte zwar wieder in der Logik vor, werden aber bis zum nächsten Ereignis (im schlimmsten Fall knapp 1 Jahr bis zum nächsten Jahreswechsel) nicht mehr an den Dispatcher durchgereicht und können daher auch nicht vom KNX per READ gelesen werden!

Daher braucht es dieses aktive Senden, wenn man die Werte am Bus (auf der Visu) anzeigen will...

In den Zeitserien ist das aber störend, deshalb habe ich auch schon an 2 Ausgänge je Wert gedacht

Den Code, den du oben zitierst braucht man, um das Senden "on change" auf ein Mindestintervall zu verlängern, ansonsten wird jeder eintreffende Zählerstand gleich auch wieder x-mal gesendet, was ich am KNX nicht brauchen kann.
=> Zählerstände werden erst am Ausgang aktualisiert, wenn der Timer mit dem Mindestintervall abgelaufen ist.

lg
Robert