Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Das sml Plugin und das smlx Plugin sind aktuell unterschiedlich. Ich hatte auf einem Fork weiterentwickelt, weil ich bei mir unbedingt die Checksumme mit haben wollte. Der einfachheit habe ich ein x drangehängt. Das ursprüngliche SML Plugin ist aber auch nachgezogen worden. In wie weit, kann ich derzeit nicht sagen.
@Sipple: Ich könnte noch einen Parameter swap_checksum_bytes mit einbauen, dann könnte es bei Dir klappen. Ich verstehe allerdings nicht, welcher Standard das so absegnen würde und warum dieser Zähler so von den Stadtwerken abgenommen wurde. Aber sei es drum...
Meines Wissens schon. Das war doch smlx, v1.1.0, also mit Integration der Checksummenberechnung. Ich gehe mal davon aus, dass die für "normale" Zähler funktioniert. Warum jetzt in diesem Fall da Low- und Highbyte vertauscht sind, weiss ich nicht, denn mehr als die Variablen zur CRC Berechnung wurden ja nicht geändert. Also tippe ich fast auf die ausgelagerte algorithms.py, aber die ganze CRC Berechnung ist mir zu hoch.
Verstehe ich auch nicht. Habe auch an den Holley Vertrieb geschrieben und sogar eine Antwort bekommen. Die Fehler sind auch bekannt und in neueren Geräten behoben. Nützt mir nur nichts. Ich muss morgen außerdem noch mal nen Test machen mit dem CRC Tool im Netz, das ich neulich verwendet habe. Da hat das geklappt und mir ist da nicht aufgefallen, dass die Bytes vertauscht waren.
So, ich habe das Plugin noch angepasst. Vor allem in Hinblick auf die OBIS Werte, die mein Zähler (oder auch andere) liefern, welche nicht auf *255 enden. Also z.B. die historischen Verbrauchswerte letzter Tag/7 Tage/30 Tage etc.
Die Debugging Ausgaben habe ich auch ein wenig modifiziert. Die "End read" Zeile kam gar nicht, weil sie im Sourcecode nur für den Netzwerk-Fall gültig war, der eh nicht geht. Die Checksumme wurde einmal dezimal, drei Zeilen weiter unten dann in hex angezeigt. Und noch ein paar Kleinigkeiten. Das ist Kosmetik, zugegeben.
Was mir jetzt noch nicht so gefällt ist die Darstellung des buffers und des objName in den Entry Zeilen, z.B. b'\x01\x00H\x07\x00\xff'. Die wären sehr nützlich, aber diese Darstellung ist nicht so schön, weil die format Methode alle Bytes im Bereich ASCII/UTF-8 als solche darstellt, den Rest dann als \x<byte>. Drum taucht in dem Beispiel auch ein großes 'H' auf. Perfekt sieht das in der Zeile mit dem 'Data:' Block aus. Einfach die Bytes als Hex mit Leerzeichen getrennt hintereinander weg.
Ich habe noch nicht rausgefunden wie das geht, aber ich suche weiter. Natürlich ist das nicht kritisch. Funktionell läuft es bei mir jetzt seit gestern tadellos. Werde aber weiter beobachten.
Leider werden git und ich keine Freunde mehr, was wohl an mir liegt. Ich bin zu alt für diesen ....
Ungefragt würde ich da aber eh nichts committen, deshalb erst mal hier.
So, ich habe das Plugin noch angepasst. Vor allem in Hinblick auf die OBIS Werte, die mein Zähler (oder auch andere) liefern, welche nicht auf *255 enden. Also z.B. die historischen Verbrauchswerte letzter Tag/7 Tage/30 Tage etc.
Die Debugging Ausgaben habe ich auch ein wenig modifiziert. Die "End read" Zeile kam gar nicht, weil sie im Sourcecode nur für den Netzwerk-Fall gültig war, der eh nicht geht. Die Checksumme wurde einmal dezimal, drei Zeilen weiter unten dann in hex angezeigt. Und noch ein paar Kleinigkeiten. Das ist Kosmetik, zugegeben.
Was mir jetzt noch nicht so gefällt ist die Darstellung des buffers und des objName in den Entry Zeilen, z.B. b'\x01\x00H\x07\x00\xff'. Die wären sehr nützlich, aber diese Darstellung ist nicht so schön, weil die format Methode alle Bytes im Bereich ASCII/UTF-8 als solche darstellt, den Rest dann als \x<byte>. Drum taucht in dem Beispiel auch ein großes 'H' auf. Perfekt sieht das in der Zeile mit dem 'Data:' Block aus. Einfach die Bytes als Hex mit Leerzeichen getrennt hintereinander weg.
Ich habe noch nicht rausgefunden wie das geht, aber ich suche weiter. Natürlich ist das nicht kritisch. Funktionell läuft es bei mir jetzt seit gestern tadellos. Werde aber weiter beobachten.
Leider werden git und ich keine Freunde mehr, was wohl an mir liegt. Ich bin zu alt für diesen ....
Mach doch einfach ein gist bei github auf und kopier das da rein oder alternativ sende mail an meine Adresse mit Zip im Gepäck. Dann kann ich das in das Plugin mit einpflegen.
An der Stelle, wo Du etwas in Hex dargestellt haben möchtest, kannst Du ja einen Kommentar im Quelltext reinschreiben.
2019-10-18 21:12:54 INFO Main plugin 'smlx': Metadata paramlist = '['serialport', 'timeout', 'buffersize', 'host', 'port', 'cycle', 'device', 'poly', 'reflect_in', 'xor_in', 'reflect_out', 'xor_out', 'swap_crc_bytes']'
2019-10-18 21:12:54 INFO Main plugin 'smlx': Metadata itemdeflist = '['sml_obis', 'sml_prop']'
2019-10-18 21:12:54 INFO Main plugin 'smlx': has no item-struct definitions in metadata
2019-10-18 21:12:54 ERROR Main Plugin 'smlx' exception during execution of plugin: module 'plugins.smlx' has no attribute 'Smlx'
Traceback (most recent call last):
File "/usr/local/smarthome/lib/plugin.py", line 553, in __init__
exec("self.plugin = {0}.{1}.__new__({0}.{1})".format(classpath, classname))
File "<string>", line 1, in <module>
AttributeError: module 'plugins.smlx' has no attribute 'Smlx'
2019-10-18 21:12:54 INFO Main Loading '/usr/local/smarthome/plugins/smlx/locale.yaml' to 'dict'
2019-10-18 21:12:54 ERROR Main Plugin 'smlx' from section 'smlx' exception: 'PluginWrapper' object has no attribute 'plugin'
Traceback (most recent call last):
File "/usr/local/smarthome/lib/plugin.py", line 145, in __init__
plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance, self.meta, self._gtrans)
File "/usr/local/smarthome/lib/plugin.py", line 571, in __init__
if isinstance(self.get_implementation(), SmartPlugin):
File "/usr/local/smarthome/lib/plugin.py", line 715, in get_implementation
return self.plugin
AttributeError: 'PluginWrapper' object has no attribute 'plugin'
bmx Ich hab das Plugin fast fertig. Läuft schon sehr gut.
Beweggrund #1 ist, dass ich was lernen kann und #2, dass ich weiß, dass Du nicht viel Zeit hast.
Eigentlich gibt es nur noch einen Punkt, bei dem ich noch nicht weiß, wie ich das lösen soll. Am Wochenende versuche ich das nochmal.
Was ich bisher eingefügt/geändert habe:
- Prinzipiell sind jetzt alle OBIS Codes verfügbar, nicht nur welche, die auf*255 enden.
- Eine enthaltene valTime (Zeitstempel der Nachricht) wird lesbar dekodiert und steht als neues sml_prop: actualTime zur Verfügung. Dazu gibt es auch einen neuen Konfigurationsparamter date_offset (Inbetriebnahmedatum und Zeit in seconds since epoch) für die plugin.yaml, der addiert wird, damit die korrekte Zeit angezeigt wird.
- Debug Meldungen modifiziert, zur besseren Lesbarkeit.
- Metadaten und Readme Update.
Ja, ich glaube es geht um die Warnung.
Ich habe deine SML Nachricht mal komplett in ein Excel Sheet eingetragen und "übersetzt". Ist unten angehängt. Da sieht man dann für quasi jedes Byte, was es bedeutet (soweit ich eine Erklärung gefunden habe).
Das Problem liegt in Zeile 29 und 30 in der Excel Datei (kann man auch aus der Log Warnung raus lesen).
Code:
77 list of 7
07 ff ff ff ff ff ff client id
Dummerweise fügt dein Zähler an dieser Stelle eine völlig nutzlose client id ein (ff ff ff ff ff ff), die leider auch noch genau 6 Bytes hat. Dadurch ist das Type-Length-Field vorne dran '07', bedeutet: Octet-String, 7 bytes length, wobei das TLF mitgezählt wird, also kommen eben SECHS Bytes (ff ff ff ff ff ff) danach.
Die Werte, die wir alle haben wollen, sind die OBIS Werte für z.B. Bezug, Lieferung, momentane Wirkleistung etc. Die kommen in dem Excel File ab Zeile 36 (75, list of 5). Es kommen bei dir also 5 verwertbare OBIS Werte (Hersteller Kennung, Server ID, Bezug, Lieferung, momentane Wirkleistung).
Alle diese Werte starten in dem Block mit '77 07 ........' und da liegt der Hase im Pfeffer. Die doofe client id weiter oben startet eben auch mit '77 07'.
Das plugin prüft relativ simpel auf diese Bytefolge und versucht fälschlicherweise die Bytefolge '77 07 ff ff ff ff ff ff .....' als OBIS Wert zu interpretieren, was natürlich nicht klappt, weil es eben kein OBIS Wert ist.
War spät heute Nacht, drum habe ich nur kurz mal geschaut, ob man das relativ einfach im Plugin abfangen kann. Noch hatte ich keine zündende Idee. Ich gehe noch mal in mich.
Anbei noch meine aktuelle Variante des Plugins. Könntest du mal testen (aber bitte alles alte vorher sichern) und die Log Ausgabe posten.
Was mich auch noch wundert in deinem Log sind die Zeilen mit den "Entry {...."
Außerdem steht da bei dir ein komischer Wert für 'valTime' drin. [None, 40385206]. Wird anscheinend als ZWEI Werte dekodiert, None ist dabei uninteressant (secIndex), 40385206 ist der Zeitstempel in Sekunden seit Epoch (Unixzeit). Bei mir kommt da nur der Wert (was mein Zähler streng genommen falsch kodiert, im Plugin dadurch aber leichter zu dekodieren ist). Da muss ich nochmal ran, damit die valTime auch mit [None, 40385206] richtig dekodiert wird. Falls du mein aktuelles smlx Plugin testen möchtest, kommt da wahrscheinlich keine verwertbare 'actualTime' raus. Würde mich interessieren, damit ich es evtl. leichter ändern kann.
Im Prinzip ist der Datenblock vom SML eine Art Dictionary das aus mehreren Basiseinträgen besteht (SML Messages) und das dann verschiedene Unterobjekte hat deren Teile binär codiert sind. Ich hatte schon mal angefangen das generisch zu parsen, bin aber noch nicht zum Ergebnis gekommen (smly Plugin, ist aber nicht in develop gepusht).
Im Prinzip wird derzeit ja nur nach den Schlüsseleinträgen im Datenblock gesucht die bekannt sind und die dann entschlüsselt werden können. Das davor oder danach interessiert den Parser nicht wirklich. Daher konnte das original sml Plugin ja auch Daten liefern trotz fehlerhafter Checksumme. Aktuell wird ja zumindest ein Datenpaket verworfen, wenn die Checksumme nicht stimmt. Aber eigentlich müßte man um es richtig zu machen die Daten auch nach Spezifikation parsen.
Und dann hat man solche Heulergeräte drin die eine falsche Checksummen Berechnung implementiert haben oder bei denen ein Timestamp fehlerhaft ist.
Das kann man aber nur gesondert betrachten, wenn der Hersteller, das Modell und die ggf. vorhandene Variante bekannt ist.
Im Prinzip sollte man dann aber die komplette Parsing Geschichte auslagern in ein Modul das auch ohne SHNG arbeiten kann und das man ggf. auch mit externen Daten füttern kann die aus einem Capture kommen.
Sipple Ich kann Dir gerne das smly mal schicken wenn Du da weitermachen willst ...
Könntest du mal testen (aber bitte alles alte vorher sichern) und die Log Ausgabe posten.
Was mich auch noch wundert in deinem Log sind die Zeilen mit den "Entry {...."
2019-10-24 12:35:07 INFO Main Loading '/usr/local/smarthome/plugins/smlx/plugin.yaml' to 'OrderedDict'
2019-10-24 12:35:07 INFO Main plugin 'smlx': Metadata paramlist = '['serialport', 'timeout', 'buffersize', 'host', 'port', 'cycle', 'device', 'date_offset', 'poly', 'reflect_in', 'xor_in', 'reflect_out', 'xor_out', 'swap_crc_bytes']'
2019-10-24 12:35:07 INFO Main plugin 'smlx': Metadata itemdeflist = '['sml_obis', 'sml_prop']'
2019-10-24 12:35:07 INFO Main plugin 'smlx': has no item-struct definitions in metadata
2019-10-24 12:35:07 INFO Main Loading '/usr/local/smarthome/plugins/smlx/locale.yaml' to 'dict'
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'timeout' -> using default value '8' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'buffersize' -> using default value '1024' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'host' -> using default value '' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'port' -> using default value '0' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'device' -> using default value 'raw' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'date_offset' -> using default value '0' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'poly' -> using default value '4129' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'reflect_in' -> using default value 'True' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'xor_in' -> using default value '65535' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'reflect_out' -> using default value 'True' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'xor_out' -> using default value '65535' instead
2019-10-24 12:35:07 INFO Main plugin 'smlx': value not found in plugin configuration file for parameter 'swap_crc_bytes' -> using default value 'False' instead
2019-10-24 12:35:07 DEBUG Main Using CRC params poly=4129, reflect_in=True, xor_in=65535, reflect_out=True, xor_out=65535, swap_crc_bytes=False
2019-10-24 12:35:07 INFO Main Initialized plugin 'smlx' from from section 'smlx'
Code:
2019-10-24 12:35:32 DEBUG Main Attach stromzaehler.bezug.energie 1-0:1.8.0*255 valueReal
2019-10-24 12:35:32 DEBUG Main Attach stromzaehler.bezug.leistung 1-0:16.7.0*255 value
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar