Die Anregung ist eigentlich klar:
Z.Zt. ist die Syntax von setreading
setreading <devspec> [YYYY-MM-DD HH:MM:SS] <reading> <value>
Gewünscht:
setreading <devspec> [YYYY-MM-DD HH:MM:SS] <reading> <value> (<reading> <value>) ...
Warum?
Über die Diskussion um Tims "93_InfluxDBLogger.pm" wurden mir die großen Vorteile gebündelter Events klar. Es betrifft aber natürlich auch andere Notifzierungssenken, und verringert die Last auf dem System, wenn Events aggregiert werden.
Innerhalb der Perlmodulentwicklung steht hierfür der Mechanismus readingsBeginUpdate / readingsBulkUpdate / readingsEndUpdate zur Verfügung. Ich weiß jetzt nicht, ob man zur Not im Notify über direktes Perl auch diese Funktionen benutzen könnte. Am ehesten "straight forward" wäre es halt, direkt mehrere Readings zusammen setzen zu können.
Der Befehl setreading wurde meines Wissens nicht dafür geschaffen, eine Vielzahl von readings in einem device durch den Anwender manuell zu setzen.
Readings sollten Werte enthalten, die von einem device ermittelt/erzeugt/gemessen/... werden und dann als Ergebnis im device auftauchen.
Ein Modulentwickler wird readings nicht über setreading setzen, sondern die dafür vorgesehenen Mechanismen und Funktionen verwenden. Dabei kann er auch entscheiden, ob für jedes Beschreiben eines reading ein event erzeugt wird oder nicht.
Ich erzeuge z.B. im 1-Minuten und 5-Minuten-Intervall mit "at" 4 Readings, die durch Auslesung der Zählerstände am Stromzähler und am Wechselrichter entstehen, und berechne danach die 4 Werte "Solarproduktion, Netzbezug, Netzeinspeisung, Hausverbrauch". Das sind 4 Werte, die jeweils ein Tupel bilden, also zusammengehören.
Diese Werte gehen dann in den Filelogger und neuerdings über das InfluxDb-Modul in die Cloud.
Wie wäre das denn eleganter zu lösen?
Mit einer sub in einer myUtils und den in FHEM vorgesehenen Funktionen für sowas. Du erwähntest sie oben.
Okay, myUtils finde ich nun gerade nicht elegant. Aber als Bestandteil der "user-servicable Configuration" habe ich es so hingekriegt und dokumentiere mal meinen Test:
define testjob at +*00:02:00 {
my $device = $defs{"testobj"};
readingsBeginUpdate($device);
readingsBulkUpdate($device, "v1", "123");
readingsBulkUpdate($device, "v2", "456");
readingsEndUpdate($device,1);
}
Gibt es dazu noch Anmerkungen, wie es besser geht?
Hm, was hindert dich, in deine MyUtils eine Subroutine aufzunehmen, die eine beliebige Menge an Key-Value-Paaren akzeptiert und dann readings*Update darauf macht?
das wäre vermutlich zu einfach 8)
Lieber schreibt man unnötigerweise die DEF eines devices mit perl Code voll, anstatt genau den gleichen Code in die dafür vorgesehene Datei auszulagern.