Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo holle75,

mit den Unterlagen, die Du angehängt hast, bekommt man das hin.
Dazu gehört leider ein wenig Geduld und Ausprobieren, da die Angaben nicht ganz eindeutig sind. Ein Phyton-Skript oder andere Sachen brauchst Du aber sicher nicht.

Aus Deiner Doku lese ich heraus, dass z.B. die Batterie-Temperatur aus dem Modbus-Input-Register 2 gelesen werden kann. Der Wert wird vermutlich an anderer Stelle als Wert Nummer 3001 bezeichnet, aber in der Doku steht als Beispiel explizit Register 2, Länge 2 und Function Code 4 (das ist der Code zum Lesen con Input-Registern. Wenn es Holding-Register wären, dann wäre das der Function-Code 3)
Also Must Du in ModbusAttr ein Objekt dafür definieren.

Code Auswählen Erweitern


attr Studer485 obj-i2-reading BatTemp
attr Studer485 obj-i2-len 2


Fraglich ist dann noch das Datenformat. In der Doku steht zwar "Float", aber da gibt es verschiedene Varianten. Im Modbus-Modul wird das über einen unpack-Code angegeben. Ich würde es mit f> oder auch mal f< ausprobieren:

Code Auswählen Erweitern


attr Studer485 obj-i2-unpack f>


Damit man dieses Objekt auch per get Abfragen kann, muss es dann noch dafür freigeschaltet werden:

Code Auswählen Erweitern


attr Studer485 obj-i2-showGet 1


oder alternativ einmal als Default für alle Input-Register:

Code Auswählen Erweitern


attr Studer485 dev-defShowGet 1


Ebenso kann man einstellen, ob das Objekt automatisch alle x Sekunden abgefragt werden soll. Das Intervall hast Du ja beim Define des Geräts auf 10 Sekunden gesetzt:

Code Auswählen Erweitern


attr Studer485 obj-i2-poll 1


Oder auch hier einmal für alle Input-Register:

Code Auswählen Erweitern


attr Studer485 dev-defPoll 1


Ein combine-Attribut würde erst mal nicht setzen. Das ist eine potentielle Optimierung für später, wenn es mal funktioniert. Es kann aber auch Probleme machen und in Deiner Doku steht sogar, dass die Länge nicht größer als zwei sein sollte...

Wenn das soweit eingegeben ist, dann solltest Du dringend verbose auf 5 setzen, damit im Log möglichst viele Details landen:

Code Auswählen Erweitern


attr Studer485 verbose 5
attr ModbusLine verbose 5


Dann schau mal was im Log landet und poste es

Interessant wäre aber auch noch die physische Verkabelung.
Wer oder was hängt denn alles am Kabel?

Die bisherigen Meldungen in Deinem Log weisen darauf hin, dass entweder ein Verkabelungsproblem vorliegt und Unsinn empfangen wird (z.B. falsch angeschlossen, falsche Terminierung o.ä.) oder dass da doch schon ein anderer Master am Bus hängt. Es darf aber nur einen Master am Bus geben.

Zudem hat Dein Gerät sicher eine Möglichkeit die eigene Id zu konfigurieren. Ggf. Per DIP-Switches.
Was ist denn da eingestellt?

Gruß
     Stefan

[holle75]

@holle75

hattes du die Lösung von @satprofie schon mal bei dir am laufen ? Da werden doch schon Werte ausgelesen.
Diese könnte man doch versuchen über MQTT nach FHEM zu senden. So könnte man das pyhton-Modul weiter nehmen. Oder man versucht es über ModBus.

Versuche mal die 30001 über ModBus RTU auszulesen.

pejonp

Hallo pejonp, danke für deine Hilfe. Satprofis python-script (resp. die Studer python Anleitung) hatte ich damals nicht ausprobiert, da ich es als Workaround im Zusammenspiel mit fhem sah. Ich wollte ohne externen Script mit fhem kommunizieren. Ich hatte mit Studer gesprochen und auf das Xcom485i gewartet. Satprofis Setup, glaube ich, sind zwei Xcom232+Moxa am Canbus der Anlage. Einer kommuniziert mit der Studer-Cloud und einer mit Python Lokal. Hat Satprofi toll umgesetzt.

Bis dato las ich die Werte über Xcom232 plus Moxa mit HTTPMOD über die Cloud aus. Bzw mach das bis jetzt noch immer.
Das funktioniert, aber Cloud nervt, wenn es direkte Lösungen im Heimnetz gibt/geben könnte.

Deswegen der Ansatz mit Modbus. Außerdem finde ich es schade, dass im Inselanlagenbereich primär nur von Victron gesprochen wird. Nicht hier, aber zB im Photovoltaik Forum. Studer ist bißchen teuerer, aber das sind sehr solide Maschinen die in der Schweiz produziert werden. Victron produziert, glaube ich, in China. Da ist nichts gegen zu sagen, aber der Support wird auschließlich über Händler abgewickelt. Welcher Händler hat Lust, 5 Jahre nach Verkauf, Support im Detail über irgendwelche Einstellungen zu geben?

Bei Studer wird mit dir jedes Problem tage- und notfalls monatelang durchgekaut bis zur Lösung. Ein guter Laden.

Wenn ich es schaffe, mit eurer Hilfe, ein AufsatzModul für Stefans Modbus hinzubiegen hätten alle zukünftigen Studer-Nutzer es recht einfach.

Das waren meine zwei Ansätze mich mit Modbus zu beschäftigen.

Dann schau mal was im Log landet und poste es

Interessant wäre aber auch noch die physische Verkabelung.
Wer oder was hängt denn alles am Kabel?

Die bisherigen Meldungen in Deinem Log weisen darauf hin, dass entweder ein Verkabelungsproblem vorliegt und Unsinn empfangen wird (z.B. falsch angeschlossen, falsche Terminierung o.ä.) oder dass da doch schon ein anderer Master am Bus hängt. Es darf aber nur einen Master am Bus geben.

Zudem hat Dein Gerät sicher eine Möglichkeit die eigene Id zu konfigurieren. Ggf. Per DIP-Switches.
Was ist denn da eingestellt?

Gruß
     Stefan

Hallo Stefan, vielen Dank!

Im Moment noch ein fhem-Testsystem mit eigenem USB Adapter und nur der Xom485i dranhängend.

Später soll die Solaranlage mit auf den Modbus der beiden Stromzähler SDM220 (wo ich dann gespannt bin, ob es Probleme mit der Parity Dfinition im Modbus-Device gibt, weil Studer will "E", ich glaube die SDM´s wollen "N", aber das ist der zweite Schritt.)

aktuelle Lists:

Code Auswählen Erweitern

Internals:
   DEF        /dev/ttyUSB0@9600,8,E,1
   DeviceName /dev/ttyUSB0@9600,8,E,1
   EXPECT     idle
   FD         4
   FUUID      5ff9c3ef-f33f-c138-67ef-7277e323cb47cd25
   LASTOPEN   1610218212.57301
   NAME       ModbusLine
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-ModbusLine
   PARTIAL   
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2021-01-09 19:50:12   state           opened
   REMEMBER:
     lid        0
     lname      Studer485
     lrecv      1610275542.74744
     lsend      1610273334.243
   defptr:
Attributes:
   verbose    5

Code Auswählen Erweitern

Internals:
   DEF        1 10
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   10
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485
   PROTOCOL   RTU
   STATE      inactive
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-10 11:08:58   state           inactive
   REMEMBER:
     lrecv      1610273334.51309
     lsend      1610273334.243
   gotReadings:
   lastRead:
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i2-len 2
   obj-i2-reading BatTemp
   obj-i2-unpack f>
   verbose    5

und das Log nach paar Sekunden nach Neustart als Anhang.

Readings bekomme ich keine rein.

Die ID Definition habe ich in keiner Doku gefunden. Den Adress-Bereich kannst du über Dip-Schalter einstellen. Bei Adress-Bereich bei 1 startend bekommt der Xcom485i die Adresse 1 und die Geräte im CanBus der Anlage dann weitere Adressen. Ich hoffe, das sind dann die ID´s??! Anbei Auszug aus einem Manual.

Ob die Testverkabelung fehlerfrei ist, kann ich noch nicht beurteilen. Blöderweise ist der USB-Adapter mit D+ und D- benannt, Studer nennt es A und B ... wie ich herausfinden mußte, gibt es keine allgemeingültige Übersetzung, was was entspricht. Soll wohl variieren. Also habe ich es jetzt so verkabelt, wie die LED-Orgeln am USB-Adapter am meisten Sinn ergeben

Auch die am USB-Stick einzustellenden Widerstände sind im Moment laut Internet gedipt. Obs stimmt, weiß ich nicht.

Wenn ich weiß, dass einstellungsseitig in fhem die Wahrscheinlichkeit groß ist, dass Readings kommen sollten, kann ich an den Kabeln spielen.

Eure Gedanken sind sehr willkommen.

Grüße!
H.

[holle75]

Hoppala, nachdem ich sowohl den/alle Widerstände am USB-Adapter rausgenommen und am Xcom485i den Endwiderstand aktiviert habe..... SPRICHT das Ding mit mir dank Stefans config. Großer Schritt .... und keine Fehlermeldungen im Log (mit verbose standard)

das allerdings nur wenn ich

Code Auswählen Erweitern

defmod ModbusLine Modbus /dev/ttyUSB0@9600,8,E,1
mit

Code Auswählen Erweitern

,8,E,1
definiere.

Ohne gibts nur Fehlermeldungen. Denke das wird dann schwierig mit den SDM220´s

als Reading bekomme ich

Code Auswählen Erweitern

BatTemp           -1.98523347012727e-23            2021-01-10 13:44:02

list

Code Auswählen Erweitern

Internals:
   DEF        1 10
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   10
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-10 13:44:52   BatTemp         -1.98523347012727e-23
     2021-01-10 13:37:41   state           opened
   REMEMBER:
     lrecv      1610282692.90027
     lsend      1610282692.8716
   gotReadings:
     BatTemp    -1.98523347012727e-23
   lastRead:
     i2         1610282692.9028
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i2-len 2
   obj-i2-reading BatTemp
   obj-i2-unpack f>

mit einem "f<" bekomme ich

Code Auswählen Erweitern

BatTemp         6.90910207835351e-41

bin ganz aufgeregt

wie bekomme ich da einen sinnvollen Wert?

mit verbose 5 im Studer485 gibt es folgende Infos im Log

Code Auswählen Erweitern

2021.01.10 14:00:07 4: Studer485: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 14:00:17.085, interval 10
2021.01.10 14:00:07 5: Studer485: GetUpdate objects from attributes: i2
2021.01.10 14:00:07 5: Studer485: GetUpdate full object list: i2
2021.01.10 14:00:07 5: Studer485: GetUpdate check i2 => BatTemp, poll = 1, polldelay = 0.5, last = 1610283597.12929
2021.01.10 14:00:07 4: Studer485: GetUpdate will request BatTemp
2021.01.10 14:00:07 5: Studer485: GetUpdate tries to combine read commands
2021.01.10 14:00:07 4: Studer485: GetUpdate readList = i2
2021.01.10 14:00:07 4: Studer485: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i2, len 2, master device Studer485, reading BatTemp (getUpdate)
2021.01.10 14:00:07 5: Studer485: ParseObj called from HandleResponse with data hex 99c00000d5, type i, adr 2, valuesLen 2, op read
2021.01.10 14:00:07 5: Studer485: ParseObj unpacked 99c00000d5 with f< to 6.90910207835351e-41
2021.01.10 14:00:07 4: Studer485: ParseObj assigns value 6.90910207835351e-41 to BatTemp
2021.01.10 14:00:07 5: Studer485: ParseObj moves to next object, skip 2 to i4
2021.01.10 14:00:07 5: Studer485: ParseObj has no information about handling i4
2021.01.10 14:00:07 5: Studer485: ParseObj created 1 readings
2021.01.10 14:00:17 5: Studer485: GetUpdate called from Fhem internal timer
2021.01.10 14:00:17 4: Studer485: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 14:00:27.087, interval 10
2021.01.10 14:00:17 5: Studer485: GetUpdate objects from attributes: i2
2021.01.10 14:00:17 5: Studer485: GetUpdate full object list: i2
2021.01.10 14:00:17 5: Studer485: GetUpdate check i2 => BatTemp, poll = 1, polldelay = 0.5, last = 1610283607.12887
2021.01.10 14:00:17 4: Studer485: GetUpdate will request BatTemp
2021.01.10 14:00:17 5: Studer485: GetUpdate tries to combine read commands
2021.01.10 14:00:17 4: Studer485: GetUpdate readList = i2
2021.01.10 14:00:17 4: Studer485: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i2, len 2, master device Studer485, reading BatTemp (getUpdate)
2021.01.10 14:00:17 5: Studer485: ParseObj called from HandleResponse with data hex 99c00000d5, type i, adr 2, valuesLen 2, op read
2021.01.10 14:00:17 5: Studer485: ParseObj unpacked 99c00000d5 with f< to 6.90910207835351e-41
2021.01.10 14:00:17 4: Studer485: ParseObj assigns value 6.90910207835351e-41 to BatTemp
2021.01.10 14:00:17 5: Studer485: ParseObj moves to next object, skip 2 to i4
2021.01.10 14:00:17 5: Studer485: ParseObj has no information about handling i4
2021.01.10 14:00:17 5: Studer485: ParseObj created 1 readings

--------------------------------------------------------------------------------------------------------------------------------------------------------

Einer eine Idee, wie ich das mit der Parity ",8,E,1" mit den SDM´s kombiniert bekomme? Eben mal im Hauptsystem mit an die Definition gehängt, also anstatt

Code Auswählen Erweitern

defmod Eastron Modbus /dev/ttyUSB1@9600
mit

Code Auswählen Erweitern

defmod Eastron Modbus /dev/ttyUSB1@9600,8,E,1

dann kommen von den SDM´s keine Readings mehr. Mmmmmmmh.

Später würde ich schon gerne nur einen USB-Adaper und einen Bus betreiben.

[holle75]

Ach so im Manual steht folgendes auf Seite 9

Code Auswählen Erweitern

At address 0x0000, there is a first register that contains the number of currently pending
messages. It should be read first using Modbus Read Input Registers with the "Quantity of Input
Registers" set to 1. It should be done like that, otherwise the Xcom-485i will send back an
exception.

Nicht das ich versuche den BatTemp-Wert in ein lesbares Format zu bekommen und es ist gar kein Wert?
Oder das eine  hängt mit dem anderen gar nicht zusammen? Sag ja, recht komplexe Angelegenheit ....

[holle75]

Ooooh, die

Code Auswählen Erweitern

6.90910207835351e-41

ist tatsächlich die BatTemp. Das Hauptsystem ruft ja über die Cloud ab und 6.9 Grad ist die Temperatur. Nur das "e-41" irritiert und gibt einem nicht das Gefühl, dass das so richtig ist.

[StefanStrobel]

In dem Fall befürchte ich dass 6.90910207835351e-41 nicht der richtige Wert ist.
Aber wenn Du auf einen Request eine prinzipiell gültige Antwort (kein CRC-Fehler) bekommst, ist das ja schon mal ein erster Erfolg!
Dann ist die Verkabelung vermutlich ok.

Von welcher Modbus-Id hast Du das denn abgefragt?
So wie ich die Doku verstehe, bekommst du von der Modbus-Id 0 z.B. die anstehenden Nachrichten, die ein Gerät von sich aus an das Gateway gesendet hat (dazu gehört der von Dir vorhin zitierte Absatz - siehe Kapitel 5 in dem zuletzt von Dir geposteten PDF).
Dazu must Du laut Deiner Doku Input Register 0 immer mit der Länge 1 abfragen und danach Register 1 immer mit der Länge 4.

Die tatsächlichen Werte der Geräte hinter dem Gateway werden über andere Modbus-Ids abgefragt. Das steht in Kapitel 6.
Da muss man dann Register 2 mit Länge 2 abfragen um die Temperatur als 64-Bit-Wert zu bekommen.
Die Id hängt von Deinen Einstellungen ab.

The value of user info 3001 is stored in register 2 and 3 and in order to read this user info on
Xtender 1, the request must be addressed to slave n°11 (0x0B) , assuming that Address Offset is
set to 0.

Gruss
   Stefan

[holle75]

Aber wenn Du auf einen Request eine prinzipiell gültige Antwort (kein CRC-Fehler) bekommst, ist das ja schon mal ein erster Erfolg!
Dann ist die Verkabelung vermutlich ok.

YES! denke ich auch. Dank dir

In dem Fall befürchte ich dass 6.90910207835351e-41 nicht der richtige Wert ist.

Schau mal meine Antwort im Thread eins über deiner. Ich denke (jetzt) schon, dass es der richtige Wert ist. Allerdings noch ein bißchen verholpert

Von welcher Modbus-Id hast Du das denn abgefragt?

ID 1

Ich verstehe das (jetzt) so, dass je nach gedipten Adressbereich (Adresse->ID) der Xcom485 ID1, bzw. ID33, bzw. ID65 bekommt. Die Studer Geräte an sich dann ID´s entsprechend dem Offset (Seite 6, ich hängs nochmal komplett an)

So wie ich die Doku verstehe, bekommst du von der Modbus-Id 0 z.B. die anstehenden Nachrichten, die ein Gerät von sich aus an das Gateway gesendet hat (dazu gehört der von Dir vorhin zitierte Absatz - siehe Kapitel 5 in dem zuletzt von Dir geposteten PDF).
Dazu must Du laut Deiner Doku Input Register 0 immer mit der Länge 1 abfragen und danach Register 1 immer mit der Länge 4.

Ich glaube mit dieser Aussage habe ich mich verrannt:

Ach so im Manual steht folgendes auf Seite 9

Code Auswählen Erweitern

At address 0x0000, there is a first register that contains the number of currently pending
messages. It should be read first using Modbus Read Input Registers with the "Quantity of Input
Registers" set to 1. It should be done like that, otherwise the Xcom-485i will send back an
exception.

Nicht das ich versuche den BatTemp-Wert in ein lesbares Format zu bekommen und es ist gar kein Wert?
Oder das eine  hängt mit dem anderen gar nicht zusammen? Sag ja, recht komplexe Angelegenheit ....

(jetzt) denke ich, es geht tatsächlich um MESSAGES im Studer CanBus. Also Hinweise wie "Transferrelais getrennt um 12:33" usw. die du dir als User im Display/RCC anschauen kannst. Seite 9
Vorher nahm ich an, mit Messages seien allgemein "Werte" gemeint.

Wenn ich davon ausgehe, dass die BatTemp-Abfrage von der ID1 den richtigen (noch nicht richtig konfektionierten) Wert enthält, und ich weiter interpretiere, dass alle Werte die lesend und nicht schreibend sind über ID1 abgefragt werden können ..... sind wir schon richtig weit.
Hättest du noch eine Idee, warum der BatTemp hinten noch das e-41 hat?

Und hey, vielleicht lieg ich mit meinen Annahmen komplett falsch.

Ich versuche jetzt mal, einen weiteren Wert nach deinem Raster abzufragen.

[holle75]

.... nach weiterer Lektüre der Doks scheine ich quatsch zu interpretieren und du das genau richtig zu sehen. Damn.
Ich muß wohl doch jedes Studer-Gerät mit eigener ID ansprechen da Register jeweils gleich sind. Aber wie ändere ich die ID wenn diese in der DEF vorgegeben ist?
... und ich Frage mich, warum mir dann ID1 (Xcom485), Register 2 den Wert von eigentlich ID10/ID11 (Xtender), Register 2 gibt.

Anlage Appendix

[StefanStrobel]

einfach für jedes Gerät auch ein eigenes Fhem-Gerät mit pasender ID anlegen.

Die nutzen dann alle das ModbusLine als IO-Device.

Wegen dem Bat-Temp-Wert: schick doch mal das Log, in dem man die tatsächlich gelesenen Byte-Werts sieht. Evt. ist ein anderer unpack-Code oder sogar das Attribut RevRegs nötig um die Register zu vertauschen. Das muss man ausprobieren.

Gruss
   Stefan

[holle75]

Danke. Ich versuche mal ein sauberes Reading auf richtiger ID anzulegen und dann mach ich ein Log.
Für später schraub ich aber erstmal das Ding auf und mach ein 33er Offset weil die SDM´s auf ID1 und ID2 liegen

[holle75]

Grandios! Infos lesen funktioniert jetzt. Danke Stefan.

[OT]
Aber was mir gerade auffällt: Ich habe wirklich Wiki, commandref durchgearbeitet und mir Beispiele angeschaut. Ich habe nichts/nicht viel verstanden.
Wenn ich jetzt die ersten Erfolge sehe, wundert es mich enorm, wie leicht es erscheint. Zumindest der erste Schritt.
Dein Modul ist hervorragend dokumentiert! .... aber setzt an einem Punkt an, wo wahrscheinlich die meisten inkl. mir vom Verständnis her (Modbus und der Wahnsinn dahinter) noch entfernt sind.
Ich fand fhem anfänglich recht steil von der Lernkurve her. Jetzt ist zumindest das Handling kinderleicht. Nicht weil ich es jetzt verstehe, sondern weil fhem an sich leicht ist ... wenn man die entscheidenden Vorgehensweisen am Anfang erklärt bekommt.
Frag mich nicht, worauf ich eigentlich hinauswill ... wahrscheinlich das zur Erklärung und Entschuldigung wenn man sich bißchen blöd anstellt und Dankeschön an deine Geduld.
[OT Ende]

mit

Code Auswählen Erweitern

Internals:
   DEF        11 5
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   5
   MODBUSID   11
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_XTM
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485_XTM
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-10 16:57:20   Battery_temperature 6
     2021-01-10 16:57:20   SoC             100
     2021-01-10 16:49:08   state           opened
   REMEMBER:
     lrecv      1610294240.29133
     lsend      1610294240.25963
   gotReadings:
     SoC        100
   lastRead:
     i14        1610294240.29408
     i2         1610294240.15802
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i14-len 2
   obj-i14-reading SoC
   obj-i14-unpack f>
   obj-i2-len 2
   obj-i2-reading Battery_temperature
   obj-i2-unpack f>

bekomme ich Infos aus dem Xtender. Mit

Code Auswählen Erweitern

Internals:
   DEF        61 5
   FUUID      5ffb1f69-f33f-c138-fbe8-92096ca34e9a6870
   IODev      ModbusLine
   Interval   5
   MODBUSID   61
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_BSP
   NOTIFYDEV  global
   NR         17
   NTFY_ORDER 50-Studer485_BSP
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2021-01-10 16:58:06   Charge_Discharge_W -2.091796875
   REMEMBER:
     lrecv      1610294286.48832
     lsend      1610294286.45657
   gotReadings:
     Charge_Discharge_W -2.091796875
   lastRead:
     i6         1610294286.49106
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i6-len 2
   obj-i6-reading Charge_Discharge_W
   obj-i6-unpack f>

Infos aus dem BSP.

Da es regnet und die Anlage recht weit weg ist, habe ich die ID´s jetzt erstmal ohne offset gelassen.

Ich bastel weiter und werde dann wieder Fragen. Danke erstmal.

[holle75]

jetzt alle Info-Werte die ich bisher über die Cloud geholt habe auf dem Modbus.
Als nächstes schaue ich mal, wie man Setting Prameter schreibt. Ich bin bestimmt recht schnell wieder hier

Aber Zwischenfrage wegen der Definition des Modbus-Devices:

wie bekomme ich (nach Umstellung der ID´s) den Xcom485 auf den selben Bus wie die SDM´s ... (wegen der ",8,E,1" - Problematik)?

[holle75]

... und noch eine Frage:

Code Auswählen Erweitern

attr Studer485_BSP obj-i6-format %2d
attr Studer485_BSP obj-i6-len 2
attr Studer485_BSP obj-i6-reading Charge_Discharge_W
attr Studer485_BSP obj-i6-unpack f>

generiert mir brav ein Reading. Dieses ist je nach Situation positiv oder negativ.
Allerdings bekomme ich im Log folgenden Fehler

Code Auswählen Erweitern

Studer485_BSP: ParseObj unpack of d2 with f> for Charge_Discharge_W resulted in undefined value

habs auch schon mit allen möglichen anderen Parametern wie "s", "c", etc in "attr Studer485_BSP obj-i6-unpack f>" probiert, aber dann bekomme ich falsche Werte im Reading.

[Hollo]

...Aber Zwischenfrage wegen der Definition des Modbus-Devices:

wie bekomme ich (nach Umstellung der ID´s) den Xcom485 auf den selben Bus wie die SDM´s ... (wegen der ",8,E,1" - Problematik)?

Das stellst du doch am Device ein, oder?
Den SDM kannst du auf jeden Fall passend konfigurieren.

[StefanStrobel]

Code Auswählen Erweitern

Studer485_BSP: ParseObj unpack of d2 with f> for Charge_Discharge_W resulted in undefined value
habs auch schon mit allen möglichen anderen Parametern wie "s", "c", etc in "attr Studer485_BSP obj-i6-unpack f>" probiert, aber dann bekomme ich falsche Werte im Reading.

Da wäre ein größerer Ausschnitt aus dem Log sehr hilfreich, damit ich den Kontext sehe.
Scheinbar hat er in dieser Situation nur ein Byte (d2) als Eingabe für den unpack-Befehl. Der erwartet aber 4 Bytes ...

Gruß
   Stefan