Während mit dem Skript aus meinem letzten Post zwar meistens alle 5 Sekunden ein aktueller Wert kam, habe ich gelegentlich nur alle 10 bis 30 Sekunden einen neuen Wert erhalten.
Inzwischen habe ich den (bzw. zumindest einen 
) Fehler gefunden und eine verbesserte Version erstellt:
>D
res=0
scnt=0
;Script to read Dataset F009 with 9600 baud
>F
;count 100ms
scnt+=1
switch scnt
case 2
;set sml driver to 300 baud and send /?! as HEX to trigger the Meter
res=sml(1 0 300)
res=sml(1 1 "2F3F210D0A")
;1200ms later \> Send ACK and ask for switching to 9600 baud in programming mode
case 14
res=sml(1 1 "063035310D0A")
;200ms later \> Switching sml driver to 9600 baud
case 16
res=sml(1 0 9600)
;200ms later ask for SOH R2 STX F009 ETX BCC CR LF
case 18
res=sml(1 1 "0152320246303039031E0D0A")
;after every 8000ms \> restart sequence
case 80
scnt=0
ends
>B
->sensor53 r
>M 1
+1,3,o,0,9600,STROM
1,1.7.0(@1,Strombezug,KW,Rein,3
1,2.7.0(@1,Einspeisung,KW,Raus,3
#
Alles anzeigen
Das Problem war wie folgt:
- Im alten Skript ist alle 5 Sekunden die gleiche Schleife abgelaufen
- Nach 2,2 Sekunden wurde der Zähler aufgefordert, das Datenset F009 zu senden
- Dann hat es eine Zeit t gedauert, bis der Zähler den Datensatz gesendet hat
- Das Senden des Datensatzes hat mit 19200 baud dann 0.4s gedauert
In Summe hat der ganze Vorgang teilweise etwas über 5 Sekunden gedauert und die Schleifen haben sich überschnitten. Bei so einer Überschneidung kam es wohl gelegentlich vor, dass Datensätze nicht ganz gesendet wurden oder nicht richtig gelesen werden konnten. Hier ein Beispiel, wie das auf der Konsole bei einem Dump aussah:
19:11:16.089 : 81.7.26(-4.5*Deg)
19:11:30.812 : 91.7(9.3ibsc>SR@<%oQg/.n+w^sV LvRa\ uZ>n&Q}UsgbTF.F(00000000)
19:11:30.837 : 0.0.0(020150833)
Im Beispiel war das Senden des Datensatzes noch nicht zu Ende und der Zähler hat bereits mit dem Senden des nächsten Datensatzes begonnen.
Das spannende dabei ist, dass der Gesamtvorgang pro Schleife mit 19200 baud länger dauert als mit 9600 baud. Die Ausgabe des Datensatzes selbst dauert bei19200 baud mit 0.4s nur halb so lange wie bei 9600 baud mit 0.8s. Dafür dauert es mit 19200 baud kurioserweise länger, bis der Zähler nach der Aufforderung beginnt den Datensatz zu schicken.
Ich habe nun 3 Veränderungen am Skript vorgenommen:
- Ich habe die Lesegeschwindigkeit auf 9600 baud umgestellt, was in Summe schneller als mit 19200 baud ist
- Ich sende die Aufforderung zum Senden des Datensatzes jetzt schon nach 1,8s und nicht erst nach 2,2s
- Ich wiederhole die Schleife nicht alle 5s, sondern alle 8s
Die 8s habe ich gewählt, da der Gesamtvorgang in meinen Tests bisher nie länger als 8s gedauert hat und ich die Werte in meiner Überschusslade-Lösung mit evcc nur alle 10s abrufe.
Beim Debuggen ist mir auch noch aufgefallen, dass man die Register mit sml in Tasmota auch wie folgt auslesen kann:
res = sml[1.7.0]
print Rein %res%
res = sml[2.7.0]
print Raus %res%
Hat zwar nur zwei statt drei Nachkomastellen, wäre für meine Zwecke aber an und für sich ausreichend.
Falls meine aktuelle Skriptversion im Praxistest dann doch noch Probleme macht, werde ich mal versuchen, gezielt die beiden Register 1.7.0 und 2.7.0 auszulesen. Aktuell kenne ich die genaue Syntax dafür aber noch nicht. Im Elster Zähler geht das wohl mit <SOH>R5<STX>1.7.0()<ETX><BCC>
Ich hoffe, das Skript hilft auch anderen Nutzern, die bisher das Problem hatten, dass der Siemens TD 3511 nur alle 5 Minuten die Werte aktualisiert hat (da im Standard der komplette Datensatz mit 300 baud gesendet wird)
