Ankündigung

Einklappen
Keine Ankündigung bisher.

LBS: 19001030: Modbus TCP Master Read

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

  • saegefisch
    antwortet
    Zitat von gulp2k Beitrag anzeigen
    Also im Moment ist es ein Schrödinger LBS
    Er existiert zum groß Teil in meinem Kopf und zum kleinen Teil in einem anderen LBS denn ich gerade baue...
    Für das Modbus für SMA-Geräte habe ich nun einen LBS gebaut, der mir für SMA-Geräte Werte liefert. Technisch kann der LBS auf andere Quellen adaptiert werden, aber Teile sind sehr SMA-spezifisch, weil
    • SMA CSV/XLS liefert für die Register mit Format-Infos, etc. Mein Ziel war es, die gwünschten Zeilen 1:1 aus der CSV oder XLS kopieren un nutzen zu können inkl. der Format-Informationen (Länge, Nachkommstellen, EIniheit, Skalierungsfaktoren,...)
    • Ich mit den vorherigen Lösungen bzw. den Umrechnunegn aus dem github-Paket nie auf sinnvolle Werte kam. Daher auf das PDF von SMA aufbauend eine eigene Umrechungsmimik.
    Als Eingang braucht man nur ein Feld und definiert damit den gesamten Lieferumfang (gemischt mit leerzeilen, aus CSV oder XLS problemlos), zum Beispiel:
    Code:
    30775    Power    S32    FIX0    W    RO
    30845    Current battery state of charge    U32    FIX0    %    RO
    30861    Load power    S32    FIX0    W    RO    
    30849    Battery temperature    S32    TEMP    °C    RO    0.1
    30783;Grid voltage phase L1;U32;FIX2;V;RO;;;
    30849    Battery temperature    S32    TEMP    °C    RO    0.1
    30803;Grid frequency;U32;FIX2;Hz;RO;;;
    
    30865    Power grid reference    S32    FIX0    W    RO    
    30867    Power grid feed-in    S32    FIX0    W    RO
    Am Ausgang kommen die Werte in der Reihenfolge als String raus und kann da smit den String-Trennern wunderbar in KO oder Archive schreiben. Das ganze roh oder mit EInheit. So erscheint es mir einfach und sinnvoll, da hocgrdaig flexibel (ohne jSON überbau, CSV,...), sondern eben mit copy&paste aus den Originalquellen von SMA.

    --> Läuft auch schon prima, weil ich von meinen WR und dem Batterie-System wunderbar Daten bekommen.
    --> Läuft leider nicht gut, weil ich zwar Werte bekomme, aber auch einen ganzen Sack Fehlermeldungen vom ModBusMaster.php-include

    2018-05-03 15:20:43 954221 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 8 | Zeile: 167 | Uninitialized string offset: 5 ERROR
    2018-05-03 15:20:43 954524 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 8 | Zeile: 167 | Uninitialized string offset: 5 ERROR
    2018-05-03 15:20:43 954642 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 8 | Zeile: 167 | Uninitialized string offset: 5 ERROR
    2018-05-03 15:20:43 954782 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
    2018-05-03 15:20:43 954891 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
    2018-05-03 15:20:43 954993 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
    2018-05-03 15:20:43 955094 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
    2018-05-03 15:20:43 955202 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR


    Mein Log higegen liefert mir den Inhalt von MODBUS ohne Fehler:
    START
    Connected
    Packet: 0c4600000006030378370002
    Send
    Wait data ...
    Data received
    Packet: 0c4600000007030304fffffff6
    Modbus response error code: NOERROR
    Disconnected
    readMultipleRegisters: DONE


    Dürfte wohl irgendwo in private function rec() zwischen "Wait data..." und "Data received" passieren...

    Frage:Hat das schon mal jemand gehabt und gelöst? An anderen Stellen las ich im Forum zum Fehler von "vielleicht andere Clients, die zugreifen"... kann es sein, dass ich mioch selber blockiere? Ich starte den Daemon mit 1x "new ModbusMaster" und rufe dann regelmäßig und in der Schleife für jedes Register "$modbus->readMultipleRegisters"... Sollte/kann man das ModBus-Object freigeben? Wie kann man das anaylsieren? Und: Es liegt in der Natur der Saceh, dass mein SMA Homemanger die WR auch abfragt (Daten gehen in das SunnyPortal); wäre es da nicht besser, es wären Infos/Warnungen, keine Fehler? Scheint mir fast ein Implemntierungsfehler in dem Include...

    Wenn das gelöst ist, kommt der LBS direkt in den Download-Bereich.

    Der LBS kann über entweder einen externen Trigger regelmäßig ausgelöst werden (Delay = 0) oder als daemon (wenn Trigger =1) mit einstellbarer Periodizität (z.B. 1000ms). Es kann also jeder machen, wie er es bevorzugt. Von der Last scheint es kaum aufzutragen (NUC core i3) bei sekündlich. @André: Habe mich für usleep entschieden - das kannte ich schon und entspricht dem Dämon-Schema von Christian.

    ModBus Read SMA.JPG ModBus Read SMA2.JPG
    Angehängte Dateien
    Zuletzt geändert von saegefisch; 03.05.2018, 16:20.

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Hi André,

    was ist aus Deiner Sicht letztlich der eleganteste Weg für einen Prozess, der dauerhaft laufen, aber zur Last-Reduzierung nur periodisch tatsächlich etwas tut:
    • Zitat von jonofe Beitrag anzeigen
      logic_setState($id, 1, $E[2]['value'] * 1000, true);
    • im EXEC-Teil mit usleep($E[2]['value'] * 1000);
    • per externem Trigger (mit dem oben von Dir schon notierten "Nachteil")
    • weitere?
    Ingesamt sehe ich auch den grundsätzlichen Bedarf daran, meine Dauerprozesse fast alle mit wechselnden Frequenzen zu verwenden, und die LBS (zur Last-Reduzierung) seltener zu prozessieren, wenn die Ergebnisse derzeit nicht relevant sind. Zum Beispiel hochfrequent (500ms) Energiewert, wenn ich auf der Energie-Seite bin, sonst aber reichen mir 5.000ms. Ähnlich auch sehe ich auch für sonos (wenn keine Seite mit Sonos-Elementen/Anzeigen, dann braucht es auch keine usleep(1000000) oder stoppt ihn ganz). All' das kann man mit externen Triggern ebenso gut lösen, wie mit einem Ex-Eingang auf Schleifen-Pausen.

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Vollkommen korrekt, wenn die externen Trigger passen, ist es das Beste von der Ressourcennutzung.

    Wenn natürlich extrem viele LBS vom gleichen Systemtrigger gestriggert werden, muss man nur berücksichtigen, dass die dann alle quasi gleichzeitig starten und somit zu diesen Zeitpunkten die Last des Systems etwas höher geht. Aber das ist ja nichts schlimmes, wenn es nicht zulange anhält.

    Einen Kommentar schreiben:


  • hartwigm
    antwortet
    jonofe - Ressourcen

    Ich würde gerne zu deinem Baustein noch nachfragen.

    Bei meinem Bausteinen habe ich immer einen externen Trigger und in der Regel komme ich mit dem 1/5/10/3/60min Trigger klar.

    Dieser Trigger kommt ja eh von System, so dass ich bisher der Meinung war, meine Ressourcen bestens zu nutzen wenn nicht zig. Bausteine permanent am Laufen sind.

    Liege ich hier falsch?

    Einen Kommentar schreiben:


  • WagoKlemme
    antwortet
    Danke, schon geklärt - Champions-League.
    Meine N3150-CPU ist im Vergleich eine Schülermannschaft.

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Ist eine virtuelle Maschine mit zwei vCPUs eines Xeon E3-1245 v6. Vielleicht geht der Unterschied in den Nachkommastellen unter.

    Einen Kommentar schreiben:


  • WagoKlemme
    antwortet
    Welche Edomi-CPU hast Du ?

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von WagoKlemme Beitrag anzeigen
    Ja, habe ich. Hierbei steigt meine CPU-Auslastung um 1-2%, weil eine Logik ständig aktiv bleibt.
    Erstaunlich. Bei mir gibt es noch nicht mal einen beobachtbaren Unterschied, zwischen laufendem und nicht laufendem LBS. Naja, viele Wege führen nach Rom, und wenn es so bei dir funktioniert, umso besser.

    Einen Kommentar schreiben:


  • WagoKlemme
    antwortet
    Zitat von jonofe Beitrag anzeigen
    Aber nicht wenn du den mit der Systemzeit triggerst.
    A2 ? Der schaut nur jede Sekunde nach, ob die Sekunden durch das Intervall teilbar ist, was zu verschmerzen ist. Anstieg der CPU-Auslastung = 0.

    Zitat von jonofe Beitrag anzeigen
    Ich vermute mit setState würde es auch ressourcenschonend gehen, wenn du das delay entsprechend einstellst. Oder hast du das getestet?
    Ja, habe ich. Hierbei steigt meine CPU-Auslastung um 1-2%, weil eine Logik ständig aktiv bleibt.

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von WagoKlemme Beitrag anzeigen
    Der Taktgeber läuft alle 10s bei mir.
    Aber nicht wenn du den mit der Systemzeit triggerst. Dann läuft er jede Sekunde und hätte auch jede Sekunde eine 0 auf A2 geschrieben. Sein Ausgang taktet alle 10 Sekunden auf 1, das ist vermutlich was du meintest.

    Ich vermute mit setState würde es auch ressourcenschonend gehen, wenn du das delay entsprechend einstellst. Oder hast du das getestet? Damit wäre dann aus meiner Sicht ein beliebiger autarker Taktgeber möglich, der ohne externen Trigger (außer Start/Stop Signal) auskommt. Grundsätzlich sollte dasselbe aber auch mit dem EDOMI Telegramgenerator funktionieren.

    PHP-Code:
    ###[DEF]###
    [name    = Sekunden Trigger ]
    [e#1    = Start/Stop ]
    [e#2    = Intervall (s) #init=5    ]
    [a#1    = Trigger ]
    ###[/DEF]###
    ###[HELP]###
    ###[/HELP]###
    ###[LBS]###
    <?php

    function LB_LBSID($id)
    {
        if (
    $E logic_getInputs($id)) {
            if (
    $E[2]['refresh'] == 1) {
                if (
    logic_getState($id))
                    
    logic_setState($id1$E[2]['value'] * 1000true);
                else
                    return;
            }
            if (
    $E[1]['refresh'] == 1) {
                if (
    $E[1]['value'] == 0) {
                    
    logic_setState($id0);
                    return;
                } elseif (
    $E[1]['value'] == 1)
                    
    logic_setState($id1$E[2]['value'] * 1000true);
            }
            
    logic_setOutput($id11);
        }
    }
    ?>
    ###[/LBS]###
    ###[EXEC]###
    ###[/EXEC]###

    Einen Kommentar schreiben:


  • WagoKlemme
    antwortet
    Der Taktgeber läuft alle 10s bei mir. Ich habe verschiedene Varianten getestet (Loop mit setstate, Oszillator, Timer ...) und mich für eben diese Variante entschieden. Die anderen Versuche waren, vor allem mit setstate und Oszillator, merklich "hungriger". Bei diesen Versuchen habe ich, ohne die 0, mehrere Aufrufe in der 10ten Sekunde im Log gesehen, deshalb die 0. Mit der 0 dann nicht mehr.

    Edit: Du hast Recht, die 0 kann weg. Habe es getestet, es wird nichts doppelt in einer Sekunde geschrieben. K.A. was da vor ein paar Tagen los war. Ressourcenmäßig bleibt es, wie zu erwarten, gleich.
    Zuletzt geändert von WagoKlemme; 26.04.2018, 15:46.

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Bzgl. Ressourcenschonung wäre meine Empfehlung möglichst die Anzahl der DB Zugriffe zu reduzieren. Im Moment macht der Taktgeber LBS jede Sekunde ein logic_setOutput(), welches mindestens einen DB Zugriff ausführt, evtl. sogar mehrere. Da EDOMI ja Event basiert ist und du einen Taktgeber benötigst, reicht es vermutlich, wenn du das Rücksetzen auf 0 einfach weglässt, denn wenn die Taktzeit nicht erreicht ist, dann macht er einfach nichts, was ja aus meiner Sicht richtig ist.

    Einen Kommentar schreiben:


  • WagoKlemme
    antwortet
    gulp2k
    Danke, für den Fehlerhinweis. Ich hatte aus Versehen die Bausteine meiner Edomi-Testinstallation reinkopiert.
    Der E3DC LBS braucht keine Hilfe, da nur die IP eingetragen werden muss und der Takt. Der Rest ist vorkonfiguriert. Die Adressen, falls sich mal was ändert, sind absichtlich zugänglich geblieben.
    Taktgeber: Daran bist Du Schuld.... Nein, im Ernst, die Loop (0) deines LBS hat nicht funktioniert und den Baustein immer in der Schleife laufen zu lassen, war mir zu ressourcenhungrig. Mein LBS beendet sich nach jedem Durchlauf und wird durch den Taktgeber alle 10s wieder neu gestartet. Eine 1s Schleife hat auch den Nachteil, dass sich die Werte auf dem Display zu schnell ändern, was ich verwirrend fand. Setstate möchte ich vermeiden, wenn es möglich ist.

    Edit: PhpModbus: In Modbus würde/werde ich nichts mehr investieren. Wenn, dann RSCP - als Winterarbeit.
    Zuletzt geändert von WagoKlemme; 26.04.2018, 12:28.

    Einen Kommentar schreiben:


  • gulp2k
    antwortet
    Hi WagoKlemme ,
    dafür hab ich den LBS orginär gebaut

    Ich würde auch mal noch die Hilfe anpassen, die ist nämlich noch orginal und passt überhaupt nicht.

    Was ist den der tiefere Sinn des Taktgebers? ( Du schreibst da auch noch auf Ausgang 2 den es nicht mehr gibt...)
    Bei mir läuft der original LBS im Sekundentakt ohne große Probleme.

    Kompletter neubau ohne phpmodbus steht auch schon ewig an bin aber leider noch nicht dazu gekommen

    Einen Kommentar schreiben:


  • WagoKlemme
    antwortet
    gulp2k
    Erstmal DANKE für deine Arbeit. Leider hat der LBS Fehler ins Log geschrieben, daher war ich gezwungen den LBS etwas zu modifizieren. Mein Ziel war unseren E3DC
    auszulesen, damit auf der Visu wenigstens ein paar Informationen vorhanden sind. Herausgekommen ist ein LBS, der schnell und ohne Vorkenntnisse Werte aus einem E3DC liefert. Vielleicht geht es ja Anderen genau wie mir...unkompliziert die Momentanwerte auf der Visu zu haben.

    Passend dazu ein Ressourcen schonender Taktgeber und die Splittung des Integerwertes für Autarkie und Eigenverbrauch.
    Das Ganze sieht dann so aus:

    Bildschirmfoto 2018-04-25 um 18.47.18.png

    Bildschirmfoto 2018-04-25 um 18.47.57.png

    Einen Kommentar schreiben:

Lädt...
X