ich habe das Modul jetzt auch eingerichtet und es funktioniert wirklich gut! Klasse Arbeit!
Zwei Punkte habe ich allerdings, die mich ein wenig stören:
Gibt es einen Grund, weshalb nicht alle Daten aus dem SML-Telegramm dekodiert und aufbereitet bzw. in Variablen gespeichert werden? Bei mir stellt das Modul nur OBIS 1.8.0, 1.8.1, 1.8.2 und 16.7.0 dar. Im Telegramm sind aber noch deutlich mehr Informationen enthalten (z.B. Hersteller-ID, Zählernummer, Public Key etc.). Diese sehe ich auch alle, wenn ich den im Debug ausgegebenen HEX-Datensatz manuell dekodiere. Vom Modul ausgewertet werden aber nur die zuvor genannten Teile. Ist das Absicht? Falls es darum geht, Variablen zu sparen, könnte man das doch vielleicht den User über eine Einstellung im Modul entscheiden lassen, was er alles sehen möchte.
Wieso werden die Werte für die Energie im Modeul hardcoded auf 2 Stellen gerundet? Ich hätte in den Variablen schon gerne die Originalwerte, deren Darstellung ich dann bei Bedarf selbst über die Variablenprofile etc. anpasse. Falls es dafür einen Grund gibt, könnte man es ja vielleicht auch konfigurierbar machen.
Ist zwar an sich schnell angepasst, aber ich fusche nicht gerne in den Modulen anderer herum - zumal man dann bei jedem Update wieder Arbeit hat.
Ja das ist Absicht. Es macht für mich keinerlei Sinn fixe, unveränderliche Daten in Symcon abzuspeichern, die typischerweise genauso auf dem Zähler aufgedruckt sind. Dann kann ich auch kurz in den Zählerschrank gucken, wenn mich die Daten interessieren.
Eine Kilowattstunde kostet 30…50Cent. Bei 2 Nachkommastellen wird auf einen Gegenwert von 0,005€ aufgelöst. Wofür braucht man eine höhere Auflösung?
Grüße
Jürgen
Das ist ja oft so im Leben, dass der eine irgendwo einen Sinn sieht, wo der andere es nicht tut. Ich persönlich bin immer ein Freund davon, dem User zu überlassen, welche Daten er mit welcher Genauigkeit benötigt oder nicht.
Bei mir ist es zum Beispiel so, dass ich mehrere Zähler mit Lesekopf nebeneinander hängen habe. Da fände ich es schon ganz hilfreich, wenn ich sofort sehe, welcher Zähler da etwas sendet. So einen Lesekopf kann man ja auch schnell mal vertauschen - sei es nun bei der Ersteinrichtung, bei Wartungsarbeiten oder einfach weil jemand Schabernack treibt. Da hilft es mir relativ wenig, wenn ich die Zählernummer abschreibe/kenne. Schickt der Zähler die Daten mit, kann ich jederzeit nachsehen, ob es auch der Zähler ist, den ich erwarte.
Wie gesagt, ich bin immer ein Freund davon, wenn der User die Datenhoheit hat. Der Zähler liefert die Daten, soll der Anwender doch auch entscheiden können, wie er sie formatiert und wie viele Nachkommastellen er sehen möchte.
Ich muss mal sehen, ob ich mir vielleicht doch was eigenes/zusätzliches baue, was mir alle Originaldaten liefert. Oder würde es dich stören, wenn ich das Modul für mich ein wenig optimiere?
bin gerade im Urlaub. Wenn ich zurück bin, gucke ich mal was ich wie umsetzen kann.
Du kann aber auch gerne einen Changerequest auf GitHub einstellen oder mir in deinem Sinne angepassten Code per PN schicken, dann gucken wir mal, was da geht.
Grüße
Jürgen
Ok, ich muss mal sehen, wann ich dazu komme. Ich fahre auch in zwei Wochen weg und habe bis dahin noch einiges zu tun. Ich muss mich ohnehin erst mal in deinen Code reindenken. Die ganzen Bitoperationen sind ja nicht unbedingt auf den ersten Blick verständlich, zumal es im Code keine Kommentare gibt.
Ich habe auch noch nicht so die Idee, wie man das Modul aus Anwendersicht möglichst flexibel gestalten kann.
Ich glaube ich würde erst mal den gesamten SML-Inhalt zumindest im Debug anzeigen, damit man im Klartext sieht, was ein Zähler so an Daten liefert.
Was man dann davon zusätzlich in Statusvariablen ausgibt, bin ich mir noch unschlüssig. Es gibt ja eine Vielzahl von OBIS-Kennzahlen. Vielleicht macht es Sinn, in der Konfiguration eine Liste aller erkannten Kennzahlen aufzuführen und man kann dann als User anklicken, welche davon man in einer Variablen haben will. Mir persönlich würde im Moment die Zählernummer reichen, aber andere Anwender haben vielleicht Bedarf an anderen Daten.
Bzgl. der Zählernummer könnte man theoretisch auch noch einen Check im Modul einbauen, wenn sich diese ändert, dass dann z.B. die Daten nicht mehr aktualisiert werden.
Ich werde mir noch mal ein paar Gedanken machen. Wünsche dir erst mal einen schönen Urlaub!
V1.11 Option zum Anlegen fehlender Variablen, Werte werden nicht mehr gerundet
Wer sich schon immer darüber geärgert hat, dass unsinnige Variablen im Modul angelegt werden, kann jetzt aufatmen. Es gibt eine neue Option im Modul, mit der man das Anlegen neuer Variablen unterbinden kann. Wie das genau funktioniert, ist oben in der Anleitung beschrieben.
Darüber hinaus ist der Wunsch umgesetzt, dass Werte nicht mehr durch das Modul gerundet werden.
Wie immer im Module-Store zunächst als Beta erhältlich.
ich habe jetzt mal auf die aktuelle Beta mit der Option zum Anlegen fehlender Variablen gewechselt.
Ich habe die Funktion so verstanden, dass jetzt zu allen verfügbaren OBIS-Kennzahlen Variablen angelegt werden, wenn der Zähler irgendwelche Daten dazu liefert, also auch zu den Kennzahlen, die du bislang ignoriert hast (z.B. Zählernummer).
Bei mir ändert sich mit der Option allerdings nichts. An der Einschränkung auf die Typen 1-95 hast du auch nichts verändert und die Berechnung der Werte würde zu solchen speziellen Typen auch nicht passen. Scheinbar habe ich die Option dann falsch verstanden, oder? In welchen Fällen sollen damit jetzt Variablen angelegt werden können?
Hallo slummi,
ja das ist anders gemeint. Es werden genau die Variablen wie bisher angelegt. Und für alle diejenigen, die sich über überflüssige Variablen ärgern, ist die neue Funktion.
Grüße
Jürgen
Ah alles klar. Ich kann die Option also deaktivieren, damit ich nicht benötigte Variablen löschen kann, ohne dass sie vom Modul jedes Mal neu erzeugt werden.
Würde es sich dann nicht aber anbieten, auch die anderen OBIS-Typen zuzulassen?
Dazu müssten dann natürlich auch nicht numerische Variablentypen vom Modul unterstützt werden.
Ich hatte noch nicht wirklich Zeit, das mal vernünftig zu implementieren. Ich habe nur für mich quick & dirty ein paar Anpassungen vorgenommen, damit ich auch die Daten für 0.0.x, 199.130.x geliefert bekomme.
Wie schon vor einiger Zeit diskutiert, sind die Daten sicher für viele nicht interessant, da es sich um statische Daten handelt. Für mich sind sie aber ganz nützlich, damit ich prüfen kann, ob der Lesekopf auch auf dem richtigen Zähler hängt.
Vielleicht komme ich ja mal dazu, eine mögliche Anpassung für das Modul zu entwerfen. Ich hatte ursprünglich gedacht, dass man vielleicht eine dynamische Liste in der Instanz anbietet, die alle vom Zähler gelieferten Typen auflistet und wo der User dann auswählen kann, ob er die Daten in Variablen und/oder im Debug angezeigt haben will.
Aber die Variante mit dem Erstellen der Variablen und dem anschließenden Löschen (und deaktiveren der Option zum Neuerstellen) durch den User ist ja auch ganz elegant.
Ja, das Thema Zählernummer und Co. hatte ich mir mal angeguckt. Das scheint aber etwas tricky zu sein, oder ich hab es nur noch nicht durchdrungen…
Einen Teil meiner Zählernummer kann ich decodieren. Den Prefix allerdings nicht. Bin mir auch nicht sicher, ob das Vorgehen für jeden Zähler gleich ist. Habe das Thema für mich dann verworfen, da das Preis/Leistungsverhältnis nicht passt.
Wenn Du aber einen php-Codeschnipsel hast, den ich in das Modul übernehmen soll, dann mache ich das gerne.
Grüße
Jürgen
Das weiß ich leider auch nicht, ob die einheitlich codiert ist. Ich konnte sie bei mir dekodieren. Übermittelt wird die Server ID. Das ist aber im Endeffekt nur die hexadezimale Darstellung der Zählernummer. Wobei das Prefix bei mir einfach der hexadezimale ASCII-Code ist und der numerische Teil 1:1 von dezimal nach hexadezimal umgerechnet wird.
Im Zweifelsfall müsste man es einfach bei der hexadezimalen Darstellung belassen. Die ist ja in jedem Fall eindeutig und steht auch hoffentlich (wie in meinem Fall) auf dem Zähler drauf.
Wenn ich mal dazu komme, das sauber zu coden, schicke ich dir einen Pull Request.
Danke für dein Modul
Läuft einwandfrei.
Ich kann aber die Pollteit niicht ändern im Modul, egal was ich eintrage er bleibt bei 4 Sek.
Auf dem Raspi will ich es eigentlich nicht ändern, da ich denke nach einem Update wird dort der Wert nicht übernommen.
Was brauchst du als weitere Infos um mir einen Hinweis zu geben?
Mit dem Modul kannst du die Update-Intervalle nur verlängern, nicht verkürzen.
Was machst du da parallel auf dem Raspi? Das Modul kommuniziert auch direkt mit dem Sensor.
nein, es wird gar nicht abgefragt. Der Zähler sendet von sich aus. Mit der Einstellung wird lediglich die Verarbeitung der ankommenden Daten zurückgehalten, weil einige User Angst um ihre Prozessorlast hatten. Diese kann mit der Einstellung gesenkt werden.
Ich fragte deshalb weil die geloggten Daten dadurch stark ansteigen und in der Tagesübersicht bei hoher Auflösung dann nicht mehr angezeigt wird.
Eine Reduzierung der Loggingdaten habe ich noch nicht gefunden.
Die Verarbeitung wird verzögert?
Im Debug wird laufend angezeigt wie dei Daten verarbeitet werden.
Danach sollte es auch bei dir funktionieren. Bin momentan gerade unterwegs, deshalb kann ich das in der nächsten Zeit nicht ändern. Wenn du dir das zutraust, passe die Zeile selbst an. Die Änderung des Moduls reiche ich dann nach.
