Ankündigung
Einklappen
Keine Ankündigung bisher.
LBS: Abfrage von Modbus TCP via Homeserver
Einklappen
X
-
Also es ist glaube ich folgendes Problem: Modicon-Notation - steht auch in der F1-Hilfe vom Baustein.
Es ist eigentlich Register 1 und nicht 40001 - du kannst also Offset auf 40000 stellen oder du trägt Register 1 ein.
In SimpleModbus machst du das Quasi mit dem ersten Register auf der linken Seite.
Kommentar
-
Das Offset verhält sich bei dem Baustein negativ. Also Adresse + Offset = Echte Adresse.
Sprich du solltest folgende Werte an E10 testen: -40000 oder -40001
Es gibt nämlich noch die Interpretation, ob man bei 0 oder 1 anfängt zu zählen.
Wenn du noch andere Registertypen hast wie z.B. Input Register, dann musst du es manuell korrigieren, da der Offset auf alle Adressen wirkt.
(Also z.B. 40001 und 30032 gemischt.)
Kommentar
-
Also entweder machst du Offset auf 0 oder -1 (beides probieren) mit Adresse 1 oder du machst -40000 / -40001 und 40001 als Adresse. Ich Tippe auf -40001 wie in deinem simplemodbusclient Screenshot.
wenn du kein Verbindungsfehler kriegst: also geht es?
kannst du von deinem Hauskraftwerk bitte mal n Screenshot der Settings machen?
da du im SimpleModbusClient unten links High-High gewählt hast, musst du in meinen Augen E8 und E9 auf Big-Endian setzen. Daran scheitert nur kein Connect Versuch. Die Werte passen nur sonst nicht.
Wenn er Werte kriegt findest du im Debug diese. Oder n Stacktrace unter HSL2Zuletzt geändert von SvenB; 13.02.2023, 18:44.
Kommentar
-
Zitat von BadSmiley Beitrag anzeigen40001-40001 =?
Edit: Geht nur mit -40001 / 40001
Zum testen auch Adresse 40083 "SOC".
image.pngZuletzt geändert von skjold; 13.02.2023, 20:59.
Kommentar
-
Super, dass es klappt.
Warum setzt du Spezial Operation auf 0?
Also Register Offset 0 und Reg address auf 0 oder Register Offset auf -1 und Reg Adress auf 1 oder wie jetzt (-40001 und 40001). - ist alles das Gleiche.
Hier der Beweis:
Code:# Get register address and apply offset register_addr = int(self._get_input_value(input_addr_id)) if register_addr == -1: return None register_offset = int(self._get_input_value(self.PIN_I_REG_OFFSET)) register_addr += register_offset if not 0 <= register_addr <= 65535: # Skip: Neg. values skips register execution self.LOGGER.warning("Modbus register out of bounds: " + str(register_addr)) return None
Kommentar
-
Ich hab mich jetzt auch nochmal etwas damit auseinandergesetzt. Mir ist aufgefallen, dass bei den 3 Bausteinen die ich hintereinander laufen lasse, die Anzahl der Durchläufe stark abnimmt.
Während der 1. Baustein z.B. 20 mal Ergebnisse ausgibt, kommen beim 2. schon nur noch 12 mal ein Ergebnis, und beim 3. sogar nur 3x.
Der Ausgang 1 gibt einfach immer seltener eine 1 aus. Dies liegt daran dass der Baustein einfach nicht fertig durchläuft.
Dadurch habe ich bei den Zeiten genauer hingesehen. Es vergehen ca. 30 Sekunden von Abfrage Start (trigger) bis die Ergebnisse dann innerhalb von 2-3 Sekunden alle 8 ankommen.
Bei 3 Bausteinen hintereinander macht das dann 1:30min. Da der Intervall auf 30 Sekunden stand, hat der Baustein durch das öffnen einer neuen Verbindung wahrscheinlich den anderen, gerade noch laufenden Baustein unterbrochen.
Kann die lange Laufzeit an einer Einstellung liegen? So müsste ich ja ca. einen 2 Minuten Intervall annehmen, um sicher zu gehen, dass die Verbindung nicht abreist?
Ich habe auf E7 Special options nur sleep100ms drin.
Falls ich hier fantasiert habe, sag mir das bitte, das waren halt meine Schlussfolgerungen.
Das Ergebnis der Abbrüche waren dann die Fehler in meinem Post neulich. Welche zwar geloggt wurden, aber nicht den Baustein gestoppt haben.
https://knx-user-forum.de/forum/öffe...75#post1844075
Kommentar
-
Ich weiß nicht ganz was du auf deine Frage hören willst? Wenn dein Gerät zu langsam arbeitet und du vorne neu startest kommt es zu zwei Parallelen Abläufen und kann je nach implementierung schlimmer werden. - Viele Modbus Geräte machen nur eine Abfrage zur gleichen Zeit oder per IP.
sleep100ms fügt immer 100ms hinzu. Dauert also ein Baustein mit 8 Eingängen um die Sekunde - außer dein Gerät ist zu langsam, dann länger. Glaub timeout ist 3s. Läuft er also 8x in timeout kannst du es dir ausrechnen.
Und wenn deine Modbus-Abfragen nicht sauber durchlaufen und eine hängt, dann kommt hinten keine 1.
Interessante Idee wäre hinten die Zahl der erfolgreichen Eingangs-Reads auszugeben. Damit kann man dann trotzdem triggern und fertig simulieren. Aber das gibts so schnell nicht weil Breaking change.
Ich würde ja sagen: debugge mal genauer was dein Gerät macht. Fragst du diese noch mit anderen Geräten wir nem RPI oder so ab? Finden Implementierungen auch manchmal doof. Teste auch „ReconnectAfterEachRead“ als Option zusätzlich zur sleep100ms. Wie hier im Thread schon andere hatten: Manche Geräte laufen mit ner frischen Verbindung besser.Zuletzt geändert von SvenB; 15.02.2023, 23:29.
Kommentar
-
Also keine weitere Abfrage läuft nicht. Wobei ich nicht weiß wie die Webinterface an die Daten kommt. Ich gehe davon aus dass die ähnlich abfragen.
Ich habe ich verschiedenen Foren gelesen das man bei den sun2000 Wechselrichtern mit dem 1. Poll 5-10 Sekunden warten und das timeout auf 5 sec stellen soll.
Wäre es möglich eine solche Verzögerung noch mit einzubauen?
ReconnectAfterEachRead bringt die Veränderung dass jedes Register 30sek. benötigt. Die anderen Möglichkeiten bringen kaum Veränderungen.
- Likes 1
Kommentar
-
Hallo Zusammen,
ich versuche über den Baustein über ein Modbus TCP zu RTU Modul auf meine Wallbox zuzugreifen, sprich einige Möglichkeiten Fehler einzubauen :-) Nachdem es (wieso sollte es auch) auf Anhieb nicht funktioniert, bzw. keine Daten gelesen werden, muss ich mit der Fehlersuche starten.
unter HSlist sieht es wie folgt aus :
hs_modbusTCP_reader14184 / 2 / 2
- 14184 / 5 / 2 / 1.1
System / 12 / 2
- 9601 / 5 / 2 / ?
- 9602 / 5 / 2 / ?
- 9501 / 6 / 4 / ?
- 9502 / 6 / 4 / ?
Ich habe aktuell noch einen zweiten Baustein laufen, der den SMA Wechselrichter ausliest, was auch problemlos funktioniert.
Kann mir jemand sagen, wie ich die Daten aus HSlist zu verstehen habe?
Kommentar
-
Ich würde vorschlagen die RTU zu TCP Konvertierung erst mit dem PC mit nem Client zu testen und dann auf den HS zu konfigurieren. Dann weißt du, dass es bis zum konverter funktioniert.
setze aber gern den einen Baustein dann auf Debug. Dann sollten mehr Informationen im Debug dazu auftauchen
Kommentar
Kommentar