ModbusRegister abhängig von anderem ModbusRegister

Begonnen von willyk, 19 Dezember 2015, 13:22:22

Vorheriges Thema - Nächstes Thema

willyk

Hallo,   mit ModbusTCP und dem wiki-Artikel http://www.fhemwiki.de/wiki/Dimplex_W%C3%A4rmepumpenmanager versuche ich gerade meine WP an fhem anzubinden. Die Register kann ich mit "define <name> ModbusRegister 1234" grossteils abfragen, ich erhalte auch Daten die korrekt aussehen.

Nun gibt es allerdings einige Register, die je nach Einstellung eines zweiten Registers unterschiedliche Bedeutungen haben. Auszug aus der Doku http://www.dimplex.de/wiki/index.php/NWPM_Modbus_TCP:

Ein Zugriff auf die Zeitfunktionen für z.B. Sperren, Absenk-/ Anhebwerte oder Zeiten erfolgt über das Umschalten der Adresse 192 (Modbus IP 5065).
*Programmierhinweis!
Um einen Absenk- oder Anhebwert für den 1.Heizkreis zu ändern, wird auf die Adresse 192 (Modbus IP 5065) der Wert 1 für Absenkung bzw. 2 für Anhebung gesendet. Anschließend können die gewünschten Werte des 1.Heizkreises geändert werden. Analog der Beschreibung erfolgt dies mit dem 2. und 3. Heizkreis oder auch Sperren für z.B. die Warmwasser- und Schwimmbadbereitung.



Ich habe versucht in den Artikeln zu Modbus einen Hinweis zu finden, bin aber nicht fündig geworden.

define dim_waterheating_select ModbusRegister 0 5065
attr dim_waterheating_select IODev HeatPumpServer
attr dim_waterheating_select event-min-interval .*:900
attr dim_waterheating_select event-on-change-reading .*
attr dim_waterheating_select plcDataType INT
attr dim_waterheating_select registerType Holding
attr dim_waterheating_select room Dimplex
attr dim_waterheating_select updateInterval 900
define dim_waterheating_hourstart1 ModbusRegister 0 5066
attr dim_waterheating_hourstart1 IODev HeatPumpServer
attr dim_waterheating_hourstart1 event-min-interval .*:900
attr dim_waterheating_hourstart1 event-on-change-reading .*
attr dim_waterheating_hourstart1 plcDataType INT
attr dim_waterheating_hourstart1 registerType Holding
attr dim_waterheating_hourstart1 room Dimplex
attr dim_waterheating_hourstart1 updateInterval 900



Die Definition für dim_waterheating_hourstart1 ist nur dann korrekt, wenn in dim_waterheating_select der Wert "7" steht.

Wie kann man sowas definieren? Oder ist das gar nicht möglich?

Danke + Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

ChrisD

#1
Hallo,

Ich habe das Modul um ein Attribut enableUpdate erweitert. Damit kannst du festlegen dass ein Register nur dann aktualisiert wird wenn eine Bedingung erfüllt. In deinem Fall sollte
attr dim_waterheating_hourstart1 enableUpdate dim_waterheating_select:state:7
funktionieren.

Beim Schreiben wird das Attribut nicht beachtet.

Grüße,

ChrisD


willyk

#2
Super, vielen Dank - aber das löst das Problem vermutlich nicht vollständig.

Wie kriege ich denn eine regelmässige Aktualisierung der Werte hin? Also z.B.

define dim_waterheating_select ModbusRegister 0 5065
attr dim_waterheating_select IODev HeatPumpServer
attr dim_waterheating_select event-min-interval .*:900
attr dim_waterheating_select event-on-change-reading .*
attr dim_waterheating_select plcDataType INT
attr dim_waterheating_select registerType Holding
attr dim_waterheating_select room Dimplex
attr dim_waterheating_select updateInterval 900
define dim_waterheating_hourstart1 ModbusRegister 0 5066
attr dim_waterheating_hourstart1 IODev HeatPumpServer
attr dim_waterheating_hourstart1 event-min-interval .*:900
attr dim_waterheating_hourstart1 event-on-change-reading .*
attr dim_waterheating_hourstart1 plcDataType INT
attr dim_waterheating_hourstart1 registerType Holding
attr dim_waterheating_hourstart1 room Dimplex
attr dim_waterheating_hourstart1 updateInterval 900
attr dim_waterheating_hourstart1 enableUpdate dim_waterheating_select:state:7

define dim_primaryheating_hourstart1 ModbusRegister 0 5066
attr dim_primaryheating_hourstart1 IODev HeatPumpServer
attr dim_primaryheating_hourstart1 event-min-interval .*:900
attr dim_primaryheating_hourstart1 event-on-change-reading .*
attr dim_primaryheating_hourstart1 plcDataType INT
attr dim_primaryheating_hourstart1 registerType Holding
attr dim_primaryheating_hourstart1 room Dimplex
attr dim_primaryheating_hourstart1 updateInterval 900
attr dim_primaryheating_hourstart1 enableUpdate dim_waterheating_select:state:1


Muss ich dann alle 15 Minuten das Register 5065 umdrehen? Das ist doch auch ein wenig schräg, oder? Bin ich der erste mit einem solchen Problem?

Gruss
willyk



P.S.: beim Laden des Moduls gibt es im logfile eine Fehlermeldung:

Found = in conditional, should be == at ./FHEM/37_ModbusRegister.pm line 495, <> line 7.

NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

ChrisD

#3
Hallo,

ZitatMuss ich dann alle 15 Minuten das Register 5065 umdrehen?
Dies wäre eine Möglichkeit.

ZitatDas ist doch auch ein wenig schräg, oder?
Ja, deshalb im Anhang eine neue Version der Module bei denen vor dem Lesen ein Wert geschrieben werden kann. Ich habe dazu das Attribut enableUpdate erweitert, mit
attr dim_waterheating_hourstart1 enableUpdate dim_waterheating_select:state:7:1
wird der Wert von dim_waterheating_select geschrieben wenn er nicht passt. Dies sollte im Moment aber nicht gleichzeitig mit dem Attribut 'combineReads' des ModbusTCPServer-Modules verwendet werden.

ZitatBin ich der erste mit einem solchen Problem?
Es gibt leider eine Reihe von Geräten auf dem Markt bei denen die Daten auf dem Modbus gemultiplext werden. Dabei bietet Modbus direkten Zugriff auf 128k Worte (64k lesen/schreiben und 64k nur lesen) was eigentlich ausreichend ist. Wieso einige Geräte trotzdem diese schrägen Zugriffe benötigen ist rätselhaft.

Die Fehlermeldung im Log ist auch behoben.

Grüße,

ChrisD

willyk

#4
Sorry dass ich mich erst jetzt wieder melde - aber Weihnachten fordert seinen Tribut ... :-)

Die Anpassung funktioniert leider nicht durchgehend. Bei mehreren Werten kommt da anscheinend was durcheinander.

Für mich ist es sehr schwer das Problem zu lokalisieren. Meine Definitionen habe ich angehängt (mit Code-Tags kann ich es nicht speichern)


Das Log mit verbose 5 ist ebenfalls angehängt.

Das "Umschalt"-Register ist 5065. event-min-interval und on-change-reading habe ich zum Testen auskommentiert, updateInterval habe ich verkürzt - sonst warte ich beim Testen ewig :-)

Bis zu RQUEUE 59 sieht alles noch normal aus. Danach wird nur noch das Register 5065 angesprochen, andere Register erst später wieder.

Einige Register werden dadurch in fhem überhaupt nicht gefüllt.




Die Coils fehlen auch noch, die sind dummerweise ebenfalls betroffen. Kannst Du das auch noch einbauen?

Wie ist das gedacht, wenn ich eines dieser Register via fhem ändere, wird dann der in enableUpdate gesetzte Wert ebenfalls vorher gesetzt?

Wenn ich was testen kann, einfach mailen, mache ich gerne.

Danke für Deine Unterstützung und Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

ChrisD

#5
Hallo,

Anbei findest du eine neue Version der Module zum Testen. Ich habe das Attribut 'enableUpdate' in 'readCondition' umbenannt, beim Neustart von FHEM sollte das alte Attribut automatisch konvertiert werden.

ZitatWie ist das gedacht, wenn ich eines dieser Register via fhem ändere, wird dann der in enableUpdate gesetzte Wert ebenfalls vorher gesetzt?
Ich habe ein Attribut 'writeCondition' hinzugefügt. Damit kann festgelegt werden was bei einem set passieren soll. Die Syntax ist wie bei readCondition: <device>:<reading>:<value>[:<force>]

ZitatDie Coils fehlen auch noch, die sind dummerweise ebenfalls betroffen. Kannst Du das auch noch einbauen?
Das Ganze funktioniert jetzt auch mit Coils.

ZitatDie Anpassung funktioniert leider nicht durchgehend. Bei mehreren Werten kommt da anscheinend was durcheinander.
Ich denke dass ich den Fehler mit Hilfe der Logs gefunden und behoben habe, kannst du mit der neuen Version testen ?

Grüße,

ChrisD

willyk

Viel besser. Aber nicht gut :-(

Zitat von: ChrisD am 28 Dezember 2015, 22:14:53
beim Neustart von FHEM sollte das alte Attribut automatisch konvertiert werden.

Hat so nicht funktioniert. Habe die neuen Module in das Verzeichnis kopiert, dann einen Restart gemacht, war das falsch? Auf jeden Fall waren weder enabelUpdate noch readCondition sichtbar, ich habe dann das cfg-File zurückkopiert und die Attribute mit einem Editor geändert.

Zitat von: ChrisD am 28 Dezember 2015, 22:14:53
Ich habe ein Attribut 'writeCondition' hinzugefügt. Damit kann festgelegt werden was bei einem set passieren soll. Die Syntax ist wie bei readCondition: <device>:<reading>:<value>[:force]

Was macht :force, wann muss ich das setzen?


Ergebnis meines Tests: es werden alle RegisterWerte gefüllt, aber nicht (alle) korrekt. Definitiv feststellen kann ich das bei (mindestens) einem Wert. Auszug aus dem Logfile:

2015-12-29_12:26:04 dim_settings1_raising_hourend2 11
2015-12-29_12:26:04 dim_settings1_raising_hourend2 RAW: 000b
...
2015-12-29_12:26:24 dim_settings1_raising_hourend2 6
2015-12-29_12:26:24 dim_settings1_raising_hourend2 RAW: 0006



Der Wert "11" ist korrekt, und ist für Register 5065=2. Der Wert "6" müsste eigentlich für Register 5065=1 übertragen werden. Geändert wurden die Werte zwischendurch natürlich nicht...

Die Definitionen habe ich etwa drei Dutzend mal überprüft, kann aber keine Fehler finden.

Config und Debug habe ich wieder angehängt.


Mit write habe ich noch nichts gemacht, das plane ich erst wenn die "reads" richtig sind  8)

Wenn ich etwas bestimmtes testen kann, lass es mich wissen.

Und - danke für Deine Mühe !!!

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

oniT

#7
Hallo willyk,

ich konnte dir leider den Code noch nicht zu 100% fertigstellen sonst hätte ich diesen schon reingesetzt. Eigentlich müssen die Werte nicht alle 15 oder X Minuten gelesen werden. Die Werte ändern sich ja nur wenn Du eine Änderung vornimmst. Zuerst müssen die Register gelesen und sollte eine Änderung von Dir vorgenommen werden, diese dann zurück geschrieben werden.

Da der Code für alle Zeitpgrogramme gültig ist, werde ich diesen erst fertig stellen und dann hier bzw. in's Wiki setzen.

Gruß
Tino
BBB - debian weezy - FHEM 5.7
HMLAN - HM-LC-Bl1-FM, HM-ES-PMSw1-PI, HM-LC-Sw1-FM, HM-TC-IT-WM-W-EU, HM-WDS40-TH-I, HM-Sen-Wa-Od, HM-Sec-RHS
Dimplex Wärmepumpe / Dimplex ZL 300 - Modbus TCP
SDM630M - Modbus TCP
SolarLog 200 / SMA SonnyBoy 1.5/2.5 - Modbus TCP

willyk

Tino,  dass die Werte nicht andauernd gelesen werden müssen ist mir schon klar. Allenfalls einige Coils welche einen aktuellen Zustand anzeigen sind da evtl. sinnvoll.

Das nutzt allerdings nichts, wenn die übertragenen Werte falsch sind. Und ob das alle 15 Minuten oder einmal am Tag falsch übertragen wird, ist beides genauso übel.

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

ChrisD

Hallo,

Die angezeigten Werte entsprechen denen die das Steuergerät liefert.

Um 2015.12.29 12:26:24 wird dim_settings1_select auf 2 gesetzt
2015.12.29 12:26:24 5: SimpleWrite [F6 B1 00 00 00 06] 00 06 13 C9 00 02
2015.12.29 12:26:24 5: ModbusTCPServer_Parse: received [F6 B1 00 00 00 06] 00 06 13 C9 00 02
und vom Gerät bestätigt.

Anschließend wird Register 5072 (dim_settings1_raising_hourend2) angefordert
2015.12.29 12:26:24 5: SimpleWrite [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.29 12:26:24 5: ModbusTCPServer_Parse: received [13 D0 00 00 00 05] 00 03 02 00 06
und als Rückmeldung kommt 6.

Der Wert wird so übernommen wie deine Steuerung ihn schickt, wieso sie den falschen Wert zurücksendet ist schwierig zu sagen. Eventuell kommt es zu Timing-Problemen. Anbei ist eine modifizierte Version von ModbusTCPServer bei der eine zusätzliche Wartezeit nach dem Schreiben (z.B. von dim_settings1_select) konfiguriert werden kann.

Kannst du zum Testen bei allen readCondition-Attributen hinter :1 noch ein :2000 anhängen, z.B.
attr dim_settings1_lowering_hourstart1 readCondition dim_settings1_select:state:1:1:2000

Die Syntax für das Attribut readCondition ist jetzt <device>:<reading>:<value>[:<force>[:waittime]].
<force> muss auf 1 stehen, <waittime> ist in Millisekunden.

ZitatWas macht :force, wann muss ich das setzen?
Wenn die angegebene Bedingung nicht erfüllt ist gibt es 2 Möglichkeiten:
- :<force> ist nicht angegeben, in dem Fall wird nichts gelesen (was du nicht willst)
- :<force> ist angegeben, in dem Fall wird zuerst versucht die Bedingung zu erfüllen und anschließend wird gelesen
Im Moment muss <force> den Wert 1 haben.

Grüße,

ChrisD

willyk

Zitat von: ChrisD am 31 Dezember 2015, 09:28:42
Kannst du zum Testen bei allen readCondition-Attributen hinter :1 noch ein :2000 anhängen, z.B.
attr dim_settings1_lowering_hourstart1 readCondition dim_settings1_select:state:1:1:2000


Gemacht.

Und siehe da - es wird der richtige Wert "7" übertragen.

Ich habe über die Logfiles versucht herauszufinden was der Unterschied ist. Bei der fehlerhaften Übertragung sieht es wie folgt aus, ab dem Eintrag "RQUEUE 21" wird es unordentlich:

2015.12.31 17:06:47 5: AddRQueue [13 91 00 00 00 06] 00 03 13 91 00 01
2015.12.31 17:06:47 5: SimpleWrite [13 91 00 00 00 06] 00 03 13 91 00 01
2015.12.31 17:06:47 5: AddRQueue [13 90 00 00 00 06] 00 03 13 90 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 1
2015.12.31 17:06:47 5: AddRQueue [13 8F 00 00 00 06] 00 03 13 8F 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 2
2015.12.31 17:06:47 5: AddRQueue [13 8B 00 00 00 06] 00 03 13 8B 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 3
2015.12.31 17:06:47 5: AddRQueue [13 97 00 00 00 06] 00 03 13 97 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 4
2015.12.31 17:06:47 5: AddRQueue [00 16 00 00 00 06] 00 03 00 16 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 5
2015.12.31 17:06:47 5: AddRQueue [13 D9 00 00 00 06] 00 03 13 D9 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 6
2015.12.31 17:06:47 5: AddRQueue [13 D7 00 00 00 06] 00 03 13 D7 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 7
2015.12.31 17:06:47 5: AddRQueue [13 CC 00 00 00 06] 00 03 13 CC 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 8
2015.12.31 17:06:47 5: AddRQueue [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 9
2015.12.31 17:06:47 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 10
2015.12.31 17:06:47 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 11
2015.12.31 17:06:47 5: AddRQueue [13 CD 00 00 00 06] 00 03 13 CD 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 12
2015.12.31 17:06:47 5: AddRQueue [13 D1 00 00 00 06] 00 03 13 D1 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 13
2015.12.31 17:06:47 5: AddRQueue [13 CB 00 00 00 06] 00 03 13 CB 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 14
2015.12.31 17:06:47 5: AddRQueue [13 CF 00 00 00 06] 00 03 13 CF 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 15
2015.12.31 17:06:47 5: AddRQueue [13 D3 00 00 00 06] 00 03 13 D3 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 16
2015.12.31 17:06:47 5: AddRQueue [13 D8 00 00 00 06] 00 03 13 D8 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 17
2015.12.31 17:06:47 5: AddRQueue [13 D2 00 00 00 06] 00 03 13 D2 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 18
2015.12.31 17:06:47 5: AddRQueue [13 D6 00 00 00 06] 00 03 13 D6 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 19
2015.12.31 17:06:47 5: AddRQueue [13 D4 00 00 00 06] 00 03 13 D4 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 20
2015.12.31 17:06:47 5: AddRQueue [13 D5 00 00 00 06] 00 03 13 D5 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 21
2015.12.31 17:06:47 5: AddRQueue [13 D9 00 00 00 06] 00 03 13 D9 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D7 00 00 00 06] 00 03 13 D7 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CC 00 00 00 06] 00 03 13 CC 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CD 00 00 00 06] 00 03 13 CD 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D1 00 00 00 06] 00 03 13 D1 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CB 00 00 00 06] 00 03 13 CB 00 01
2015.12.31 17:06:47 5: AddRQueue [13 CF 00 00 00 06] 00 03 13 CF 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D3 00 00 00 06] 00 03 13 D3 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D8 00 00 00 06] 00 03 13 D8 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D2 00 00 00 06] 00 03 13 D2 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D6 00 00 00 06] 00 03 13 D6 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D4 00 00 00 06] 00 03 13 D4 00 01
2015.12.31 17:06:47 5: AddRQueue [13 D5 00 00 00 06] 00 03 13 D5 00 01
2015.12.31 17:06:47 5: AddRQueue [00 15 00 00 00 06] 00 03 00 15 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 22
2015.12.31 17:06:47 5: AddRQueue [13 8A 00 00 00 06] 00 03 13 8A 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 23
2015.12.31 17:06:47 5: AddRQueue [13 DD 00 00 00 06] 00 03 13 DD 00 01
2015.12.31 17:06:47 5: adding to RQUEUE - 24
2015.12.31 17:06:48 5: AddRQueue [13 DC 00 00 00 06] 00 03 13 DC 00 01
2015.12.31 17:06:48 5: adding to RQUEUE - 25
2015.12.31 17:06:48 5: AddRQueue [13 D9 00 00 00 06] 00 03 13 D9 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D7 00 00 00 06] 00 03 13 D7 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CC 00 00 00 06] 00 03 13 CC 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CD 00 00 00 06] 00 03 13 CD 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D1 00 00 00 06] 00 03 13 D1 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CB 00 00 00 06] 00 03 13 CB 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CF 00 00 00 06] 00 03 13 CF 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D3 00 00 00 06] 00 03 13 D3 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D8 00 00 00 06] 00 03 13 D8 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D2 00 00 00 06] 00 03 13 D2 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D6 00 00 00 06] 00 03 13 D6 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D4 00 00 00 06] 00 03 13 D4 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D5 00 00 00 06] 00 03 13 D5 00 01
2015.12.31 17:06:48 5: AddRQueue [13 E0 00 00 00 06] 00 03 13 E0 00 01
2015.12.31 17:06:48 5: adding to RQUEUE - 26
2015.12.31 17:06:48 5: AddRQueue [00 5D 00 00 00 06] 00 03 00 5D 00 01
2015.12.31 17:06:48 5: adding to RQUEUE - 27
2015.12.31 17:06:48 5: AddRQueue [13 DF 00 00 00 06] 00 03 13 DF 00 01
2015.12.31 17:06:48 5: adding to RQUEUE - 28
2015.12.31 17:06:48 5: AddRQueue [13 D9 00 00 00 06] 00 03 13 D9 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D7 00 00 00 06] 00 03 13 D7 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CC 00 00 00 06] 00 03 13 CC 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 17:06:48 5: AddRQueue [13 CD 00 00 00 06] 00 03 13 CD 00 01
2015.12.31 17:06:48 5: AddRQueue [13 D1 00 00 00 06] 00 03 13 D1 00 01


Bei der neuen Version sieht das anders aus:

015.12.31 16:59:05 5: HeatPumpServer dispatch ModbusCoil:0:91:1:1:0
2015.12.31 16:59:07 5: AddRQueue [13 91 00 00 00 06] 00 03 13 91 00 01
2015.12.31 16:59:07 5: SimpleWrite [13 91 00 00 00 06] 00 03 13 91 00 01
2015.12.31 16:59:07 5: AddRQueue [13 90 00 00 00 06] 00 03 13 90 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 1
2015.12.31 16:59:07 5: AddRQueue [13 8F 00 00 00 06] 00 03 13 8F 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 2
2015.12.31 16:59:07 5: AddRQueue [13 8B 00 00 00 06] 00 03 13 8B 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 3
2015.12.31 16:59:07 5: AddRQueue [13 97 00 00 00 06] 00 03 13 97 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 4
2015.12.31 16:59:07 5: AddRQueue [00 16 00 00 00 06] 00 03 00 16 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 5
2015.12.31 16:59:07 5: AddRQueue [23 98 00 00 00 06] 00 06 13 C9 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 6
2015.12.31 16:59:07 5: adding to RQUEUE - 7
2015.12.31 16:59:07 5: AddRQueue [13 D9 00 00 00 06] 00 03 13 D9 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 8
2015.12.31 16:59:07 5: AddRQueue [13 D7 00 00 00 06] 00 03 13 D7 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 9
2015.12.31 16:59:07 5: AddRQueue [13 CC 00 00 00 06] 00 03 13 CC 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 10
2015.12.31 16:59:07 5: AddRQueue [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 11
2015.12.31 16:59:07 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 12
2015.12.31 16:59:07 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 13
015.12.31 16:59:07 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 13
2015.12.31 16:59:07 5: AddRQueue [13 CD 00 00 00 06] 00 03 13 CD 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 14
2015.12.31 16:59:07 5: AddRQueue [13 D1 00 00 00 06] 00 03 13 D1 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 15
2015.12.31 16:59:07 5: AddRQueue [13 CB 00 00 00 06] 00 03 13 CB 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 16
2015.12.31 16:59:07 5: AddRQueue [13 CF 00 00 00 06] 00 03 13 CF 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 17
2015.12.31 16:59:07 5: AddRQueue [13 D3 00 00 00 06] 00 03 13 D3 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 18
2015.12.31 16:59:07 5: AddRQueue [13 D8 00 00 00 06] 00 03 13 D8 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 19
2015.12.31 16:59:07 5: AddRQueue [13 D2 00 00 00 06] 00 03 13 D2 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 20
2015.12.31 16:59:07 5: AddRQueue [13 D6 00 00 00 06] 00 03 13 D6 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 21
2015.12.31 16:59:07 5: AddRQueue [13 D4 00 00 00 06] 00 03 13 D4 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 22
2015.12.31 16:59:07 5: AddRQueue [13 D5 00 00 00 06] 00 03 13 D5 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 23
2015.12.31 16:59:07 5: AddRQueue [F8 52 00 00 00 06] 00 06 13 C9 00 02
2015.12.31 16:59:07 5: adding to RQUEUE - 24
2015.12.31 16:59:07 5: adding to RQUEUE - 25
2015.12.31 16:59:07 5: AddRQueue [13 D9 00 00 00 06] 00 03 13 D9 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 26
2015.12.31 16:59:07 5: AddRQueue [13 D7 00 00 00 06] 00 03 13 D7 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 27
2015.12.31 16:59:07 5: AddRQueue [13 CC 00 00 00 06] 00 03 13 CC 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 28
2015.12.31 16:59:07 5: AddRQueue [13 D0 00 00 00 06] 00 03 13 D0 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 29
2015.12.31 16:59:07 5: AddRQueue [13 CA 00 00 00 06] 00 03 13 CA 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 30
2015.12.31 16:59:07 5: AddRQueue [13 CE 00 00 00 06] 00 03 13 CE 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 31
2015.12.31 16:59:07 5: AddRQueue [13 CD 00 00 00 06] 00 03 13 CD 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 32
2015.12.31 16:59:07 5: AddRQueue [13 D1 00 00 00 06] 00 03 13 D1 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 33
2015.12.31 16:59:07 5: AddRQueue [13 CB 00 00 00 06] 00 03 13 CB 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 34
2015.12.31 16:59:07 5: AddRQueue [13 CF 00 00 00 06] 00 03 13 CF 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 35
2015.12.31 16:59:07 5: AddRQueue [13 D3 00 00 00 06] 00 03 13 D3 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 36
2015.12.31 16:59:07 5: AddRQueue [13 D8 00 00 00 06] 00 03 13 D8 00 01
2015.12.31 16:59:07 5: adding to RQUEUE - 37
2015.12.31 16:59:07 5: AddRQueue [13 D2 00 00 00 06] 00 03 13 D2 00 01


War das die Ursache?

Bei der neuen Version gibt es nach dem Eintrag "RQUEUE 6" eine Lücke, ist das OK oder gibt das noch ein Problem?

Wie geht's weiter, wird das die "gültige" Version, oder kann ich noch was testen ?

Danke nochmal + Gruss + ein schönes Neujahrsfest
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

ChrisD

Hallo,

ZitatBei der neuen Version gibt es nach dem Eintrag "RQUEUE 6" eine Lücke, ist das OK oder gibt das noch ein Problem?
Das ist richtig, hier wird die Wartezeit in die Queue geschrieben. Da es sich dabei nicht um ein Modbustelegramm handelt gibt es kein Detail.

ZitatWie geht's weiter, wird das die "gültige" Version, oder kann ich noch was testen ?
Ich muss noch einige Details ändern, so wird im Moment nur die 1. Wartezeit verwendet und combineReads funktioniert nicht (was im Moment aber bei deinem Anwendungsfall nicht stört). Weiterhin weiß ich noch nicht ob das Schreiben funktioniert.

Du kannst noch testen wie weit du mit der Wartezeit runtergehen kannst und ob beim Schreiben auch eine Wartezeit nötig ist.

Grüße,

ChrisD

willyk

Hallo,   bin bis Freitag abwesend, kann erst am nächsten WE testen.

Danke + Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

willyk

So,  weiter getestet.

Wartezeit 2000, 1000 und 500 funktionieren. Bei 100 oder 200 werden die Werte durcheinandergeworfen.

Beim Schreiben konnte ich keine Probleme feststellen, allerdings habe ich das nicht intensiv getestet.

Welche Grösse verwendest du für die Wartezeiten? ms sind es nicht, sonst wären es immer 2 Sekunden pro Register ..  :)

Und noch eine Frage: was sind denn sinnvolle / mögliche Abfrage-Intervalle? Ich habe einige Register die ich z.Zt. alle 5 Sekunden abfrage - was noch zu ungenau ist, da der Mischer teilweise nur ein oder zwei Sekunden läuft.

define dim_mixer22_open_output ModbusCoil 0 91
attr dim_mixer22_open_output IODev HeatPumpServer
attr dim_mixer22_open_output disableRegisterMapping 1
attr dim_mixer22_open_output event-min-interval .*:900
attr dim_mixer22_open_output event-on-change-reading .*
attr dim_mixer22_open_output room Dimplex
attr dim_mixer22_open_output source Coil
attr dim_mixer22_open_output updateInterval 5


Danke + Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

ChrisD

Hallo,

ZitatWelche Grösse verwendest du für die Wartezeiten? ms sind es nicht, sonst wären es immer 2 Sekunden pro Register ..
Die Zeit ist in ms. Wenn aber mehrere Register die gleiche Bedingung haben und aufeinander folgen, wird nur ein Mal gewartet. Aus diesem Grund hast du keine 2s Wartezeit pro Register.

ZitatUnd noch eine Frage: was sind denn sinnvolle / mögliche Abfrage-Intervalle? Ich habe einige Register die ich z.Zt. alle 5 Sekunden abfrage - was noch zu ungenau ist, da der Mischer teilweise nur ein oder zwei Sekunden läuft.
Dies hängt von der eingesetzten Hardware ab, wenn die Geräte schnell genug sind kannst du versuchen alle 100ms zu lesen:
attr dim_mixer22_open_output updateInterval 0.1
attr HeatPumpServer pollInterval 0.1

Wichtig dabei ist dass 'pollInterval' des Servers kleiner oder gleich des kleinsten 'updateInterval' ist.

Grüße,

ChrisD

willyk

Der Vollständigkeit halber:

Zitat von: willyk am 11 Januar 2016, 16:44:14
Wartezeit 2000, 1000 und 500 funktionieren. Bei 100 oder 200 werden die Werte durcheinandergeworfen.

War so nicht richtig. Bei 500, 700 und 800 gab es immer noch vereinzelte Fehler. Bei der Einstellung 900 sieht es nun seit einem Tag gut aus.

gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner