fhem Fehler ab V2.03

[Andersmacher]

Hier meine Systeminfos aus dem Info-Reiter, Rest siehe Signatur:
Plattform linux
Betriebssystem linux
Architektur arm64
CPUs 4
Geschwindigkeit 1500 MHz
Modell Cortex-A72
RAM 7.63 GB
System-Betriebszeit 01:32:37
Node.js v18.19.0
time 1701552062375
timeOffset -60
NPM 10.2.3
Anzahl der Adapter 516
Datenträgergröße 6.76 GB
freier Festplattenspeicher 2.08 GB
Aktive Instanzen 25
Pfad /opt/iobroker/

Ich benutze eigentlich Homematic-Thermostate, jedoch an zwei Heizkörpern historisch bedingt noch eQ3-MAX!-Thermostate. Letztere steuere ich schon seit mehreren Jahren erfolgreich mit dem fhem-Adapter, über einen umgeflashten MaxCube (als 4fach CUL, betrieben als CUN) via ioBroker. Vor ein paar Tagen habe ich mehr oder weniger zufällig festgestellt, daß die beiden MAX!en vom ioBroker nur noch Zahlenwerte als Temperaturvorgaben akzeptieren. Das "Setzen der Modi" (auto, boost, eco, ...) ignorieren sie.

Aktuell läuft der fhem-Adapter V2.0.5. Gehe ich zurück auf V2.0.2 funktioniert das Setzen der Modi wieder.

Das Problem scheint der Datenpunkt "desiredTemperature" zu sein, über den man nach meinem bisherigen Wissen bei den MAX!en sowohl Temperaturen als Zahlenwerte, als auch die Modi vorgeben muß.

In V2.0.2 ist "desiredTemperature" noch als "Zeichenkette/String" definiert, in den höheren Versionen dann aber als "Zahl".

Da man eine Zahl wohl problemlos in einem String übergeben kann, aber keinen String "in einer Zahl", kann man in Versionen größer als V2.0.2 wohl den Modus der MAX!en nicht mehr einstellen.

Würde mich freuen, falls das jemand bestätigen kann, bevor ich da evtl. Pferde via github-issue scheu mache.
Muß auch erstmal rausfinden, wen ich ansprechen müßte oder wo genau ich das finde, denn wenn man auf den "Pfeil nach rechts" klickt:

landet man seltsamerweise weder bei fhem noch bei git, sondern auf seinem eigenen ioBroker-Host:

Das blicke ich noch nicht.

Edit:
Habe noch vergessen zu erwähnen, daß FHEM auf dem gleichen Raspi läuft, wie ioBroker.

[Andersmacher]

@andersmacher Noch ein Hinweis:
Der workaround, den Typ des Datenpunktes in der V2.0.3 und höher manuell wieder auf String zu setzen funktioniert zwar, aber leider nur temporär, da jedesmal wenn der Objektbaum neuerstellt wird, der Typ wieder auf Zahl zurückgesetzt wird.

[Andersmacher]

@andersmacher Hmm, ist meine Kombination (eq3-MAX!-Komponenten via fhem-Adapter in ioBroker einbinden) zu speziell oder meine Frage zu wirr formuliert? Ich wundere mich, daß ich da der einzige sein soll, dem das bisher aufgefallen ist bzw. der damit seit der fhem-Adapter-Version 2.0.2 Probleme hat.

[Thomas Braun]

@andersmacher sagte in fhem Fehler ab V2.03:

Ich wundere mich, daß ich da der einzige sein soll, dem das bisher aufgefallen ist

Gibt es kein Issue dazu? Dann bist du wohl der erste und einzige. Leg dann eins an.

[Andersmacher]

@thomas-braun Danke für Dein Rückmeldung!

Nee, habe kein Issue dazu gefunden. Werde dann eins anlegen. Wie ich anfangs ja auch geschrieben hatte, wollte ich vorher eben nur prüfen, ob das jemand bestätigen kann, weil meine Meldung dann vielleicht belastbarer/genauer wäre.

Edit: Issue ist angelegt
https://github.com/iobroker-community-adapters/ioBroker.fhem/issues/240

Andersmacher created this issue in iobroker-community-adapters/ioBroker.fhem

open eQ3-MAX!-Thermostate: Datenpunkt "desiredTemperature"; Datentyp Zahl nicht funktionabel #240