Fibaro FGT-001 valve problem


I have a Fibaro FGT-001 thermostatic valve that I have been controlling with Danfoss wall thermostat. Basically if room temperature falls below setpoint, openhab turns the valve on (1) and of temperature is above setpoint, openhab turns it off (0). It worked well until now. I reinstalled Openhab and added the devices and now the valve isn’t responding as it should.
The valve itself has led indicators that show the status of it: white=off, different colors (blue to orange) correspond to the temperature it supposed to hold, red=24+ degrees and magenta=valve open.
When the rule controls the valve as on=1 and off=0. On the logs it works - the valve “mode” changes to 1 and 0 accordingly but in reality when the valve is turned “on”, it is set to the level what ever “green” represents (20 degrees according to the manual). Physically the valve is in green state but it actually does not change the physical position - the motor doesn’t engage, only the LED changes. If i manually turn the valve controller to red or magenta, it does open as expected. And then if temperature reaches setpoint and the rule turns the valve off, it actually turns off.
Does anybody have an idea what’s going on? It worked a long time before the reinstall. Can the valve “go bad” and not work as expected? The rule i use is as follows:

var boolean heating = false
var boolean cooling = false

rule "Change thermostat mode to heating"
    Item DanfossTemperature changed
    or Item DanfossSetpoint changed
    if (DanfossTemperature.state < DanfossSetpoint.state) {
        if (!heating) {
            sendCommand(Thermostat1_Thermostatmode, 1)           
            heating = true
    } else {
        heating = false

rule "Change thermostat mode to cooling"
    Item DanfossTemperature changed
    or Item DanfossSetpoint changed
    if (DanfossTemperature.state > DanfossSetpoint.state) {
        if (!cooling) {
            sendCommand(Thermostat1_Thermostatmode, 0)            
            cooling = true
    } else {
        cooling = false

First: you don’t need two rules.
Second: which Item types are DanfossTemperature, DanfossSetpoint and Thermostat1_Thermostatmode?

A more safe way to do the job:

rule "thermostat mode"
    Item DanfossTemperature changed or
    Item DanfossSetpoint changed
    if(!(DanfossTemperature.state instanceof Number)) {
        logWarn("thermo","DanfossTemperature state is not a valid number: {}, therefor exiting rule.", DanfossTemperature.state)
    if(!(DanfossSetpoint.state instanceof Number)) {
        logWarn("thermo","DanfossSetpoint state is not a valid number: {}, therefor exiting rule.", DanfossSetpoint.state)
    val nTempIs  = (DanfossTemperature.state as Number).floatValue
    val nTempSet =    (DanfossSetpoint.state as Number).floatValue

    if(nTempIs < nTempSet && Thermostat1_Thermostatmode.state != 1)
    if(nTempIs > nTempSet && Thermostat1_Thermostatmode.state != 0)

So first check whether all item states are of type Number (and if not send a warning and exit the rule).
After that step, get the values to local constants.
Then check the difference and if the current mode matches.

Please be aware that Number Items may be compared correctly without casting, but if one ore both Items are of type Number:Temperature, it’s very unlikely that comparison without casting will work correctly.
instead of < and > it would be better to define a hysteresis, e.g.

    if(nTempIs < nTempSet - 0.1 && Thermostat1_Thermostatmode.state != 1)
    if(nTempIs > nTempSet + 0.1 && Thermostat1_Thermostatmode.state != 0)

to avoid frequent switching.

Hi Udo

I know my rule might not be optimal, I don’t know much about coding/scripting and this rule was made by ChatGPT with my descrtiption.

Anyway, I replaced my rule with the one that You provided but nothing changed. Event log doesn’t give the warning either (or should it be shown in somewhere else?). All the item types should be number (I get it from the item page, under the item name). Any more ideas?

2023-10-29 11:16:00.908 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘DanfossSetpoint’ changed from 22 °C to 23 °C
2023-10-29 11:16:01.279 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘DanfossSetpoint’ received command 24
2023-10-29 11:16:01.282 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘DanfossSetpoint’ predicted to become 24
2023-10-29 11:16:01.286 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘DanfossSetpoint’ changed from 23 °C to 24 °C
2023-10-29 11:16:01.719 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘DanfossSetpoint’ received command 25
2023-10-29 11:16:01.722 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘DanfossSetpoint’ predicted to become 25
2023-10-29 11:16:01.724 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘DanfossSetpoint’ changed from 24 °C to 25 °C
2023-10-29 11:16:01.737 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Thermostat1_Thermostatmode’ received command 1
2023-10-29 11:16:01.738 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Thermostat1_Thermostatmode’ predicted to become 1
2023-10-29 11:16:01.738 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Thermostat1_Thermostatmode’ changed from 0 to 1

Don’t do that. ChatGPT is a dumb piece of software, there is no intelligence in it :slight_smile: sorry for rant…

 Item ‘DanfossSetpoint’ changed from 22 °C to 23 °C

This is a Number:Temperature Item, not a Number Item.

No warnings: So the rule just works as it should.
Question is: is the command Thermostat1_Thermostatmode 1 correct at all?

Well, since I myself can’t code much and it wrote the code much better than someone in the forum a long time ago (battery consumption of the same valve decreased about 6x times thanks to the improved code), it has been good enough for me. It’s fast and the code works (not currently of course).

You are correct - Danfoss temperature and setpoint are both Number:Temperature. I thought it was the same as just “Number” item with just “temperature” addition for degree symbols. This shows how little I know about this stuff. But is that even relevant? The problem is controlling the valve, which is a “number” and conditions of the rule (related to danfoss items) seem to work.

I have thought about that myself. But since it has been working like that for years (didn’t anymore after the reinstall), it seems like it is correct. As I said, someone in the past wrote rule like that and later ChatGPT also but in the manual I can’t actually find 0 and 1 for toggling the valve. In the manual page 19 ( it says like that:

0 = Set OFF mode (unfreeze function)
99 = Set HEAT mode (last set temperature)
255 = Set MANuFACTuRER SPECIFIC mode (valve fully opened)

As I said before - 0 works. If I have manually opened the valve and rule sets the mode to “0”, the valve closes.
But when I change the “1” to 99 or 255 (logs show the mode change to 99 or 255), it doesn’t work anymore (even 0 stops working then).

So this is the information about your hardware in openHAB:

So please check if the channel is correct (channel type is thermostat_mode, and there is an additional channel thermostat_mode1, I don’t see any explanation why or how…)

ChatGPT is just getting information from the internet, i.e. it steals code (nothing about source of code) and doesn’t understand the code itself. That’s why I’m a bit harsh about this “AI hype”. :slight_smile:
In general, ChatGPT is very bad in question of openHAB code, because there is much less information in the internet as for other code. (which is obviously the cause of all these desperate attempts to get code from ChatGPT in the first place :joy:)

Situation gets even more confusing but I think I found a solution. Not ideal, so if anyone still has some ideas, I’d like to test them.

I tried the channel “thermostat_mode1” as You suggested, but with no help. At first it didn’t work at all, changing the state only gave errors:

2023-10-29 20:31:55.417 [ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 2: Unsupported mode type 0
2023-10-29 20:31:55.419 [WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 2: Generating message failed for command class = CO                                                              MMAND_CLASS_THERMOSTAT_MODE, endpoint = 1
2023-10-29 20:33:36.380 [ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 2: Unsupported mode type 1
2023-10-29 20:33:36.381 [WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 2: Generating message failed for command class = CO                                                              MMAND_CLASS_THERMOSTAT_MODE, endpoint = 1

Then I recreated the “thermostat_mode” and later again “thermostat_mode1”. Then both channels “worked” again (actual valve still isn’t opening).
But then I noticed something - when I manually open the valve as far as it goes (magenta color LED), openhab reports its state as “31”. So instead of “1” in the rule, I changed it to “31” and now the valve opens and closes when the rule tells it to. It is not ideal, because when I want to open the valve from the Item page, it does not work, since the item itself changes its state to 1, not 31. Not to mention that it has worked with 1 and 0 for years.

So if You get any additional ideas from that, I appreciate it but if not then thanks for thinking along.


Glad this is working for you.

The log entries are a little odd. Obviously type 0 and type 1 are supported mode values and there have been no changes to this section of the ZW binding in some time. The only thing I could think of is somehow it is not being sent from the rule as a number. At the risk of redundancy you could try something like

var mode = Thermostat1_Thermostatmode.state as Number

The Mode command class is 0x40 and there is no 0xC0 command class in Zwave, so that is odd too. A debug log would be required to better diagnose. In OH4 that can be done easily from the Zwave UI binding page using the steering wheel icon. No need here if you are okay

A couple of other tidbits

  1. Endpoint 0 (root) channels are frequently a duplicate of EP1, so only one of the channels needs to be linked to an item. Sometimes it is trial and error to see which one (or if both) are working.
  2. There are a couple of other mode options in the ZW binding, not shown on the device documentation. You are using the manual one.
        FULL_POWER(15, "Full Power"),
        MANUAL(31, "Manual");

Hi Bob!
Thanks for the reply. Yes, it’s working but I’m not happy still. I’d like it to be working correctly.

So I’m pretty sure, the problem isn’t the rule. Because the valve acts the same when I switch it to “Heat” or “Off” from the item page manually. When I set it to Heat, in the logs the mode becomes “1” and if I switch it off the mode becomes “0” but the physical valve doesn’t do anything, only the color of the LED changes to something. Only differents to before “my own solution” is that if before the color was green, now the color changes to yellow. Both represent some temperature setpoint value but doesn’t open the valve if it’s lower than the actual air temp (and all the colors/settings exempt red and magenta are).
After adding the thing to the system I haven’t done any additional modifications to the settings - all the default settings are set and that also goes for the item. So I’m starting to wonder if the valve itself is going bad?

A debug log would be required to better diagnose

I changed the add-on log settings to debug. Attached the log file. Log starting when the valve is off and I turn it to Heat. debug.txt (80.0 KB)

Sometimes it is trial and error to see which one (or if both) are working

Both channels are working exactly the same. Either work as expected.

You are using the manual one.

Well that’s just awesome that they are not putting them in the manual :stuck_out_tongue:
Both of these would help me when using the rule but I think I can’t set the item to use the values when switching it from the item page, can I?

Thanks for that! There are no warn or error messages embedded with the debug, which is good for you, but doesn’t help understanding of what is going wrong. One comment; having the device included with security slows things down. Generally security is only required on external access devices, like locks. The mode command was received at 32.293 and the state updated by 35.702. FYI - There is a zwave log viewer (in color!) that helps present these files in a more understandable format
Z-Wave Log Viewer (

I’m trying to get my head around the difference with this kind of device versus the thermostat I have for a central Air heating. In addition to the Mode CC I have a Thermostat Op State CC, so I just set mode to Heat (1) for the winter and the op state CC tells me if it idle (0) or heating (1). Are you needing to turn off the Mode because steam/water always flowing when the Mode is Heat (regardless of room temperature)? Also can you change the local device color with OH by changing the Setpoint?

I was wondering about this because of the WARN about command class C0, but again did not see this in the debug.

I’ll have a look at the Z-wave log viewer. Thanks.

I set up the security only because at the time of OH reinstall I had some trouble identifying the Things and some users had gotten help by adding them securely. My solution was different but the setting stayed. Is it bad idea to just remove the setting now? Will it break something?

Are you needing to turn off the Mode because steam/water always flowing when the Mode is Heat


can you change the local device color with OH by changing the Setpoint

Well, yes. But I’m not using the valves setpoint. Temperature is measured by Danfoss thermostat and also the same thermostat setpoint is used. I made a setpoint item from valves setpoint channel to test and it does change the LED color.

I wouldn’t suggest doing anything at this point. Security is just extra traffic, a bit slower and harder on the battery, but doesn’t appear to be the cause of your issues. To reverse it you would have to exclude the device and reinclude (as new node)

I guess I just don’t have enough understanding of how the device works or your setup to give any helpful hints to avoid the Mode on/off :frowning_face: Sorry.