Gelöst: HmIP-SMI - Firmware 3.2.48 - Problem?

[Paradox]

Krass. Danke für das Aufschlüsseln! Mein SMI55 muss ich auch wieder downgraden. Der ist auch vom gleichen Fehler betroffen!

[Xel66]

Bei der 1.4.8 gibt es die Datenpunkte
...
und mit der 3.2.48 die DP

Hmmmm... Nicht andersrum? Mein Screenshot der XML-API sieht anders aus. Firmwareversion siehe mein vorheriges Posting. Ist es irgendwie anders, fehlt da was. Dann sollte aber ein Drüberlernen helfen, die fehlenden Datenpunkte hervorzuzaubern. Das würde auch erklären, warum dann manche Anwender ein Problem haben.

(Und ja, ich weiß, dass niemand was mit iseIDs oder Geräteadressen anfangen könnte. Mache es trotzdem unkenntlich.)

Gruß Xel66

[Paradox]

Hallo xel66, ich benutze meine SMI ausschließlich in DVs. Weder für Scripte noch für sonstige Sachen. In den DVs frage ich aber die verschiedenen Helligkeiten ab um den BDT zu schalten bzw zu verlängern. Bei mir Wert 80 bzw 150 für die Verlängerung. Das ging seit dem Update nicht mehr. Ich hatte mich schon gewundert. Aber aufgrund von Arbeitsstress keiner weiterer Beachtung geschenkt. Nach dem Lesen hier ist es mir erst bewusst geworden. Evtl hast Du, xel66, Glück mit deinen SMI. Meine 9 Stück sind alle mit dem Update auf die Firmware 3.xx.xx ohne Helligkeitsangabe. Und eben auch die DVs gehen jetzt immer an. Und eben nicht mehr erst bei unter 80.

Edit: nach dem berühmten Ablernen und Anlernen geht der SMI55 wieder wie er soll. Auch Die Helligkeit wird übermittelt 🫣

[jp112sdl]

Hmmmm... Nicht andersrum?

Ich habe die Geräte nicht und kann daher nur den Inhalt der XMLs zusammentragen.

Wenn du die HMIPServer.jar nach .zip umbenennst und entpackst, findest du darin alle Geräte- und Kanalbeschreibungen.
Die Inhalte will ich hier (auch nicht auszugsweise) schreiben, wegen Lizenz und so.

In der aktuellen HMIPServer-Version sind CURRENT_ILLUMINATION und ILLUMINATION zumindest nur für den Subtyp "SLO", Gerätefirmware größer 3.x aufgeführt.

"alte" Firmware vom SMI55?

https://github.com/jp112sdl/HMDeviceFir ... 170929.tgz
https://github.com/jp112sdl/HMDeviceFir ... 220711.tgz

[Xel66]

Evtl hast Du, xel66, Glück mit deinen SMI.

An Glück glaube ich bei solchen technischen Vorgängen eher nicht. Ich halte meine Konstellation einfach für den eigentlich vom Hersteller beabsichtigten Zustand. Ich vermute, meine haben einfach den Reboot nach dem Update sauber gemacht und die ("neuen") Datenpunkte an die CCU gemeldet. Keine Ahnung, habe vorher nicht draufgeschaut und leider auch keinen Export davon.

Ich gehe davon aus, dass dieser Vorgang bei Anwendern mit den beschriebenen Problemen, dieser Vorgang nicht sauber abgelaufen ist (warum auch immer). Darum ja mein Tipp, ggf. mal drüberzulernen. Gerätereset (ohne WebUI!) und dann einfach noch mal den Anlernvorgang starten. Dann verschwinden die Geräte auch nicht aus den Programmen und Verknüpfungen. Im Posteingang ist auch dann nichts, weil die CCU die Geräte ja schon kennt. Aber diese haben die Chance, ihre Datenpunkte zu melden und die Geräteeinstellung von der CCU zu empfangen. Ggf. muss man die Programme oder Verknüpfungen nochmals auf die hoffentlich dazugekommenen Datenpunkte anpassen. Ist aber leider alles eben "hätte", "wäre", "wenn", da man hier nur Vermutungen anstellen kann, weil die Ausgangsbasis nicht bekannt ist.

Gruß Xel66

[Xel66]

Ich habe die Geräte nicht und kann daher nur den Inhalt der XMLs zusammentragen.

OK, die Gerätedefinitionen müssen ja auch auf der CCU sein. Hast Du da auf die Schnelle den Pfad? Muss gleich los zum Brötchen verdienen, kann aber später mal auf meine CCU schauen, wenn ich mit dem CUxD-Dateibrowser drankomme. Dann könnten wir mal schauen, was in meinen Definitionen steht. Danke. Bin noch auf der Oktoberversion der Raspberrymatic. Vielleicht liegt es da dran.

Gruß Xel66

[Paradox]

Ich war auf der Dezember RM und habe wieder auf die Oktober RM zurück gewechselt. Was aber auffällig ist, das fast alle BMW bei mir keine Helligkeit angeben. Ich habe noch 4 SPI und die sind auch bei 0 trotz Festbeleuchtung und gewackelt darunter ...

[jp112sdl]

OK, die Gerätedefinitionen müssen ja auch auf der CCU sein.

Sie sind nur innerhalb der HMIPServer.jar. Sie liegen nicht direkt im Dateisystem der CCU.

Aber kann man nicht auch per WebUI-Skript alle vom Schnittstellenprozess (HMIPServer) präsentierten Datenpunkte anzeigen lassen?
dom.GetObject(ID_DATAPOINTS).EnumUsedNames(); gibt ja "nur" die Datenpunkte aus, die die ReGa kennt.

Und da liegt möglicherweise auch die Diskrepanz nach so einem Geräte-Firmwareupdate.
Der Schnittstellenprozess gibt die zur (neuen) Geräte-Firmware gültigen Datenpunkte zurück.
Die ReGa hat in ihrem DOM noch den alten Stand (vom Zeitpunkt des Anlernens).

[Baxxy]

Lokalen Werksreset machen.
Das reicht häufig schon um Probleme nach Gerätefirmware-Updates zu beheben.

[Xel66]

Sie sind nur innerhalb der HMIPServer.jar. Sie liegen nicht direkt im Dateisystem der CCU.

War mir eigentlich sicher, dass ich vor grauen CCU2-Zeiten mal in irgendwelchen XML-Dateien rumgestiert habe. Wird wohl jetzt so sein. Liegt vielleicht auch daran, dass es damals noch kein HmIP gab.

Der Schnittstellenprozess gibt die zur (neuen) Geräte-Firmware gültigen Datenpunkte zurück.
Die ReGa hat in ihrem DOM noch den alten Stand (vom Zeitpunkt des Anlernens).

Klingt erst mal plausibel (Du steckst ja diesbezüglich auch tiefer in der Materie), aber meine BWM bedienen ja die vorhandenen Datenpunkte. Wären diese in der ReGa nicht vorhanden, könnten sie ja auch nicht durch die Geräte beschrieben werden. Irgendwo ist da ein Wurm. Sehe gerade, ich habe eine Uptime von größer 50 Tagen - also nach dem Update definitiv noch nicht neu gebootet. Würden die Geräte nach einem Reboot dann wieder nicht vorhandene Datenpunkte beschreiben, müsste es doch nach meinem Verständnis Fehlermeldungen im Log hageln. Strange...

Gruß Xel66