Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[fu_zhou]

@wal Das Thema in Github bezieht sich zwar auf real, wir haben aber festgestellt, dass das auch bei CHAR und INT der Fall ist...

Hier der entsprechende Kommentar dazu:
https://github.com/ioBroker/ioBroker.s7/issues/13#issuecomment-1782649439

[Wal]

@fu_zhou sagte in S7 mit Node Red (node-red-contrib-s7):

@wal Das Thema in Github bezieht sich zwar auf real, wir haben aber festgestellt, dass das auch bei CHAR und INT der Fall ist...

Das ist komisch da ich ein Javascript für die Autokalibration der Zisterne am laufen habe, das auch ohne Probleme funktioniert.

Der Node-Red-Adapter basiert nicht auf Snap7 sondern auf Nodes7 da wird der Hund begraben sein, es kann sein das es gar nicht am S7-Adapter liegt.

[fu_zhou]

@wal zeichnest du den gesteuerten Wert "s7.0.DBs.DB2.zisterne_offset_voll" auf (z.B. SQL) und hast dir die Werte mal angeschaut? Ich bin mir fast sicher, dass du da Ausreißer wie im Issue beschrieben finden wirst. Snap7 ist ja auch schon viele Jahre etabliert, ich kann mir nicht vorstellen, dass das Verhalten übersehen wurde und ein Snap7-Problem ist. Aber die Frage wäre, ob jemand (du?) den Adapter mal auf nodes7 umbaut? Ich teste dann gerne...

[Wal]

@fu_zhou ,
nodes7 kann keine Logo, evtl. finde ich ja was.
Viel Zeit werde ich aber nicht verschwenden.

[Wal]

@fu_zhou ,
habe das jetzt eine halbe Stunde mit 1000 und -1000 laufen lassen und kein Fehler bekommen.

Kann ich das irgendwie nachstellen ?

[fu_zhou]

@wal das Verhalten ist leider hoch sporadisch und wir haben noch keinen Weg gefunden, das zu reproduzieren.

Kannst du mit einem Vergleicher in der S7 mal einen Ausreißer fangen.: Wenn IN <> der Grenzen von der Zufallszahl => schreibe den Wert in einen DB. Und damit mal ein paar Stunden laufen lassen? Oder alternativ den Wert mit SQL loggen (s. Screenshot oben). Was hast du für eine Poll Delay im Adapter eingetragen? (bei mir sind es 200ms bei einer durchschnittlichen Zykluszeit von 15ms)

[fu_zhou]

@wal Geh vielleicht mit dem Trigger auch mal auf eine Sekunde runter

[Zero_two]

@Wal der Fehler läst sich schnell reproduzieren wenn du dir einfach die aktuelle Uhrzeit vom iobroker als dint wert in die s7 schreibst dabei entsteht der Fehler Recht schnell.

[Wal]

@fu_zhou ,
der poll ist auf 1sec.
Die Zufallszahl habe ich jede Sekunde erzeugt,sieht man im Log.

@Zero_two ,
das mit der Uhrzeit teste ich mal.

[Wal]

@zero_two ,
jetzt musst du mir nur noch zeigen wie du die Uhrzeit in DInt umrechnest.
Mein Script erzeigt ein Überlauf, da die Zahl anscheinend zu groß ist.

schedule("* * * * * *", async () => {
  setState('s7.0.DBs.DB2.test1', (new Date().getTime()));
});

[Zero_two]

[Wal]

So, ich habe den Poll auf 200ms gestellt und das Script von @Zero_two erweitert.
Nach 10 Minuten hatte ich einen Objektunterschied festgestellt.

Wenn ich das aber auswerte, liegt der Fehler nicht am S7 Adapter, sondern am Javascript ?
Wie zu sehen lese ich das Objekt vom S7 Adapter wieder aus das ich mit Javascript beschrieben habe und es ist 0.

Edit: In der S7 habe ich den DB1.DBD8 (real_test1) auf den DB1.DBD12 (real_test2) geschrieben.

[Blockmove]

@wal said in S7 mit Node Red (node-red-contrib-s7):

Wenn ich das aber auswerte, liegt der Fehler nicht am S7 Adapter, sondern am Javascript ?
Wie zu sehen lese ich das Objekt vom S7 Adapter wieder aus das ich mit Javascript beschrieben habe und es ist 0.

Ohne jetzt im Detail dein Problem nachvollziehen zu wollen, aber schau dir mal bei Javascript / Node.js das Thema async / await an.

[Wal]

@blockmove ,
zu Glück habe ich das Problem nicht, aber danke für die Info, sollen die Jungs sich das mal reinziehen. ;-)

[fu_zhou]

@blockmove hmh... im Issue wurde "postuliert", dass das Verhalten nicht auf Werte beschränkt ist, die vom Script kommen:
Es ist dabei auch egal ob es sich um einen Wert aus der Vis oder Javascript handelt. Über VIS fällt das natürlich weniger auf, da hier wesentlich seltener Werte gesendet werden (s. Link oben zum entsprechenden Kommentar).
Ich bin leider nur Anwender, kein Programmierer, d.h. ein bisschen Blockly kriege ich noch hin, aber Codezeilen übersteigen meine Fantasie und Fähigkeiten. Wenn ich mir jetzt async/await anschaue, verstehe ich da erst mal nur Bahnhof, aber: Meinst du dass async/await im Adapter oder in unseren Scripten zum Einsatz kommen sollte, um das Problem der sporadischen, fehlerhaften Datenübertragung zu beheben? Warum hat Node-Red das Problem nicht?

[mickym]

Mit dem Eingangspost hat das alles nichts mehr zu tun. Sobald jemand NodeRed nutzen will, weil vielleicht ein Adapter Probleme macht, dann wird daraus sofort ein Supportthread für den Adapter gemacht.

Warum gibt es eigentlich die NodeRed Integration im iobroker, wenn man genau damit die Probleme eines Adapters umgehen kann?

Vielleicht lässt man den Threadersteller einfach mal mit dem Tool arbeiten und diskutiert den Rest parallel

Ich nutze mal die iobroker Adapter, mal die NodeRed Nodes. Ich kann zwar nichts zu S7 beitragen, aber der Harmony-Adapter im iobroker oder der snmp v1 Adapter waren auch schlechter, als die entsprechenden Nodes.

Wenn der Adapter Vorteile bringt kann man ja wieder umsteigen. Außerdem kann der Threadersteller so auch die Logik von NodeRed verstehen lernen und muss sich nicht mehr puzzeln rumschlagen, noch zu codieren anfangen.

@Homoran
Vielleicht verschiebt man den Thread hier mal aus dem NodeRed Bereich?

[fu_zhou]

@mickym Die Idee war schon, hier die Anwendungsfälle von Node-Red mit S7 zusammenzutragen, das hat jetzt ein Eigenleben entwickelt. Ich würde gerne den initialen Post lassen und den Rest vielleicht nach "S7 Adapter" verschieben?

[mickym]

@fu_zhou sagte in S7 mit Node Red (node-red-contrib-s7):

@mickym Die Idee war schon, hier die Anwendungsfälle von Node-Red mit S7 zusammenzutragen, das hat jetzt ein Eigenleben entwickelt. Ich würde gerne den initialen Post lassen und den Rest vielleicht nach "S7 Adapter" verschieben?

Gut wenn Du allgemeine Fragen zu Node Red hast, kann ich Dir helfen. Zu S7 und auch der entsprechenden Node kann ich Dir nicht helfen.

Zu den einzelnen Punkten.

sinnvolle Erstellung/ Strukturierung von Flows (z.B. an S7 senden, von S7 lesen)

ich würde erst mal alles in einen Flow packen - ich kann aber nicht beurteilen wie umfangreich das wird, kann man aber auch im Nachhinein noch aufteilen mit etwas Nacharbeit.

Spreadsheet-Engineering (z.B. Anlegen der S7 Variablen über Excel und Import in Node Red)

habe ich persönlich noch nicht gemacht. Aber es gibt wohl eine Node, die mächtig ist und auch gepflegt wird. Kannst Du Dir hier mal anschauen: https://flows.nodered.org/node/node-red-contrib-spreadsheet-in

Das könnte ich mit einem einfachen Excelsheet mal in einer Testumgebung mit nachvollziehen.

automatisiertes Verknüpfen der Variablen (z.B. über JSON Import)

Weiß zwar nicht was das bedeutet. Grundsätzlich werden alle Javascript Objekte über JSON ausgetauscht und das beherrscht NodeRed von sich aus, sehr gut - jedenfalls besser als Blockly. Kommt halt darauf an, wo was gespeichert ist und ob bereits im JSON-Format.

Funktionen in Node Red (z.B. Signalverarbeitung als Alternative zu Blockly/ Java-Script)

Man kann in function Nodes komplettes Javascript schreiben. Ich würde Dir jedoch empfehlen, solange wie möglich darauf zu verzichten und ggf. lieber Subflows verwenden, damit Du die Vorteile der grafischen Programmierung nicht verlierst und wieder ins Codieren verfällst. ;)

[Wal]

@fu_zhou ,
nur zur Info, habe jetzt einen Negativen Wert geloggt und der kommt vom S7 Adapter, ihr hattet recht.

[fu_zhou]

@wal danke für die Info... eigentlich gut oder auch schade. Coole Antwort wäre gewesen: Ihr Blinden, das liegt nicht am Adapter, sondern an... ;-)

Hast du eine Idee, wo du nachschauen kannst?