SML Stromzähler per USB Schreib-Lesekopf?

[voller]

Moin Leute,
ich hab mich mal mit dem Modul an meinen beiden Easymeter Q3B via Volkszähler Lesekopf an der vorderen Infoschnittstelle versucht (Null Perl-Kenntnisse ... Ergebnis: Fhem stürzte ab...
Wat hat gehelft??
1. cat /dev/ttyUSBx | od -tx1 >> zweiwege.txt dat wat der Zähler raushaut speichern.
2. Das Ergebnis als $smlfile = "......." in 70_SMLUSB_parsertest.pl eintragen.
3. ausführen perl 70_SMLUSB_parsertest.pl (Windows) siehe da 0 Divisionsfehler mit $scaler

Hinter       
      $scaler=10 if (substr($telegramm,$length_all,4) eq "52FF");
      $scaler=1  if (substr($telegramm,$length_all,4) eq "5200");
      $scaler=1  if (substr($telegramm,$length_all,4) eq "5201");
einfach dies noch eingefügt
      $scaler=1;

Keine Abstürze von FHEM mehr...
Für den Bezug kommt dann auch ein Wert raus, den man als stimming bezeichnen kann.
Beim Rest sieht das n büschen anders aus.

Beim Q3B  sieht die Ausgabe ungefähr so aus:
1B1B1B1B01010101760551EEEFCF62006200726500000101760101074553595133420B0645535901071BB1430F010163A9AC00760551EEEFD06200620072650000070177010B0645535901071BB1430F01726201650027E3237977078181C78203FF01010101044553590177070100010800FF0101621E52FC690000000063A6A6480177070100020800FF0101621E52FC6900000000AF8A98FE0177070100010801FF0101621E520165000040C60177070100010802FF0101621E520165000000880177070100020801FF0101621E520165000072870177070100020802FF0101621E520165000000830177070100010700FF0101621B52FE55FFFD57F00177070100600505FF010101016301A00101016360D700760551EEEFD1620062007265000002017101630A8200001B1B1B1B1A01A3FF

Und der Raspi meckert im Augenblick darüber:
0xffffffff non-portable at ./FHEM/70_SMLUSB.pm line 346

Ende mit dem Zwischenbericht...

Und noch mal meinen Dank an matzefisi für die Arbeit.

Und Tschüß
Voller

[matzefisi]

Hi Voller,

danke für Deinen Input. Da ist eine neue Obiskennzahl dabei und auch neue Werte für den Scaler usw. Ich werde mir die Daten in den nächsten Tage mal in ruhe angucken und in meinen Code mit einbauen.

BTW: Ich habe deine Werte mal in den Parsertest mit aufgenommen. Neuste Version liegt gleich auf Github.

@Tom0711: Den Fehler in hexstr_to_signed32int hab ich nun wahrscheinlich auch gefunden. Anstatt **30 müsste es **32 heißen. Allerdings funktioniert dann die Anzeige der Momentanleistungen nicht mehr. SML gibt an welchen Datentyp es im Feld verwendet (int8, int16, in32 usw.) Daher werde ich die Funktion noch auf hexstr_to_signed(X)int umändern müssen. Oder kennt jemand noch einen besseren Weg in perl aus HEX ein signed INT zu bauen?

MfG
Matthias

[matzefisi]

Hi Voller,

ich bin etwas weitergekommen und habe durch Deinen Input wieder was zum SML Protokoll dazugelernt.

Code Auswählen Erweitern


Header - OK
77070100010800FF 0101 621E 52FC 69 0000000063A6A64801   Zählerstand Bezug Total       : 167186.59 kW/h
77070100020800FF 0101 621E 52FC 69 00000000AF8A98FE01   Zählerstand Lieferung Total   : 187135.41 kW/h
77070100010801FF 0101 621E 5201 65 000040C601   Zählerstand Tarif 1 Bezug     : 1.66 kW/h
77070100010802FF 0101 621E 5201 65 0000008801   Zählerstand Tarif 2 Bezug     : 1360.00 W/h
77070100020801FF 0101 621E 5201 65 0000728701   Zählerstand Tarif 1 Lieferung : 2.93 kW/h
77070100020802FF 0101 621E 5201 65 0000008301   Zählerstand Tarif 2 Lieferung : 1310.00 W/h
77070100010700FF 0101 621B 52FE 55 FFFD57F001   Momentanleistung Bezug - Voller : 322105.14 kW/h


Ich habe jetzt ein Hauptproblem identifiziert. Und zwar ist das die Behandlung der verschiedenen Datentypen. Bislang nutzte mein Modul nur signed integer 32, aber dein (und auch andere) Zähler nutzen auch z.B. signed integer 8, 16 oder auch unsigned. Z.B. ist der Wert 77070100010700FF bei Dir ein signed integer 32, aber durch einen Fehler in dem Modul mit der hex2integer Funktion wird der Wert nicht korrekt umgerechnet. Das ist bislang noch nicht aufgefallen. Ich bin aber weiterhin dran.

MfG
Matthias

[voller]

Moin Matthias,
ich hab da mal ein büschen an der Routine zum Parsen rumgeschraubt. So sieht sie jetzt bei mir aus:

Code Auswählen Erweitern


sub
SMLUSB_Parse($$)
{
  my ($hash,$rmsg) = @_;

  my $telegramm;
  my $scaler;
  my $unit;
  my $direction = "Bezug";
  my $bzt = 0;
  my $lzt = 0;

  my $length_all = 0;
  my $length_value = 0;

  my $smlfile = $rmsg;

  # Try to find a SML telegramm in the SML file

# Log3 $hash, 5, "SMLUSB: Started parsing".$smlfile ;

  readingsBeginUpdate($hash);
  $bzt = hex(substr($smlfile,244,16));
  $lzt = hex(substr($smlfile,292,16));
  readingsBulkUpdate($hash, $obiscodes{'77070100010800FF'}, sprintf("%.6f",($bzt/10000000)));
  readingsBulkUpdate($hash, $obiscodes{'77070100020800FF'}, sprintf("%.6f",($lzt/10000000)));
  readingsBulkUpdate($hash, $obiscodes{'77070100010801FF'}, sprintf("%.3f",(hex(substr($smlfile,340,8)))/100));
  readingsBulkUpdate($hash, $obiscodes{'77070100010802FF'}, sprintf("%.3f",(hex(substr($smlfile,380,8)))/100));
  readingsBulkUpdate($hash, $obiscodes{'77070100020801FF'}, sprintf("%.3f",(hex(substr($smlfile,420,8)))/100));
  readingsBulkUpdate($hash, $obiscodes{'77070100020802FF'}, sprintf("%.3f",(hex(substr($smlfile,460,8)))/100));
  if (substr($smlfile,500,2) eq "FF")
{
$direction = "Lieferung";
readingsBulkUpdate($hash, $obiscodes{'770701000F0700FF'}, sprintf("%.3f", -((4294967295 - hex(substr($smlfile,500,8)))/100)));
}
else
{
$direction = "Bezug";
readingsBulkUpdate($hash, $obiscodes{'770701000F0700FF'}, sprintf("%.3f",(hex(substr($smlfile,500,8)))/100));
}


  readingsEndUpdate($hash, 1);

  return undef;
}


Ist sehr statisch für den Easymeter QBAxxxxx aber funktioniert. Das kommt als Readings raus, die auch mit den Zählerständen übereinstimmen (Zählerstände in kW/h Leistung in W - ist Einspeisung + ist Bezug)..

Code Auswählen Erweitern


2014-08-07 12:32:03 SMLUSB powerZaehler Zählerstand-Bezug-Total: 193.569644
2014-08-07 12:32:03 SMLUSB powerZaehler Zählerstand-Lieferung-Total: 321.626311
2014-08-07 12:32:03 SMLUSB powerZaehler Zählerstand-Tarif-1-Bezug: 192.200
2014-08-07 12:32:03 SMLUSB powerZaehler Zählerstand-Tarif-2-Bezug: 1.360
2014-08-07 12:32:03 SMLUSB powerZaehler Zählerstand-Tarif-1-Lieferung: 320.310
2014-08-07 12:32:03 SMLUSB powerZaehler Zählerstand-Tarif-2-Lieferung: 1.310
2014-08-07 12:32:03 SMLUSB powerZaehler Momentanleistung: -1179.450
2014-08-07 12:32:06 SMLUSB powerZaehler1 Zählerstand-Bezug-Total: 15.152566
2014-08-07 12:32:06 SMLUSB powerZaehler1 Zählerstand-Lieferung-Total: 3325.614691
2014-08-07 12:32:06 SMLUSB powerZaehler1 Zählerstand-Tarif-1-Bezug: 13.820
2014-08-07 12:32:06 SMLUSB powerZaehler1 Zählerstand-Tarif-2-Bezug: 1.330
2014-08-07 12:32:06 SMLUSB powerZaehler1 Zählerstand-Tarif-1-Lieferung: 3324.290
2014-08-07 12:32:06 SMLUSB powerZaehler1 Zählerstand-Tarif-2-Lieferung: 1.320
2014-08-07 12:32:06 SMLUSB powerZaehler1 Momentanleistung: -1701.240


Ich hab da mal ne steile These alle Zähler des gleichen Typs haben die selbe Position der interessanten Werte im Telegramm. Sprich wenn man den Anfang des Telegramms gefunden hat kann genau bestimmt werden, welche Werte für die Position und Länge der substr-Funktion zählerspezifisch gewählt werden muss. Somit könnte man es sich sparen die weiteren OBIS-Codes im Telegramm zu finden. In Anlehnung an 21_VBUSDEV.pm

Code Auswählen Erweitern


my %VBUS_devices = (
"7751" => {"name" => "DiemasolC", "cmd" => "0100", "fields" => [
{ "offset" =>  0,"name" => "temperature_T01","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  2,"name" => "temperature_T02","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  4,"name" => "temperature_T03","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  6,"name" => "temperature_T04","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  8,"name" => "temperature_T05","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 10,"name" => "temperature_T06","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 12,"name" => "temperature_T07","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 14,"name" => "temperature_T08","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 16,"name" => "temperature_T09","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 18,"name" => "temperature_T10","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 20,"name" => "temperature_T11","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
  { "offset" => 22,"name" => "volumeflow", "bitSize" => 15,"factor" => 0.1,"unit" => "l/min"},
  { "offset" => 24,"name" => "speed_R01", "bitSize" => 8, "unit" => "%"},
  { "offset" => 25,"name" => "speed_R02", "bitSize" => 8, "unit" => "%"},
  { "offset" => 26,"name" => "speed_R03", "bitSize" => 8, "unit" => "%"},
  { "offset" => 27,"name" => "relais_R04", "bitPos" => 0, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R05", "bitPos" => 1, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R06", "bitPos" => 2, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R07", "bitPos" => 3, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R08", "bitPos" => 4, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R09", "bitPos" => 5, "bitSize" => 1 },
  { "offset" => 28,"name" => "heatquantity", "bitSize" => 32, "factor" => 0.001,"unit" => "kWh" },
]},


könnte man versuchen eine Typenliste für die einzelnen Zählertypen, die die Werte beinhaltet. (Mit dem VBUS an USB muss ich mich auch noch auseinandersetzen 
Auf http://wiki.volkszaehler.org/software/sml sind ja schon paar Telegramme zerlegt.
Ich weiß es nicht, bin wie gesagt Perl-Dummi, aber die Funktion hex( ) scheint einen Hex-String in unsigned Integer umzuwandeln.

Mal gucken wie motiviert ich bin an der Lösung mit der Telegrammparameterliste weiter zu feilen...  jetzt läufts ja bei mir. 

MfG
Volker

[matzefisi]

Hallo Volker,

vorsicht! Die Länge eines Telegramms ist nicht immer gleich! Sie wird durch mehrere Type Length Felder innerhalb eines Telegramms verändert.
Und auch der Scaler (10 hoch X) sowie die Unit (Watt, W/h, Ampere usw) werde mit im Type Length Feld übergeben. Daher wird dein Code auch nur für deinen Zählertyp funktionieren. Bzw. sobald dein Zähler z.B. meint er müsste den Scaler ändern, weil er die Werte nicht mehr korrekt Darstellen kann, könnte es ebenfalls passieren, dass Dein Code nicht mehr passt.

Ich versuche das Type Length Feld und alle anderen Variablem im Moment in meinem Parsertest vernüftig auszulesen, brauche dafür aber noch Zeit.
Mein großes Ziel ist es irgendwann alle Zähler zu unterstützen, indem ich das SML Protokoll zu 100% abbilde. Aber dazu muss ich es erstmal selbst ganz verstehen.

BTW: Ob vom Zähler ein signed oder unsigned Integer (oder anderer Variablentyp) übergeben wird, steht ebenfalls im Type Length Field.

Etwas Background: http://www.emsycon.de/downloads/SML_081112_103.pdf (Ab Seite 35 von 42 werden die Datentypen des TL-Feldes beschrieben)

Code Auswählen Erweitern


         77 Liste mit 7 Einträgen (Type Length Feld)
            07 01 00 01 08 00 FF objName 1-0:1.8.0*255 (Total Active Energy+ = Bezugsrichtung) OBIS Code
            63 01 80 status
            01 valTime (leer)
            62 1E unit (unsigned8) 1E = Wh --62 Ist hier z.B. das Type Length Feld und 1E der Wert
            52 FF scaler (int8) -1 = *10^-1 = /10 -- Hier ist 52 das Type Length Feld 52 = 8 bit signed integer.
            59 00 00 00 00 01 91 F2 60 value (1*16^6+9*16^5+1*16^4+15*16^3+2*16^2+6*16^1+0*16^0)/10 = 26341984/10 =  2634198,4 Wh = 2634,1984 kWh
            01 valueSignature (leer)

Quelle: http://volkszaehler.org/pipermail/volkszaehler-dev/2012-September/002002.html



MfG
Matthias

[voller]

Moin Matthias,
ok, das SML-Protokoll vollständig auswerten ist schlußendlich der richtige  Ansatz. 
Für meinen Quick & Dirty-Ansatz muss sich jeder User erstmal die Telegramme selber anschauen um die Werte zu extrahieren.
Ausgehend von der Vermutung, dass ein Zählertyp eines Herstellers während der Einsatzzeit nicht sein Telegrammstil ändert, wäre das ein einmaliger Aufwand die passenden Werte für das Parametrisierungs-Array zusammen zu suchen. Die nächste Vermutung wäre, dass jemand, der sich die Arbeit gemacht hat, dies mitteilen würde um das Array typenspezifisch zu erweitern. 
Anderer Ansatz, das Array wird während der Initialisierungphase aufgebaut, in dem man das Telegramm Byte für Byte auswertet. Dann sollte nach jedem neu laden des Moduls eine Anpassung auf den Zähler erfolgen. Mal gucken ob ich in die Richtung was machen will. Aber ich denke mal nicht so bald. Ich brauch noch ne VBUS-Auswertung (USB RS 232 Resol), n Kaco usb rs232 Modul,  AEconversion Auswertung und Parametrisierung (usb RS485), ne S0 Auswertung via (Firmata ?) und ne Buderus-Auswertung (I2C via Firmata ?).  Hab ich bis jetzt noch alles noch nicht. Deshalb gibt sich der alte Mann erstmal mit Quick & Dirty zufrieden, so lange die Ergebnisse stimmen. 
Aber Deine Anregungen waren Gold wert für die Auswertung der USB-Leseköpfe. 

MfG
Volker

[voller]

Moin Matthias,
isch hab mir mal paar Gedanken übers Protokoll gemacht. Die Annahme ist wie folgt:
Das TL-Feld ist das Low-Level-Protokoll (Transport Layer) mit dem der String bzw. das Telegramm in Werte zerlegt werden kann. Die möglichen Werte  und deren Bedeutung:
Merkmal weiteres Byte: 8-Fx           #Das nächste Byte gehört mit zum TL Feld
Merkmal kein weiteres Byte: 0-7x   #Dies ist das einzige TL-Byte
Octet String: 0x oder 8x                  #Die nächsten x Byte (bei 0x)  sind ein Octet-String bei 8x geht die Definition mit dem nächsten Byte weiter
Boolean: 4x                                     #Die nächsten x Byte sind ein Boolean-Wert
Integer: 5x oder Dx                         #Die nächsten x Byte (bei 0x)  sind ein Integer bei Dx geht die Definition mit dem nächsten Byte weiter
unsigned: 6x oder Ex                      #Die nächsten x Byte (bei 0x)  sind ein unsigned bei Ex geht die Definition mit dem nächsten Byte weiter
List of: 7x oder Fx                            #Die nächsten x Byte (bei 0x)  sind ein unsigned bei Fx geht die Definition mit dem nächsten Byte weiter
weiters Byte mit typdef : Cx            #
reserviert: 1x oder 9x # z.Z. keine Verwendung
reserviert: 2x oder Ax # z.z. keine Verwendung
reserviert: 3x oder BX # z.Z. keine Verwendung
Die x die Länge wird bei mehreren Byte für die Definiton durch hex ( x(1).x(2)....x(n)) ermittelt.

Beispiel:
0000 1B1B1B1B    # ESC-Sequenz Start Telegramm
0008 01010101   # Protokolversion 1
0010 76                # List of 5 Byte
0011 0551F414BD   # Irgendwas
0016 62         # int Byte
0017 00         # Wert 0
0018 62         # int Byte
0019 00         # Wert 0
001a 72         # List of 2 Bytes
.........
wenn man das Telegramm  bis zum nächsten "1B1B1B1B" nach diesem Motto zerlegt wird man am Ende ein Array von Werten haben deren Bedeutung man an Hand folgender Bedingung aufschlüsseln muss (ständiges senden über die Info Schnittstelle ist ein "Response without Request"):
Zum Einsatz von SML über Transportmedien mit geringer Performance1, können
SML-Nachrichten ohne den Rahmen einer SML-Datei und ausschließlich als
,,Response without Request" versendet werden. Dieser Anwendungsfall ist explizit
von der Applikation zu definieren.

Diese Bedingung lässt erahnen, dass jeder Zählerhersteller im weiteren sein eigenes Süppchen kocht. 
Das macht eine universelle Auswertung zumindest schwierig.

Ich hoffe ich hab da keinen Denkfehler.... 

MfG
Volker

[SK]

Hallo zusammen,

ich bin ein begeisterter Nutzer von FHEM und habe bereits viele Beiträge über Leistungsmessung gelesen. Primär ging es dabei um Strom oder Gas/Wasserzähler.

Ich habe hier aber einen Wärmemengenzähler ultraheat xs der mit einer optischen Schnittstelle nach IEC 870 ausgestattet ist. Jetzt war die Idee über lirc die Signale des Wärmemengenzählers analog der von Euch in dem Forum diskutierten USB IR Schnittstelle standardisiert zu übertragen.  Somit müsste der Datentransfer ja möglich sein.

Somit meine Frage:
Gibt es in Modul das nach  IEC870 Daten auswerten kann?
Hat es in dieser Richtung bereits Erfahrungen im Forum- ich habe bisher nichts gefunden- Habe aber das Gefühl das Ihr thematisch am nächsten seit.

Gruß und schönes WE
SK


Hardware: RPI mit über GPIO Pin 18 angeschlossenen IR Empfänger. Die Signale kommen bereits mode2... an.

[matzefisi]

Hallo zusammen,

@Volker: Bislang ist mir noch kein Zähler untergekommen, der sein eigenes Süppchen kocht. Bislang konnte ich noch jeden Zähler anhand der SML Dokumentation sauber auswerten. In meinem Modul fehlt bislang nur das korrekte Interpretieren des TL Feldes. Das war nur sehr statisch geregelt. In dem Parsertest Script habe ich das jetzt schon etwas besser gelöst, bin aber noch nicht fertig.

@SK: Die IEC870 kenne ich bislang nocht nicht. Das Modul 70_SMLUSB versteht bislang nur SML im Binärformat per serieller Infrarotschnittstelle. Also z.B. /dev/ttyUSB0. Hast Du denn schon Daten über die Infrarotschnittstelle auslesen können? Wenn ja, kannst Du hier mal ein Beispiel posten? Theoretisch kann SML auch Gas, Wasser und Wärmewerte weitergeben.

MfG
Matthias

[Omega-5]

Hallo,
diesen Fehler

Code Auswählen Erweitern

Use of uninitialized value $scaler in division (/) at ./FHEM/70_SMLUSB.pm line 292.
Illegal division by zero at ./FHEM/70_SMLUSB.pm line 292.

hatte ich auch gelegentlich, als ich Anfang des Jahres meinen Zähler eHZ EDL21 eingebunden habe.
Ich nahm an das Lesefehler von der Schnittstelle daran Schuld waren.
Darum habe ich die Variable mit einem Wert initialisiert.

Code Auswählen Erweitern

228| my $scaler = 10;

Wahrscheinlich wäre eine Checksummenprüfung vor der Auswertung gut, doch das wird nicht so einfach sein.
Man müßte erst alles von ersten 1b 1b 1b 1b 01 01 01 01 bis zum nächsten in eine Puffer schreiben, wobei die Länge nicht vorhersehbar ist (Zählerabhängig).

Meine "Bemühungen" sind unter "Tarifumschaltung HT/NT erkennen - eHZ EDL21 - SMLUSB.pm - USB-IR-Lesekopf" zu sehen.
http://forum.fhem.de/index.php/topic,20525.msg140618.html#msg140618

Und dann habe ich da noch eine Informationsquelle zu SML-Protokoll und OBIS-Kennzahlen, zwar V1.2, aber meiner Meinung nach gut dokumentiert.
http://www.itrona.ch/downloads.html

MfG
Frieder

[voller]

Moin Frieder

Und dann habe ich da noch eine Informationsquelle zu SML-Protokoll und OBIS-Kennzahlen, zwar V1.2, aber meiner Meinung nach gut dokumentiert.
http://www.itrona.ch/downloads.html

Jupp, is endlich mal wat womit ich wat anfangen kann...
Die vielen "Dieses Telegramm kann im SMART METER unterdrückt we
rden. " darin sind aber böse...
Aber immerhin kann ich meine gesammelten Message-Strings an Hand der Doku erfolgreich händisch auswerten. 

MfG

Voller

[tommi]

Moin,

leider funtkioniert dass bei mir nur sporadisch...oder besser gesagt nur nach Shutdown Restart. Ich benutze die einfache Schaltung mit einer Fotodiode und einem Wiederstand. Das ganze wird über ein EXsys 6030 seriel to Ethernet konvertiert und in Linux per Socat als Device eingebunden. Am Terminal sehe ich das SML-Telegramm schön, nur FHEM liest es nicht. Hab auch schon versucht die Zeiten zu verändern, oder den buffer von Socat zu verändern, aber er liest es nur am Anfang und im Logfile steht danach

2014.09.05 21:15:27 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:27 5: SMLUSB: Started parsing
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 77070100010800FF
2014.09.05 21:15:27 5: SMLUSB: Reading BulkUpdate. Value > 0
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 77070100020800FF
2014.09.05 21:15:27 5: SMLUSB: Reading BulkUpdate. Value > 0
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 77070100010801FF
2014.09.05 21:15:27 5: SMLUSB: Reading BulkUpdate. Value > 0
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 77070100020801FF
2014.09.05 21:15:27 5: SMLUSB: Reading BulkUpdate. Value > 0
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 77070100010802FF
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 77070100020802FF
2014.09.05 21:15:27 5: SMLUSB: SML Telegram found: 770701000F0700FF
2014.09.05 21:15:27 5: SMLUSB: Reading BulkUpdate. Value > 0
2014.09.05 21:15:27 5: SMLUSB: Setting state
2014.09.05 21:15:27 5: SMLUSB: Parsing ended
2014.09.05 21:15:27 5: SMLUSB: Beginning of SML File found start parsing
2014.09.05 21:15:28 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:29 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:31 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:33 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:35 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:36 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:38 5: SMLUSB: End of SML found. Looking for a beginning.
2014.09.05 21:15:40 5: SMLUSB: End of SML found. Looking for a beginning.

weiß jemand Rat?? Die Werte (wenn sie denn gelesen werden) sind übrigens korrekt. Der Zähler ist ein EDL-300 Zweirichtungszähler.

[Damian]

Hallo zusammen,

ausgehend vom SMLUSB-Modul (Danke an @matzefisi) habe ich für mich einige Anpassungen vorgenommen.

Ich besitze den EMH eHZ-H-Zweirichtungszähler und eine PV-Anlage mit einem elektronischen Zähler, den ich über S0 an einen umgebauten EM-1000 von ELV angeschlossen habe. Der EMH eHZ-H sendet im Sekundentakt, dadurch ist der serielle Puffer regelmäßig übergelaufen, so dass ich ein reopen einbauen musste (System läuft unter Windows). Auch mit der Momentan-Leistung konnte ich für die Plots wenig anfangen. Dann wollte ich die beiden Zähler synchronisieren, damit saubere Logs über Produktion, Einspeisung, Bezug und Eigenverbrauch zustande kamen. Herausgekommen ist ein rudimentäres Teil, welches ereignisgesteuert funktioniert und so aussieht (siehe Anhänge).

Bei Interesse hier melden.

Gruß

Damian

[marcus42]

Hallo,

bin gerade dabei meine FHEM Installation im Hinblick auf Performance zu optimieren.
Dabei ist mir mit Hilfe von apptime aufgefallen, dass die Funktion SMLUSB_Read
pro Minute fast 3000 mal aufgerufen wird. Das erscheint mir etwas hoch ...

name           function              max  count       total        average   maxDly
Strom          SMLUSB_Read    161   509659    70227     0.14         0 HASH(Strom)

Die CPU-Load liegt bei durchschnittlich 0.25 obwohl auf der FHEM-Installation (Test-RasPi ) ausser dem Stromzähler nix läuft.

Als Attribute habe ich gesetzt :

event-min-interval .*:30
event-on-change-reading Zählerstand-Bezug-Total

Hat jemand eine Idee, wie ich das optimiert bekomme?

[jnewton957]

Hallo,

ich habe meinen Volkszähler (UDO) USB Schreibkompf zum Anzeigen gebracht.
Da ich einen 2009 eHz FW8 habe, liefert der nur den Zählerstand. Leider keinen Momentanverbauch oder Tagesverbrauch.

define zaehler USBEHZ /dev/ttyUSB0
attr zaehler interval 120
attr zaehler intervalReading 300
attr zaehler room IR-Sensor
define FileLog_power1 FileLog ./log/power1-%Y-%m.log FileLog_power1:zaehler|power1
attr FileLog_power1 room IR-Sensor
define SVG_power1 SVG FileLog_power1:power4
attr SVG_power1 label "power1 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_power1 room IR-Sensor

Ich schreibe also alle 5 Minuten einen Wert weg, der in ein monatslog geht.

Ich suche nach einer Möglichkeit, dass er einerseits alle 300 Sekunden UND alle 24 Std einen Wert wegschreibt. Ein zweites define "Tag USBEHZ /dev/ttyUSB0" führte zu einem Fehler

Dann suche ich nach einer Möglichkeit, dass er den "aktuellen" Verbauch (errechent aus (wert-vorwert)/5*60 ) errechnet. So möchte ich sehen, was ich in den 5 Minuten als durchschnitts/aktueller Verbrauch so genutzt habe.

Bin am Verzweifeln, da ich es nicht hinbekomme.

Danke für die Hilfe.

Jörg