Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 9063
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 378 Mal
Danksagung erhalten: 1467 Mal
Kontaktdaten:

Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von jmaus » 12.01.2023, 20:49

Hallo Zusammen,

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
Wie man daran sehen kann scheint das ganze leider doch nicht ein singuläres Ereignis gewesen zu sein und es wohl gewisse Geräte in meiner produktiven Umgebung zu geben die laut der ParamDescription über mehr Parameter verfügen als das was der HMIPServer aktuell dazu in den *.dev Dateien abgespeichert hat und somit als veränderbar vorhält.

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"
}
Wer also interesse hat kann diesen tclsh skript einfach mal als /tmp/check.tcl auf der jeweiligen Zentrale abspeichern und dort dann via "chmod a+x /tmp/check.tcl" ausführbare Rechte geben und dann einmal auf seine Umgebung loslassen um zu schauen ob sein HmIP-Gerätepark ähnliche Dinge aufweist oder nicht. Denn wenn dies generell eine größere Verbreitung hätte, dann könnte man z.B. darüber nachdenken in einer zukünftigen RaspberryMatic Version über diesen Umstand ggf. zu warnen und als Aktion einen manuellen Werksreset vorzuschlagen.

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.
RaspberryMatic 3.67.10.20230114 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

ptweety
Beiträge: 467
Registriert: 07.01.2017, 16:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 41 Mal
Danksagung erhalten: 53 Mal

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von ptweety » 12.01.2023, 21:27

Hm, ich habe hier ne relativ alte Firmware (3.63.9.20220625) drauf und auch einige Geräteupdates ausstehen. Vielleicht also nicht der ideale Test. Aber bei mir spuckt das Skript nur die erwartete 1. Zeile aus.

Code: Alles auswählen

$ ./check.py   
listDevices

Code: Alles auswählen

Gerät	Seriennummer	Aktuell	Neu
HMIP-eTRV	xxx	2.2.8	2.2.10
HmIP-SMI	xxx	1.4.8	3.2.48
HmIP-WTH-2	xxx	2.6.0	2.8.2

jp112sdl
Beiträge: 11369
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 771 Mal
Danksagung erhalten: 1884 Mal
Kontaktdaten:

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von jp112sdl » 12.01.2023, 22:00

jmaus hat geschrieben:
12.01.2023, 20:49
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.
Solche Inkonsistenzen gibt es nicht nur dort.
Das hatten wir auch schon mit den Geräte-Meta-Informationen zwischen ReGaDom und Interface
viewtopic.php?f=65&t=77314&p=750234#p750328

Und so ist es halt auch hier bei getParamset und getParamsetDescription.
Das erste holt die Infos aus dem Gerät (bzw. der "Geräte-Dev-datei"), die zum Zeitpunkt des Anlernens verfügbar waren und das zweite aus der aktuellen XML.
Ergo: Man (eQ-3) muss halt auch die Geräte-.dev updaten, wenn mit einer neuen HMIPServer-Version nun auch neue Geräte-Firmware-Features unterstützt werden.

Ist das hier nicht da uralte Thema, dass HmIP-Geräte nach einem Update neu angelernt werden müssen / sollten, was eigentlich gefixt sein sollte?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
jmaus
Beiträge: 9063
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 378 Mal
Danksagung erhalten: 1467 Mal
Kontaktdaten:

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von jmaus » 12.01.2023, 22:07

jp112sdl hat geschrieben:
12.01.2023, 22:00
Ist das hier nicht da uralte Thema, dass HmIP-Geräte nach einem Update neu angelernt werden müssen / sollten, was eigentlich gefixt sein sollte?
Nein das ist/war was anderes. Da gab es den Mechanismus gar nicht das nach einem Firmware-Update eine Re-inclusions gemacht wird. Hier liegt ja eine manuell hervorgerufene Inkonsistent vor. Einfach weil eQ3 fälschlicherweise die Firmware schon freigegeben hat und die min Version der CCU Firmware falsch angegeben hatte und deshalb Leute wie ich das Firmware-Update machen konnten und bei der Re-Inclusion danach dann eben der HMIPServer nichts von dem neuen Parameter wusste. Und prinzipiell haben Leute die eben fabrikneue Geräte bei ELV kaufen und die dann neuere Versionen aufweisen und man die dann in eine alte CCU Version anlernen das selbe Problem. Nur erhalten die dann aber die Aufforderung zum downgrade damit alles wieder zueinander passt.
RaspberryMatic 3.67.10.20230114 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

jp112sdl
Beiträge: 11369
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 771 Mal
Danksagung erhalten: 1884 Mal
Kontaktdaten:

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von jp112sdl » 12.01.2023, 22:16

jmaus hat geschrieben:
12.01.2023, 22:07
Einfach weil eQ3 fälschlicherweise die Firmware schon freigegeben hat und die min Version der CCU Firmware falsch angegeben hatte und deshalb Leute wie ich das Firmware-Update machen konnten und bei der Re-Inclusion danach dann eben der HMIPServer nichts von dem neuen Parameter wusste.
Ja, soweit verstanden. Das Gerät ist "neuer" und könnte mehr Parameter verarbeiten, als der aktuelle HMIPServer.

Nun kommt irgendwann der HMIPServer, der nun auch alle Parameter des neuen Gerätes bedienen kann.
=> Das muss erkannt werden und die lokale .dev angepasst werden.
Die Firmware auf dem Gerät ist ja schon die neuere. In der .dev steckt noch das Paramset der alten Firmware

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
jmaus
Beiträge: 9063
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 378 Mal
Danksagung erhalten: 1467 Mal
Kontaktdaten:

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von jmaus » 12.01.2023, 22:24

jp112sdl hat geschrieben:
12.01.2023, 22:16
Ja, soweit verstanden. Das Gerät ist "neuer" und könnte mehr Parameter verarbeiten, als der aktuelle HMIPServer.

Nun kommt irgendwann der HMIPServer, der nun auch alle Parameter des neuen Gerätes bedienen kann.
=> Das muss erkannt werden und die lokale .dev angepasst werden.
Die Firmware auf dem Gerät ist ja schon die neuere. In der .dev steckt noch das Paramset der alten Firmware
Genau so ist es. Und dafür gibt es momentan anscheinend keine Methodik innerhalb des HMIPServer. Die einzige Möglichkeit ist wohl einen Hardware Werksreset zu initiieren und dann passt der HMIPServer sein *.dev file, etc. an. Softwaretechnisch geht das anscheinend momentan zumindest noch nicht.
RaspberryMatic 3.67.10.20230114 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

Benutzeravatar
Baxxy
Beiträge: 7863
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 454 Mal
Danksagung erhalten: 1500 Mal

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von Baxxy » 12.01.2023, 22:52

Bei meinen ganzen Systemen ist alles konsistent.

Wenn eQ-3 die "CCUxFirmwareVersionMin" korrekt angibt ist man da ja schon mal aus dem Schneider.

Und wenn man neu hinzugefügte Geräte mit neuerer Firmware auf die "als Update" angebotene Firmware downgraded dann passt doch auch alles.
(das hattest du ja auch immer empfohlen)

Interessant ja, aber nicht weiter kritisch wie ich finde.

Zumindest kannst du bei deinen SWDO's nun die Batterielaufzeit verlängern indem du "SAMPLE_INTERVAL" erhöhst.
Glaube dieses Feature hatte ich irgendwann im letzten Herbst schon bei meinen SWDO's entdeckt. :wink:

scorpionking
Beiträge: 937
Registriert: 14.02.2016, 12:32
System: Alternative CCU (auf Basis OCCU)
Wohnort: Heidenheim
Hat sich bedankt: 49 Mal
Danksagung erhalten: 166 Mal

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von scorpionking » 13.01.2023, 07:35

Bei mir auch keine Inskonsistenzen bei meinen paar HmIP-Geräten, obwohl ich auch zu den Early Adoptern gehöre, die den "Ich muss alles was angeboten wird installieren"-Zwang haben... :mrgreen:

Fände es aber gut wenn man bei eventuellen Problemen in der WebUI benachrichtigt würde, sofern sich das nicht automatisch reparieren lässt.

Gerti
Beiträge: 2622
Registriert: 28.01.2016, 18:06
System: CCU
Wohnort: Hürth
Hat sich bedankt: 16 Mal
Danksagung erhalten: 202 Mal

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von Gerti » 13.01.2023, 07:48

Hi,

ist ja eigentlich nichts neues und eher unkritisch.
Hatte ich vor längerer Zeit auch schon einmal geschrieben, dass ein lokaler Gerätereset reicht um ggf. fehlende Parameter sichtbar zu machen.
Ich hatte das bei mir mit dem Combined Parameter festgestellt, bei dem es genauso war.

Gruß
Gerti

Benutzeravatar
jmaus
Beiträge: 9063
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 378 Mal
Danksagung erhalten: 1467 Mal
Kontaktdaten:

Re: Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

Beitrag von jmaus » 13.01.2023, 08:09

Gerti hat geschrieben:
13.01.2023, 07:48
ist ja eigentlich nichts neues und eher unkritisch.
Naja, ganz so entspannt sehe ich das ehrlich gesagt nicht. Wenn der Nutzer nichts davon mitbekommt kann er auch nicht agieren und diesen Werkreset duchführen (wie selbst bei mir passiert). Dann tauchen einfach gewisse WebUI Einstell-/Konfigurationsmöglichkeiten nicht auf und man wundert sich dann schon warum das so ist. Und das mögen Du und ich und die aufmerksamen Leser dieses Forum vielleicht ja noch hinbekommen das selbst irgendwie rauszufinden, aber Otto-Normal-Nutzer bekommt da niemals was von mit und wundert sich dann schon. Deshalb wäre es IMHO das mindeste das darüber eine Information an den Nutzer geht wenn solch eine Inkonsistenz gefunden/identifiziert wird, sodass der Nutzer dann diesen Werksreset entsprechend durchführen kann. Besser noch wäre es der HMIPServer stellt selbst diese Inkonsistenz fest (was er theoretisch könnte) und initiiert dann selbstständig das frische Einlesen der aktuellen Geräteparameter genauso wie das bei einem manuellen Werksreset am Schluss ja offensichtlich passiert. Da letzteres aber nur eQ3 umsetzen kann, werde ich zumindest für RaspberryMatic für eine der nächsten Versionen wohl mal einen solchen Prüfskript direkt im System umsetzen das ggf. 1x die Woche (oder nach einem Neustart) nach solchen Inkonsistenzen ausschau hält und dann ggf. den Nutzer via Alarmmeldung darüber informiert das ein Gerät mal einen manuellen Werksreset bräuchte um sich frisch abzugleichen. So zumindest aktuell der Plan.
RaspberryMatic 3.67.10.20230114 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

Antworten

Zurück zu „RaspberryMatic“