Unable to talk to FHT80B-3 radiator valve controller


I have recently installed OpenHAB 1.8.0 with the intention of controlling a collection of wireless FHT80B-3 radiator thermostats. I have a Busware CULv3 which seems to be working since I can see frequent messages in the logs (I have debug mode enabled) about messages received from CUL:

12:30:02.448 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T3D4E00A6003C 12:30:02.449 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:296 ] - Requesting credit report 12:30:02.469 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: 21 900 12:30:02.470 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:278 ] - credit10ms = 900 12:30:22.842 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T3C5F00A60D2F 12:30:22.842 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:296 ] - Requesting credit report 12:30:22.863 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: 21 900 12:30:22.863 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:278 ] - credit10ms = 900

The four characters after the T of the 13 char address are the four characters used as the ‘sync code’ between the radiator valve and the wireless thermostat. This makes me think that I have flashed the Busware USB stick with the correct firmware and configured the FS20 binding in openhab_default.cfg correctly. The relevant part of openhab_default.cfg that I have added is:

############################### FS20 Binding ######################################## fs20:device=serial:/dev/ttyACM0 fht:housecode=DC69 # (or whatever you have, I don't think that this is necessary) fht:device=serial:/dev/ttyACM0

I used the FHT80 section from Dirk Clemens’ post here as a basis for my items.cfg file. My very simple items config file for the FHT80B-3 in my study is:

FHT80B - Funk-Heizkörperthermostate /
binding: fht=“housecode=;address=;datapoint=” /
items: Switch, Number /
Number HeatingBlueroomDesired “Blueroom Desired-Temp. [%.1f °C]” (Heating, logger) { fht=“housecode=3D4E;datapoint=DESIRED_TEMP” }

Number HeatingBlueroomMeasured “Blueroom Actual-Temp. [%.1f °C]” (Heating) { fht=“housecode=3D4E;datapoint=MEASURED_TEMP” }

Number HeatingBlueroomValve “Blueroom Valve [%.1f %%]” (Heating) { fht=“housecode=3D4E;address=00;datapoint=VALVE” }

Switch HeatingBlueroomBattery “Blueroom Heating Battery [%s]” (Heating, Battery) { fht=“housecode=3D4E;datapoint=BATTERY” }


The only data I changed when copying the item from Dirk’s example is the housecode (apart from the descriptions and names). The housecode matches the codes I can see in the debug messages from the CUL handler in the log and the sync code I can see on the FHT80B thermostat.

However, when viewing the items in a browser via there is no data in any of them. Where I would expect to see a number there is only a dash.

So, how can I go about investigating this further? Is my config correct? Are there any debugging steps I can go through? This is the first time I’ve installed OpenHAB so I’m a complete novice.

Any help would be appreciated.



Unfortunately I didn’t manage to get it running under 1.8.0, so finally I downgraded back to 1.7.1
Maybe something went wrong in the version upgrade?
I have no IDE, so I’m not able to investigate more.


I had not noticed a message in the log that stated that the parity option was mandatory. The relevant part of openhab.cfg now looks like this:

fs20:device=serial:/dev/ttyACM0 fht:housecode=6178 fht:device=serial:/dev/ttyACM0 fht:baudrate=38400 fht:parity=NONE

Strangely, even with the addition of fht:parity=NONE the following error still appears in the log:

17:22:17.024 [ERROR] [o.i.t.c.i.CULSerialHandlerImpl:157 ] - Error parsing config key 'parity'. Use one of [EVEN, MARK, SPACE, NONE, ODD].

I also found that stopping and starting the OpenHAB service caused problems the busware USB stick. OpenHAB was no longer able to access the USB stick:

16:21:52.107 [DEBUG] [.o.b.fs20.internal.FS20Binding:77 ] - Opening CUL device on serial:/dev/ttyACM0 16:21:52.108 [DEBUG] [.o.io.transport.cul.CULManager:75 ] - Trying to open device serial:/dev/ttyACM0 in mode SLOW_RF 16:21:52.108 [DEBUG] [.o.io.transport.cul.CULManager:140 ] - Searching class for device type serial 16:21:52.110 [DEBUG] [o.i.t.c.i.CULSerialHandlerImpl:241 ] - Opening serial CUL connection for /dev/ttyACM0 16:21:52.111 [ERROR] [.o.b.fs20.internal.FS20Binding:81 ] - Can't open cul device org.openhab.io.transport.cul.CULDeviceException: The port /dev/ttyACM0 is currenty used by org.openhab.io.transport.cul.internal.CULSerialHandlerImpl at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:246) ~[na:na] at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:154) ~[na:na] at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:170) ~[bundlefile:na] at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:89) ~[bundlefile:na] at org.openhab.binding.fs20.internal.FS20Binding.getCULHandler(FS20Binding.java:78) [bundlefile:na] at org.openhab.binding.fs20.internal.FS20Binding.updateDeviceSettings(FS20Binding.java:72) [bundlefile:na] at org.openhab.binding.fs20.internal.FS20Binding.updated(FS20Binding.java:200) [bundlefile:na] at org.eclipse.equinox.internal.cm.ManagedServiceTracker$1.run(ManagedServiceTracker.java:183) [org.eclipse.equinox.cm_1.0.400.v20120522-1841.jar:na] at org.eclipse.equinox.internal.cm.SerializedTaskQueue$1.run(SerializedTaskQueue.java:36) [org.eclipse.equinox.cm_1.0.400.v20120522-1841.jar:na]

However, rebooting the machine solved the problem.

Now I have to buy some more valves to automate the rest of the house. :laughing:

Hi - did you get this working on version 1.8? I ended up going back to 1.7.1, so if you’ve got the whole thing running error-free on 1.8 that would be quite interesting.
I didn’t try that parity entry in the config file though…

Hi Matt,

Yes, I’m running 1.8.

I have 1.8 running in an Ubuntu VM on an ESXi 6.0 update 1b host. I installed 1.8 from the repo listed on the wiki. The USB devices (CUL v3 and Aeon Z-Stick) are connected to a USB hub which is in turn connected to the ESXi host. The USB devices are then passed through to the VM via ESXi. I had a problem where OpenHAB couldn’t open the CUL device on /dev/tty/ACM0 but I’ve just swapped the USB hub to a different one that I had in a drawer and that problem seems to have gone away for the moment.

Let me know if you want any more info.