CUXD Werte werden verändert

[Sandomor]

Describe the bug
Der Datenpunkt eines CUXD Devices (Wrapper Devices) hat auf der CCU (Raspberry Matic Vers 3.51.6.20200621) den Wert 90.7
und wird im iobroker mit 50.05 dargestellt. Dies trifft auf alle numerischen Datenpunkte zu: Min, Max, State, Median, Mean

Hier der Auszug aus dem Log von ioBroker:
hm-rpc.2.CUX9000001.1.STATE ==> UNIT: "%" (min: -99999, max: 99999) From "90.7" => "50.05"

Versions:

• hm-rpc version: 1.14.15
• hm-rega version: 2.6.14
• Node version: 10.15.3
• Operating system: Linux -
• CCU model: raspberrymatic
• CCU firmware: 3.51.6.20200621)

[foxriver76]

Zeig mal eines der betroffenen Objekte bitte

[Sandomor]

Hier das Objekt aus IOBroker:
{ "from": "system.adapter.hm-rega.0", "user": "system.user.admin", "ts": 1596623061745, "common": { "name": "Zisterne_%:1.STATE", "type": "number", "unit": "%", "role": "state", "def": 0, "min": -99999, "max": 99999, "read": true, "write": false }, "native": { "ID": "STATE", "UNIT": "%", "TYPE": "FLOAT", "TAB_ORDER": 0, "OPERATIONS": 5, "FLAGS": 1, "MIN": -99999, "MAX": 99999, "DEFAULT": 0 }, "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1636 }, "_id": "hm-rpc.2.CUX9000001.1.STATE", "type": "state" }

[Sandomor]

[Sandomor]

Was ich in der Zwischenzeit mal gemacht habe:

hm-rpc.2 gestoppt - Das Device in IOB gelöscht - und hm-rpc2 wieder gestartet (mit Neueinlesen der Datenpunkte)

[Sandomor]

Hier noch der Auszug aus dem Log

<
hm-rpc.2 2020-08-05 12:39:08.622 silly (11655) States user redis pmessage hm-rpc.2./hm-rpc.2.CUX9000001.1.STATE:{"val":50.05,"ack":true,"ts":1596623948620,"q":0,"from":"system.adapter.hm-rpc.2","user":"system.user.admin","lc":159662306573
hm-rpc.2 2020-08-05 12:39:08.619 debug (11655) hm-rpc.2.CUX9000001.1.STATE ==> UNIT: "%" (min: -99999, max: 99999) From "90.5" => "50.05"
hm-rpc.2 2020-08-05 12:39:08.619 debug (11655) binrpc <- event ["CUxD","CUX9000001:1","STATE",90.5]
hm-rpc.2 2020-08-05 12:39:08.619 debug (11655) bin multicall : CUxD,CUX9000001:1,STATE,90.5
hm-rpc.2 2020-08-05 12:38:54.848 silly (11655) States user redis pmessage hm-rpc.2./hm-rpc.2.CUX9000001.1.STATE:{"val":50.05,"ack":true,"ts":1596623934847,"q":0,"from":"system.adapter.hm-rpc.2","user":"system.user.admin","lc":159662306573
hm-rpc.2 2020-08-05 12:38:54.846 debug (11655) hm-rpc.2.CUX9000001.1.STATE ==> UNIT: "%" (min: -99999, max: 99999) From "90.4" => "50.05"
hm-rpc.2 2020-08-05 12:38:54.846 debug (11655) binrpc <- event ["CUxD","CUX9000001:1","STATE",90.4]
hm-rpc.2 2020-08-05 12:38:54.845 debug (11655) bin multicall : CUxD,CUX9000001:1,STATE,90.4

[foxriver76]

Danke. Schaue dann mal tiefer rein, wenn ich wieder im Lande bin, muss hier in etwa dran liegen

ioBroker.hm-rpc/main.js

Line 1094 in 91e3bfd

val = ((parseFloat(params[3]) - dpTypes[name].MIN) / (dpTypes[name].MAX - dpTypes[name].MIN)) * 100;

[Sandomor]

danke...

[foxriver76]

Ah.. warum eigentlich min: -9999 und Max: 9999? das macht eigentlich gar kein Sinn, ist doch ein prozentualer Wert zwischen 0 und 100 der so direkt geliefert wird.

[Sandomor]

das wird automatisch angelegt. Natürlich kommen nur Werte zw 0 und 100 hinein...

[foxriver76]

Hm was der Adapter dort "eigentlich" korrekterweise tut, ist, den Prozentwert selbst zu berechnen. Und dann landet man mit den ca. 90 bei knapp über 50 %. Die Konvertierung wird für viele andere Geräte in dieser Form benötigt - ich weiß aktuell nicht warum CuxD sich da anders verhält.

[foxriver76]

Muss auf jeden Fall an einer Stelle gefixt werden. Och schaue nächste Woche im Detail.

[Sandomor]

Danke für die Hilfen - Nach Studium des Codes in dem Bereich habe ich mal als schnellen Fix die Einheit im WrapperDevice auf der CCU weggegeben - jetzt stimmen die Werte...