Modulentwicklung Anfänger - berechnete Readings - BulkUpdate - welche Strategie?

[jual]

Ich bin gerade dabei mein erste Modul zu entwickeln und hätte dabei ein paar strategische und Verständnisfragen. Ich hoffe, dass ich hier auch ein paar Antworten bekommen, kann, da ich mich noch nicht im Entwicklungsbereicha anmelden wollte und erst einmal schauen, wie das so klappt mit der Modulentwicklung.

Vorab zum Modul. Ich habe ein Modulentwickelt, mit dem eine SMA Wallbox (EV Charger) in FHEM eingebunden werden kann. Das funktioniert alles auch schon perfekt.

Nun möchte ich gerne einige "berechnete" Werte als Readings zur Verfügung stellen, die nicht direkt von der Wallbox geliefert werden. So soll zum Beispiel ermittelt werden, wie oft die Box das Auto lädt, wenn es angeschlossen ist (PV gesteuerte Ladung). Evtl könnten weitere Werte, wie Zeitpunkt, an dem der Stecker das letzte mal angesteckt wurde usw.

Ich nutze im Modul nonBlocking und BulkUpdate. Meine Frage ist nun eigentlich, zu welchem Zeitpunkt sollte ich die notwendigen Berechnung machen und wie gehe ich damit um, wenn ich ggf. feststellen will, wie der alte Wert im Reading war und wie der neue Wert aussieht. Damit verbunden ist auch die Frage, zu welchem Zeitpunkt steht eigentlich ein Wert in hash-{READING}{meinReading} bzw. wenn ReadingsVal genutzt wird.

Grundsätzlich wäre meine Vorgehensweise wie folgt angedacht:

• BulkUpdate starten
• Werte ermitteln und mit BulkUpdate aktualisieren
• Nun die berechneten Werte ermitteln und im gleichen BulkUpdate wegschreiben

[li]BulkUpdate beenden
[/li][/list]

Die Frage ist, welchen Wert hat zum Beispiel ein Reading, wenn ich es bereits mit BulkUpdate weggeschrieben habe und der BulkUpdate-Prozess noch nicht beendet ist. Sind da noch die alten Werte im Reading und gibt es eine Möglichkeit an die neuen zu kommen? Sollte ich mir benötigte Werte aus den Readings vorher selbst zwischenspeichern? Wäre es geschickter erst den BulkUpdate Ablauf zu beenden und für die berechneten Werte einen neuen BulkUpdate Ablauf zu starten? Hilft mit hash->{CHANGED} dabei in irgendeiner Form?

Für einen kleinen Tipp, welche Strategien man am besten verfolgen sollte wäre ich euch dankbar. Gerne auch einen Verweis auf entsprechende Beiträge oder Dokus, falls ich zu ungeschickt war, entsprechende Infos über meine Suchen zu finden .

[Beta-User]

Ein Blick in fhem.pl sollte die Frage eigentlich beantworten...

Aber du hast ja die Werte bereits während der Auswertung in irgendwelchen Variablen, oder? Warum gehst du nicht her und berechnest erst alles mit den vorhandenen Variablenwerten (anstatt dann wieder indirekt darauf zuzugreifen...) und schreibst dann nicht erst am Ende alles in einem Rutsch weg?

[Wzut]

Code Auswählen Erweitern

wenn ich ggf. feststellen will, wie der alte Wert im Reading war
Solange du kein readingsBulkUpdate($hash, 'Heinz' losgelassen bzw endUpdate geht immer ReadingsVal($name bzw ReadingsNum($name , später halt via OldReadingsxxx
aber warum willst du das wissen ? Mach bitte die Aktualisierung der Readings nicht von einem alt-neu Vergleich abhängig.
Berechne und haue alles raus - der User soll die Freiheit haben selbst zu entscheiden mittels event-on-update / event-on-change ob und wann Events generiert werden. 

[KölnSolar]

events sollten schon knapp gehalten werden, da die Menge einen enormen Einfluß auf die performance hat. Wem hilft z.B. ein event auf einem reading, dass sich nie ändern kann(z.B. manufacturer, model, ser.no.....)? Dafür nehme ich schon gerne "ifchanged". Man sollte aber drauf hinweisen.

Ich bin auch der Meinung, dass bei den meisten Geräten das wesentliche vom device kommt. Zusätzliche Berechnungen .... kann der User selber machen, sofern er es wünscht. Fördert auch die Übersichtlichkeit.

Nur meine Meinung.

Grüße Markus