Mag sein, dass bei dir die Datensätze gut durchlaufen, aber du hast halt nur einen Zähler.
Jeder Zähler ist etwas anderes. Ruhe kehrt nur ein, wenn wir uns wirklich penibel an den Standard halten. Sonst wird das eine Dauerbaustelle…
Ich selber lese seit 10 Jahren die Zähler aus. Bisher mit dem ASCII D0-Protokoll (Klartext).
Da gibt es leider keine Checksumme. Ich habe ständig Probleme mit den Übertragungsfehlern.
Jede Paar Wochen lösche ich fehlerhafte Werte im Archiv.
Mittlerweile habe ich mein Dekodierscript soweit verfeinert, dass ungültige Werte erkannt werden (über einen Zeitfaktor und den letzten Variablenwert).
CRC MUSS daher funktionieren. Das ist aber meine Baustelle. Du bekommst das von mir fertig geliefert.
Übrigends:
Der Modulname SML-Couter ist sehr unglücklich gewählt.
Besser wäre „SML Parser“ oder ähnlich. Schließlich liefern die Zähler auch viele andere Werte.
Aktuell habe ich meinen Zähler noch nicht per Pin freigeschaltet. Der Pin ist im Zulauf.
Dann habe ich ca. 15 Parameter, die ich weiterverarbeiten will. Von Spannungen, Ströme, Phasenwinkel etc…
Bin mal gespannt, ob das alles korrekt dekodiert wird.
Fehlt hier eventuell das demaskieren der Nutzdaten, falls die Escape Sequenz in den Nutzdaten vorkommt?
Dann könnte dadurch auch die CRC Prüfung beeinflusst werden.
Hatte ein ähnliches Thema schon mit anderen Protokollen. Nur selten ist dann gut beschrieben in welcher Reihenfolge etwas erfolgen muss.
Hat das Protokoll kein Längen Feld?
Dann könnte man nach dem Header einfach die Bytes zählen.
Wobei da auch das Problem ist, ob Escape, CRC oder füllbytes mitgezählt werden, oder auch nicht
Michael
Ich habe jetzt viele Stunden mit dem Lesen der CRC verbracht und @mischo22 ganz sicher auch. Mein persönliches Fazit ist, dass es bisher noch niemand stabil für alle Zähler geschafft hat, die Checksumme zu bilden.
Ich lasse das Thema deshalb erstmal ruhen und führe Basis-Tests ein, welche die Datensätze absichern. Dann sehen wir mal weiter, was die Erfahrungen hier mit dem Modul ergeben. Wenn es zu häufigen Problemen kommt, müssen wir weitere Maßnahmen ergreifen, sonst nicht.
V1.05 Neu: Basis-Prüfung des Datensatzes, Prüfungen abschaltbar
Ich habe die neue Beta gerade online gestellt. Hierin gibt es jetzt Experteneinstellungen, bei denen man die CRC-Prüfung einschalten und eine neue Basis-Prüfung abschalten kann.
In der Basis-Prüfung wird das Ende des Datensatzes geprüft.
nein, demaskieren muss man nur die Escapesequenz.
Die hab ich hier bei meinem Zähler nicht im stream.
Die BSI Spezifikation sagt auch eindeutig:
Die Prüfsumme ist nach CCITT-CRC16 zu berechnen. Sie wird über alle Bytes des
Datenstroms im SML-Transportprotokoll mit Ausnahme der letzten beiden Bytes (und damit ohne die Bytes der Prüfsumme selber) berechnet.
Soll heißen: Prüfsumme wird gebildet über die Rohdaten, die empfangen wurden.
ja, du hast recht, wusste ich nicht. Ich dachte das wird immer geloggt bei Aktualisierung.
Aber das regelmäßige Aktualisieren verursacht Last im System, Einträge im Log, im Webfront etc.
Muss ja nicht sein.
Bis auf das Log ist das aber vernachlässigbar. Immerhin wird Modbus auch mit 500ms gepollt.
Paresy schrieb Mal dass es egal ist.
Wenn es nicht immer gleich 500kb String Variablen sind, merkt das niemand.
Wie häufig kommen die Werte den rein?
Alle 1-5 Sekunden?
Michael
PS: Und Wert HTML-BOXen benutzt schaltet eh das VariableWatch im Log ab
Die Häufigkeit ist einstellbar. Damit kann man die Last auf das Erträgliche dimmen. Da das Modul in den Zeiten, wo keine Daten gewünscht sind, auch den Datenstrom per ReceiveDataFilter blockt, ist die Last des Systems minimiert.
Grüße
Jürgen
Wenn es um den Zähler geht, von dem Du mir den Datenstrom geschickt hast, dann kann es auch keine Nachkommastellen geben. Der angegebene Faktor ist 1000, also 1 Digit = 1 kWh.
War es nicht so, dass im SML die Werte mit einer Zahl dargestellt werden und einem Teilfaktor?
da steht dann z.B. 33512 als Wert, was durch den angegebenen Faktor geteilt werden muss, was dann 33,512 entspricht.
Das ist fast richtig. Du hast einen sogenannten Scaler. Der kann positive und negative Werte annehmen und bestimmt als Potenz von 10 den Faktor. Dazu kommt dann noch die Einheit. Diese ist typischerweise und bei Dir auch Wh. Die Darstellung in Symcon ist in kWh, wodurch sich schon ein Grundfaktor von 0,001 ergibt. Mein Hauszähler hat einen Scaler von -1. Damit habe ich 4 Nachkommastellen. Dein Zähler hat einen Scaler von 3, also einen Faktor von 1000. Dadurch hast Du keine Nachkommastellen.
Ja, ist die Stable. Hatte es aber auch mal mit der Beta versucht. Ergebnis war aber das gleiche. Habe von daher wieder zurück auf die Stable Version umgestelt.
Auf 32-bit-Systemen konnte es bei der Umwandlung von HEX in signed Integer dazu kommen, dass die Berechnung mit einer Fehlermeldung abbricht. Dieser Fehler ist in der neuen Version behoben.
Die Version ist wie immer zunächst als Beta verfügbar.
