Ankündigung

Einklappen
Keine Ankündigung bisher.

Einbindung von Modbus TCP

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

  • ivande
    antwortet
    Dass "Input Register" und "Holding Register" gelesen werden ist doch schon mal etwas..
    Außentemperatur sollte dann eigentlich gehen.. schick mal die Item-Konfig der Außentemp.


    Ich hab nochmal ein paar Kleine Änderungen hochgeladen Version 1.0.4a (__init__ + plugin.yaml ersetzten)

    Gruß Ivan

    Einen Kommentar schreiben:


  • ooUrmeloo
    antwortet
    Danke!! Sieht schon mal gut aus! 😀

    "Input Register" und "Holding Register" scheinen zumindest mit den Test-Registern zu funktionieren. Die erwarteten Werte werden regelmäßig ausgelesen, siehe auch Screenshot. Ich habe testhalber auch mal versucht, die Außentemperatur auszulesen aber das Register funktioniert (noch?) nicht.

    Mit den "Coils" scheint es - wie befürchtet - noch Probleme zu geben.

    Auszug log hier:

    Code:
    2022-02-03 11:48:37 ERROR plugins.modbus_tcp read error: Exception Response(129, 1, IllegalAddress) register:9995 registerCount:1 slaveUnit:1
    2022-02-03 11:48:37 ERROR plugins.modbus_tcp something went wrong in the poll_device function: 'bool' object has no attribute 'decode_bits'
    und Screenshot vom Webinterface:

    2022-02-03_11h41_56.png

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von ooUrmeloo Beitrag anzeigen
    Klar, teste ich natürlich sehr gerne!
    hier auf meinem plugin-Fork wäre ein Test-Version - wenn möglich mit folgenden Registern:


    Code:
    paradigma:
        TestInputRegister:
            type: num
            name: TestIR
            enforce_updates: True
            modBusObjectType: InputRegister
            modBusAddress: 9997
            modBusFactor: 0.1
            modBusDataType: int16
        TestHoldingRegister:
            type: num
            name: TestHR
            enforce_updates: True
            # modBusObjectType: HoldingRegister (default)
            modBusAddress: 9998
            modBusFactor: 0.1
            modBusDataType: int16
        TestCoil0:
            type: bool
            name: TestC0
            enforce_updates: True
            modBusObjectType: Coil
            modBusAddress: 9995
            modBusDataType: bit
        TestCoil1:
            type: bool
            name: TestC1
            enforce_updates: True
            modBusObjectType: Coil
            modBusAddress: 9996
            modBusDataType: bit


    wäre super wenn du die Log-Ausgabe und evtl. einen sceenshot vom Webinterface schicken kannst (wenn zumindest ein paar der Register gelesen werden)
    Am ehesten wird es Probleme mit den "Coil" geben,.. da ich das bei mir nicht testen konnte,..

    Gruß Ivan

    Einen Kommentar schreiben:


  • ooUrmeloo
    antwortet
    Zitat von ivande Beitrag anzeigen

    Das lesen der Coils, Input Registers und Holding Registers müsste ich erst ins Plugin einbauen, das müsste ich in 1-2Tagen schaffen.. Wenn Du mir das dann testen könntest wäre super,..
    Klar, teste ich natürlich sehr gerne! Ich würde das Plugin ja gerne nutzen
    Ich dachte, die Funktionscodes können über die Adressen/Register abgebildet werden: Coils: 0xxxx, Input Registers: 3xxxx, Holding Registers: 4xxxx, ....
    Das geht aber nicht.

    Vielen Dank schon mal vorab!

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Anhang A: Verfügbare Datenpunkte
    Die Datenpunkte des Reglers sind gemäß des Modbus-Standards in die 3 Modbus-Tabellen Coils, Input Registers und Holding Registers gruppiert, für die jeweils eigene Lese- und Schreibbefehle (Funktionscodes) verwendet werden. Die zu verwendenden Funktionscodes sind bei der jeweiligen Tabelle angegeben.
    Das lesen der Coils, Input Registers und Holding Registers müsste ich erst ins Plugin einbauen, das müsste ich in 1-2Tagen schaffen.. Wenn Du mir das dann testen könntest wäre super,..

    Einen Kommentar schreiben:


  • ooUrmeloo
    antwortet
    Danke. Nochmal ein guter Hinweis. In der Anleitung steht das nicht so im Klartext aber am Anfang eine Art "Übersetzung" (auf Seite 7).

    Hier auf der Seite ganz unten gibt's das PDF zum Modbus:
    https://www.paradigma.de/produkte/re...ystacomfortll/

    Klappt auf Anhieb trotzdem nicht. Muss morgen nochmal ran ...

    Einen Kommentar schreiben:


  • ivande
    antwortet
    ich denke du versuchst eine modBusAddresse (=Register) zu lesen, welche die Steuerung nicht kennt. In der Modbus-Anleitung deiner Stuerung müssten die Register folgendermaßen aufgelistet sein (ich weiß jetzt nicht ob dies mit deiner Steuerung übereinstimmt)

    paradigma.jpg
    also für die Außentemperatur:

    modBusAddress: 30001

    evtl schickst Du den Link deiner Anleitung oder die Datei, dass ich mir diese ansehen kann.
    Zuletzt geändert von ivande; 01.02.2022, 22:47.

    Einen Kommentar schreiben:


  • ooUrmeloo
    antwortet
    Zitat von ivande Beitrag anzeigen

    ich würde Dir empfehlen das modbus_tcp -Plugin aus dem develop-Branch zu testen.
    Danke! Das hat mir schon mal einen Schritt weiter geholfen. Mit der V 1.0.3 läuft der Plugin und ich bekomme auch das Webinterface dargestellt und er zeigt "Verbunden".
    Jetzt kämpfe ich noch mit dem Einlesen der Werte. Grundsätzlich habe ich m.E. alle Einstellungen (in einer Paradigma Beschreibung) hier.
    Über das Windows Tool QModMaster kann ich die Werte auch auslesen.

    Ich steh gerade aber auf dem Schlauch. Wie setzt sich denn die 'modBusAddress' zusammen?

    Ich habe per Anleitung einen Funktionscode zum Lesen: "0x04 Read Input Registers" und dann ein- bzw. zweistellige Adressen für die einzelnen Daten, bei mir alle in int16 mit Faktor 0,1 (Modbus Unit ID ist 1).
    0x04 hex ist für mich 4 dec, also sollte die Adresse irgendwas mit 4xxxx o.ä. sein ?!? Tut aber nicht ...

    Was mache ich falsch?

    Auszug aus dem yaml:

    Code:
    paradigma:
      Aussentemperatur:
        type: num
        name: Aussentemperatur
        enforce_updates: True
        modBusAddress: 40100
        modBusFactor: 0.1
        modBusDataType: int16
    Fehlermeldung aus dem log:

    Code:
    2022-02-01 21:36:49 ERROR plugins.modbus_tcp something went wrong in the poll_device function: 'ExceptionResponse' object has no attribute 'registers'


    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von ooUrmeloo Beitrag anzeigen
    Hallo zusammen,

    ich habe gerade sukzessive von Smartvisu 3.1 -> 3.2 und danach auch ShNG 1.82 -> 1.9 aktualisiert und wollte jetzt das neue Modbus_tcp Plugin nutzen, um auf meine Paradigma Heizungs- und Solaranlage zuzugreifen.

    Für das Modbus_tcp Plugin habe ich noch fehlerfrei pymodbus installiert und pip aktualisiert (da gab's ne Fehlermeldung dazu mit dem Hinweis dazu).

    Allerdings bekomme ich jetzt folgende Fehlermeldungen:
    Code:
    2022-02-01 12:57:18 ERROR lib.metadata plugin 'modbus_tcp' version differs between Python code (1.0.1) and metadata (1.0.0)
    
    
    2022-02-01 13:58:08 ERROR plugins.modbus_tcp something went wrong in the poll_device function: 'ExceptionResponse' object has no attribute 'registers'
    2022-02-01 13:58:14 ERROR cherrypy.error.1708919952 [01/Feb/2022:13:58:14] HTTP
    Traceback (most recent call last):
    File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/_cprequest.py", line 638, in respond
    self._do_respond(path_info)
    File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/_cprequest.py", line 697, in _do_respond
    response.body = self.handler()
    File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/lib/encoding.py", line 219, in __call__
    self.body = self.oldhandler(*args, **kwargs)
    File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__
    return self.callable(*self.args, **self.kwargs)
    File "/usr/local/smarthome/plugins/modbus_tcp/__init__.py", line 331, in index
    _regToRead=sorted(self.plugin._regToRead, key=lambda k: int(k)),
    File "/home/smarthome/.local/lib/python3.7/site-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
    File "/home/smarthome/.local/lib/python3.7/site-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
    File "/home/smarthome/.local/lib/python3.7/site-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
    File "/usr/local/smarthome/plugins/modbus_tcp/webif/templates/index.html", line 44, in top-level template code
    {% set tab1title = "<strong>" ~ p.get_shortname() ~ " readed registers </strong> (" ~ _regToRead|length ~ ")" %}
    File "/usr/local/smarthome/modules/http/webif/gtemplates/base_plugin.html", line 183, in top-level template code
    {% if scroll_heading is not defined %}
    File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 1, in top-level template code
    {% block doc -%}
    File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 4, in block "doc"
    {%- block html %}
    File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 79, in block "html"
    {% block body -%}
    File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 82, in block "body"
    {% block content -%}
    File "/usr/local/smarthome/modules/http/webif/gtemplates/base_plugin.html", line 57, in block "content"
    {% block headtable %}
    File "/usr/local/smarthome/plugins/modbus_tcp/webif/templates/index.html", line 37, in block "headtable"
    <td class="py-1">{{ p._pollStatus.last_dt.strftime('%d.%m.%Y %H:%M:%S %Z') }} ({{ p._pollStatus.regCount }})</td>
    File "/home/smarthome/.local/lib/python3.7/site-packages/jinja2/environment.py", line 471, in getattr
    return getattr(obj, attribute)
    jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'last_dt'
    Kann damit jemand was damit anfangen und mir weiterhelfen?
    Wie kann ich " ... version differs between Python code (1.0.1) and metadata (1.0.0)" lösen?
    Die Version 1.0.1 kommt mit Shng 1.9. Wie bekomme ich die metadata auch auf 1.0.1?
    im modbus_tcp -Plugin (1.9. - master) ist leider ein Fehler in der plugin.yaml dort sollte in Zeile 14 auch 1.0.1 bei der Version stehen

    version: 1.0.1 # Plugin version

    ich würde Dir empfehlen das modbus_tcp -Plugin aus dem develop-Branch zu testen.
    Zuletzt geändert von ivande; 08.02.2022, 09:32.

    Einen Kommentar schreiben:


  • Tom Bombadil
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    Universell ist es doch genau dann, wenn es doch alle Anforderungen abdeckt?!
    Das tut es doch, aber nicht dadurch, dass man für jedes neue Gerät jedesmal den Plugin-Code gerätespezifisch ändert (jemand muss die Spezialanpassungen implementieren, Pull-Request, jemand muss die Anpassungen validieren, ggf testen und mergen, dann knallt es nach dem nächsten Pull bei 20 Anwendern, wo es vorher sauber lief (weil die Spezialanpassungen für eine KWL sich plötzlich auch auf die Routinen für Wechselrichter auswirken) - Fehlerbehebung, neuer pull request, neues testen/mergen, die User müssen wieder pullen, etc pp).

    Übernimmst Du das alles?

    Lieber auslagern in yaml's, da kann jeder die Beispiele nach brauchbarem durchsuchen und ggf. für neue Geräte verändern - fertig ...

    /tom
    Zuletzt geändert von Tom Bombadil; 17.01.2022, 00:27.

    Einen Kommentar schreiben:


  • tsb2001
    antwortet
    Zitat von Tom Bombadil Beitrag anzeigen
    Wenn ich es richtig verstanden habe, war es das Ziel, ein universelles Modbus-Plugin zu schreiben, das auch wartbar ist und pflegeleicht bleibt (das Ding heisst ja auch Modbus-Plugin und nicht Wechselrichter-Plugin).
    Hmm, aber wird es nicht genau dadurch zu einem universellen Modbus-TCP-Plugin?
    Universell ist es doch genau dann, wenn es doch alle Anforderungen abdeckt?!

    Einen Kommentar schreiben:


  • Tom Bombadil
    antwortet
    Zitat von tsb2001 Beitrag anzeigen
    Daher nochmal: der "sunssf" als zusätzliches Attribut tut keinem weh; hilft aber extrem dem Verständnis, wie man mit einfacher Multiplikation von Daten, die im Item-Baum schon aufgelöst als Dezimalzahl beispielsweise mit 0.001 erscheinen, sauber und simpel mit einer Multiplikation auf den passenden Wert kommt.
    Wenn ich es richtig verstanden habe, war es das Ziel, ein universelles Modbus-Plugin zu schreiben, das auch wartbar ist und pflegeleicht bleibt (das Ding heisst ja auch Modbus-Plugin und nicht Wechselrichter-Plugin).

    Ich sehe momentan nicht, wie mir ein Parameter "sunssf" helfen sollte, meine KWL oder meinen Heizungsregler anzuflanschen, die hier beide per Modbus ausgelesen werden.

    Statt dessen sehe ich sehr viel Sinn darin, eine oder mehrere Muster-yaml's mitzuliefern, die Spezifika für Geräte an Beispielen oder fertigen Implementierungen aufzeigen. So habe ich es in der Vergangenheit mit meinen eigenen Plugins gehalten, und das hat gut funktioniert. Sowas gehört einfach nicht in den Code (sagt jemand, der derartige Dinge beruflich jeden Tag für eine Vielzahl von Kunden mit unterschiedlichen Anforderungen 'in großem Stil' verwalten muss).

    Just my 2 cents ...

    /tom

    Einen Kommentar schreiben:


  • tsb2001
    antwortet
    Das Problem sehe ich woanders:
    Es gibt Anwender, versierte Anwender und Entwickler; folglich solche und solche.
    Aber auch der einfache "Anwender" soll ja auch hiermit etwas anfangen können.

    Mit "math.pow" als Funktion von Python und auch der "**" für die Auflösung des Exponenten ist jemand, der SmarthomeNG einfach nur nutzen möchte, schlichtweg überfordert.

    Mach mal einen Perspektivwechsel und versetze dich in die Situation:
    Du bist jemandem, der sich zum ersten Mal SmarthomeNG installiert, die Konfigurationsanleitung vom SmarthomeNG und deren Plugins durchliest, Items zusammenbaut und daraus versucht, sich sein Haus etwas "smarter" zu machen.

    "Python" hält er grundsätzlich erst mal für eine Schlange und hat gar keine Ahnung, was da im Hintergrund überhaupt passiert.

    Grundrechenarten mit plus, minus mal und geteilt beherrscht dieser in seinem grundlegenden Mathematikwissen und kann das auch in Items definieren. Das leuchtet ein und wird auch an sehr vielen Stellen erklärt.

    Nun findet derjenige auch dein Plugin und möchte seinen Wechselrichter über Modbus TCP anbinden. Das alleine gestaltet sich schon schwierig, die Register passend zu lesen und dann steht da tatsächlich in den Unterlagen des Wechselrichters, dass es einen Datentyp namens "sunssf" gibt.

    Genau dann steht dieser Anwender da, wo ich stand: Wie der Ochse vor dem Berg!
    Und nun muss er sich eine Lösung überlegen, wie er eine Zahl von -5 bis + 5 (oder auch höher) dahingehend umwandeln kann, dass es einen Faktor mit 0.irgendwas ergibt.

    Das mag aus Sicht eines Entwicklers simple Mathematik und Anwendung von einfachen Python-Befehlen sein, die er selbst hat und darüber lächelt, wenn es einer nicht umsetzen kann, weil die Grundkenntnisse fehlen und das Verständnis einfach nicht da ist.

    Der normal sterbliche Anwender scheitert aber an solchen einfachen Dingen.

    Der möchte beispielsweise "5682 * 0.0001" aus dem Item "Strom" multipliziert mit dem "Skalierungsfaktor" rechnen; das kennt der und kann das auch nachvollziehen.
    5682 als Strom und -4 als verschobener Dezimalpunkt bringt der aber einfach nicht zusammen.

    Guck dir doch mal den Verlauf dieses Postings an, wie Schusselig ich mich angestellt habe. Das betrifft aber die meisten Anwender die als "Otto-Normalverbraucher" versuchen, hier etwas schönes zu generieren. Und wenn das nicht klappt, schmeißen viele auch schnell die Flinte ins Korn und stöpseln alles wieder ab. Erst recht, wenn nicht die Möglichkeit besteht, jemanden direkt zu fragen. Dann entsteht schnell ein Frustlevel.

    Um das zu umgehen, muss man halt alles berücksichtigen; und nicht nur das, was einem selbst einfach erscheint.

    Daher nochmal: der "sunssf" als zusätzliches Attribut tut keinem weh; hilft aber extrem dem Verständnis, wie man mit einfacher Multiplikation von Daten, die im Item-Baum schon aufgelöst als Dezimalzahl beispielsweise mit 0.001 erscheinen, sauber und simpel mit einer Multiplikation auf den passenden Wert kommt.
    Das versteht jeder einfach gestrickte Anwender wie z.B. ich.

    Einen Kommentar schreiben:


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

    Code:
    eval: value*math.pow(10, sh.PV_GEN_24.DCA_SF())
    Code:
    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
    Zuletzt geändert von ivande; 10.01.2022, 14:25.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:

Lädt...
X