Vorgehensweise Logikaufbau allgemein

[pewe1835]

Hallo zusammen,

ich habe gerade angefangen mich etwas mehr mit EDOMI zu beschäftigen. Leider stolpere ich ziemlich oft über kleinere und größere Fallstricke gerade was die Rechenreihenfolge oder auch die Triggerung der Berechnung betrifft.

Mal ein paar kleine Beispiele bei denen ich nicht nicht verstehe wieso die Berechnung nicht funktioniert.

Beispiel 1: Ich triggere die Ausgabe der Daten meiner Photovoltaik minütlich. Soweit funktioniert das auch. Meine Erwartung wäre, dass minütlich die nachgelagerte Berechnung ausgeführt wird und ich ein aktualisiertes Ergebnis erhalte. Leider ändert sich aber der Ausgabe von 184 nichts, die Ausgabe bleibt immer auf 0.
PV.JPG

Beispiel 2: Füllstand der Zisterne berechnen. Das funktioniert grundsätzlich auch. Allerdings bekomme ich sehr schnell hintereinander eine Ausgabe auf der gleichen Gruppenadresse (Block 150) mit unterschiedlichen Werten, obwohl die Berechnung doch eigentlich nur durchgeführt wird wenn an der Eingangsbox 138 ein neues Stromsignal ankommt. Micha (Vento66) hat mir diesbezüglich schon versucht auf die Sprünge zu helfen. Ich verstehe es aber einfach nicht.
Zisterne.JPG

Gibt es vielleicht so eine Art Programierleitfaden oder ein How-To für Dummies?

Viele Grüße

[ChrisAllgaeu]

Die Antwort ist ganz einfach. Der SENEC Baustein ist ja von mir. Der gibt, zwecks besserer Formatierung und lesbarkeit Strings am Ausgang aus. Strings lassen sich nicht mit Zahlen UND vergleichen. Dazu einfach im Quelltext des LBS den "format" Befehl (der Strings ausgibt), gegen einen "round" auswechseln....
Hätte ich im Kommentartext des Bausteines erwähnen sollen, Sorry. Das Problem liegt also nicht bei Dir....

[seppelp]

1 ist geklärt.

Beim zweiten Beispiel kommen alle Werte des unteren Strangs aus einer Quelle. Diese werden jedoch nach und nach bearbeitet. Sprich die Berechnung 142, 143 triggert 156 und die Berechnung 154,157 triggert 156. Deshalb erhältst du zwei mal Werte an deiner Ausgabebox.

Programmierleitfaden für Dummies gibt es nicht. Vielleicht helfen dir die Beispiele im Wiki: https://www.knx-home.net/wiki/index.php?title=Beispiele

[ChrisAllgaeu]

Zu deinem 2. Punkt ist eigentlich alles schon gesagt. Ich versuche es mal mit anderen Worten. Wenn Du Berechnungen parallel alsführen lassen willst. Also z.b. Block 142 und Block 154, so wird dies in der Praxis eben nicht absolut genau exakt parallel berechnet. Mal ist der eine Pfad schneller, mal der andere. d.h. du hast undefinierte Zwischenzustände (im Microsekundenbereich) bei denen beide Ergebnisse noch nicht parallel ausgeführt sind. Das triggert dann den Baustein 156 nicht genau definiert. Und das ergibt dann die beschriebenen Effekte. Lösung ist eben die gezielte Verzögerung eines Berechnungspfades um wieder in eine kontrolliert definierte Situation zu kommen.

[ChrisAllgaeu]

... haha... du warst schneller seppelp

[starwarsfan]

Hallo miteinander

Der gibt, zwecks besserer Formatierung und lesbarkeit Strings am Ausgang aus.

Warum das denn!? Wenn schon Zahlenwerte ermittelt werden, dann sollte diese auch so auf die Ausgänge kommen.

Dazu einfach im Quelltext des LBS den "format" Befehl (der Strings ausgibt), gegen einen "round" auswechseln....

Das kann aber nicht die Lösung sein würde ich sagen. Wenn's ein Update des Bausteines gibt und man nicht an die händische Modifikation denkt, wundert man sich dann, dass die Berechnungen nicht mehr funktionieren. Wenn die Formatierung als String so wichtig ist, dann wäre es keine schlechte Idee, dem Baustein weitere Ausgänge zu spendieren, welcher richtige Zahlenwerte ausgeben.

Just my two cents...

[ChrisAllgaeu]

Hallo Yves, Du hast ja Recht. Das Thema mit der String Ausgabe habe ich auch erst später bei mir in der Anlage entdeckt, als ich mit den ausgegebenen Werten rechnen wollte. Da war der LBS aber schon veröffentlicht und schon mehrfach heruntergeladen und im Einsatz. Deswegen wollte ich dann auch keine neue Version nachschieben, um dort wieder die Anwender mit veränderten Ausgangsformaten zu verärgern. Deswegen meine Überlegung, diesen kleinen Hinweis in dem Hilfetext zu schreiben, und dann den LBS neu zu veröffentlichen.

[starwarsfan]

N'abend miteinander

Deswegen wollte ich dann auch keine neue Version nachschieben, um dort wieder die Anwender mit veränderten Ausgangsformaten zu verärgern. Deswegen meine Überlegung, diesen kleinen Hinweis in dem Hilfetext zu schreiben, und dann den LBS neu zu veröffentlichen.

Grundsätzlich sollte man nie, niemals und auf gar keinen Fall irgendetwas verändern und dann mit einer bereits veröffentlichten Versionsnummer nochmal veröffentlichen! Da stellen sich mir immer alle Nackenhaare auf, denn das führt früher oder später immer zu Problemen oder zumindest Verwirrungen. Die Versionsnummer kostet nichts!

Also wenn auch nur ein Schreibfehler in der Doku korrigiert wird, dann steht das in den Releasenotes und der Release bekommt eine neue Version, ohne Diskussion. Dafür sind ja Releasenotes da und wer sich ernsthaft damit beschäftigt, liesst diese auch, bevor etwas aktualisiert wird.

Hier bei diesem Fall hast Du ja auch mehrere Optionen. Wenn Du vermeiden möchtest, dass sich das Ausgangsformat ändert, dann kannst Du all die Ausgänge, welche numerische Werte liefern, auch einfach am Ende nochmal nach aussen führen und dort mit "echten" numerischen Werten füttern. Dann läuft definitiv alles was vorher schon lief weiter und wer die numerischen Werte braucht, der nimmt eben die neuen Ausgänge.

Aber in Anbetracht dessen, dass das Strings sind, ist es ggf. auch gar kein Problem, das Format auf echte numerische Werte zu ändern. Ich meine, wenn momentan Strings heraus fallen und weiterverarbeitet werden und neu kommen echte numerische Werte, dann sollte das doch auch ootb funktionieren!? Korrigiert mich, wenn ich falsch liege. Anders herum wäre das natürlich etwas anderes...

[pewe1835]

Die Antwort ist ganz einfach. Der SENEC Baustein ist ja von mir. Der gibt, zwecks besserer Formatierung und lesbarkeit Strings am Ausgang aus. Strings lassen sich nicht mit Zahlen UND vergleichen. Dazu einfach im Quelltext des LBS den "format" Befehl (der Strings ausgibt), gegen einen "round" auswechseln....
Hätte ich im Kommentartext des Bausteines erwähnen sollen, Sorry. Das Problem liegt also nicht bei Dir....

Hi Chris,

sorry für die späte Rückmeldung. Wir waren in Urlaub.

Leider scheitert es bei mir gerade beim ändern der Befehle. Ich habe den Befehl "format" so nicht gefunden, sondern nur "number_format". Diesen habe ich gegen "round" ausgetauscht. Leider lässt sich der editierte lbs aber nun nicht mehr importieren. Stimmt an der Syntax ggf. etwas nicht, bzw. benötigt "round" andere Argumente?

Danke und viele Grüße
pewe php_senec.JPG php_senec.JPG

[ChrisAllgaeu]

Hallo Pewe,

ich hab dir mal nen Codeschnipsel angefügt, wie es mit dem round Befehl aussehen soll:

 $statusId = intval(parseValue($data["ENERGY"]["STAT_STATE"])); // Statustext
if($statusId < 0 || $statusId > count($statusarray))
logic_setOutput($id, 1, "Fehler! Status unbekannt"); // Statustext
else
logic_setOutput($id, 1, $statusarray[$statusId]); // Statustext

$akkufuellstand = round(parseValue($data["ENERGY"]["GUI_BAT_DATA_FUEL_CHARGE"]), 1);
logic_setOutput($id, 2, $akkufuellstand); // Akkufüllstand
$momentanPVerzeugung = round(parseValue($data["ENERGY"]["GUI_INVERTER_POWER"]), 0);
logic_setOutput($id, 4, $momentanPVerzeugung); // PV-Erzeugung aktuell
$momentan_hausverbrauch = round(parseValue($data["ENERGY"]["GUI_HOUSE_POW"]), 0);

Ich schicke Dir auch noch per PM eine funktionierende Variante des ganzen LBS mit dem round Befehl.

Und dann lade ich ne neue Version in den Downloadbereich mit den entsprechenden Hinweisen im Hilfetext.
Auch wenn der round wesentlich mehr Sinn im Code macht, will ich den LBS nicht einfach so geändert neu
raushauen, ume eben die Installationen, die draussen sind nicht zu "verwirren".

liebe Grüße
Chris