Logik für Tagesverbrauch aus Zählerstand

[stonie2oo4]

ch hab mir hier ne kleine Logik gebastelt die evtl. auch andere interessieren könnte und natürlich nehme ich auch sehr gern Verbesserungsvorschläge der Profis hier entgegen .
Erst mal kurz zu dem was vorhanden ist. Ich hab hier mehrere Modbuszähler die verschiedene Teile unseres Hauses messen.
Diese schreiben im 10min Takt über das Modbusgateway von Masifi (Danke für die tolle Hardware) ihren Zählerstand auf den Bus.

Nun, was wollte ich erreichen?? Im ersten Step, wollte ich erst mal alle Zählerstände addieren, damit ich dann einen "Gesamtzählerstand" vom Haus habe.
Ich hätte diesen auch vom Wechselrichter auslesen können, aber hier müsste ich dann vom WR -> RS485 zu TCP Wandler -> EVCC -> Edomi -> Bus.
Und da mir hier einfach viel zu viele Zwischenstationen drin sind habe ich mich für die andere Variante entschieden.
Die Lösung hierfür ist übrigens nicht auf meinem Mist gewachsen, dafür hat mir mumpf im Logikmodul Thread den richtigen Anstoß gegeben (Danke nochmals).

Als nächstes kam ich gestern Abend auf die Idee, ich könnte doch auch den heutigen Verbrauch über eine Logik auswerten. Einmal zur Anzeige und mit diesem lassen sich später auch in Grafana die Charts einfacher darstellen. Möglich dass dies auch anders geht, aber ich hab noch nichts in der Richtung gefunden bzw. hin bekommen.
Aber hierzu später mehr.

Ich versuch das ganze mal mit Screenshots zu zeigen und schreib evtl. noch ein bisschen meine Gedanken dazu .
Als erstes mal die Hauptseite der Logik, hier ist auch der erste Punkt bei dem ich mir nicht ganz sicher bin was das beste Verhalten bei "Logikauswertung" und "Logik-Trigger" ist.
Mein Gedanke zur "Logikauswertung" war das ich will das erst beide Eingänge ein Zählerstand anliegen haben sollen, bevor es weiter geht, da ansonsten am Schluss ein zu geringes Ergebnis ermittelt werden könnte, was ich nicht will und vermutlich auch später in Grafana komisch aussehen würde.

Den "Trigger" habe ich auf der Standardeinstellung belassen, hier wird die Häufigkeit einfach über die Zählerstände gesteuert, also alle 10min, evtl. 2mal, da ja 2 Eingänge belegt sind.
Screenshot 2023-08-11 211601.png


Die Eingänge sind recht unspektakulär, hier wird das bestehende KO vom Modbusgateway weiter verwendet (Auf richtigen Datentyp achten).

Screenshot 2023-08-11 211631.png

Eingang 2 the same:
Screenshot 2023-08-11 211650.png

Und beim Ausgang (ganz unten im letzten Block) kommt dann die Addition der beiden Eingangs-Werte ins Spiel:
Screenshot 2023-08-11 211705.png


Nun wird im Prinzip diese Logik so oft wiederholt, bis alle Zählerstände aufaddiert wurden, ich zeig grad mal noch von der letzten Logik den Eingang 1, der Rest ist ja immer gleich. Hier wird dann auch der Ausgang mit dem KO für den Gesamtzählerstand belegt. Ich empfehle hier erst einmal mit Zwischenergebnissen zu rechnen und diese interne Verknüpferei erst ganz am Schluss einzubauen. War auch ein Tipp von mumpf und war wirklich Gold wert .
Hier wurde eben einfach das Ergebnis der Logik 11 wiederverwendet:
Screenshot 2023-08-11 214247.png




Nun kommen wir zur Logik für den heutigen Verbrauch. Als erstes habe ich mir überlegt wie ich zu diesem Wert komme.
Und im Prinzip ist es ja Zählerstand heute "minus" Zählerstand gestern.
Zählerstand heute ist ja kein Problem, dieser wird ja wie oben beschrieben regelmäßig ermittelt.
Also brauchen wir Zählerstand gestern und müssen diesen ~24h speichern.
Ich hab mich dafür entschieden den Wert um 23:55 zu schreiben. Ich hatte erst 00:00 aber nach ein bisschen überlegen kam ich zum Entschluss dass das evtl. suboptimal ist, wenn der Wert nicht vor oder = Mitternacht wieder von vorne anfängt zu zählen. Könnte dann in Grafana komisch aussehen, muss ich aber noch testen und spielt hier momentan auch nicht die große Rolle. Eure Meinungen oder Erfahrungen dazu sind mir herzlich Willkommen.

So, nun haben wir die Schaltzeit, easy peasy über die integrierte Zeitschaltuhr. Nun müssen wir aber noch zu dem Zeitpunkt den aktuellen Zählerstand auf den Bus schreiben und speichern. Da kam mir die TOR Funktion in den Sinn. Also TOR für Zählerstand öffnet sich WENN Zeitschaltuhr GLEICH 1.


Abgesehen von der Schaltzeit blieb diese Logik auf Grundstellung. Hab ich nun nach mumpfs Empfehlung angepasst.
zeitschaltuhr Übersicht.png




Nun kommen wir zum TOR. Hier ist aber auch wirklich alles klasse beschrieben, es hat einfach so auf Anhieb geklappt. Wirklich genial, ich muss das einfach immer wieder Loben .Hab ich ebenfalls nach mumpfs Empfehlung angepasst.

Hier wird eingestellt dass das Tor sofort nach öffnen wieder schließt und das beim öffnen der Eingangswert gesendet wird.
Also hier der Gesamtzählerstand. Und somit wird auch sichergestellt das dieser nur einmal während dem öffnen des TORs weitergeleitet wird.
Tor Übersicht.png





Der erste Eingang ist wie man sieht der Dateneingang, in unserem Fall der errechnete Zählerstand von der oberen Logik (Wieder auf DPT achten).

Screenshot 2023-08-11 215910.png



Am 2ten Eingang wird unserer Toreingang definiert. hier kommt das Signal der Zeitschaltuhr drauf (wieder intern verknüpft).

Screenshot 2023-08-11 215952.png


Und hier der Ausgang, sollte selbst erklärend sein.
Screenshot 2023-08-11 220027.png

[stonie2oo4]

Hätte nicht gedacht, das es so lange wird . Aber der letzte Logikblock fehlt noch .


Also hier ermitteln wir dann den Heutigen Verbrauch, dieser wächst natürlich über den Tag.
hier werden wieder 2 Eingänge benötigt, wie oben beschrieben Zählerstand Heute und Zählerstand gestern.
Screenshot 2023-08-11 222503.png


Der erste Eingang ist wieder intern verknüpft mit dem heutigen Zählerstand aus der aller ersten Logik.
Screenshot 2023-08-11 222446.png



Und hier ist der ermittelte Zählerstand von Gestern von unserer TOR Logik. Diesen Wert habe ich NICHT intern verknüpft, was ja theoretisch möglich wäre. ABER wenn ich ihn intern verknüpfe hab ich hier unten die Option nicht: "Eingangswert vorbelegen".
Und hier möchte ich das der Wert im nicht flüchtigen Speicher landet. Ich hab in der Doku dazu nichts gefunden ob dies mit internen KOs möglich ist, lasse mich aber gerne eines besseren belehren
Den Aufwand betreibe ich weil ich ja den Zählerstand gestern auch über einen Stromausfall, oder programmieren des Gateways hinaus erhalten möchte. Sonst kommt es ja einen Tag lang zu Datenmüll.


Screenshot 2023-08-11 222514.png


Und hier wieder der Ausgang, eine einfache Subtraktion und schon haben wir unser gewünschtes Ergebnis .
Screenshot 2023-08-11 222528.png


Ich hoffe ich konnte dem ein oder anderem mit dieser kleinen Anleitung ein bisschen helfen. Bei mir steht als nächstes auf dem Plan mit dieser Logik den "Heutigen Netzbezug", "Heutige Einspeisung", evtl. "Heutige Erzeugung" (bekomm ich momentan schon vom WR), den "heutigen Eigenverbrauch" und den Heutigen Wasserbrauch zu ermitteln.
Und dann werden diese Tageswerte in meine influxdb geschoben und per Grafana hübsch angezeigt.

Diese Addition-Geschichte von den Zählerständen hatte ich vor einiger Zeit auch schon für die Leistung umgesetzt. Also man hat hier echt wahnsinnig viele Möglichkeiten und ich kratze hier grad mal an der Spitze. Das was ihr hier geschaffen habt, Hardware wie Software, ist einfach der Hammer .

[mumpf]

Hi Ben,

danke für die Blumen... ich finde es schön, wenn das Logikmodul auch mal in nichttrivialen Szenarien verwendet wird. Du hast das auch so gut gemacht, dass ich kaum noch Anmerkungen habe.

Den "Trigger" habe ich auf der Standardeinstellung belassen, hier wird die Häufigkeit einfach über die Zählerstände gesteuert, also alle 10min, evtl. 2mal, da ja 2 Eingänge belegt sind.

Ja, bei der Einstellung wird immer beim Telegrammeingang berechnet, also wie Du vermutet hast, 2 mal. Wenn Du das nicht willst (weil es evtl falsche Zwischenergebnisse gibt), kannst Du auch "bei folgenden Eingangstelegrammen" benutzen und nur Eingang 1 anclicken.

Da kam mir die TOR Funktion in den Sinn

Das ist auch genau richtig so. Du hättest bei der Zeitschaltuhr auch nur ein EIN-Signal schicken können und bei dem TOR auf "Tor geht sofort wieder zu" clicken. Dann ist das Tor nicht eine Minute lang auf und sendet mögliche Eingangswerte auf den Ausgang. Bei einer Auflösung von 10 Minuten wirst Du das Problem nicht haben, aber falls Du öfters rechnen würdest, könntest Du mehrere Ergebnisse zwischen 23:55 und 23:56 auf den Ausgang bekommen. Bei "Tor geht sofort wieder zu" bekommst Du genau einen Wert.

ABER wenn ich ihn intern verknüpfe hab ich hier unten die Option nicht: "Eingangswert vorbelegen".

Das ist auch richtig so. Du musst bedenken, die Verknüpfung mit einem "fremden" KO (Du nutzt das auch so, dass Du die KO vom Modubus-Modul verknüpfst, die das Logikmodul ja gar nicht kennt) kann man nicht einfach so die Werte im nichtflüchtigen Speicher speichern und nach dem Neustart wieder laden. Diese Werte würden dann ja ins "fremde" KO geladen und könnten da irgendwas auslösen, was absolut ungewollt ist. Vor allem, wenn diese "fremden" KO Eingänge für irgendwas anderes sind. Wenn man also ein KO speichern will, muss das ein Logikmodul-Eingang des speichernden Kanals sein. Deswegen musst Du das korrekterweise extern über GA verknüpfen.

Interne KO-Verknüpfungen gibt es ja sonst nicht so im KNX, deswegen ist das auch Neuland für mich, aber ich möchte das schon möglichst seiteneffektfrei implementieren und die anderen Module der vorliegenden Hardware (das Logikmodul ist ja in fast allen unseren Geräten drin) nicht negativ beeinflussen bzw. kein Fehlverhalten provozieren.

Danke für Deine Anleitung und viel Spaß mit den Folgeprojekten, das hört sich alles spannend an.

Viele Grüße,
Waldemar

[stonie2oo4]

Ja, bei der Einstellung wird immer beim Telegrammeingang berechnet, also wie Du vermutet hast, 2 mal. Wenn Du das nicht willst (weil es evtl falsche Zwischenergebnisse gibt), kannst Du auch "bei folgenden Eingangstelegrammen" benutzen und nur Eingang 1 anclicken.

Mhh, ich hab das jetzt mehrmals gelesen, aber glaube immer noch nicht richtig verstanden 😅.
Das mit den 2maligem Trigger ist klar. Klingt logisch.
Die Option das man nur auf bestimmte Eingänge reagiert hab ich zufällig gestern auch in meiner Reschere in der Doku nachgelesen, ist mir auch einleuchtend.

Aber möchte ich nicht auf alle Änderungen der Eingänge reagieren?
Also wenn sich Eingang 1 (Zwischenergebniss der vorherigen Logik) ODER Eingang 2 (nächster Zählerstand) ändert?
Wäre es da nicht kontraproduktiv nur auf einen Eingang mit dem Trigger zu reagieren?

Das ist auch genau richtig so. Du hättest bei der Zeitschaltuhr auch nur ein EIN-Signal schicken können und bei dem TOR auf "Tor geht sofort wieder zu" clicken

Die Möglichkeit habe ich auch gesehen war mir aber ehrlich gesagt unsicher ob es funktioniert 😅.
Ich wusste nicht ob das TOR immer wieder auf ein neues TRUE reagiert, oder ob ich einen Wechsel von FALSE auf TRUE benötige, deswegen auch die Einstellung bei der Zeitschaltuhr mit dem Ein und Aus.
Aber eigentlich müsste ich doch mit der Einstellung im TOR, das nur auf das schließen reagiert wird ebenfalls verhindert werden, das es länger offen bleibt. Also das es nur einmal offen ist, beim Zustandswechsel von TRUE auf FALSE.
Bitte berichtige mich falls der Gedanke falsch ist, weil das doppelte senden möchte ich vermeiden.

Das ist auch richtig so

Dann ist ja perfekt ☺️.

Danke für Deine Anleitung und viel Spaß mit den Folgeprojekten, das hört sich alles spannend an.

Danke auch. Ja es hat echt super Spaß gemacht das umzusetzen.
Und ich dachte vielleicht kann das noch jemand anders gebrauchen, oder es dient einfach als Anregung was so möglich ist.

[mumpf]

Aber möchte ich nicht auf alle Änderungen der Eingänge reagieren?

Ich glaube, Du möchtest das, wissen kannst nur Du es . Im Allgemeinen ist es bei Summen kein Problem, auf jedes Telegramm zu reagieren, weil dann auch am Ende die Summe rauskommt. Aber stell Dir mal vor, Du hast einen Quotient A/B, B wird viel häufiger gesendet als A und kann auch sehr klein werden. Du weißt aber, dass das Ergebnis vom Quotient nur dann richtig ist, wenn der aktuelle A-Wert kommt. Dann würdest Du den Trigger auf A legen.

Aber eigentlich müsste ich doch mit der Einstellung im TOR, das nur auf das schließen reagiert wird ebenfalls verhindert werden, das es länger offen bleibt. Also das es nur einmal offen ist, beim Zustandswechsel von TRUE auf FALSE.

Da gibt es noch ein Mißverständnis deinerseits (oder meine Doku ist nicht klar genug):
Du musst Dir das TOR am besten wie ein Gartentor oder eine Tür oder sonst was reales vorstellen. Wenn es offen ist, geht jedes Telegramm, dass am Eingang reingeht, auch hinten raus. Dein TOR ist eine Minute lang offen, alle Telegramme, die in dieser Zeit am Eingang eintreffen, werden auch am Ausgang gesendet.Wenn solange das TOR offen ist, kein Telegramm empfangen wurde, wird auch keines am Ausgang gesendet. Das ist das normale Torverhalten.

Mit den Einstellungen am TOR kannst Du noch 2 besondere Zeitpunkte beeinflussen: Der Augenblick, in dem das TOR aufgeht und der, in dem es zugeht. Was man möchte, hängt vom Anwendungsfall ab und ist nur im Detail wichtig (und für Dein Szenario ist nur eines von beidem wichtig):
Wenn das TOR aufgeht, kann man einen bestimmten Wert (AN oder AUS) oder den am Eingang anliegenden Wert an den Ausgang senden.
Wenn das TOR zugeht, kann man entsprechend das gleiche machen. Damit erzeugt man ein zusätliches Telegramm und kann damit folgeaktionen triggern. In Deinem Fall die Berechnung der Differenz zu gestern.

Ich wusste nicht ob das TOR immer wieder auf ein neues TRUE reagiert, oder ob ich einen Wechsel von FALSE auf TRUE benötige,

Auch hier hilft es in Telegrammen zu denken: Wenn das TOR auf ist, kann es nicht nochmal aufgehen, wenn es zu ist, nicht nochmal zugehen. Wenn es sich selbst sofort schließt, funktioniert es folgendermaßen: Es öffnet sich mit TRUE, führt die Aktionen aus, die es beim öffnen machen soll, schließt sich sofort wieder und führt die Aktionen aus, die es beim schließen machen soll. Dann ist es natürlich geschlossen und wird nichts tun, wenn ein erneutes FALSE kommt. Aber es wird natürlich wieder aufgehen, wenn ein erneutes TRUE kommt.

Gruß, Waldemar

[mumpf]

Um Dich noch komplett zu verwirren : Du willst beim Tor schließen nicht wirklich den Eingangswert senden. Du willst eine 1 senden, die den Ausgangkskonverter für EIN triggert und der Deine Berechnungen macht. Dass es bei Dir funktioniert, liegt daran, dass Du für den Eingangswert beim Eingangskonverter gesagt hast, jeder Wert liegt im Intervall und somit wird jeder Wert zu einer 1 konvertiert.

Gruß, Waldemar

[stonie2oo4]

Aber stell Dir mal vor, Du hast einen Quotient A/B, B wird viel häufiger gesendet als A und kann auch sehr klein werden. Du weißt aber, dass das Ergebnis vom Quotient nur dann richtig ist, wenn der aktuelle A-Wert kommt. Dann würdest Du den Trigger auf A legen.

Ok, hab jetzt ein bisschen drüber nachdenken müssen, aber glaub ich hab’s jetzt verstanden 😁.
Danke für die Erklärung.

Mit den Einstellungen am TOR kannst Du noch 2 besondere Zeitpunkte beeinflussen: Der Augenblick, in dem das TOR aufgeht und der, in dem es zugeht. Was man möchte, hängt vom Anwendungsfall ab und ist nur im Detail wichtig (und für Dein Szenario ist nur eines von beidem wichtig):

Die Doku ist übrigens klasse. Das ganze ist (für mich) einfach ein recht komplexes Thema und man kann es einfach an so vielen Stellen beeinflussen. Ich glaub das kann man auch einfach nicht alles super detailliert dokumentieren.

Ich hab es nach deiner Erklärung jetzt so abgeändert das ich per Zeitschaltuhr nur noch ein Ein um 23:55 schreibe.
Und das TOR hab ich abgeändert, das es sofort wieder zu geht und beim öffnen der Eingangswert gesendet wird. Das ist beim drüber nachdenken tatsächlich die sicherer Art es umzusetzen.
Bzw. fühlt es sich so eher richtig programmiert an 😉.

Ich werd das gleich mal oben in meiner Beschreibung abändern.

Um Dich noch komplett zu verwirren

Ein bisschen 😂.

[mumpf]

Ein bisschen 😂.

War natürlich nicht ernst gemeint. Für Summen, vor allem wenn die Werte selten kommen (wie bei Dir alle 10 Minuten), ist es unkritisch und Du brauchst die ganzen Feinheiten nicht. Ich wollte Dir (und anderen, die hier mitlesen) nur Hintergrundinfos geben, falls Du mal was komplizierteres machen willst.

Gruß, Waldemar

[stonie2oo4]

Find ich auch total klasse von dir. Auch wenn ich nicht immer alles gleich verstehe ist das total interessant.
Und wenn man sich dann mal später Gedanken zu einer Lösung macht, erinnert man sich bestenfalls daran das man schon mal was darüber gelesen hat.

[stonie2oo4]

Ich hab das ganze jetzt schon wie ich sehe tatsächlich ein ganzes Jahr in Betrieb und soweit läuft das eigentlich ganz gut.
Nur ab und zu läuft leider etwas schief und ich finde die Ursache nicht.
Es geht eigentlich um 2 Probleme.
Das erste sieht folgendermaßen aus:
Screenshot 2024-08-31 161516.png

Aus irgend einem Grund ist das Ergebnis viel zu groß und ich kann auch nicht einordnen wieso, das geht dann bis 0 Uhr und dann passt es wieder. Da wird der neue/alte Zählerstand ja weg gespeichert.
Ich weiß ich hab da was rumgedocktert aber ich kanns nicht mehr nachstellen. Ist übrigens kein Einzelfall, hatte ich dieses Jahr nun 3mal.
Was ich heute versucht habe und alles blieb gut:
- Gerät neustarten über ETS
- Partiell programmieren
- Applikation programmieren
- Hilfsspannung 12V ausgeschalten
- Bus + Hilfsspannung ausschalten (hätte schwören können das wars)

Wüsste nicht was ich noch testen kann, aber vielleicht hat ja jemand von euch eine Idee. Wenn nicht muss ich nächstes mal besser aufpassen wenn es auftritt.
Achso, so sollte das ganze eigentlich normalerweiße aussehen, bloß sind die falschen Werte von dem Ausreißer so groß, das es oben wie ne grade Linie aussieht:
Screenshot 2024-08-31 160039.png

Was mich auch gleich zum nächsten Problem bringt, welches nur bei einer Berechnung auftritt. Wie hier zu sehen beim berechnen des Direktverbrauchs. Hier subtrahiere ich einfach Erzeugung - Einspeisung (die aus dem Diagramm). Das Problem ist, das manchmal der errechnete Wert negativ ist.
Das hängt damit zusammen das ich die Logik nur mit dem ersten Eingang triggere.
Passiert wenn nach 00:00 der erster Eingang als erstes auf 0 gesetzt wird und 2ter Eingang kommt manchmal erst danach. Da erster Eingang Berechnung triggert, kommt es zu falschem Ergebnis.
Kann man das irgendwie vermeiden?
Oder kann man nochmal eine Logik dahinter hängen die die Negativ Werte rausfiltert?


Achso, ich verwende übrigens dafür das Modbusgateway von Masifi, da ist nicht das aktuelle Logikmodul drauf.

[mumpf]

Hi Ben,

für Dein Problem 2 ist die Lösung ganz einfach. Je nachdem, wie viel später Dein Wert am Eingang 2 ankommt und wann die Folgewerte kommen, kannst Du eine Einschaltverzögerung setzen (Du rechnest ja beim EIN-Signal, oder?). Die sollte bei einem erneuten EIN nicht weiter verzögern.
Nehmen wir an, Deine Werte kommen jede Minute. Eingang 2 spätestens 5 Sekunden nach Eingang 1.
Was dann passiert: Eingang 1 Triggert, da er auf 0 gesetzt wurde. Jetzt startet die Einschaltverzögerung (z.B. 10 Sekunden). Der Wert für Eingang 2 kommt erst nach 5 Sekunden, weitere 5 Sekunden später ist die Einschaltverzögerung vorbei und die Berechnung erfolgt.

Bei dem ersten Problem wäre die Ursache schon besser rauszufinden. Mit dem Logikmodul könnte man einen Filter hinter den Ausgang schalten, der so große Werte nicht durchlässt. Einfach am Eingang den Wertintervall im gewünschten Bereich wählen und nur bei EIN den Wert vom Eingang 1 senden, sonst einfach nichts senden. Aber damit lässt Du Werte weg. Ob Du das willst, musst Du überlegen.

Gruß, Waldemar

[stonie2oo4]

Mal wieder vielen lieben Danke für deine Hilfe .
Ich habs auch mal so probiert, aber so ganz glücklich war ich nicht damit. Da die Werte zum Teil fast 5min auseinander liegen hab ich die Verzögerung auch auf 5min gestellt, somit kam das Ergebnis natürlich auch immer 5min verzögert.
Ich hab jetzt aber noch ein anderes Problem festgestellt. Erzeugung und Einspeisung werden ja addiert, beide Werte wachsen mit der Zeit.
Nur wenn Erzeugung getriggert wird, wird gerechnet. Nun kann es passieren das Einspeisung schon wesentlich älter ist, dadurch gibt es im Graph so ein auf und ab.
Obwohl das Ergebnis nur immer größer werden darf.
Screenshot 2024-09-01 192024.png

Ich hab jetzt früher angesetzt und wenn Zählerstand Einspeisung im Modbus Modul geschrieben wird, hab ich das in einer Logik ausgewertet und ein Read Request auf Zählerstand Erzeugung ausgeführt. Damit kommt dieser Wert immer kurz (1 Sekunde bis jetzt) nach dem anderen und kann die kommende Logik nicht falsch triggern.

Also Erzeugung schreibt seinen Wert nun nur noch durch dieses Read Request und somit kommt Erzeugung Heute aus der späteren Logik auch immer kurz danach wo dann gerechnet wird.

Mal die nächsten Nächte beobachten ob nun auch das Negativ-Wert Problem dadurch gelöst ist, theoretisch müsste es gehen .

[mumpf]

Gute Idee, durch den Read stellst Du ja sicher, dass der 2. Wert immer danach kommt. Wenn man 2 Werte verrechnen will, die in loser Folge kommen, aber die Reihenfolge die Berechnung stark beeinflussen kann, fallen mir folgende weitere Möglichkeiten zur Synchronisierung ein:

1. Wie oben beschrieben, durch zeitliche Verzögerung (Einschaltverzögerung), die muss größer sein, als der maximale Zeitabstand der beiden Werte.
2. Durch Synchronisation mittels Flip-Flop (Schalter). Ein Wert geht auch auf den SET-Eingang, schaltet den Schalter also EIN, der andere auf den RESET-Eingang, schaltet also den Schalter aus. Gerechnet wird immer, wenn der Schalter EIN ist (immer AUS geht natürlich auch). Hier können die Werte beliebig häufig kommen, gerechnet wird nur, wenn beide Werte erneuert wurden.
3. Durch zeitliche Taktung, die Werte gehen beliebig auf die beiden Eingänge, ein Logikkanal taktet z.B. alle halbe Stunde und triggert die Berechnung.

Aber Deine Lösung ist auch prima, wenn es funktioniert, würde ich es so lassen.

Gruß, Waldemar

[stonie2oo4]

Danke für die weitere Inspiration ☺️.
Ja ich lass das mal vorerst so, scheint ganz gut zu funktionieren.
Bin gestern echt lange dran gesessen, hab zwar noch paar andere Sache umgezogen, aber es nimmt halt doch viel Zeit in Anspruch alle Parameter von Hand einzutragen.
Es gibt halt einfach Sau viele Einstellmöglichkeiten, was es ja aber auch so genial macht 😉.
Ich hoffe für das Modbusgateway gibt es auch mal ein Update auf das neueste Logikmodul.
Der Konfigurationstransfer macht hier schon einiges einfacher ☺️.

[mumpf]

Ich hoffe für das Modbusgateway gibt es auch mal ein Update auf das neueste Logikmodul.
Der Konfigurationstransfer macht hier schon einiges einfacher ☺️.

Modbus mit SAMD oder RP2040? Beim ersteren: Nein, beim letzteren: Ja.

Unabhängig davon: Mit dem damaligen Logikmodul musst Du, wenn ich mich recht erinnere, ja sowieso alle Werte auf den Bus schicken, damals gab es noch keine internen KO-Verknüpfungen, oder? Damit kannst Du auch die Werte auf einem anderen Gerät mit einem neuen Logikmodul mit ConfigTransfer auswerten .

Gruß, Waldemar