Neue Versionen und Support zum Modbus-Modul

[breitbanddilettant]

Hallo Zusammen,

ich besitze eine Ecodan ERSC-VM2C und greife per Modbus Interface auf die Ecodan zu.

Code Auswählen Erweitern


define ModbusBus Modbus /dev/ttyUSB0@9600
define Ecodan ModbusAttr 1 60
attr Ecodan IODev ModbusBus
attr Ecodan dev-h-defPoll 1
attr Ecodan event-min-interval .*:600
attr Ecodan event-on-change-reading .*


Einmal die Minute hole ich mir mit ca. 30 Readings die Werte diverser Ecodan Register ab - darunter auch z.B. der Sollwert der Vorlauftemperatur. Die Vorlauftemperatur kann ich dann von fhem aus auch anpassen und an die Ecodan zurückschicken.

Das reading für Tsoll-Vorlauf sieht z.B. so aus:

Code Auswählen Erweitern


attr Ecodan obj-h32-expr $val/100
attr Ecodan obj-h32-hint 30,31,32,33,34,35,36,37,38,39,40
attr Ecodan obj-h32-max 60
attr Ecodan obj-h32-min 10
attr Ecodan obj-h32-reading Tsoll-Vorlauf
attr Ecodan obj-h32-set 1
attr Ecodan obj-h32-setexpr $val*100


Über ftui habe ich eine GUI gebaut, mit der ich per Knopfdruck diesen Sollwert um 1 erhöhen oder verringern kann.

Code Auswählen Erweitern


<div class="cell">
<div class="doublebox-v tiny">
<div data-type="push" data-device="Ecodan" data-set="Tsoll-Vorlauf" data-icon="fa-chevron-up" data-background-icon="fa-square-o" data-set-on="[Ecodan:Tsoll-Vorlauf-Up]">
</div>
<div data-type="push" data-device="Ecodan" data-set="Tsoll-Vorlauf" data-icon="fa-chevron-down" data-background-icon="fa-square-o" data-set-on="[Ecodan:Tsoll-Vorlauf-Down]">
</div>
</div>


Außerdem habe ich eine Anzeige für Tsoll-Vorlauf

Code Auswählen Erweitern


<div class="cell">
<div data-type="label" data-device="Ecodan" data-get="Tsoll-Vorlauf" data-unit="&deg;C" data-fix="0" class="big bold cell orange"></div>
<div class="top-narrow  small">Soll</div>
</div>


Folgendes Verhalten (wir starten mit 35°C Tsoll-Vorlauf):

- in der GUI wird Tsoll-Vorlauf angepasst. Drei mal drücken auf "push" -daher sollte folgende Sequenz angezeigt werden 35°C->36°C->37°C->38°C

- bei jedem neuen Wert wird ein set Befehl an die Ecodan geschickt, diese Braucht aber einige Sekunden, um das Empfangene zu verarbeiten. In ftui wird aber alles direkt richtig angezeigt. Also 35°C->36°C->37°C

- ABER: ziemlich zeitgleich werden manchmal zufällig (z.B. weil eine Minute wieder vergangen ist) die Register der Ecodan ausgelesen - und hier steht auf Grund der Verzögerung der Ecodan noch der alte Wert 35°C drin

- Das hat dann zur Folge, dass der in fhem/ftui angezeigte Wert von Tsoll-Vorlauf mal dem neuen Vorlaufwert (von mir per gui vorgegeben) und mal dem alten Vorlaufwert (der, der halt noch von der Ecodan genutzt wird und gerade vom reading geholt wurde) entspricht. Also springt die Anzeige von 35°C->36°C->37°C->35°C und mein nächster Tastendruck erhöht den Wert dann wieder auf 36°C. Also schauts dann in Realität so aus: 35°C->36°C->37°C->35°C->36°C.

Grundsätzlich ist das Problem, dass ich den neuen Sollwert auf Basis des aktuellen Wertes berechne und sich durch das minütlich wiederkehrende reading teilweise der falsche aktuelle Wert ausgelesen wird.

Jetzt zu meiner Frage:
- Gibt es eine Möglichkeit neue set Werte direkt zu übermitteln, aber mit dem get Abruf der Werte eine Vorgegebene Zeit zu warten, sodass sich set und get nicht in die Quere kommen?
- hat jemand eine alternative Idee?

Danke und schöne Grüße

[StefanStrobel]

Hallo breitbanddilettant,

Du könntest mal versuchen, für Dein Soll-Reading ein pollDelay zu setzen.
Die Modbus-Response für function code 6 (write Holding Register) enthält ja wieder den gesetzten Wert.
Der wird vom Modul wie eine Antwort auf function code 3 verarbeitet und dabei merkt sich das Modul, wann das Reading zuletzt gelesen wurde. Auch wenn es kein function code 3 zum Lesen sondern 6 zum Schreiben war.

Beim nächsten Update-Zyklus (wenn die Minute um ist) schaut das Modul dann für jedes zu lesende Objekt ob ein gesetzter pollDelay auch schon abgelaufen ist. Falls nicht (weil zwischen drin ein set Befehl kam) wird das Reading dieses Mal nicht abgefragt, sondern erst beim nächsten Update-Zyklus.
Eventuell kannst Du Dein Problem so lösen.

Gruß
   Stefan

[breitbanddilettant]

Hi Stefan,

vielen Dank - das scheint geholfen zu haben

Grüße,
Konstantin

[ch.eick]

Hi,

ich lese gerade ein Gerät mit modbus aus und kann den Wert auch schon sehen.

Code Auswählen Erweitern


dev-type-INT16-format %s
dev-type-INT16-len 1

obj-h40077-reading Phase_A_to_Neutral_AC_Voltage
obj-h40077-type INT16


Das ergibt folgendes Reading

Code Auswählen Erweitern


Phase_A_to_Neutral_AC_Voltage 23081


%s ergibt hierbei natürlich einen String, jedoch müsste der Wert 230.08 werden und ich finde das Zauberwort dazu nicht.

In der Modbus Doku steht dazu als Beispiel folgendes "4950 Hz * 10 ^ {- 2} = 49.50 Hz"

Wie kann ich das nun im modbus Modul umsetzen? Gibt es eventuell einen anderen Parameter (anstatt %s), der mir den Wert umrechnet?
Kann ich die Formel bei der Formatanweisung irgendwie direkt einsetzen? Wie wäre da der Syntax?

Viele Grüße
    Christian

[Frank_Huber]

Müsstest doch nur durch 100 teilen.

Das obj-h40077-expr attribut auf "$val/100"



Gesendet von meinem Doogee S60 mit Tapatalk

[ch.eick]

Müsstest doch nur durch 100 teilen.
Das obj-h40077-expr attribut auf "$val/100"

Hallo Frank,
ich bin echt dem Depp sein Sohn

Mit der folgenden Format geht es problemlos

Code Auswählen Erweitern


dev-type-INT16-expr  $val/100
dev-type-INT16-format  %.2f
dev-type-INT16-len 1


Und schon sieht es dann so aus

Phase_A_to_Neutral_AC_Voltage  232.97

Gruß
    Christian

[w125t]

Ich hatte schon seit einiger zeit einen EPEVER TRACER Laderegler mit USB-RS485 Adapter mit CM340 und Modbussattr am laufen , seit voriger Woche erhalte ich jedoch keine Readings mehr.
Am WINDOWS rechner funktioniert der Adapter problemlos.

Ich habe schon einige tests mit den timern gemacht , aber leider immer kein Ergebnis.

Könnt Ihr helfen ?

LOG ist als Anlage dran.
Danke

[w125t]

ich habe FHEm neu aufgesetzt und damit funktioniert es erstmal readings sind wieder da ,aber interessant wäre schon , warum es nicht mehr ging.
Es hat 2 Monate funktioniert. Ich mache jetzt nochmal ein Fhem update und schaue mal.

Ich denke der der CH340 chip ist eher ungeeignet , ich habe mir jetzt mal diesen bestellt ,
https://www.amazon.de/gp/product/B07B416CPK/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
was denkt Ihr als Profis darüber ??

[w125t]

nach update all wieder keine readings , schade , habt ihr eine Idee???

[w125t]

letzte Version war die 5.8 Fhem mit der läuft es

[w125t]

letzte Version war die 5.8 Fhem mit der läuft es

NAch  1 Stund fällt es wieder aus

[The Spirit]

Hi.
Ich versuche mit dem SolarEdge modul was Modbus benutzt auf meinen Wechselrichter zuzugreifen.
Leider klappt dies nicht (disconnected).
Daher wollte ich erstmal nur mit dem Modbus Modul versuchen, ein connected hinzubekommen.
Leider bleibt auch hier das device auf disconnected stehen.
Im log steht einmal:

Code Auswählen Erweitern

Open Callback: ip: Connection refused (111)
bzw.

Code Auswählen Erweitern

successive open ignored
Ich muss dazu sagen, das ich von einer anderen Haussteuerungssoftware schon auf den Wechselrichter per Modbus TCP zugreife.
Kann es sein, das ich dann mit FHEM nicht mehr per modbus TCP auf das gleiche Gerät zugreifen kann?
Was kann ich noch testen?
Danke

[bertl]

Hallo Zusammen,

ich habe eine Mitsubishi Ecodan Luft-Wärmepumpe.
An der Inneneinheit EHST20C-YM9EB ist das Modbus-Modul Procon MelcoBEMS MINI A1M angeschlossen.
Das Modbus RTU Protokoll wird über den Ethernet-Converter USR-TCP232-410s ins hausinterne LAN gespeist.
Von dort holt sich mein Raspberry Pi 3 Model B die Daten ab.

Code Auswählen Erweitern

define mdbsWaermepumpe ModbusEcodanWP 1 30 192.168.1.101:502 TCP

Prinzipiell funktioniert das Ganze auch, aber ich bekomme relativ viele Einträge im Log-File folgender Art:

Code Auswählen Erweitern

2020.03.19 12:20:06 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 152, type i, adr 28, len 2 for device mdbsWaermepumpe reading Kaeltemittel_Fehlerinfo (getUpdate), queued 5.93 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:35:11 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 63, type i, adr 8, len 2 for device mdbsWaermepumpe reading Modbus_Fehler (getUpdate), queued 11.09 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:37:37 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 129, type i, adr 39, len 2 for device mdbsWaermepumpe reading Heizen_Quelle (getUpdate), queued 6.67 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:57:42 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 247, type i, adr 29, len 2 for device mdbsWaermepumpe reading Anlage_Fehlercode1 (getUpdate), queued 11.82 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:58:40 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 104, type i, adr 32, len 2 for device mdbsWaermepumpe reading WP_Frequenz_Hz (getUpdate), queued 9.61 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:07:14 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 15, type i, adr 32, len 2 for device mdbsWaermepumpe reading WP_Frequenz_Hz (getUpdate), queued 14.02 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:14:40 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 70, type i, adr 8, len 2 for device mdbsWaermepumpe reading Modbus_Fehler (getUpdate), queued 9.60 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:36:12 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 225, type i, adr 44, len 2 for device mdbsWaermepumpe reading Temp_Vorlauf_SOLL (getUpdate), queued 11.81 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:44:39 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 2, tid 91, type d, adr 21, len 1 for device mdbsWaermepumpe reading Wasserpumpe (getUpdate), queued 8.88 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:46:09 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 2, tid 64, type d, adr 21, len 1 for device mdbsWaermepumpe reading Wasserpumpe (getUpdate), queued 8.87 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:53:07 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 103, type i, adr 28, len 2 for device mdbsWaermepumpe reading Kaeltemittel_Fehlerinfo (getUpdate), queued 6.69 secs ago, sent 3.00 secs ago, read buffer empty

Pro Tag in etwa 30 bis 50 Einträge, wobei es sich um verschiedenste Readings handelt.

Meine Frage dazu:
Sind diese Log-Einträge normal oder passt irgend eine Einstellung nicht (ich kann leider mit dieser Log-Info nicht viel anfangen)?

Danke für eure Hilfe!

(Im Anhang die Internals und ein 17min Verbose 5 Log - leider kein Timeout in dieser Zeit)

[laserrichi]

ohne jetzt das zu kennen, evtl. ein Ansatz:

dev-timing-timeout 3

3 Sekunden ist vieleicht etwas wenig

und bei deinem DEFINE vom Device   hast du 30 Sekunden intervall angelegt, vieleicht definierst du das device mit einem längeren intervall.

[bertl]

Hallo laserrichi,

danke für deinen Vorschlag!

Dadurch wird aber wahrscheinlich das Problem nicht gelöst, WARUM diese Timeouts mit den 'read buffer empty' auftreten.
Auf was soll ich das 'dev-timing-timeout' setzen?
Bei den Meldungen 'queued X.XX secs ago, sent 3.00 secs ago' variert X.XX von 3.00 bis zu 17.00 secs!

Sicher könnte man das Device Abfrageintervall auf 120 Sekunden und das Register-Timeout auf 30 Sekunden setzen - aber gehen dann nicht wichtige Infos verloren?

Wenn man den Grund für die hohen Timeouts findet (falsches Setup, Internetverbindung, Sync-Probleme, ...), dann kann man das Problem bei den Wurzeln packen und lösen.
Leider habe ich überhaupt keine Idee, wo ich zum Suchen anfangen soll!

Daher meine Frage um Hilfe in diesem Forum.