Neu: 77_SMAEM - Modul für SMA Energie Meter. Alternative zum Sunny Home Manager.

[DS_Starter]

Die Bytezählung im Modul-Regex habe ich noch der SMA-Doku angepasst.

[300P]

Habe es entsprechend umgebaut. Die Firmware Version wird nun als Reading dargestellt. Außerdem wird auch ein Reading SerialNumber generiert wenn das Attribut disableSernoInReading nicht gesetzt ist. Im anderen Fall wird die Seriennummer ja immer vor die Readingnamen integriert. Somit weiß man nun immer ob der richtige EM gelesen wird.

Hallo Heiko,

Bei mir mit EM ist jetzt alles okay.

Danke für die geduldige Codierung / Umsetzung

Gruß
300P

[DS_Starter]

Prima. Jetzt brauchen wir noch Testergebnisse von Nutzern mit HM 2.0 und neuester Firmware.
Unterstütze gerne 

LG

[MiVo69]

Bei mir sieht mit dem Home Manager mit neuester Firmware nun alles gut aus.
Ganz toll finde ich nun die Möglichkeit für jedes SMA Gerät ein Device anlegen zu können, somit auch die Seriennummer aus den Readings verbannen zu können.
Das ganze ist nun wesentlich übersichtlicher.
Vielen Dank für eure tolle Arbeit. 
Gruß Michael

[DS_Starter]

Guten Morgen,

danke for the good news Michael. 
Die Commandref hatte ich auch schon angepasst. Damit wäre die Version bereit zum einchecken.
Ich würde das im Laufe des Tages machen, sodass sie morgen früh im Regelupdate zur Verfügung steht.

@Volker, du möchtest die Version sicherlich wieder in dein GIT laden. Welche Adresse war das ? (Vielleicht lädst du es gleich aus meinem contrib dorthin)

Vermutlich wird es notwendig bzw. günstig sein alle Auslesungen im Modul auf Regex respektive OBIS Kennzahlen
umzustellen. Vielleicht setze ich mich mal daran wenn ich mit meinen anderen Projekten soweit durch bin. Nehme es mal auf meine ToDo wenn Volker einverstanden ist.
Ansonsten sehen wir ja wenn "mal wieder schnell" etwas nachgezogen werden muss weil SMA etwas verändert hat.

schönes WE+Advent,
Heiko

[RiG]

Hallo Heiko

erstmal danke für das Modul und die Anpassungen an die neue Firmwareversion.
Ich hab mir den Aufbau der OBIS Kennzahlen mal angeschaut und ein kleines Testskript gebaut das den String nach den Kennzahlen zerlegt:

Code Auswählen Erweitern

#!/usr/bin/perl
package main;

use strict;
use warnings;
use bignum;
use IO::Socket::Multicast;
use Data::Dumper;
my $socket;
$socket = IO::Socket::Multicast->new(
           Proto     => 'udp',
           LocalPort => '9522',
           ReuseAddr => '1',
           ReusePort => 0,
  );
$socket->mcast_add('239.12.255.254');
my $data;
my $status;
my $hex;
$socket->recv($data, 608);
$hex = unpack('H*', $data);
print Dumper($hex);
my $obis = {};
my $i = 56;
my $length;
#obis klassen
my $b;
my $c;
my $d;
my $e;
while (substr($hex,$i,8) ne "00000000") {
  $b = hex(substr($hex,$i,2));
  $c = hex(substr($hex,$i+2,2));
  $d = hex(substr($hex,$i+4,2));
  $e = hex(substr($hex,$i+6,2));
  $length = $d*2;
  if (144 == $b) {
    # Softwareversion
    $obis->{"1-144:0.0.0"} = hex(substr($hex,$i+8,2)).".".hex(substr($hex,$i+10,2)).".".hex(substr($hex,$i+12,2)).".".chr(hex(substr($hex,$i+14,2)));
    $i = $i + 16;
    next;
  }
  $obis->{"1:".$c.".".$d.".".$e} =  hex(substr($hex,$i+8,$length));
  $i = $i + 8 + $length;
}
$socket->mcast_drop('239.12.255.254');

close($socket);

foreach my $k (sort keys %{ $obis }) {
  printf "%s = %s\n", $k, $obis->{$k};
}


Damit könnte man dann:

Code Auswählen Erweitern

my $bezug_wirk             = hex(substr($hex,64,8))/10;
einfach mit

Code Auswählen Erweitern

my $bezug_wirk             = $obis->{"1:1.4.0"}/10;
ersetzen.

Vielleicht hilft es dir etwas wenn du das Modul auf die OBIS Kennzahlen umstellen willst.

Gruss
Andreas

[DS_Starter]

Hi Andreas,

das sieht super aus, danke. 
Das nehme ich doch gerne als Grundlage zum Einbau. An so eine Schleifenzerlegung hatte ich auch schon gedacht, deine macht das aber perfekt !

Super, dann wird die Komplettumstellung sicherlich nicht mehr allzu lange dauern.

LG,
Heiko

[Wzut]

Super Arbeit RiG, das ist genau der richtige Weg !!! Respekt

[DS_Starter]

Kann mich Wzut nur anschließen und habe die Zerlegung bereits ins Modul eingebaut.
Mit verbose 5 werden die OBIS Kennzahlen direkt im Log ausgegeben und die Firmware entnehme ich nun schon aus dem OBIS Kennzahlen-Hash.
Liegt wieder in meinem contrib.

Könnt ihr gerne testen. Den Stand würde ich auch einchecken. Die restliche Umstellung ist dann eine Fleißarbeit ... weiß nicht ob ich am WE noch dazu komme. Aber es juckt mich schon 

[300P]

Kann mich Wzut nur anschließen und habe die Zerlegung bereits ins Modul eingebaut.
Mit verbose 5 werden die OBIS Kennzahlen direkt im Log ausgegeben und die Firmware entnehme ich nun schon aus dem OBIS Kennzahlen-Hash.
Liegt wieder in meinem contrib.

Könnt ihr gerne testen. Den Stand würde ich auch einchecken. Die restliche Umstellung ist dann eine Fleißarbeit ... weiß nicht ob ich am WE noch dazu komme. Aber es juckt mich schon 

Rennt !!

[RiG]

Danke für die schnelle Umsetzung.
Mir ist noch aufgefallen das es Probleme mit der while Schleife geben könnte wenn der String nicht komplett eingelesen wird. Da sollte man evtl noch prüfen das $i nicht größer als die Länge sein kann.

[Volker Kettenbach]

Sourcecode ist im Git auf:

https://gitlab.com/volkerkettenbach/FHEM-SMA-Speedwire

und neuerdings auch wieder auf:

https://github.com/kettenbach-it/FHEM-SMA-Speedwire

[DS_Starter]

Hallo zusammen,

die Modulversion 3.5.0 ist eingecheckt (auch im contrib aktualisiert) und morgen früh im Regelupdate.

@Andreas, deinen Hinweis habe ich noch mit berücksichtigt, wobei eigentlich bereits am Anfang gecheckt wird ob mindestens 600/608 Bytes eingelesen werden.

Ich habe noch ein Hash SMAEM_obisitem am Anfang des Moduls erstellt. Dieses enthält den Beschreibungstext der OBIS Kennzahlen und wird später bei der generellen Umstellung helfen alle OBIS korrekt zuzuordenen.
Darüber hinaus sieht man mit verbose 5 nun diese Einträge:

Code Auswählen Erweitern


2019.12.14 12:49:25.174 4: SMAEM SMA_Energymeter - ###############################################################
2019.12.14 12:49:25.175 4: SMAEM SMA_Energymeter - ### Begin of new SMA Energymeter 1900212213 get data cycle ###
2019.12.14 12:49:25.176 4: SMAEM SMA_Energymeter - ###############################################################
2019.12.14 12:49:25.177 4: SMAEM SMA_Energymeter - discarded cycles since module start: 0
2019.12.14 12:49:25.178 4: SMAEM SMA_Energymeter - last update time set to: 14.12.2019 / 12:49:25
2019.12.14 12:49:25.198 4: SMAEM SMA_Energymeter - Blocking process with PID: 16894 started
2019.12.14 12:49:25.232 5: SMAEM SMA_Energymeter - OBIS metrics identified:
2019.12.14 12:49:25.234 5: SMAEM SMA_Energymeter - 144:0.0.0 -> Softwareversion -> 1.02.04.R
2019.12.14 12:49:25.234 5: SMAEM SMA_Energymeter - 1:1.4.0 -> SUM Wirkleistung + -> 2638
2019.12.14 12:49:25.235 5: SMAEM SMA_Energymeter - 1:1.8.0 -> SUM Wirkleistung + Zaehler -> 36129381480
2019.12.14 12:49:25.235 5: SMAEM SMA_Energymeter - 1:10.4.0 -> SUM Scheinleistung − -> 0
2019.12.14 12:49:25.236 5: SMAEM SMA_Energymeter - 1:10.8.0 -> SUM Scheinleistung − Zaehler -> 55232052840
2019.12.14 12:49:25.236 5: SMAEM SMA_Energymeter - 1:13.4.0 -> SUM Leistungsfaktor -> 947
2019.12.14 12:49:25.237 5: SMAEM SMA_Energymeter - 1:2.4.0 -> SUM Wirkleistung − -> 0
2019.12.14 12:49:25.238 5: SMAEM SMA_Energymeter - 1:2.8.0 -> SUM Wirkleistung − Zaehler -> 54597079800
2019.12.14 12:49:25.238 5: SMAEM SMA_Energymeter - 1:21.4.0 -> L1 Wirkleistung + -> 0
2019.12.14 12:49:25.239 5: SMAEM SMA_Energymeter - 1:21.8.0 -> L1 Wirkleistung + Zaehler -> 6327992160
2019.12.14 12:49:25.239 5: SMAEM SMA_Energymeter - 1:22.4.0 -> L1 Wirkleistung − -> 952
2019.12.14 12:49:25.240 5: SMAEM SMA_Energymeter - 1:22.8.0 -> L1 Wirkleistung − Zaehler -> 21669412680
2019.12.14 12:49:25.240 5: SMAEM SMA_Energymeter - 1:23.4.0 -> L1 Blindleistung + -> 0
2019.12.14 12:49:25.241 5: SMAEM SMA_Energymeter - 1:23.8.0 -> L1 Blindleistung + Zaehler -> 2703088440
2019.12.14 12:49:25.242 5: SMAEM SMA_Energymeter - 1:24.4.0 -> L1 Blindleistung − -> 278
2019.12.14 12:49:25.242 5: SMAEM SMA_Energymeter - 1:24.8.0 -> L1 Blindleistung − Zaehler -> 3457992960
2019.12.14 12:49:25.243 5: SMAEM SMA_Energymeter - 1:29.4.0 -> L1 Scheinleistung + -> 0
2019.12.14 12:49:25.243 5: SMAEM SMA_Energymeter - 1:29.8.0 -> L1 Scheinleistung + Zaehler -> 8515184400
2019.12.14 12:49:25.244 5: SMAEM SMA_Energymeter - 1:3.4.0 -> SUM Blindleistung + -> 0
2019.12.14 12:49:25.244 5: SMAEM SMA_Energymeter - 1:3.8.0 -> SUM Blindleistung + Zaehler -> 1911115440
2019.12.14 12:49:25.245 5: SMAEM SMA_Energymeter - 1:30.4.0 -> L1 Scheinleistung − -> 992
2019.12.14 12:49:25.245 5: SMAEM SMA_Energymeter - 1:30.8.0 -> L1 Scheinleistung − Zaehler -> 22226853600
2019.12.14 12:49:25.246 5: SMAEM SMA_Energymeter - 1:31.4.0 -> L1 Strom -> 525
2019.12.14 12:49:25.246 5: SMAEM SMA_Energymeter - 1:32.4.0 -> L1 Spannung -> 230354
2019.12.14 12:49:25.247 5: SMAEM SMA_Energymeter - 1:33.4.0 -> no item found -> 960
....


Wenn ihr "no item found" seht, dann konnte ich an Hand der Doku noch keinen Beschreibungstext für den OBIS Item finden.
Das könnt ihr gern zuliefern.

LG,
Heiko

[DS_Starter]

Die OBIS 1:33.4.0, 1:53.4.0, 1:73.4.0 konnte ich noch als die Phasen-Leistungsfaktoren identifizieren.
Außerdem habe ich durch diese Änderungen festgestellt, dass die bisherigen Readings Lx_THD Unfug sind und die Phasenstromwerte darstellen.

Das alles werde ich im nächsten Release mit korrigieren.

[DS_Starter]

Hallo miteinander,

durch die super Vorarbeit/Anregung von Andreas (RiG) habe nun etliche Neuerungen und Änderungen im Modul sehr zügig durchführen können.
Um es zu verdeutlichen ist die Versionierung auf 4.0.0 gesetzt.

Hier alles im Überblick:

* Komplettumstellung auf OBIS Kennzahlen
  Ein Offset ist nicht mehr nötig und wurde entfernt.
 
* Das Reading "FirmwareVersion" wurde nach "SoftwareVersion" umbenannt.
  Dadurch passt es sich besser in den Readinglesefluss in der Detailansicht ein.
 
* Die Readings "Lx_THD" wurden alle  nach "Lx_Strom" geändert.
  Ich kann heute nicht mehr sagen wie wir damals auf THD (den Klirrfaktor) gekommen waren.

* es gibt ein neues Attribut "noCoprocess"
  Als wir vor ein paar Jahren das Modul entwickelten, kam es häufig zu Freezes in FHEM wenn die Daten des EM verarbeitet
  wurden. Aus diesem Grund wurde das Modul auf non-Blocking umgestellt. Dadurch wird bei jedem Zyklus (bei mir alle 60s)
  ein Hintergrundprozess zu Abarbeitung gestartet.
  Nicht in jedem Fall ist das aber vom Nutzer gewünscht oder nötig. Es sind ein paar Jahre vergangen und die eingesetzte
  Hardware hat sich verändert, etc.
  Mit diesem Attriibut kann man nun festlegen, dass kein Hintergrundprozess verwendet werden soll.
  Ohne Hintergrundprozess liegt SMAEM_Read bei mir mit apptime max gemessen bei 290 - 519 ms, mit Hintergrundprozess zeigt SMAEM_Read nur 17 ms. 
  Wie dem auch sei, der Nutzer hat nun die Möglichkeit zu entscheiden wie er das Modul betreiben möchte.
 
* neue Kennzahlen werden im verbose 5 Log mit "unknown item" gekennzeichnet und es wird das Reading "OBISnewItems" generiert
  Durch die Umstellung der Readingerstellung mit OBIS Kennzahlen bekommt man nicht mehr mit wenn durch ein Firmware Update
  neue Kennzahlen hinzukommen (außer bei verbose 5 Log).
  Aus diesem Grund wird das Reading "OBISnewItems" erstellt. Es enthält den Wert "none" wenn alle empfangenen OBIS Kennzahlen
  im Modul bekannt sind. Kommen neue hinzu die noch nicht im obisitem-Hash benannt sind, werden diese OBIS in diesem Reading
  ausgegeben, z.B.
 
                  OBISnewItems  1:10.8.0,1:13.4.0
 
  Wenn man als Nutzer so etwas bemerkt, kann man nun reagieren und hier im Thread eine Meldung aufmachen damit dieses Item
  aufgenommen wird.
 

Das wären erstmal die aktuellen Neuerungen und ich hoffe dass sich dadurch wieder ein Fortschritt bzw. Mehrwert für die Modulnutzer ergibt.

Da sich teilweise die Readings geändert haben, müsst ihr die alten loswerden. Das kann man ganz einfach durch kurzzeitiges
switchen des Attributs "disableSernoInReading" erreichen. Dadurch werden immer alles Readings gelöscht und neu aufgebaut.

Die neue Version liegt wieder in meinem contrib zum Test bereit.
Insbesondere MiVo69 bitte ich wieder um einen Test ob das neue OBIS Item erkannt wird.
Bei mir habe ich bisher beim Vergleich mit der produktiven Instanz (Version 3.5.0) keine Unterschiede feststellen können,
d.h. ich sollte keine falschen Zuordungen, Dreher usw. implementiert haben.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

Code Auswählen Erweitern

"wget -qO ./FHEM/77_SMAEM.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/77_SMAEM.pm"

Grüße,
Heiko