angestoßen von der noch offenen Problematik das der Maintenance TIME_OF_OPERATION Datenpunkt bei einem HmIP-SWSD in der WebUI keine korrekten Werte anzeigt (siehe https://github.com/jens-maus/RaspberryMatic/issues/2008 bzw. viewtopic.php?f=65&t=76124) jedoch via XMLRPC die richtigen Werte ausspuckt, hab ich mir die ganze Problematik nun etwas näher angeschaut und vor ein paar Tagen bin ich schon drauf gestoßen das es in der ReGaHss bei gewissen Datentypen gerade bei Maintenance Kanälen anscheinend Inkonsistenzen gibt.
Als Beispiel kann man da in der Tat den TIME_OF_OPERATION Datenpunkt her nehmen. Dieser ist laut Gerätedoku bzw. XMLRPC getParamsetDescription() Ausgabe wie folgt definiert:
Code: Alles auswählen
... 'TIME_OF_OPERATION': {'MIN': 0, 'OPERATIONS': 5, 'MAX': 1415491200, 'FLAGS': 1, 'ID': 'TIME_OF_OPERATION', 'TYPE': 'INTEGER', 'DEFAULT': 0}, ...
Code: Alles auswählen
<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>
Code: Alles auswählen
<valtype>8</valtype>
<subtype>24</subtype>
Warum ReGa das falsch macht, daran bin ich gerade dran und habe auch eine Lösung parat. Aber es interessiert mich natürlich trotzdem wie lange das Problem der falschen Datentypzuordnung in ReGa schon existiert und wie verbreitet das gerade in großen produktiven Umgebungen so ist. Und daher hab ich mal ein kleines ReGa-Skript gebaut das versucht diese Inkonsistenzen ausfindig zu machen und auszugeben und es wäre schön wenn das vielleicht der Eine oder Andere mit einer großen Installation auf seine Umgebung mal loslassen könnte um rauszufinden über welche Geräte- und Kanäle das Problem ggf. verbreitet ist.
Dazu hier nun einmal dieses Skript:
Code: Alles auswählen
integer i=0;
WriteLine("Searching for invalid datatyped object values:")
while(true) {
object obj = dom.GetObject(i);
if((obj)) {
if(obj.MetaData('MAX')) {
var mmin;
var mmax;
if(obj.ValueType() == 16) { ! Integer
mmin = -2147483647;
mmax = 2147483647;
if((obj.MetaData('MIN').ToInteger() < mmin) || (obj.MetaData('MAX').ToInteger() > mmax)) {
WriteLine(obj.ID() # " - " # obj.Name() # " - MIN:" # obj.MetaData('MIN') # " MAX:" # obj.MetaData('MAX') # " <> " # obj.Value() # " (INTEGER/" # obj.ValueSubType() # ")");
}
} elseif((obj.ValueType() == 4) || (obj.ValueType() == 6)) { ! Float
mmin = "-1.79769e+308".ToFloat();
mmax = "1.79769e+308".ToFloat();
if((obj.MetaData('MIN').ToFloat() < mmin) || (obj.MetaData('MAX').ToFloat() > mmax)) {
WriteLine(obj.ID() # " - " # obj.Name() # " - MIN: " # obj.MetaData('MIN') # " MAX:" # obj.MetaData('MAX') # " <> (FLOAT/" # obj.ValueSubType() # "): " # obj.Value());
}
} elseif(obj.ValueType() == 2) { ! bool
if((obj.MetaData('MIN') != 'false') || (obj.MetaData('MAX') != 'true')) {
WriteLine(obj.ID() # " - " # obj.Name() # " - MIN:" # obj.MetaData('MIN') # " MAX:" # obj.MetaData('MAX') # " <> (BOOL/" # obj.ValueSubType() # "): " # obj.Value());
}
} elseif(obj.ValueType() == 8) { ! byte
if(obj.ValueSubType() == 24) {
mmin = 0;
mmax = 255;
} else {
mmin = -128;
mmax = 128;
}
if((obj.MetaData('MIN').ToInteger() < mmin) || (obj.MetaData('MAX').ToInteger() > mmax)) {
WriteLine(obj.ID() # " - " # obj.Name() # " - MIN:" # obj.MetaData('MIN') # " MAX:" # obj.MetaData('MAX') # " <> (BYTE/" # obj.ValueSubType() # "): " # obj.Value());
}
} elseif(obj.ValueType() != 20) { ! !string
WriteLine("UNKNOWN: " # obj.Name() # " = " # obj.ValueType());
}
}
}
i=i+1;
}
WriteLine("DONE");
Code: Alles auswählen
Searching for invalid datatyped object values:
2667 - BidCos-RF.MEQ0186XXX:0.RSSI_DEVICE - MIN:-2147483648 MAX:2147483647 <> (BYTE/24): 1
2668 - BidCos-RF.MEQ0186XXX:0.RSSI_PEER - MIN:-2147483648 MAX:2147483647 <> (BYTE/24): 1
2825 - HmIP-RF.001098A9963XXX:0.RSSI_DEVICE - MIN:-128 MAX:127 <> (BYTE/24): 0
2826 - HmIP-RF.001098A9963XXX:0.RSSI_PEER - MIN:-128 MAX:127 <> (BYTE/24): 0
2942 - HmIP-RF.000A5F29920XXX:0.RSSI_DEVICE - MIN:-128 MAX:127 <> (BYTE/24): 195
2943 - HmIP-RF.000A5F29920XXX:0.RSSI_PEER - MIN:-128 MAX:127 <> (BYTE/24): 0
2944 - HmIP-RF.000A5F29920XXX:0.TIME_OF_OPERATION - MIN:0 MAX:1415491200 <> (BYTE/24): 0
2977 - HmIP-RF.000A18A9A81XXX:0.RSSI_DEVICE - MIN:-128 MAX:127 <> (BYTE/24): 196
2978 - HmIP-RF.000A18A9A81XXX:0.RSSI_PEER - MIN:-128 MAX:127 <> (BYTE/24): 0
DONE
Lange Rede, kurzer Sinn: Wäre schön einmal ein paar weitere Ausgaben zu sehen um einzuschätzen wie weit diese Inkonsistenzen verbreitet sind und welche davon eine Korrektur benötigen und welche nicht. Beim TIME_OF_OPERATION Datenpunkt ist dies zumindest ganz einfach indem man den ValueType() auf Integer setzt und schon passt der Wert in der WebUI dann. Allerdings gehört das natürlich am Ursprung (d.h. in ReGaHss) repariert und jetzt nicht gar via eines Skriptes oder ähnliches und da bin ich ja wie gesagt dran das dann wieder konsistent zu machen. Aber ich möchte eben erst einmal sehen welche Datenpunkte da wirklich und in welcher Breite betroffen sind.
