RaspberryMatic
RaspberryMatic copied to clipboard
jens-maus
[REGA] RSSI_PEER + RSSI_DEVICE werden nicht korrekt ausgelesen
Describe the bug Im Rahmen des iobroker.hm-rega Adapters werden zu Beginn alle Datenpunkte mittels Rega Skript ausgelesen.
Die Werte für RSSI_PEER und RSSI_DEVICE scheinen immer positiv zu sein und nicht in der Range wie für RSSI Werte üblich. Sehr häufig scheint 0 oder 1 geliefert zu werden, siehe auch https://github.com/ioBroker/ioBroker.hm-rpc/issues/273#issuecomment-683699425
Es scheint so als würde XML-RPC die Werte als dBm ausgeben, während man mit den Rega Werten noch eine Umwandlung vornehmen müsste? Bei mir werden häufig Werte um +180 geliefert
To Reproduce Steps to reproduce the behavior:
- Tab Programme -> Skript testen
- DPs ausgeben lassen mittels https://raw.githubusercontent.com/ioBroker/ioBroker.hm-rega/master/regascripts/datapoints.fn
Expected behavior RSSI values sollten dem tatsächlichen Wert entsprechen wie auch von XML-RPC geliefert
System information (please complete the following information):
- Version RaspberryMatic 3.51.6.20200621
- Hardware: Pi 3
Es scheint so als müssten von den Werten jeweils 256 abgezogen werden. In meinen Augen wäre es trotzallem schick, wenn die Rega direkt die 'korrekten' Werte liefern würde.
Quelle: https://forum.fhem.de/index.php?topic=106900.0
@foxriver76 Danke. Da müsste ich aber erst einmal rausfinden wo genau das passiert, denn eigentlich stellt die ReGa da meines Wissens keine eigenen Berechnungen an, sondern nimmt die werte die das xmlrpc ihr liefert bei abfrage des schnittstellenprozesses. Müsste man einmal genauer debuggen warum das an dieser stelle anscheinend falsch ist.
So, nun habe ich mir das ganze mal näher angeschaut und konnte das Problem in der Tat reproduzieren. Das folgende tcl Skript direkt ausgeführt auf der RaspberryMatic/CCU liefert auf ein HmIP Gerät...
#!/bin/tclsh
load tclrpc.so
load tclrega.so
set iurl "xmlrpc://127.0.0.1:32010"
set devaddress "000D5A4991XXXX"
# get via tclrpc
set rssi_device 65536
set rssi_peer 65536
catch { set rssi_device [xmlrpc $iurl getValue "$devaddress:0" "RSSI_DEVICE"] }
catch { set rssi_peer [xmlrpc $iurl getValue "$devaddress:0" "RSSI_PEER"] }
puts "tclrpc - RSSI_DEVICE:$rssi_device RSSI_PEER:$rssi_peer"
# get via tclrega
set cmd ""
append cmd "object o1=dom.GetObject('HmIP-RF.$devaddress:0.RSSI_DEVICE');"
append cmd "object o2=dom.GetObject('HmIP-RF.$devaddress:0.RSSI_PEER');"
append cmd "WriteLine('tclrega - RSSI_DEVICE:' # o1.Value() # ' RSSI_PEER:' # o2.Value());"
append cmd "WriteLine('tclrega converted - RSSI_DEVICE:' # (o1.Value() - 256) # ' RSSI_PEER:' # (o2.Value() - 256));"
array set result [rega_script "$cmd"]
puts "$result(STDOUT)"
folgende Ausgaben hier:
tclrpc - RSSI_DEVICE:-75 RSSI_PEER:65536
tclrega - RSSI_DEVICE:181 RSSI_PEER:0
tclrega converted - RSSI_DEVICE:-75 RSSI_PEER:-256
D.h. via rega skript liegen die Werte des RSSI_DEVICE/RSSI_PEER Datenpunktes in der Tat in einem falschen Bereich und die direkte xmlrpc abfrage über den HmIPServer liefern die richtigen werte (65536 bedeutet n/a). Und wie man auch im Skript und resultat sehen kann gibt es hier in der Tat einen Offset von 256. D.h. wenn man die Werte die man via rega skript erhält minus 256 nimmt passen die Werte (-256 bedeutet dann auch n/a).
Wieso, weshalb, warum bleibt natürlich als Frage bestehen und das müsste man sich dann noch einmal im ReGa gesondert anschauen was er mit den Werten so anstellt die er via xmlrpc selbst erhält vom rfd/HmIPServer und warum er die mit einem offset abspeichert und da obwohl das MIN des Wertes wohl korrekt auf -127 und das MAX auf +127 steht. Ich vermute daher in der Tat ein Fehler in ReGaHss. Eine weitere Frage wäre wie man das dann entsprechend korrigiert. Da der Fehler ja erst nicht seit gestern besteht haben sich ggf. externe Programme schon darauf eingerichtet damit umzugehen in dem sie -256 machen wie oben gezeigt. Wenn das also von ReGa plötzlich "richtig" ausgegeben würde, dann könnte es sehr wohl sein das das regressions auslöst.
Eine weitere Frage wäre wie man das dann entsprechend korrigiert. Da der Fehler ja erst nicht seit gestern besteht haben sich ggf. externe Programme schon darauf eingerichtet damit umzugehen in dem sie -256 machen wie oben gezeigt. Wenn das also von ReGa plötzlich "richtig" ausgegeben würde, dann könnte es sehr wohl sein das das regressions auslöst.
Guter Punkt. Trotzallem fände ich es schick, wenn das Problem direkt an der Wurzel gelöst wird, ansonsten kann ich es gerne auch auf ioBroker Seite konvertieren. Mir fehlt hier leider die Einsicht, wie in RM mit Breaking Changes umgegangen wird. Schon mal danke, dass du dir es angeschaut hast. ;-)
Möchte nur anmerken, dass aktuell immer noch im Zusammenhang mit den RSSI_DEVICE-Werten im ioBroker Warnungen ausgegeben werden, dass der Wert mit 128 größer als der Maximalwert von 127 sei.
Nicht sicher, ob es das selbe Problem ist, aber mit ist heute auch aufgefallen, dass die Werte in der WebUI und devconfig.cgi falsch sind.. aber nur für manche HM-Geräte. HmIP-Geräte sind soweit ich sehen kann alle sauber:
Das selbe in der WebUI:
Auch hier gilt: (Anzeigewert * -1) -256 führt zu einem plausibel aussehenden Wert (im Kasten daneben jeweils dargestellt). Hier schreibt jemand (2019), dass es ein Problem zwischen signed und unsigned integern ist, ggf hilft das weiter?: https://de.elv.com/forum/feldstaerkeanzeige-in-webui-falsch-14247
Ob die falschen Werte nun vom Aktor kommen oder irgendwo zwischendurch entstehen ist mir vollkommen unklar. An irgendeiner Stelle sollten sie aber korrigiert werden.
Möchte nur anmerken, dass aktuell immer noch im Zusammenhang mit den RSSI_DEVICE-Werten im ioBroker Warnungen ausgegeben werden, dass der Wert mit 128 größer als der Maximalwert von 127 sei.
Das müssten Werte sein die über XML-RPC kommen sein und liegen meines Wissens nach nicht in Jens Aufgabenbereich. Im ioBroker Rega Adapter hatte ich ab 3.0.23 einen Workaround eingebaut.
Und noch eine Kuriosität zu den RSSI Werten ist mir aufgefallen, diesmal für einen HmIP FCI6:
In der Geräteübersicht alles i.O.
In dem Protokoll stehen wieder unsinnige 2xx Werte:
Es scheint, dass das Thema mit den RSSI Werten an diversen Stellen (oder irgendwo sehr zentral) nicht ganz sauber ist..
Inzwischen hat sich bzgl. dieses Problems hier etwas getan. Siehe ein ähnliches Ticket hier: https://github.com/jens-maus/RaspberryMatic/issues/2008 bzw. hier (https://github.com/jens-maus/RaspberryMatic/issues/2008#issuecomment-1371907488) bzgl. des Gründe für Unterschiede bzgl. RSSI_DEVICE/PEER Werten die via ReGa abgeholt werden und RSSI_DEVICE/PEER Werten die via XMLRPC andere Werte (die richtigen) zeigen.
@foxriver76
Das müssten Werte sein die über XML-RPC kommen sein und liegen meines Wissens nach nicht in Jens Aufgabenbereich. Im ioBroker Rega Adapter hatte ich ab 3.0.23 einen Workaround eingebaut.
Diesen Workaround (https://github.com/ioBroker/ioBroker.hm-rega/blob/master/main.js#L1461-L1464) könnte man nun IMHO entfernen bzw. müsste aber stattdessen wohl eine Überprüfung des zugrundeliegenden Datentypes (ReGa ValueType()) vornehmen. D.h. ob RSSI_DEVICE/PEER innerhalb von ReGa ein BYTE oder INTEGER typ ist um abhängig davon dann die Subtraktion doch weiterhin vorzunehmen weil der Fix erst mit der nächsten RaspberryMatic Version kommen wird).
Da das Problem in der ReGaHss nun prinzipiell beseitigt sein sollte die mit der nächsten RaspberryMatic rauskommen wird, mache ich hier mal zu. Nun liegt es an @foxriver76 für ioBroker.hm-rega die entsprechenden Anpassungen zu machen um je nach verwendetem Datentyp der RSSI_DEVICE/PEER Datenpunkte entweder (für alte system) noch dieser -256 subtraktion zu machen oder eben für neuere Systeme dies zu unterlassen weil dort die ReGa die richtigen Werte zwischen -127 und +127 zurückgibt.
Diesen Workaround (https://github.com/ioBroker/ioBroker.hm-rega/blob/master/main.js#L1461-L1464) könnte man nun IMHO entfernen bzw. müsste aber stattdessen wohl eine Überprüfung des zugrundeliegenden Datentypes (ReGa
ValueType()) vornehmen. D.h. ob RSSI_DEVICE/PEER innerhalb von ReGa ein BYTE oder INTEGER typ ist um abhängig davon dann die Subtraktion doch weiterhin vorzunehmen weil der Fix erst mit der nächsten RaspberryMatic Version kommen wird).
Danke für das Update. Baue ich bei Gelegenheit ein. https://github.com/ioBroker/ioBroker.hm-rega/issues/352