Ankündigung

Einklappen
Keine Ankündigung bisher.

Einbindung von Modbus TCP

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • tsb2001
    antwortet
    Zitat von ivande Beitrag anzeigen
    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):
    Code:
    ...
        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.
    Zuletzt geändert von tsb2001; 09.01.2022, 16:21.

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    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ß

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    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,..

    Einen Kommentar schreiben:


  • tsb2001
    antwortet
    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.

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Modbus_TCP1.png

    Einen Kommentar schreiben:


  • tsb2001
    antwortet
    Zitat von ivande Beitrag anzeigen
    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:
    Code:
        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...

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    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:
    Zitat von tsb2001 Beitrag anzeigen
    float(math.pow(10, value.decode_16bit_int()))

    Code:
       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


    Einen Kommentar schreiben:


  • Tom Bombadil
    antwortet
    Zitat von ivande Beitrag anzeigen
    oder so im Scale-Factor-Item: (je nach dem wie die Daten ankommen)
    Code:
    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

    Einen Kommentar schreiben:


  • tsb2001
    antwortet
    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
    Code:
    import math
    Ab Zeile 267 habe ich folgendes eingefügt:
    Code:
    #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):
    Code:
        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
    Zuletzt geändert von tsb2001; 09.01.2022, 12:13.

    Einen Kommentar schreiben:


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

    Code:
    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
    Zuletzt geändert von ivande; 09.01.2022, 08:23.

    Einen Kommentar schreiben:


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

    Danke euch allen!

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    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?


    Einen Kommentar schreiben:


  • Tom Bombadil
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    Und das müsste ich passend unter Berücksichtigung der „1“ des höchstwertigen Bits als Vorzeichengeber umrechnen…
    Daran scheitere ich grade…
    Hier:
    Code:
      eval: value - 65535 if value > 32767 else value
    (ungetestet, frei aus dem Beispiel von ivande übernommen)

    /tom
    Zuletzt geändert von Tom Bombadil; 08.01.2022, 23:41.

    Einen Kommentar schreiben:


  • Bonze
    antwortet
    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

    Einen Kommentar schreiben:


  • tsb2001
    antwortet
    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:
    Code:
    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…

    Einen Kommentar schreiben:

Lädt...
X