Einbindung von Modbus TCP

[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

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

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

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]

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

[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

[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

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

Modbus_TCP1.png

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

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,..

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

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

Nee, es gibt doch gar kein Hilfsitem.

doch das DCA_SF - Item (eigentlich interessiert dieses doch niemandem) es wir ja nur zur Berechnung des eigentlichen Wertes A_DC_Bat benötig.

ich sehe die SF alle als Hilfsitem (auch bei mir) weil mir diese Werte ja eigentlich nicht interessieren.

[ivande]

damit die Berechnung mittels sunssf Skalierungsfaktor (über eval) vielleicht weniger verwirrend erscheint, dürfte auch dies zum Ergebnis führen:

eval: value*math.pow(10, sh.PV_GEN_24.DCA_SF())

PV_GEN_24;
    DCA_SF:
       type: num
        modBusAddress: 40265
        modBusUnit: 1
        modBusDataType: int16
    A_DC_Bat:
        type: num
        enforce_updates: True
        eval: value*math.pow(10, sh.PV_GEN_24.DCA_SF())
        modBusAddress: 40322
        modBusUnit: 1