Ich hänge jetzt nicht vollständig in dem Modul drin, aber ich vermute, dass das ganze mit der Zählerlogik von IP-Symcon zu tun hat. Allgemein gilt: Werden Variablen als Zähler geloggt, werden positive Deltas geloggt. Wenn du also beispielsweise innerhalb einer Stunde von 5 auf 10 ansteigst, dann auf 0 zurücksetzt und wieder bis 3 ansteigst, wären die positiven Sprünge 5 (von 5 auf 10) und 3 (von 0 auf 3), also würde für die Stunde ein Wert von 8 gelten.
So werden zumindest die aggregierten Werte wie im Graphen dargestellt. Rohdaten werden abgespeichert wie sie kommen. Das erklärt auch, warum in deinem Graphen der Wert bei ca. 6530 liegt (ungefähr 7165 - 654), was halt die Differenz darstellt. Was vielleicht leicht zu übersehen ist: Da ist ein Faktor 10 in dem Sprung. Bis 9:57 - 654,37 haben die Zahlen 3 Stellen, danach 4, was natürlich einen gewaltigen Sprung darstellt, wo auch immer der herkommt.
Wenn das alles nicht passt, dann poste gerne nochmal deine Rohdaten und hol aus, was du erwartet hättest. Für mich sieht das auf den ersten Blick aber so aus, als wenn das Modul korrekt funktioniert.
Hallo @Dr.Niels ,
erst mal danke für die Rückantwort. Anbei versuche ich die Basisdaten der beteiligten Variablen aus dem Dezember zu posten. Wie der Sprung entsteht, ist mir vollkommen klar - es werden eben die aktuellen Messwerte zu dem Zeitpunkt gegeneinander verrechnet. Die Werte bis 09:57 sind über die Funktion „Füge vergangene Werte hinzu“ - vom 01.12. bis zum „jetztigen Zeitpunkt“ entstanden. Um 10:00:42 wurde das erste mal die (Basis-) Variable der Messtelle geändert - und daher ergibt sich aus den dann aktuellen Werten die 7165,16. Der Sprung müsste aber m.E. nicht zum „ersten intern berechenten Wert“ der Messstelle entstehen, sondern ggf. zum allerersten vorhandenen Wert (also zum ersten berechnetet am 1.12. - oder eben gar nicht - weil es sich ja um eine Differenzbetrachtung der Basiswerte handelt. Ich hoffe, ich habe mich verständlich ausgedrückt
Meiner Meinung nach würde es Sinn machen, diesen „globalen Startzählerstand“ der virtuellen Schnittstelle noch auf einer weiteren internen Variable zu hinterlegen, weil dieser ja nicht wirklich in der Historienbetrachtung darzustellen ist.
Bei Rückfragen stehe ich gern zur Verfügung - ich würde euch auch Zugang zu meinem System gebem wenn das sinnvoll ist. vms_daten.zip (35,5 KB)
Ach so - die Variablen werden wir folgt in der VMS verrechnet:
Hallo @Dr.Niels ,
ich muss mich leider noch einmal zum Thema der virtuellen Messstelle melden. Entweder habe ich einen Denkfehler im Hirn, oder das Modul regiert anders als erwartet.
Hier mal win Diagramm mit der Übersicht der Einzelwerte meiner PVA’s:
Die beiden hellgrünen Kurven stellen die Einspeisung ins Netz dar, die hellroten den Bezug je Anlage und die dunkelrote den Bezug gersamt. Eigentlich hätte ich jetzt erwartet, dass sich auf der virtuellen Messstelle „Einspeisung total“ über Mittag ein Einspeisewert ergibt - aber das ist nicht der Fall. Hier die Definition der VM:
Dein Bezug scheint ja höher als deine Einspeisung zu sein, damit kommt halt kein posiviter Wert zustande und die virtuelle Messstelle bleibt bei 0. Das Modul „merkt“ sich auch die bisherige Differenz, damit bleibt es auch gegen 11, wenn die Einspeisung mal hoch geht, auf 0.
Hallo @Dr.Niels - zunächst mal danke für sie schnelle Antwort aber: …nun, das stimmt m.E. so nicht. Im Zeitraum von ca. 9:30 bis ca. 11:30 habe ich definitiv eine Einspeisung - der Bezug liegt hier bei 0 und wird vor der Einspeisung von Strom ins öffentliche Netz durch Eigenverbrauch gedeckt. Demzufolge erwarte ich von der virtuellen Messstelle für meine „Einspeisung“ in diesem Zeitraum auch, dass die entsprechende Einspeisung dort registriert und dargestellt wird. Es geht hier ja nicht um „totalen“ Bezug+Einspeisung je Tag oder noch längere Zeiträume, sondern um Bezug und Einspeisung je Zeiteinheit, wenn ich das richtig verstanden habe. Andernfalls würde die Bilanzierung der Verbräuche/Einspeisungen der virtuellen Meßstellen nicht für Auswertungen und Abrechnungszwecke verwendet werden können…? Und die Zeiteinheit wird - sofern ich das verstanden habe - ja von der Änderungen des „Leitmerkmals“ der primären Meßstelle abgeleitet. Je Änderung des Wertes an dieser Stelle sollten doch die abhängigen Änderungen verrechnet werden - oder sehe ich das falsch?
Vielleicht sind deine Variablenbenennungen für mich irreführend aber müsstest du nicht die Einspeisung minus des Verbrauch rechnen und nicht so wie bei dir minus totaler Netzbezug?
Hallo da8ter,
ja, das mit den Variablenbenennungen ist schwierig.
Hier noch mal die Aufstellung meiner Variablen und Einstellungen für die virtuellen Meßstellen:
PVA 1 - Bezug
PVA 1 - Einspeisung
PVA 2 - Bezug
PVA 2 - Einspeisung
Dabei gilt für alle: Es sind „totale“ Zähler, die fortlaufend geführt werden und bei denen kein „Rücksetzen“ je Tag erfolgt - das war die erste Herausforderung, da ich für die PVA1 eigentlich nur Tageswerte habe. Das habe ich aber über das Modul „Zählerspung“ mit einer eigenen Anpassung der Berechnungsvorschrift gut gelöst.
Dann benötige ich zwei virtuelle Meßstellen:
PVA Gesamt Bezug =
PVA 1 Bezug +
PVA 2 Bezug -
PVA 1 Einspeisung -
PVA 2 Einspeisung
PVA 1 Bezug ist die Einzelkenngröße mit der größten Änderung im Bezug und damit die Primäre Messstelle für den Bezug - und gleiches gilt für die PVA2 Einspeisung als Primäre Meßstelle.
Den realen Verbrauch kann ich bei einer Abbildung der Werte als virtuelle Meßstelle gegenüber dem Netzbetreiber nicht verwenden, da in diesen ja auch der Eigenverbrauch des erzeugten Stromes eingeht. Da ich aber die Überschüsse der PVA2, die i.d.R. höher sind als bei PVA1, gern „selbst“ im Subnetz der PVA1 verbrauchen möchte (und umgekehrt), will ich zunächst einmal für mich bilanzieren, was bei der Nutzung virtueller Summenzähler als Endergebnis da steht, bevor ich hiermit an meinen Netzstellenbetreiber herantrete…
Ach so - noch zur Ergänzung. Im Stromnetz wird wohl alle 15 minuten bilanziert, meine Werte laufen derzeit alle 5 Minuten ein… aber da fällt mir gerade auf, dass es einen Unterschied im Zeitmanagement zwischen PVA1 und PVA2 geben könnte - das werde ich direkt noch mal prüfen…
Kann natürlich sein, dass ich eine falsche Vorstellung von der Bilanzierung habe oder dass meine Formeln falsch sind, aber ich lasse mich gern belehren, wenn es jemand besser weiß.
Das Ziel der ganzen Aufwendung sollte jedenfalls ersichtlich sein.
Danke vorab für jede Art Kommentar zum Thema!
Gruss - Uwe.
Dann hilft dir die Virtuelle Messstelle leider nicht für deinen Anwendungsfall, da diese sich die negative Differenz halt merkt bis diese aufgebraucht wird und nicht nach bestimmten Zeiten zurückgesetzt wird. Die Motivation ist hier, dass die Zähler ja möglicherweise nicht synchron laufen und beispielsweise zu verschiedenen Zeitpunkten aktualisiert werden.
Wenn deine Zähler synchron laufen, dann kannst du dir das vielleicht via Rechenmodul oder Ablaufplan zusammenbasteln. Da kannst du simpel und einfach A + B - C - D rechnen und bei Änderung einer Variablen aktualisieren.
Hallo @Dr.Niels ,
…dann erst mal danke für die Antwort. Das muss ich jetzt erst einmal ein wenig sacken lassen und dann prüfen, wie ich hiermit weitermache… Das ist zwar eigentlich nicht das, was ich unter einer „virtuellen Meßstelle“ verstehe, aber das ist zunächst einmal mein Problem…
Im Sinne von virtuellen Meßstellen für den Bezug von Elektroenergie müssten die Zähler alle 15 Minuten die dann jeweils aktuellen Werte verrechnen - unabhängig von einem Aktualisierungsintervall. Aber ich werde weiter berichten, wenn sich da etwas neues ergibt.
Jetzt aber erst mal ein schönes Weihnachtsfest und einen guten Start ins neue Jahr!
Es tut mir leid, dass das Modul da nicht deine Erwartungen erfüllt hat. Prinzipiell sind wir ja aber aktuell recht aktiv im Bereich von Energiemanagement. Ohne dass ich was von der Roadmap parat hätte, könnte ich mir trotzdem vorstellen, dass hier noch neue Werkzeuge kommen, die besser auf deinen Anwendungsfall passen.
Hallo @Dr.Niels , kein Problem - ich seh’s eher sportlich. Und deswegen sind wir ja hier auch eine Community. Ich find’s eh gut, was Ihr hier so auf die Beine stellt - grosses Lob dafür (sorry, hätte ich auch eher schn mal loswerden können)! Und wenn es hier was neues gibt, bin ich bestimmt dabei. Und Ihr habt meinen Anwendungsfall vielleicht im Kopf und gebt mir eine Info dazu - und ich stell mich gern als Testkarnickel zur Verfügung!
Also - gute Zeit - und bis zur nächsten Optimierung
Gruss - Uwe.
habe über das Jahr meinen Gas Zähler über einen mdt BE-02001.02 KNX Eingang und passenden Sensor „smart“ gemacht. Der Zählimpuls kommt auch zuverlässig in Symcon an und wird in einer Integer Variable „A“ mit dem KNX Format DPT 12 gespeichert.
Kurz vor Mitternacht lasse ich den Zählerstand in eine andere Variable „B“ schreiben und alle Veränderungen werden im Archiv gespeichert.
Nun möchte ich gerne die täglich Verbrauchsdifferenz in eine andere Variable „C“ speichern und dies visualisieren. Ich dachte, dafür kann ich dieses PHP-Modul nutzen.
Doch leider ergibt das Sript immer Null als Ergebnis raus.
Wer kann helfen?
Und noch eine Frage dazu: Muss ich den Zeitpunkt der gewünschten Berechnung über ein zyklisches Ereignis selber definieren oder kann das im Modul eingestellt werden?
Alternativ: Was nutzt ihr, um den Gas Verbrauch vernünftig auszuwerten?
Hallo Fietze,
so ein ähnliches Problem habe ich auch gehabt - beim Stromzähler, der jeden Tag nur die aktuellen Verbrauchswerte liefert. Die Fortschreibung in einen Summenzähler habe ich allerdings hier über eine angepasste Version des Module „Zählerüberlauf“ umgesetzt, vergleiche folgenden Artikel:
Hier ist auch beschrieben, welche Anpassungen dort nötig waren.
Leider ist das dort bisher (noch?) nicht eingearbeitet, d.h. du müsstest ggf. das Coding des Moduls selbst anpassen…
Jetzt kommen Werte, die aber völlig unrealistisch sind.
Bisher wurden heute 10m³ verbraucht. Der Energierechner weist aber 95,14m³ und damit auch zu hohe Kosten aus.
Nur wenn ich alle Gas Felder mit einer „1“ fülle, kommenden die richtigen m³ heraus.
Der Preis stimmt dann aber nicht und ich finde dazu auch keinen erklärebaren Berechnungsfaktor
Hallo @Dr.Niels ,
über Weihnachten und in den letzten Tagen habe ich jetzt an meinem „eigenen“ Virtuellen Summenzähler gebastelt - und - ich denke, ich bin durch. Folgendes Ergebnis:
Das ganze ist zwar derzeit „nur“ ein parametrisierbares und via Aktion aufrufbares PHP-Skript und kein Modul, ich würde das aber bei Interesse trotzdem gern zur Verfügung stellen. Vielleich bastelt ja irgendwann irgendjemand mal ein Modul draus.
Ich denke, viel erläutern muss ich nicht - man sieht gut die Einzelwerte der beiden PVA’s, die Summe des Bezugs (hellblau) und die Summe der Einspeisung (gelb).
Das ganze läuft - wie das wohl bei den EVU’s auch ist - im Viertelstundentakt und aggregiert jeweils die Basiswerte der beiden PVA’s aus diesem Zeitraum - ohne „Merken“ eventueller Negativ-Differenzen von vorher. Einziges Manko ist, dass ich zwar die historischen Werte gut darstellen kann, aber den „Gesamtzählerstand“ des jeweiligen Summenzählers bei Start nicht auf den jeweiligen ermittelten Wert stellen kann - da dieser dann die komplette Logik durcheinanderhaut. Also muss ich bei Start des Zählers eben von 0 ausgehen. Es wäre schick, wenn bei „AC_AddLoggenValues“ oder „AC_ReAggregateVariable“ der jeweils letzte Wert in den entsprechenden Variablenwert selbst übernommen werden könnte. Derzeit gibt es dann eben den Schnitt zwischen dem Update der historischen Werte einerseits und dem beim Produktivlauf jeweils angepassten Variablenwert. Aber das ist nur ein Schönheitsfehler; den Startzählerstand lege ich dann wohl einfach noch auf einer weiteren Variable ab.
Mir ist schon mal wichtig, dass ich jetzt die aggregierten Daten sehen kann und mitbekomme, wie viel reale Einspeisung ich über meine Grundstücksgrenze hinaus habe, wenn ich beide Marktlokationen gegeneinander verrechne. So zum Beispiel hier:
