RaspberryMatic 3.59.6.20210807 – Neue Version

[MichaelN]

• HM-Strommess-Aktoren: 2 Nachkommastellen beim Messwert-Kanal und beim Entscheidungswert
• IP-Strommess-Aktoren: 1 Nachkommastelle beim Messwert-Kanal und 0 Nachkommastellen beim Entscheidungswert.

Wo stammen die Grenzwerte denn her? Im letzten Thread zum ProofAndSetValue wurde eine XML erwähnt. Aber in welcher stecken die Werte für den PSM?

[jmaus]

• HM-Strommess-Aktoren: 2 Nachkommastellen beim Messwert-Kanal und beim Entscheidungswert
• IP-Strommess-Aktoren: 1 Nachkommastelle beim Messwert-Kanal und 0 Nachkommastellen beim Entscheidungswert.

Wo stammen die Grenzwerte denn her? Im letzten Thread zum ProofAndSetValue wurde eine XML erwähnt. Aber in welcher stecken die Werte für den PSM?

Tja, da ist eben ein Unterschied der alten BidCos vs. HmIP Geräte zu erkennen. Meines Wissens stecken all diese Dinge (Datenpunkte, Limits, etc.) eben bei HmIP Geräten in der Gerätefirmware selbst drin und die WebUI bzw. der HmIPServer fragt die lediglich ab und stellt sie dann dar. Wenn also ein Min/Max-Wert falsch ist, dann müsste hierfür die Gerätefirmware angepasst werden. So zumindest mein Wissensstand.

[MichaelN]

Wenn also ein Min/Max-Wert falsch ist, dann müsste hierfür die Gerätefirmware angepasst werden.

Oh. Dann wird das eher nichts.

[jmaus]

Wenn also ein Min/Max-Wert falsch ist, dann müsste hierfür die Gerätefirmware angepasst werden.

Oh. Dann wird das eher nichts.

Ganz so würde ich das nicht sagen. Ich hab mir das mal angeschaut. Die besagte Zeile in der WebUI die das ProofAndSetValue() verwendet ist diese hier:

https://github.com/eq-3/occu/blob/maste ... .tcl#L2660

Wenn man sich die mal genau anschaut, sieht man das hier das ProofAndSetValue() meines Erachtens zwar richtig aufgerufen wird, der Wert für "value=" wird jedoch in eine floating point zwar mittels "[expr $ps($param). / 100]" abgeändert. Warum das passiert ist mir aktuell noch ein rätsel? Denn eigentlich sollte das IMHO korrekterweise einfach der Wert geteilt durch 100 als integer-wert sein. Durch den "." wird aber explizit ein Gleitkommawert draus gemacht. Und das ist dann die Inkonsistenz die wir in der WebUI warnehmen. Nämlich das die Min/Max Werte eigentlich INTEGER werte sind ohne nachkommastellen, aber die Werte in der WebUI eben als floating point dargestellt werden. D.h. RaspberryMatic WebUI macht das eigentlich richtig das es die kommastellen abschneidet.

Die Frage ist nur:

1. warum wird an der stelle doch ein Floating Point generiert?
2. Nimmt der PSM definitiv eine Floating Point zahl an und verarbeitet die auch richtig? Wenn ja, dann wäre das ein hinweis darauf, das die Min/Max Werte falsch sind und dann müsste man diese Stelle in der WebUI im Grunde "nur" umpatchen das der ProofAndSetValue() ein Min/Max als Floating Point auf den Weg gegeben wird.

Vllt. könnte Punkt 2 ja mal jemand versuchen zu testen/rauszubekommen

[MichaelN]

Also in der WebUI sieht es so aus:

Unbenannt.JPG (24.04 KiB) 1912 mal betrachtet

im SDV habe ich diese Werte identifiziert (ich hoffe richtig)

Wie man sieht sind die dort mit Faktor 100 abgespeichert. Würden also 2 Nachkommastelle verkraften.
Und wenn ich mit dem SDV für Low den Wert 1005 reinschriebe, kommt in der WebUI auch 10,05W an:
(was auch beweisst, das ich den richtigen Parameter identifiziert habe)

Unbenannt3.JPG (21.55 KiB) 1912 mal betrachtet

[Paradox]

das würde meine Automation für den Trockner und Waschmaschine ja echt deutlich vereinfachen mit den Kommazahlen. Ich gucke mir mal das SDV an

[Baxxy]

Ich gucke mir mal das SDV an

Kannst du auch über devconfig machen.

[Paradox]

Ich gucke mir mal das SDV an

Kannst du auch über devconfig machen.

PSM_devconfig.JPG

Bekomme eine Fehlermeldung, Bad Request

[Baxxy]

Wenn ja, dann wäre das ein hinweis darauf, das die Min/Max Werte falsch sind und dann müsste man diese Stelle in der WebUI im Grunde "nur" umpatchen das der ProofAndSetValue() ein Min/Max als Floating Point auf den Weg gegeben wird.

Wenn von eQ-3 vorgesehen ist das nur "ganze Watt" für die Entscheidungswerte zulässig sind dann sind die Limits korrekt.
Das das Gerät mehr kann steht auf einem anderen Blatt. Persönlich würde ich zumindest eine Nachkommastelle gutheißen.

Das umzupatchen auf bspw. 0.0 - 3680.0 bringt m.E. nichts wenn nicht auch zusätzlich der entsprechende ProofAndSetValue-Aufruf angepasst wird.
Vorher...

Code: Alles auswählen

onblur=\"ProofAndSetValue(this.id, this.id, 0, [getUserDefinedMaxValue $devType $param], 1);

Nachher...

Code: Alles auswählen

onblur=\"ProofAndSetValue(this.id, this.id, '0.0', [getUserDefinedMaxValue $devType $param], 1);

[jp112sdl]

Wenn von eQ-3 vorgesehen ist das nur "ganze Watt" für die Entscheidungswerte zulässig sind dann sind die Limits korrekt.

Das wäre ja eine drastische Verschlechterung ggü. dem BidCos Leistungsmesser.
Der kann 2 Stellen dezimal, die werden auch übertragen und korrekt zurückgegeben,