angetrieben von der Geräteparameterproblematik mit einem HmIP-FSM16 mit Firmware 1.22.8 (siehe viewtopic.php?p=752397#p752397) hab ich mich mal hingesetzt und ein kleinen Analyseskript dazu geschrieben den ich hier mal (und die entsprechende Analysemethode) zur Diskussion stellen möchte.
Um was geht es hier nun genau?! Nun, es geht darum, das mir aufgefallen war, das ein HmIP-FSM16 zwar mit Firmware 1.22.8 es eigentlich zulassen sollte zwischen Verbrauchsmodus und Einspeisemodus in der WebUI in Kanal 5 wechseln zu können. Das war aber in meiner produktiven Umgebung trotz Firmware 1.22.8 bei den FSM16 die ich angelernt hatte nicht der Fall. Einen frischen FSM16 hatte ich noch in der Schublade liegen, dieser hatte Firmware 1.16.x und als ich den an eine frische 3.67.x RaspberryMatic angelernt hatte und dann ein Firmwareupdate auf die 1.22.8 vorgenommen hatte zeigte dieser jedoch auf dem Testsystem zu meiner überraschung die entsprechenden WebUI Elemente um zwischen Verbrauchs- und Einspeisemodus zu wechseln. Offensichtlich war dort also alles i.O. Nach etwas Analyse des ganzen war mir dann aufgefallen, das die WebUI für die Auswahl welche UI Elemente eingeblendet/ausgeblendet werden sollen an der Stelle die Rückgaben der "getParamset()" XML-RPC Methode nutzt und wenn dort der besagte Parameter (CHANNEL_OPERATION_MODE) nicht existiert werden die UI Elemente kurzerhand dafür nicht dargestellt und sind insofern nicht für eine Änderung zur Verfügung. Dies konnte ich bei den FSM16 auch entsprechend mit eigenen xmlrpc getParamset() Abfrage reproduzieren. Interessanterweise zeigte sich dann jedoch das in den getParamsetDescription() XMLRPC-Abfragen des gleichen Gerätes+Kanal dieser Parameter mit seinen entsprechenden Metadaten auftaucht. Da kam mir die Idee das hier wohl eine irgendwie geartete Inkonsistenz zwischen dem was der HmIPServer in seinen /etc/config/crRFD/data/*.dev files als aktuell genutzte Gerätebeschreibung ablegt und dem was die Firmware des Gerätes wirklich beherrscht vorliegen muss.
Nach weiteren eigenen (teilweise auch mit eQ3 Hilfe) Analysen zeigte sich dann, das dies wohl in der Tat der Fall zu sein scheint und im Falle des FSM16 wohl so passiert ist weil eQ3 die 1.22.8 Firmware freigegeben hatte mit einer falschen CCU minVersion Angabe, sodass Nutzer wie ich die sehr früh die 1.22.8 FW der FSM16 einspielen lassen hatten leider dieser Geräteparameter dem HMIPServer noch nicht bekannt war und dies nun erst mit der 3.67.10 Version wohl überhaupt der Fall ist. Das hatte dann eben zur Folge das man zwar die 1.22.8 Firmware des FSM16 installiert hatte, aber der HMIPServer von dem neuen Parameter gar nichts mitbekommen konnte, eben weil die interne Gerätebeschreibung nicht passte. Das selbe passiert dann sicherlich auch Leuten die hier regelmäßig auftauchen mit neueren Gerätefirmwareversionen als das was für die CCU Firmware vorgeschrieben wird und denen dann eben ein downgrade vorgeschlagen wird.
Lange Rede, kurzer Sinn: Es scheint wohl so zu sein das es mitunter zu Inkonsistenzen in den aktuell genutzen Gerätebeschreibungen des HMIPServer vs. den eigentlich von der jeweiligen Gerätefirmware unterstützten Parametern kommen kann. Normalerweise löst sich sowas natürlich dann mit einem Ablernen+Werksreset samt frischen Anlernen. Da man da aber auch alle Direktverbindungen und bisherigen Geräteeinstellungen verlieren würde ist das natürlich nicht das optimale Mittel. Glücklicherweise lässt sich das Problem jedoch auch durch einen direkten Werksreset am Gerät selbst erledigen. D.h. man kann im angelernten Zustand einfach einen Hardware-Werksreset durchführen und dann wird nach dem finalen Neustart des Gerätes dann eine Re-inclusion angetriggert die zur Folge hat das die Zentrale das Gerät als bereits angelernt erkennt und dann quasi nur der HMIPServer die Geräteparameter frisch abgleicht als wenn man das Gerät komplett frisch anlernen würde. Im Anschluss sendet er dann die momentanen Gerätesettings (inkl. DVs) gleich mit an das Gerät und alles ist wieder gut. Bei meinen beiden FSM16 die eben bisher diesen CHANNEL_OPERATION_MODE trotz Firmware 1.22.8 nicht zeigten hat das dann auch sofort (bei Nutzung der CCU/RaspberryMatic 3.67.10 Version) zum Erfolg geführt und so kann ich dort nun den Verbrauchsmodus entsprechend wechseln.
Nun bin ich aber eben getrieben von dieser Erkenntnis der Frage einmal nachgegangen, ob das vielleicht nicht nur ein Einzelfall bzw. ein singuläres Ereignis war, sondern ob das vielleicht einfach eine gewisse Schwachstelle in der Art+Weise des Anlernprozesses bzw. Firmware-Update vorganges des HMIPServer bzw. von eQ3 ist. Ich hab mir daher eben einmal ein kurzes tclsh Skript geschrieben das sich für alle meine HmIP Geräte jeweils via getParamsetDescription() eine Liste der Parameter holt und dann damit vergleicht was getParamset() entsprechend zurückgibt. Und wenn es dort irgendwelche Inkonsistenzen gibt (d.h. ein Parameter zwar in der Description zu finden ist aber nicht im gespeicherten Paramset des HMIPServer) er dann diesen Parameter samt GeräteID und Typ einmal ausgibt. Und siehe da, das wurde ausgespuckt:
Code: Alles auswählen
000C17099XXXXX:0|HmIP-SPI = DISABLE_MSG_TO_AC
00095569AXXXXX:0|HmIP-SMO = DISABLE_MSG_TO_AC
001CDA498XXXXX:5|HmIPW-WTH = CLIMATE_FUNCTION
001CDA498XXXXX:5|HmIPW-WTH = HUMIDITY_LIMIT_VALUE
001CDA498XXXXX:5|HmIPW-WTH = TWO_POINT_HYSTERESIS_HUMIDITY
001CDA498XXXXX:5|HmIPW-WTH = CLIMATE_FUNCTION
001CDA498XXXXX:5|HmIPW-WTH = HUMIDITY_LIMIT_VALUE
001CDA498XXXXX:5|HmIPW-WTH = TWO_POINT_HYSTERESIS_HUMIDITY
0000D3C98XXXXX:0|HMIP-SWDO = DISABLE_MSG_TO_AC
0000D3C98XXXXX:1|HMIP-SWDO = SAMPLE_INTERVAL
001CDA498XXXXX:5|HmIPW-WTH = CLIMATE_FUNCTION
001CDA498XXXXX:5|HmIPW-WTH = HUMIDITY_LIMIT_VALUE
001CDA498XXXXX:5|HmIPW-WTH = TWO_POINT_HYSTERESIS_HUMIDITY
000C17099XXXXX:0|HmIP-SPI = DISABLE_MSG_TO_AC
Und für das oberste Gerät (den HmIP-SPI) hab ich dann auch das gleiche unmittelbar versucht wie mit den FSM16. D.h. ein direkter Hardware-Werkreset im angelernen Modus durchgeführt und schon tauchte der fehlende "DISABLE_MSG_TO_AC" Parameter danach in der frischen getParamset() Ausgabe auf und dieser ist auch in der passenden *.dev Datei dann zu finden.
Es stellt sich also in der Tat nun für mich die Frage, wie weit verbreitet diese Inkonsistenz gerade bei den Personen ist die einen recht großen/breiten Park an HmIP Geräten haben und die Zentrale auch schon über mehrere Jahre mit aktuellsten Firmware-Updates pflegen die dann eben mitunter neuere Parameter mit sich bringen.
Deshalb würde ich hier einmal meinen tclsh-Skript den ich für diese Testzwecke verfeinert habe zur Verfügung stellen, sodass jeder damit gerne experimentieren kann und dann ggf. entsprechend Feedback geben kann ob bei ihm auch Geräte gefunden werden die offensichtlich nicht komplett mit allen zur Verfügung stehenden Parametern aktuell ausgestattet sind und einen Werksreset benötigen würden.
Code: Alles auswählen
#!/bin/tclsh
load tclrpc.so
set url "http://127.0.0.1:2010/"
set devicesFound [catch {set devices [xmlrpc $url listDevices]}]
if {$devicesFound == 0} {
# iterate over all devices returned by listDevices
foreach _device $devices {
array set device $_device
set address $device(ADDRESS)
set paramsets $device(PARAMSETS)
if {[string first MASTER $paramsets] != -1 } {
array unset paramsetDesc
set paramsetDescFound [catch {array set paramsetDesc [xmlrpc $url getParamsetDescription [list string $address] [list string "MASTER"]]}]
if {$paramsetDescFound == 0 && [array size paramsetDesc] > 0} {
array unset paramset
set paramsetFound [catch {array set paramset [xmlrpc $url getParamset [list string $address] [list string "MASTER"]]}]
if {$paramsetFound == 0} {
# iterate over all paramsetDesc
foreach desc [array names paramsetDesc] {
# and search in paramset if it is present
if {[info exists paramset($desc)] == 0} {
puts "$address|$device(PARENT_TYPE) = $desc"
}
}
}
}
}
}
} else {
puts "ERROR: no devices found"
}
Und übrigens habe ich das ganze auch mal auf die BidCos-Welt meiner produktiven Umgebung losgelassen und dort konnte ich mit diesem einfachen getParamsetDescription() vs. getParamset() Vergleich keine Inkonsistenzen finden. Da scheint also alles zu passen.
Über entsprechendes Feedback würde ich mich natürlich wie immer freuen.