Falsche Anzeige "Betriebszeit" im Maintenance-Kanal von IP-Rauchmeldern (HmIP-SWSD)

[Baxxy13]

Describe the issue you are experiencing

Im Maintenance-Kanal von HmIP-SWSD's gibt es ein Feld für die "Betriebszeit".
Hier wird ind er WebUI der CCU/RaspberryMatic ein unrealistischer/falscher Wert angezeigt.

1. Liest man den Wert von TIME_OF_OPERATION mit einem üblichen Script-Einzeiler aus...
   WriteLine(dom.GetObject('HmIP-RF.000A5A4998xxxx:0.TIME_OF_OPERATION').Value());
   ... kommt da bei meinem SWSD (knapp 3 Jahre in Betrieb) aktuell 0 raus, gestern waren es noch 128. Das gleiche Verhalten bzw. diese Werte sind auch in der WebUI zu sehen.

2. Liest man den Wert über xmlrpc.GetParamset() vom MAINTENANCE (:0) Kanal aus bekommt man einen realisitischeren Wert zurückgeliefert:

string kanalname = "Rauchmeldername:0";
object oCh = channels.Get(kanalname);
object oInterface = dom.GetObject(oCh.Interface());
string sDevSerial = oCh.Address();
WriteLine(xmlrpc.GetParamset(oInterface, sDevSerial, "VALUES"));

Dies liefert zwischen den <i4>XXXX</i4> XML tags von TIME_OF_OPERATION dann sinnvolle bzw. von den Werten von (1.) abweichende Werte.

Describe the behavior you expected

Idealerweise würde die Betriebszeit korrekt angezeigt, am besten gleich in Tage umgerechnet.

Steps to reproduce the issue

1. SWSD bei eingeblendeten Maintenace-Kanälen unter > Status und Bedienung > Geräte anwählen
2. Feld "Betriebszeit" betrachten
3. Scripte zum Auslesen (ReGa / XMLRPC) testen
   ...

What is the version this bug report is based on?

3.65.11.20221005

Which base platform are you running?

rpi4 (RaspberryPi4)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

-

Additional information

Diskussion, Scripte und Screenshots zum Thema im Homematik-Forum >>hier

[jens-maus]

Danke! Bitte aber die Skripte hier mit reinstellen und nicht nur fremdverlinken.

[Baxxy13]

Script hinzugefügt.

[jens-maus]

Nach kurzer Analyse scheint es wohl so zu sein, das in der Kanaldescription dieses Gerätes für den TIME_OF_OPERATION Datenpunkt der falsche Datentyp (Byte) gewählt wurde und hier natürlich Int gesetzt sein müsste damit werte >128 möglich sind. Müsste man jetzt malnim HmIPServer nachschauen was da in der device description so hinterlegt ist.

Und wenn das so ist erklärt das warum dann in der ReGa bzw in der WebUI nur werte von 0 und 128 ankommen, denn der intern genutzte byte datentyp läuft da natürlich über! Wenn das so ist, ist das dann allerdings ein Bug im HmIPServer an dem nur eQ3 etwas drehen könnte.

Wenn also mal einer in der HmIPServer.jar nach der Kanaldescription schauen könnte würde sich das vmtl schnell klären lassen.

[jp112sdl]

Wenn also mal einer in der HmIPServer.jar nach der Kanaldescription schauen könnte würde sich das vmtl schnell klären lassen.

Kann man machen. Darf man nur nicht drüber reden. Reverse-Engineering ist aus meiner Sicht ein klarer Lizenzverstoß.
Ich erinnere nur an eq-3/occu#107
Das wurde ja dann auch unter der Hand abgetan.

[jens-maus]

Wenn also mal einer in der HmIPServer.jar nach der Kanaldescription schauen könnte würde sich das vmtl schnell klären lassen.

Kann man machen. Darf man nur nicht drüber reden. Reverse-Engineering ist aus meiner Sicht ein klarer Lizenzverstoß.

Ich darf! ;) Und das jar auspacken und die device datei raussuchen und anschauen ist kein reverse engineering, das ist wissenschaft ;)

[jp112sdl]

In den Geräte-XMLs steht nur weder Einheit noch Datenbreite. Das steht woanders.
Aber dazu müsste man den Decompiler ansetzen. Und daaaaa... hab ich keine Lust auf Abmahnanwälte.

[Elix-g]

Wenn das so heikel ist, bleibt doch lediglich, auf die öffentliche Dokumentation zurückzugreifen die den Datenpunkt klar als Integer ausweist. Aufgrund von Beobachtungen kann man vermuten, dass aber stattdessen der DP als Byte im HmIPServer deklariert wurde. Wenn ein Hersteller auf so etwas nicht anspringt und mit Lizenzgeplänkel anfängt...

[jp112sdl]

@jens-maus Hab dir mal ne E-Mail mit meinen Erkenntnissen geschickt.

[jens-maus]

So, nach neuesten Erkenntnissen ist das Problem doch nicht im HmIPServer gelegen, sondern es liegt wohl ein Problem in ReGaHss vor der beim Anlernen der Geräte nachdem er die Gerätebeschreibung via getParamsetDescription() holt wohl eine Datentypbestimmung vornimmt und hier beim TIME_OF_OPERATION Datentyp sich einfach den falschen Datentyp schnappt. Exemplarisch wird das Problem sichtbar durch einen Blick in den entsprechenden homematic.regadom Bereich der sich um den TIME_OF_OPERATION Datentyp dreht:

<dp>
<obj>
<id>2944</id>
<name>HmIP-RF.000A5F299XXXXX:0.TIME_OF_OPERATION</name>
<type>393281</type>
<enabled>1</enabled>
<accessrights>4294967295</accessrights>
<objflgs>1</objflgs>
<metadata>
<count>3</count>
<property>MAX</property>
<value>1415491200</value>
<property>MIN</property>
<value>0</value>
<property>TYPE</property>
<value>INTEGER</value>
</metadata>
</obj>
<dp-info></dp-info>
<chnid>2931</chnid>
<valtype>8</valtype>
<alvalev>1</alvalev>
<cachtmout>0</cachtmout>
<dvi>0</dvi>
<op>5</op>
<subtype>24</subtype>
<polltime>0</polltime>
<valdef>
<val>0</val>
<type>8</type>
</valdef>
</dp>

Hervorzuheben sind hier vor allem folgende auffällig Einträge für diesen Datentyp:

<valtype>8</valtype>
<subtype>24</subtype>

Hierbei entspricht ein valtype von 8 eben dem Byte Datentyp der Werte zwischen -128 und 128 annehmen kann und durch das setzen von subtype 24 wird dieser als unsigned datentyp ausgewiesen was wiederum dann einen Wert von 0 bis 256 zulassen sollte. Betrachtet man nun einmal die Metadaten der Datentypbeschreibung (MIN: 0, MAX: 1415491200) passt das natürlich überhaupt nicht rein und eigentlich sollte hier der valtype auf 16 (Integer) stehen damit dieser Datenpunkt auch die entsprechenden Werte annehmen kann.

Wenn man sich nun einmal anschaut was bei der getParamsetDescription() XMLRPC Methode generell zurückgegeben wird stimmt das was der HmIPServer für einen HmIP-SWSD prinzipiell zurückliefert:

... 'TIME_OF_OPERATION': {'MIN': 0, 'OPERATIONS': 5, 'MAX': 1415491200, 'FLAGS': 1, 'ID': 'TIME_OF_OPERATION', 'TYPE': 'INTEGER', 'DEFAULT': 0}, ...

D.h. hier wird korrekt der Type als INTEGER angegeben und auch die MIN/MAX Werte stimmen mit dem überein was in der regadom am schluss zu finden ist.

Ergo passiert hier wohl folgendes: Beim Anlernen eines Gerätes gibt es wohl eine Methode in ReGaHss die anhand der XMLRPC Beschreibung den jeweiligen Datenpunkt anlegt und dort dann für INTEGER Werte (bzw. wohl generell) keine Überprüfung der geforderten MIN/MAX Werte vornimmt und generell dann wohl (zumindest für den Maintenance Kanal) den internen Datentyp dieser Datenpunkte auf Byte statt Integer setzt. Das führt dann in der Konsequenz dazu, das bei entsprechende Abfragen innerhalb der ReGaHss ein Überlauf passiert weil eben TIME_OF_OPERATION größere Werte annehmen kann. Deshalb zeigt die WebUI dann folglich falsche Werte an, aber via XMLRPC Abfrage scheint alles i.O. zu sein.

Sucht man nun einmal in der regadom nach mehr solchen <subtype>24</subtype> Einträgen, fällt es auf das diese nur in Maintenance (:0) Kanälen auftauchen und dort vor allem für AES_KEY, RSSI_DEVICE, RSSI_PEER, ERROR_CODE, etc.. Und auch dort ergibt sich das selbe Bild. Auch dort passen die MIN/MAX Werte der Metadaten mitunter nicht mit dem gewählten Datentyp (<valtype>) überein. Das hat aber wohl bis jetzt keine Probleme verursacht bzw. zu Tage gefördert, weil diese Datenpunkte wohl trotz anderer MIN/MAX Werte nicht wirklich >256 bzw. >128 Werte annehmen oder man sich die ohnehin nicht in der WebUI anschaut oder via Skripting ausgeben lässt.

Zusammenfassend lässt sich also sagen, das hier wohl in der Tat ein Problem in ReGaHss vorliegt welche nun einerseits durch die Anpassung dieser Datenpunktgenerierung beim anlernen korrigiert werden muss, aber auch für bereits angelernte/existierende Datenpunkte wohl eine Plausibilitätsüberprüfung einmal eingebaut werden muss ob der gewählte Datentyp für einen Datenpunkt mit den in den Metadaten angegebenen MIN/MAX Werten übereinstimmt und ggf. den Datentyp dann anpasst.