Einbindung von Modbus TCP

[tsb2001]

und mit eingebautem sunsff muss ja immer noch mit Item und Hilfitem gerechnet werden..

Nee, es gibt doch gar kein Hilfsitem.

Beide Items braucht es doch sowieso. Du musst die generell den Skalierungsfaktor und den eigentlichen Wert abholen.
Erst das zusammen ergibt die wirkliche Nutzdaten.
Die Rechenfunktion erfolgt daher direkt in dem Wert-Item (grundsätzlich genau so wie bei dir):

...
    DCA_SF:
        type: num
        value: '0'
        modBusAddress: 40265
        modBusUnit: '1'
        modBusDataType: 'sunssf'
...
    A_DC_Bat:
        type: num
        enforce_updates: True
        eval: value*sh.PV_GEN_24.DCA_SF()
        modBusAddress: 40322
        modBusUnit: '1'
        modBusDataType: 'uint16'

Benötigt also auch kein Hilfsitem, sondern wird genau so verarbeitet wie in deinem Fall.

[ivande]

Aber jeder einfache Nutzer, der das Plugin "out of the Box" versucht einzusetzen, scheitert halt kläglich daran.

dann sollte ich dies evtl. in die Plugin-Doku einbauen/erklären..
Zumindest schon mal gut dass das wenige Tage alte Plugin schon ein paar Anwendungen gefunden hat.
Gruß

[ivande]

Was spricht denn dagegen

prinzipiell nichts - da das modbus-Plugin universell bleiben sollte, sollten nur eingebaut werden, was es zur Funktion auch braucht.

und mit eingebautem sunsff muss ja immer noch mit Item und Hilfitem gerechnet werden..

Wichtig dass es nun läuft,.. Ich brauch auch manchmal mehrere Stunden/Tage bis ich eine (meist Kleinigkeit) peile oder sehe,..

[tsb2001]

Ja, du weißt das.

Aber jeder einfache Nutzer, der das Plugin "out of the Box" versucht einzusetzen, scheitert halt kläglich daran.
Und ohne deine und die Erklärung von Tom wäre ich auch nie darauf gekommen, weil ich mich grundsätzlich als "Einfacher Nutzer" bezeichne.

Daher bekommst du hierbei nur Werte heraus, wenn du das Hintergrundwissen hast, wie Dezimalzahlen mit -5 bis +5 als Exponentialfunktion in Items zur Umrechnung in Zehnerpotenzen verwendet werden können. Das kann man aber bei keinem Normalsterblichen voraussetzen.

[ivande]

Modbus_TCP1.png

[tsb2001]

Wenn die Plugin's ein Update bekommen, musst du dann ständig Deine Änderungen in Plugin einbauen/korrigieren.

Was spricht denn dagegen, den "sunsff" nicht mit in das Plugin zu schreiben; sprich meinen Testblock schlichtweg in deinen Code einzuarbeiten?
Ist nur eine Variable im Item mehr zur Verwendung möglich, um sich damit das Leben einfacher zu machen. Wer das nicht benötigt, lässt es einfach weg.

Wäre für alle klassischen "Anwender" (die sich wie ich zum Beispiel stundenlang den Kopf darüber zerbrochen hat, wie dieser blöde sunssf-Faktor mathematisch in einen Dezimalpunkt verwandeln lässt) doch viel simpler umzusetzen.

Der integriert nur die Variable und macht im Item folgenden Schritt:

    DCA_SF:
        type: num
        value: '0'
        modBusAddress: 40265
        modBusUnit: '1'
        modBusDataType: 'sunssf'

    A_DC_Bat:
        type: num
        enforce_updates: True
        eval: value*sh.PV_GEN_24.DCA_SF()
        modBusAddress: 40322 
        modBusUnit: '1'
        modBusDataType: 'uint16'

Nichts mit Konvertierung von irgendwelcher Hochzahlen innerhalb eines Items (da wäre ich übrigens nie drauf gekommen, dass das über zwei * (**) hintereinander ausgelöst wird), sondern schlichtweg pure Multiplikation mit Werten, die das Plugin zurückliefert.

Erklärt sich von selbst, lässt sich als Variable im Item-Baum und auch in dem Webinterface für jeden darstellbar nachvollziehen und kostet nix extra.

Um darauf zu kommen, habe ich zwei Tage benötigt...

[ivande]

Was ich jetzt nicht weiß: Beeinflusst die Anordnung der Items die Abfrage?

ja so ist es, desswegen zuerst die SF's anlegen und darunter die Werte:

die Berechnung würde ich nur in dem Items machen, ohne am Plugin Änderungen zu machen. Wenn die Plugin's ein Update bekommen, musst du dann ständig Deine Änderungen in Plugin einbauen/korrigieren.


Du bräuchtest damit nur deine Items richtig anlegen: (die 10Potenz rechne ich ja im eval !)

das doppelte Multiplikationszeichen im Eval bildet ja bereits die 10er Potenz,... Basis 10 und Hochzahl hole ich aus dem Item z.B. sh.PV_GEN24.DCV_SF
eval: value*10**sh.PV_GEN24.DCV_SF()

dies wird dann überflüssig:

float(math.pow(10, value.decode_16bit_int()))

   PV_GEN24:    
    DCV_SF:
        type: num
        modBusAddress: 40266
        enforce_updates: True
        modBusUnit: 1
        modBusDataType: int16
    V_DC_1:
        type: num
        enforce_updates: True
        eval: value*10**sh.PV_GEN24.DCV_SF()    # Basis 10 und Hochzahl aus dem Item sh.PV_GEN24.DCV_SF
        modBusAddress: 40283
        modBusUnit: 1

[Tom Bombadil]

oder so im Scale-Factor-Item: (je nach dem wie die Daten ankommen)

eval: value - 32768 if value < 0 else value

Ist natürlich richtig, wenn das Ding bereits signed Int ist. Das von mir oben verlinkte eval wertet den 'Rohwert' (=Buswert) aus - der kennt noch keine negativen Zahlen, sonden nur unsigned 16 Bit Int (siehe Link zur __init__.py des Trovis Plugins). Zu diesem Zeitpunkt kann man '<0' noch nicht auswerten ...

/tom

[tsb2001]

Hallo Ivan,
da ich das ganze Problem nun verstanden habe (vor allem habe ich mich mit dem blöden Zweierkomplement ablenken lassen (dabei ist das im int16 ja ohnehin verwurzelt) ), habe ich heute morgen herumexperimentiert.

Die hohen Zahlen waren offensichtlich ein Eingabefehler bei den Registernummern. Das hat vermutlich zu den falschen Werten geführt.
Hole ich das passende Register mit dem sunssf-Wert als int16 ab, kommt da tatsächlich ein Wertebereich von -10 bis +10 direkt heraus.

Da das aber nur der Stellenwert der Verschiebung des Kommas ist und man damit nicht rechnen kann, habe ich etwas herumexperimentiert und versucht, dass in dein Programm einzubauen.
Was habe ich gemacht:
Ich habe eine neue Variable in den Items mit der Bezeichnung "sunssf" definiert

Im __init__.py mache ich jetzt folgendes:
ich importiere "math" in Zeile 27

import math

Ab Zeile 267 habe ich folgendes eingefügt:

#Testblock
        elif dataType.lower() == 'sunssf':
            if bits == 16:
                 return float(math.pow(10, value.decode_16bit_int()))
            else:
                 self.logger.error("Number of bits or datatype not supportet : {0}".format(typeStr))
#Ende Testblock

Ich werte folglich aus, ob das Item die Variabel "sunssf" enthält und forme dann einen float-Wert mit dem Exponenten (definiert durch die dezimale Variable mit -10 bis +10) zur Basis 10 und gebe die zurück.

Das Ergebnis ist ein Skalierungsfaktor zwischen 1000000000 und 0.0000000001, je nach übertragener Dezimalzahl. Damit kann man dann direkt in den Items rechnen und somit skalieren.

Was ich jetzt nicht weiß: Beeinflusst die Anordnung der Items die Abfrage?
Sprich, wenn der Skalierungsfaktor oberhalb der zu skalierenden Werte in den Items angeordnet ist, wird sich der auf das nachgeordnete Item sofort auswirken?

Gruß Torsten

Edit:
Hier die Testitems dazu (die Skalierungswerte für Spannung, Strom und Leistung im gesamten DC-Bereich des Wechselrichters):

    DCA_SF:
        type: num
        value: '0'
        modBusAddress: 40265
        modBusUnit: '1'
        modBusDataType: 'sunssf'
    DCV_SF:
        type: num
        value: '0'
        modBusAddress: 40266
        modBusUnit: '1'
        modBusDataType: 'sunssf'
    DCW_SF:
        type: num
        value: '0'
        modBusAddress: 40267
        modBusUnit: '1'
        modBusDataType: 'sunssf'

Hier noch das Bild aus dem WebIF:
Unbenannt.png

[ivande]

oder so im Scale-Factor-Item: (je nach dem wie die Daten ankommen)

eval: value - 32768 if value < 0 else value

um präziser helfen zu können, müssten wir erst sehen/verstehen wie die Daten tatsächlich ankommen...

convertInt16.jpg

[tsb2001]

Ihr seit so genial!
Nu habe auch ich es verstanden…
Ich denke manchmal einfach viel zu kompliziert…
Der Test folgt…

Danke euch allen!

[ivande]

Dezimal Binär
-10 1000 0000 0000 1010

dies solle doch die Betrags-Vorzeichendarstellung sein? - das Bit ganz Links gibt das Vorzeichen an

“Value_SF” of type “sunssf” that is a 16 bit two’s compliment integer.

16 bit two’s compliment integer sollte eigentlich eine ganz normale int16 - Variable mit Vorzeichen sein? Da wird doch das 2erKomplement verwendet, oder?

modBusDataType: int16

kannst du vielleicht einen Sceenshot vom Webinterface des modbus-Plugins schicken in welchen man die ausgelesenen Werte der skale-Faktor-Register sieht?

[Tom Bombadil]

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

Hier:

  eval: value - 65535 if value > 32767 else value

(ungetestet, frei aus dem Beispiel von ivande übernommen)

/tom

[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

[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…