Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Chris 1]

Moin

TS0610 / "_TZE204_g2ki0ejr"

ich doktore hier immer noch mit dem Thermostaten (new device, Aliexpress, ) herum, denn ausgerechnet auf "current_heating_setpoint" reagiert er nicht so wie gewünscht - er ignoriert es scheinbar einfach, nach wenigen Sekunden ist der Wert wieder auf dem an Thermostat eingestellten Wert.

Ist ein Experte unter Euch, der mir hier vielleicht ein paar hilfreiche Tips an die Hand geben könnte?

In "converter/fromZigbee.js" (ja, ist wohl Gegenrichtung) fand ich bei Zeile 7427 zumindest etwas, welches ein vergleichbares Problem umschreibt, wenn ich es recht verstanden habe.

Nochmal konkretiesieren:
Wenn ich den Datenpunkt in ioBroker ändere, wird er an <device>/current heating_setpoint raus geschickt und ich finde auch keine Fehlermeldung in den Logs (zigbee2mqtt), aber ratz fatz ist der Wert wieder durch jenen am Device überschrieben.

Nur zur Übersicht noch was bisher meine mehr aber auch minder erfolgreiche Ausbeite bei den Datenpunkten ist. Valve_Position ist definitiv falsch und auch bei battery* bin ich noch am herumsuchen.

Danke an die Experten für mögliche Tips
Gruss von der Ostsee
Chris

       // Chris Start
        fingerprint: tuya.fingerprint('TS0601', [
            '_TZE204_g2ki0ejr', /* model: 'WKF-LCD-W' / 'BAB-1413 Pro', vendor: 'Shenshen' */
            ]),
        model: 'TS0601_thermostat_WKF',
        vendor: 'TuYa',
        description: 'Thermostatic radiator valve',
        icon: '/icons/thermostat1.jpg',
        fromZigbee: [tuya.fzDataPoints],
        toZigbee: [tuya.tzDataPoints,
                                    tz.tuya_thermostat_current_heating_setpoint
                                   ],
        onEvent: tuya.onEventSetLocalTime,
        configure: tuya.configureMagicPacket,
        exposes: [
            e.child_lock(), e.battery_low(), e.battery(), e.voltage(),
            e.battery_voltage(),
            // e.valve_detection(),
            e.position(),
            // e.running_state(), is no function
            exposes.climate()
                .withSetpoint('current_heating_setpoint', 5, 35, 1, ea.STATE_SET)
                .withLocalTemperature(ea.STATE)
                .withSystemMode(['auto', 'heat', 'off'], ea.STATE_SET)
                .withRunningState(['idle', 'heat'], ea.STATE)
                .withLocalTemperatureCalibration(-3, 3, 1, ea.STATE_SET),
            exposes.binary('scale_protection', ea.STATE_SET, 'ON', 'OFF').withDescription('If the heat sink is not fully opened within ' +
                'two weeks or is not used for a long time, the valve will be blocked due to silting up and the heat sink will not be ' +
                'able to be used. To ensure normal use of the heat sink, the controller will automatically open the valve fully every ' +
                'two weeks. It will run for 30 seconds per time with the screen displaying "Ad", then return to its normal working state ' +
                'again.'),
            exposes.binary('frost_protection', ea.STATE_SET, 'ON', 'OFF').withDescription('When the room temperature is lower than ' +
                '5 °C, the valve opens; when the temperature rises to 8 °C, the valve closes.'),
            exposes.numeric('error', ea.STATE).withDescription('If NTC is damaged, "Er" will be on the TRV display.'),
        ],
        meta: {
            tuyaDatapoints: [
                 // [1, 'dp_01', tuya.valueConverter.raw],  // doesnt start
                [2, 'system_mode', tuya.valueConverterBasic.lookup({'auto': tuya.enum(0), 'heat': tuya.enum(1), 'off': tuya.enum(2)})],
                [3, 'running_state', tuya.valueConverterBasic.lookup({'heat': tuya.enum(0), 'idle': tuya.enum(1)})],
                [4, 'current_heating_setpoint', tuya.valueConverter.divideBy10],
                [5, 'local_temperature', tuya.valueConverter.divideBy10],
                [6, 'valve position', tuya.valueConverter.divideBy100], // TODO: check DP
                [7, 'child_lock', tuya.valueConverter.lockUnlock],
                // [8, 'dp_8', valueConverter.raw], // TEST
                // [9, 'dp_9', valueConverter.raw], // TEST
                // [10, 'dp_10', valueConverter.raw], // TEST
                // [11, 'dp_11', valueConverter.raw], // TEST
                // [35, 'dp_35', tuya.valueConverter.errorOrBatteryLow],
                [35, 'dp_35', tuya.valueConverter.raw],
                [36, 'frost_protection', tuya.valueConverter.onOff],
                [37, 'dp_37', tuya.valueConverter.raw], // datatype:1 , dp:37 TODO: Unknown DP
                [39, 'scale_protection', tuya.valueConverter.onOff],
                [47, 'local_temperature_calibration', tuya.valueConverter.localTempCalibration2],
                [49, 'dp_49', tuya.valueConverter.raw], // TODO: Unknown DP
            ],
        },
    },

[arteck]

um das zu lösen musst du zuerst verstehen wie die Wert im Zigbee abgelegt bzw. gesendet werden.. du kannst natürlich rumstochern und hoffen dass du den richtigen Register erwischt.. na ja viel spass dabei...

Der Wert wird wieder überschrieben weil der Thermostat diesen gesendeten Wert nicht verarbeiten kann und nicht bestätig, im zuge dessen sendet es dir den ihm zuletzt bekannten Wert

Thermostate sind kacke ..vor allem vom Tuya.. mach ein isse auf zigbee2mqtt auf
und lies dich hier ein
https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html

p.s: ich seh gerade der ist doch schon längst implementiert
https://github.com/Koenkk/zigbee-herdsman-converters/blob/f3d6d59a65e20bcf3f116c9d288bdbcb1f1f135b/src/devices/tuya.ts#L2578

installier mal die GIT version vom Adapter

[Chris 1]

@arteck Oh, gaaaaanz herzlichen Dank!

Ich sollte wohl häufiger die tuya.js von GitHub her aktuallisieren.

Probiere ich nachher gleich mal aus

Gruss von der Ostsee
Chris

[Chris 1]

Nunja.... die Device Detail Seite hat sich mächtig gefüllt, was allerdings nicht gleichbedeutend damit ist, dass sich darüber die Werte auch verändern liessen.
Es ist nur voller
Chris

[Chris 1]

@arteck
ok, also ich konnte mitlerweile feststellen, dass Setpoint über den Slider funktioniert, nicht jedoch über Eingabe des Wertes, warum? Achselzucken.

Weiterhin kann ich auch weder durch Änderung des Setpoint in den Objekten des ioB, noch per mosquitto_pub dauerhafte Änderungen hervorrufen, es wird binnen kürzester Zeit überschrieben.

Bin gerade verzweifelt am Suchen, wie/wo das z2m Frontend (wo es im Slider ja möglich ist) das ganze anders macht....

Gruss
Chris

[arteck]

@chris-1 sagte in z2m Herdsman Tuya, Experten hier?:

Ich sollte wohl häufiger die tuya.js von GitHub her aktuallisieren.

du sollst das ganze aktualisieren nich tnur die eine Datei... du bist ja lustig
und sich dann wundern das nur die hälfte geht

[Chris 1]

@arteck Ich habe vorhin 1x komplett npu uninstall z-h-converters und wieder install gemacht. Rein theoretisch sollte da nun alles aktuell sein.

[arteck]

@chris-1 du muss das ganze projekt aktualisieren wenn du zigbee2mqtt verwendest..

[Chris 1]

@arteck
Mein Vorgehen war zuletzt

1. npm uninstall zigbee-herdsman-converters
2. npm install zigbee-herdsman-converters
   wonach der Adapter auch gemäß neuer Device-Beschreibung (fingerprint) direkt erkannt wurde.

Auf GitHub bekam ich nun folgende interessante Info:

[Chris 1]

@arteck Moin

Kleines WorkAround um direkt in den Datenpunkt schreiben zu können.
Die Variablen sind nur der Übersicht halber.
Modus <dev>/preset muss natürlich für das Setzen auf manual sein, aber alles andere rentiert sich ja im Hinblick auf die Steuerung durch ioB eh nicht.

Gruss von der Ostsee
Chris