Einbindung von Modbus TCP

[ivande]

hab nun slaveUnit zu den Itams hinzugefügt:

 modBusUnit: '71'                    #(optional) default: slaveUnit aus der Plugin-Konfig

evtl. zum Austesten aus meinem Fork:

https://github.com/ivan73/plugins-mo...lop/modbus_tcp

[tsb2001]

ivande

Hey, super, vielen Dank!
Ich habe einfach nur die __init__.py getauscht und es funktioniert mit der Angabe von mehreren Units einwandfrei.

Wo es noch hängt:
beim parsen der Items wird ja quasi der Index der Abfrage anhand der ModBus-Adressen erzeugt.
Da es zwei gleiche (aber mit unterschiedlichen Units) versehene Registernummern gibt, fragt er immer nur eine von beiden (mit der vielleicht höheren BusUnit?) ab.
Oder "gewinnt" das letzte hierarchisch angeordnete Item in der Item-Konfiguration?

Der erste Eintrag unten vom Strom L1 (das ist der Wechselrichter) wird gar nicht abgefragt und auch nicht getriggert. Da steht immer nur

Update durch

Init:Initial_Value

beim Starten von SmarthomeNG.

Versehe ich die Zeilen vom Smartmeter mit der "#" (I_SM_L1), gibt es nur den einen Eintrag mit (I_L1) vom Wechselrichter. Dieser wird dann auch korrekt gelesen.
Nehme ich die "#" wieder weg und werden zwei Einträge generiert, "gewinnt" wieder das Smartmeter und liefert Daten.

Beispiel:

PV_GEN_24:
   I_L1:
      type: num
      value: '0'
      modBusAddress: 40072
      modBusUnit: '1'
      modBusFactor: '0.0001'
...
   I_SM_L1:
      type: num
      value: '0'
      modBusAddress: 40072
      modBusUnit: '200'
      modBusFactor: '0.0001'

[ivande]

Da es zwei gleiche (aber mit unterschiedlichen Units) versehene Registernummern gibt, fragt er immer nur eine von beiden (mit der vielleicht höheren BusUnit?) ab.
Oder "gewinnt" das letzte hierarchisch angeordnete Item in der Item-Konfiguration?

das letzte gewinnt.. zur Problem-Behebung muss ich im plugin die Auflistung anpassen/umgestalten, da die Registeradresse als Dictionary-Key verwendet wird und nur 1x enthalten sein kann.. ich melde mich wenn es wieder ein update zum testen gibt.

Danke für Deine Rückmeldung

[tsb2001]

das letzte gewinnt.. zur Problem-Behebung muss ich im plugin die Auflistung anpassen/umgestalten, da die Registeradresse als Dictionary-Key verwendet wird und nur 1x enthalten sein kann.. ich melde mich wenn es wieder ein update zum testen gibt.

Danke für Deine Rückmeldung

Nee, FALSCH! Vielen Dank für diese gute Arbeit und deine Mühen!

Aber ich ich mir schon gedacht. Ich versuche grade, den Code zu verstehen. Leider sind meine Python-Kenntnisse sehr rudimentär, sonst würde ich gerne mehr helfen.
Ich habe die Unit mal mit ins Webinterface gebracht und da sieht man das Ergebnis ganz gut:
Unbenannt.png

Einfach mal eine Idee: Was ist denn, wenn du im Dictionary die Unit dem Register vorne anstellst, sodass sich eine beispielsweise Zahl mit 8 Stellen ergibt
Aus dem Register des Wechselrichters mit der Unit "1 " und dem Strom L1 der Adresse "40072" würde "00140072"
Aus dem Register des Smartmeters mit der Unit "200" und dem Strom L1 der Adresse "40072" würde "20040072"
Ein weiterer Zähler mit der Unit 201 würde auf die "20140072" den Strom L1 zuordnen.

Der Vorteil wäre; egal wie viele Units vorkommen würden, der Index wäre eindeutig, da die Nummer der Unit nur einmal vorkommt.
Beispiel Fronius: es lassen sich noch mehr Zähler via ModBus RTU anschliessen. Somit könnte auf der Modbus-TCP-Seite auch ein gleicher Zähler mit der Unit 201, 202, usw. entstehen.
Durch das Voranstellen der Unit wäre somit eine eindeutige Indizierung möglich.

[ivande]

hab es inzwischen schon so gelöst, allerdings mit dem unit dahinter,.. muss nur noch ein paar Tests machen, voraussichtlich am abend kann ich es dann ins git pushen


Adresse "40072" + Unit "200" ergibt 40072.200

[tsb2001]

Ja, auch ne Lösung!
Wenn ich was testen soll, nur her damit. Heute wird es nichts mehr; da ich aber noch Urlaub habe, kann ich morgen experimentieren.

Mal als Info für mich: Mit welchen Methoden entwickelst du das? Hast du irgendwie eine IDE, mit der du online die Daten mitverfolgen kannst?

[ivande]

hier wären wieder die Änderungen zum Testen:

https://github.com/ivan73/plugins-mo...lop/modbus_tcp

bitte auch die anderen Dateien austauschen, nicht nur die __init__.py
zumindest die plugin.yaml und die Datei webif/templades/index.html

Mal als Info für mich: Mit welchen Methoden entwickelst du das? Hast du irgendwie eine IDE, mit der du online die Daten mitverfolgen kannst?

angefangen habe ich mit eclipse und Remote Debug, damit kann man den python-Code debuggen und die verschiedensten Variablen von SH verfolgen. Da das Händling damit aber recht umständlich ist, benutze ich eigentlich nur mehr einen Editor (notepad++) und sehe mir die Variabel über Log-Ausgaben an

[tsb2001]

hier wären wieder die Änderungen zum Testen:

https://github.com/ivan73/plugins-mo...lop/modbus_tcp

bitte auch die anderen Dateien austauschen, nicht nur die __init__.py
zumindest die plugin.yaml und die Datei webif/templades/index.html

Noch eben schnell ausgetauscht. Funktioniert bis hierhin ohne Probleme!
Alle Register mit gleicher Registernummer vom Smartmeter und Wechselrichter werden mit dem jeweiligen Trennpunkt mit der Unit benannt und kommen jetzt auch richtigerweise doppelt an.

In den Items werden die Werte auch offensichtlich alle gelesen, jedoch sind die Werte des Wechselrichters bei der momentanen Sonneneinstrahlung um 00:49 Uhr leider alle auf "0" 😄
Ich gebe morgen dazu Rückmeldung!

[ivande]

Alle Register mit gleicher Registernummer vom Smartmeter und Wechselrichter werden mit dem jeweiligen Trennpunkt mit der Unit benannt

Registernummer mit Trennpunkt und Unit sollte mit der ausgetauschter Datei webif/templates/index.html eigentlich im Webinterface nicht sichtbar sein..

[tsb2001]

Hi, doch, das war es.
Die Adresse wurde nach folgendem Format ausgegeben: 40072.200
Vor der Änderung:
Vorher.png

Irgendwie hat die sich in dem Item versteckt. Ich habe jetzt nicht explizit geguckt, wo die herkommt, habe mich aber an der Zusammensetzung des "regToRead" orientiert und die Zeile im Webinterface:

<td class="py-1">{{ item }}</td>

umgeändert und die Adresse aus dem regToRead herausgelöst mit:

<td class="py-1">{{ p._regToRead[item].regAddr }}</td>

Nach der Änderung:
Nachher.png


Dann passt auch das Ergebnis im Web-Interface.

Alles andere funktioniert einwandfrei!

Vielen Dank nochmal!

Wenn du noch Änderungen implementieren möchtest und dazu Tester suchst, schreib mich gerne an.

[ivande]

super dass es soweit läuft, die index.html hat es aus versehen nicht auf git geschaft. Aber dort war nur die Änderung enthalten welche Du selber herausgefunden hast.

[tsb2001]

So, kurze Statusrückmeldung:
Das Plugin läuft nun seit 4 Tagen ohne jegliche Einschränkung oder Fehler.

Leider ist mir jetzt eines aufgefallen:
Mein Wechselrichter (und nicht nur Fronius, sondern auch SMA, Kostal, Solaregde usw.) tauscht Daten auf dem Modbus nach dem Sunspec-Format aus. Dies ist ein freier Zusammenschluss ganz vieler Hersteller, um einen herstellerübergreifenden Standart zum Datenaustausch über Modbus einzuführen. Hier kann man mal gucken, wer da alles mitmacht: https://sunspec.org/members/

Dummerweise kochen die ihr eigenes Süppchen und übertragen die Daten nach einem interessanten Muster:
in einem Register wird der Wert übertragen, und dann gibt es ein weiteres Register, in dem der ScaleFactor übertragen wird. Es werden folglich nur ganze Zahlen übertragen und die Nachkommastellen werden durch das ausgelesene Register mit dem ScaleFactor in der Stelle „verschoben“.

Ich habe mich gewundert, warum die Strom- und Leistungswerte nur manchmal zueinander passten. Bis ich gemerkt habe, dass die Stromwerte variabel skaliert werden.

Jetzt könnte man einfach das Register des jeweiligen ScaleFactor mit auslesen und mit dem übertragenen Wert multiplizieren.

Leider einfacher als gedacht: Das Datenformat lautet sunssf und besteht aus folgendem Aufbau:

As an alternative to floating point format, values are represented by integer values with a signed scale factor applied. The scale factor explicitly shifts the decimal point to the left (negative value) or the right (positive value). Scale factors may be fixed and specified in the documentation of a value, or may have a variable scale factor associated with it. For example, a value “Value” may have an associated value “Value_SF” of type “sunssf” that is a 16 bit two’s compliment integer.
sunssf signed range: -10 ... 10 Not Implemented: 0x8000
If a value is implemented and has an associated scale factor, the scale factor must also be implemented.

Die originale Umschreibung findet sich hier: https://sunspec.org/wp-content/uploa...dels-12041.pdf

Kann mir irgendwer auf die Sprünge helfen, wie ich den „16 bit two’s compliment integer“ aus dem Plugin in eine rechenbare Zahl umgewandelt bekomme?

[ivande]

beim solaredge-Wechselrichter welcher auch nach dem sunspec-Format tickt, hab ich ein eigenes Skale-Faktor-Item (AC_Leistung_sf) angelegt und dann mit dem eval im eigentlichen Leistung-Item (AC_Leistung) die Berechnung gemacht:
eval: value*10**sh.Photovoltaik.AC_Leistung_sf()

der Scale-Faktor ändert sich auch laufend, (z.B. 0, -1 -2, -3, -4)

solaredge_SE6000:
    AC_Leistung_sf:    # hier landet der Scale-Faktor z.B. -1
        type: num
        name: I_AC_Power_SF
        enforce_updates: True
        modBusAddress: 40084
        modBusDataType: int16
    AC_Leistung:  # hier wird die Leistung ausgelesen und mit dem Scale-Faktor-Item verrechnet:
                  #z.B. 35.362*10**-1 = 3.536,2 W * 0.001(modBusFactor) = 3,5362 kW
        type: num
        name: I_AC_Power
        enforce_updates: True
        eval: value*10**sh.Photovoltaik.AC_Leistung_sf()
        modBusAddress: 40083
        modBusFactor: 0.001

wichtig dabei, dass das Item mit dem Skale-Faktor zuerst angelegt wird, damit auch beim Lesen der Modbus-Register zuerst der Scale-Faktor gelesen wird und dann erst das Item mit dem eigentlichen Wert gelesen wird, welches dann das eval auslöst.

mit modBusFactor: 0.001 skaliere ich das ganze dann noch von Watt auf kW

[tsb2001]

Ja, das ist mir komplett klar.
Aber das Problem bei Fronius ist halt, dass sie den Wert zur Verschiebung des Dezimalpunktes einen Wert von -10 bis +10 als 16-Bit 2-er-Komplement liefert.

Wenn ich den Inhalt des Registers mit dem Datentypen „int16“ lese, kommen da Zahlen von 6123 oder irgendetwas in dieser Größenordnung raus; aber nichts, was sich zum Skalieren eignet.

Der modBusDataType ist eben beim Fronuis der nicht der „int16“ sondern der spezielle „sunssf“ nach dem in den Sunspec-beschriebenem Format.

Wenn ich es richtig deute, kommen diese Zahlen vor:

Dezimal Binär
-10         1000 0000 0000 1010
-09         1000 0000 0000 1001
-08         1000 0000 0000 1000
…
+08         0000 0000 0000 1000
+09         0000 0000 0000 1000
+10         0000 0000 0000 1010

Und das müsste ich passend unter Berücksichtigung der „1“ des höchstwertigen Bits als Vorzeichengeber umrechnen…
Daran scheitere ich grade…

[Bonze]

Naja, das is ja nur ne darstellungsart, d.h. das is schon soweit richtig...
Bin( Int16) wandelt in ne binärdarstellung, taugt aber auch nicht zum berechnen , höchstens zum anguckn

Vl hilft dir das https://wiki.python.org/moin/BitwiseOperators