Nanocul not working with FHT device

Add-ons Bindings
,
1

Dear Community,

I have been battling for some time to get my self-built nanocul working on my openhab 1.8.0 installation on a raspberry pi 2 with little success. I intend to use this to monitor the ELV FHT devices I have installed.

I am able to talk to the device via a terminal program (minicom) and the nanocul responds (e.g. SHIFT V returns nanocul version number “V 1.66 nanoCUL868”). However I receive the following error message in the debug logs

FHT binding:

2016-01-31 16:11:05 DEBUG o.o.b.f.internal.FHTActivator[:34]- FHT binding has been started.
2016-01-31 16:11:05 ERROR o.o.b.fht.internal.FHTBinding[:150]- Can’t open CUL
org.openhab.io.transport.cul.CULDeviceException: gnu.io.UnsupportedCommOperationException: Invalid Parameter
_ at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:273)_
_ at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:154)_
_ at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:170)_
_ at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:89)_
_ at org.openhab.binding.fht.internal.FHTBinding.bindCULHandler(FHTBinding.java:146)_
_ at org.openhab.binding.fht.internal.FHTBinding.setNewDeviceName(FHTBinding.java:172)_
Caused by: gnu.io.UnsupportedCommOperationException: Invalid Parameter
_ at gnu.io.RXTXPort.setSerialPortParams(RXTXPort.java:212)_
_ at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:258)_
_ at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:154)_
_ at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:170)_
_ at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:89)_
_ at org.openhab.binding.fht.internal.FHTBinding.bindCULHandler(FHTBinding.java:146)_
2016-01-31 16:11:05 ERROR o.o.b.fht.internal.FHTBinding[:159]- CUL device is not accessible
2016-01-31 16:12:05 ERROR o.o.b.fht.internal.FHTBinding[:159]- CUL device is not accessible

CUL binding:

2016-02-23 12:58:55 DEBUG o.o.i.t.cul.CULActivator[:35]- CUL transport has been started.
2016-02-23 12:58:56 DEBUG o.o.i.transport.cul.CULManager[:132]- Registering class org.openhab.io.transport.cul.internal.CULSerialHandlerImpl for device type serial
2016-02-23 12:58:56 DEBUG o.o.i.transport.cul.CULManager[:132]- Registering class org.openhab.io.transport.cul.internal.CULNetworkHandlerImpl for device type network
2016-02-23 12:58:57 DEBUG o.o.i.transport.cul.CULManager[:74]- Trying to open device serial:/dev/ttyUSB0 in mode SLOW_RF
2016-02-23 12:58:57 DEBUG o.o.i.transport.cul.CULManager[:140]- Searching class for device type serial
2016-02-23 12:58:57 INFO o.o.i.t.c.i.CULSerialHandlerImpl[:123]- Update config, baudrate = 38400
2016-02-23 12:58:57 INFO o.o.i.t.c.i.CULSerialHandlerImpl[:131]- Update config, parity = NONE (0)
2016-02-23 12:58:57 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:234]- Opening serial CUL connection for /dev/ttyUSB0

I have the following configuration settings:

  1. nanocul is on a powered usb hub (have also tried locally mounted)
  2. cul and fht addons are 1.8.0 jar files with 555 permissions set (as other addons)
  3. I am using raspbian jessie
  4. nanocul is on ttyusb0
  5. I have added the line *-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0 * to JAVA ARGS in the file /etc/init.d/openhab (I have also tried using the cul without this line)
  6. ttyUSB0 is locked when openhab is running
  7. java version is: "java version “1.8.0”, Java™ SE Runtime Environment (build 1.8.0-b132), Java HotSpot™ Client VM (build 25.0-b70, mixed mode)
  8. openhab account is a member of the dialout group (I also run a USB Z-Wave stick on ttyACM0 and that is working fine)
  9. The cul is setup in openhab.cfg as follows:
    fht:device=serial:/dev/ttyUSB0
    fht:baudrate=38400
    fht:parity=0
    fht:housecode=1223
  10. My openhab.log file:
    2016-02-23 12:58:09.624 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.0).
    2016-02-23 12:58:16.611 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
    2016-02-23 12:58:17.259 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.
    2016-02-23 12:58:24.432 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.sitemap’
    2016-02-23 12:58:28.959 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'rrd4j.persist’
    2016-02-23 12:58:29.124 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'exec.persist’
    2016-02-23 12:58:29.169 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'myopenhab.persist’
    2016-02-23 12:58:29.538 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.script’
    2016-02-23 12:58:30.311 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.items’
    2016-02-23 12:58:31.838 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest
    2016-02-23 12:58:37.374 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /classicui/openhab.app
    2016-02-23 12:58:40.950 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.rules’
    2016-02-23 12:58:43.532 [INFO ] [.service.AbstractActiveService] - FritzBox refresh Service has been started
    2016-02-23 12:58:43.536 [INFO ] [o.b.f.internal.FritzboxBinding] - Fritzbox conditional deActivate: true
    2016-02-23 12:58:43.558 [INFO ] [o.b.f.internal.FritzboxBinding] - Attempting connection to FritzBox on 192.168.178.1:1012…
    2016-02-23 12:58:43.597 [INFO ] [o.b.f.internal.FritzboxBinding] - Connected to FritzBox on xxx.xxx.xxx.x:1012
    2016-02-23 12:58:45.876 [INFO ] [.myopenhab.internal.MyOHClient] - Connected to my.openHAB service (UUID = 03b5e0d1-3c09-4fbf-9573-c86afe4d3492, local base URL = http://localhost:8080)
    2016-02-23 12:58:47.283 [INFO ] [.o.io.habmin.HABminApplication] - Started HABmin REST API at /services/habmin
    2016-02-23 12:58:52.632 [INFO ] [.service.AbstractActiveService] - NTP Refresh Service has been started
    2016-02-23 12:58:54.433 [INFO ] [.p.rrd4j.internal.RRD4jService] - Removing invalid defintion component = null heartbeat = 0 min/max = 0.0/0.0 step = 0 0 archives(s) = [] 0 items(s) = []
    2016-02-23 12:58:55.004 [INFO ] [.service.AbstractActiveService] - HTTP Refresh Service has been started
    2016-02-23 12:58:55.245 [INFO ] [.service.AbstractActiveService] - Exec Refresh Service has been started
    2016-02-23 12:58:55.450 [INFO ] [.z.internal.ZWaveActiveBinding] - Update config, port = /dev/ttyACM0
    2016-02-23 12:58:55.453 [INFO ] [.z.internal.ZWaveActiveBinding] - Update config, setSUC = true
    2016-02-23 12:58:55.456 [INFO ] [.z.internal.ZWaveActiveBinding] - Update config, softReset = false
    2016-02-23 12:58:55.458 [INFO ] [.z.internal.ZWaveActiveBinding] - Update config, masterController = true
    2016-02-23 12:58:55.463 [INFO ] [.service.AbstractActiveService] - ZWave Refresh Service has been started
    2016-02-23 12:58:55.631 [INFO ] [b.z.i.protocol.ZWaveController] - Starting Z-Wave controller
    2016-02-23 12:58:55.634 [INFO ] [b.z.i.protocol.ZWaveController] - Z-Wave timeout is set to 5000ms. Soft reset is false.
    2016-02-23 12:58:55.636 [INFO ] [b.z.i.protocol.ZWaveController] - Connecting to serial port /dev/ttyACM0
    2016-02-23 12:58:56.743 [INFO ] [b.z.i.protocol.ZWaveController] - Serial port is initialized
    2016-02-23 12:58:57.066 [INFO ] [.service.AbstractActiveService] - NetworkHealth Refresh Service has been started
    2016-02-23 12:58:57.277 [INFO ] [.service.AbstractActiveService] - FHT Refresh Service has been started
    2016-02-23 12:58:57.279 [INFO ] [.p.internal.PanasonicTVBinding] - TV registered ‘lounge_tv’ with IP 'xxx.xxx.xxx.xx’
    2016-02-23 12:59:00.206 [INFO ] [rialApiGetInitDataMessageClass] - NODE 1: Node found
    2016-02-23 12:59:02.467 [INFO ] [rialApiGetInitDataMessageClass] - NODE 6: Node found
    2016-02-23 12:59:02.468 [INFO ] [rialApiGetInitDataMessageClass] - NODE 7: Node found
    2016-02-23 12:59:02.472 [INFO ] [rialApiGetInitDataMessageClass] - ZWave Controller using Controller API
    2016-02-23 12:59:02.474 [INFO ] [rialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
    2016-02-23 12:59:02.476 [INFO ] [rialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
    2016-02-23 12:59:02.478 [INFO ] [rialApiGetInitDataMessageClass] - # Nodes = 3
    2016-02-23 12:59:02.480 [INFO ] [rialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
    2016-02-23 12:59:04.592 [WARN ] [i.p.s.IsFailedNodeMessageClass] - NODE 6: Is currently marked as failed by the controller!
    2016-02-23 13:00:02.558 [ERROR] [.myopenhab.internal.MyOHClient] - Socket.IO error: io.socket.engineio.client.EngineIOException: websocket error
    2016-02-23 13:00:02.574 [INFO ] [.myopenhab.internal.MyOHClient] - Disconnected from my.openHAB service (UUID = 03b5e0d1-3c09-4fbf-9573-c86afe4d3492, local base URL = http://localhost:8080)
    2016-02-23 13:00:21.850 [INFO ] [.myopenhab.internal.MyOHClient] - Connected to my.openHAB service (UUID = 03b5e0d1-3c09-4fbf-9573-c86afe4d3492, local base URL = http://localhost:8080)

I would be very grateful if someone could give me some assistance here as I would be tearing my hair out (if I had any) :joy:

br

vbevan

2

Hi Vincent,

did you get the problem solved in the meantime? If yes - what have you done?

Regards - machnetz

3

Please read through this pull request:

@tarioch very kindly updated the wiki pages for the affected bindings, so make sure to read these recent updates, and try the newly improved CUL-based bindings from the 1.9.0-SNAPSHOT builds:

https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastSuccessfulBuild/artifact/bundles/binding/

And please, report your observations here!!!

4

Hi watou and machnetz,

apologies I only just had time to look at this. I installed the 1.90 snapshot files.

My debug log for cul shows success:

2016-04-23 22:00:08 DEBUG o.o.i.t.cul.CULActivator[:35]- CUL transport has been started.
2016-04-23 22:00:08 DEBUG o.o.i.transport.cul.CULManager[:132]- Registering class org.openhab.io.transport.cul.internal.CULSerialHandlerImpl for device type serial
2016-04-23 22:00:08 DEBUG o.o.i.transport.cul.CULManager[:132]- Registering class org.openhab.io.transport.cul.internal.CULNetworkHandlerImpl for device type network

Also my FHT debug log shows:

2016-04-23 22:00:08 DEBUG o.o.b.f.internal.FHTActivator[:34]- FHT binding has been started.

So far so good. I believe my nanoCul has not been wired correctly (needs a resistor) so I don’t believe I will receive any messages from my FHT devices yet. Will inform you further when I get this fixed.

Tarioch I looked at your wiki updates for cul and fht… for fht I couldn’t see the listing under bindings in the wiki page list (right hand side under bindings)? I searched for it and found it. However I don’t understand what has been written there? It seems to have changed a great deal. Does anyone have any example items and sitemap files to share? Also I didn’t see where I put the FHT housecode (fht declaration in openhab.cfg or items file)?

Cheers Vincent

5

Thought I’d add an update here. I tried out OH2 and had similar problems with not being able to get my nanoCUL working. The nanoCUL works perfectly with a terminal program Minicom. I can see the FHT devices broadcasting their status after issuing the raw command “X21” in the terminal to the nanoCUL.
I then went back to OH 1.8.3 and used the 1.9 snapshot CUL transport and 1.9 FHT modules as suggested by Tarioch, all to no avail. I’ve decided to shelve my OH environment until I can find some detailed reliable documentation on how to have this work.

6

High, I’m using a CUL with the Intertechno - binding. Started with “Can’t open CUL” errors, however when changing the user that is starting OH2 to root, it started to work!

7

Hi Jürgen,

greetings from Bayern… I will try this. I tried switching the user to Root in my OH1 instance but no joy :frowning: Will spin up a new OH2 instance and try with Root and report back. Cheers!

8

Hi finally tried this with root user of OH2 and when I start the FHT bundle in Karaf (jar in addons folder and cfg file in Services folder) with CUL successfully running I get…

[ERROR] [org.openhab.binding.fht ] - FrameworkEvent ERROR - org.openhab.binding.fht
org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.SingleComponentManager.getService()
…
…
Caused by: java.lang.ClassNotFoundException: org.openhab.io.transport.cul.CULLifecycleListener cannot be found by org.openhab.binding.fht_1.9.0.201602270920

FYI I also tried out the org.openhab.io.transport.serial_3.12.0.a1.jar serial bundle which I read about.

I’m done with this now until openHAB distributions have more stability for ARM/Linux.

Cheers!

9

I use the CUL with Intertechno binding and I have no experience with FHT.
Sorry, can’the help in this case.

10

Ok thanks anyway for the feedback Jürgen :wink:

11

Just by way of update I decided to have another couple of days of hair pulling and installed a new instance of OH2 on an RPI3 with openhabian.

With the standard openhab serial transport 2.0.0.SNAPSHOT there is still obviously a port locking issue on the RPI under raspbian - typically in the debug log in Karaf “gnu.io.UnsupportedCommOperationException: Invalid Parameter” is reported when opening the CUL.

I now did the following:

  1. In Karaf I installed feature for CUL1.9.0.SNAPSHOT (feature:install openhab-transport-cul1) and deinstalled the feature for serial transport 2.0.0.SNAPSHOT (feature:uninstall openhab-transport-serial),
  2. I installed org.openhab.io.transport.serial_3.12.0.a1.jar and org.openhab.binding.fht-1.9.0-SNAPSHOT.jar in the addons folder, with the requisite cul.cfg in the services folder:

fht:device=serial:/dev/ttyUSB0
fht:baudrate=38400
fht:parity=NONE
fht:housecode=1115

The new serial port library throws the error “Can’t open CUL org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException”. This was overcome by installing liblockdev1 (sudo apt-get install liblockdev1) to enable exclusive locking of the serial ports.

Now the CUL seems to run fine, and the FHT binding is loading correctly. However although when opeming the CUL in a raw terminal mode I receive reports from the various FHT80B and FHT8V units in the house the binding always reports “[DEBUG] [nhab.binding.fht.internal.FHTBinding] - Processing 0 waiting FHT temperature commands”.

I am still a little confused with the FHT/CUL syntax in the items file… is it correct to use this…

Group FHT_Lounge “Heating” (Heating, Lounge)
Number Lounge_Temp_Target “Target Temp. [%.1f °C]” (FHT_Lounge) { fht=“housecode=0C17;datapoint=DESIRED_TEMP” }
Number Lounge_Temp_Actual “Actual Temp. [%.1f °C]” (FHT_Lounge) { fht=“housecode=0C17;datapoint=MEASURED_TEMP” }
Number Lounge_Radiator_Valve “Radiator valve [%.1f %%]” (FHT_Lounge) { fht=“housecode=0C17;address=00;datapoint=VALVE” }
Switch Lounge_Sensor_Battery “Sensor Battery [%s]” (FHT_Lounge) { fht=“housecode=0C17;datapoint=BATTERY” }
Contact Lounge_Windows_Status “Lounge [MAP(en.map):%s]” (FHT_Lounge) { fht=“housecode=0EDC;address=7B;datapoint=WINDOW” }

or should I be using this…??

Group FHT_Lounge “Heating” (Heating, Lounge)
Number Lounge_Temp_Actual “Actual Temp. [%.1f °C]” (FHT_Lounge) { cul=“TR0C17” }
Number Lounge_Radiator_Valve “Radiator valve [%.1f %%]” (FHT_Lounge) { cul=“TR0C1700” }
Contact Lounge_Windows_Status “Lounge [MAP(en.map):%s]” (FHT_Lounge) { cul=“TR0EDC90” }

Note: the housecode I have used is an example of the hex value housecode of my lounge FHT80B… which I have recieved reports in raw terminal mode on my nanocul.

I’d be grateful for any assistance here,a nd would also take a stab at the FHT documentation in the documentation if I get this solved :wink:

Cheers vbevan

12

High Vincent,

you made the move to OH2, great!
And you also got your CUL-stick working under the user “openhab”, or did I misunderstand that?

I need to change to user"root" in order to have a working CUL-stick!
Could you post your “bundle:list”, at least the parts that are needed for the CUL?

Mine look like:

208 | Active | 80 | 1.9.0.201612160210 | openHAB CULIntertechno Binding
209 | Active | 80 | 1.9.0.201612160210 | openHAB CUL Transport Bundle
210 | Active | 80 | 2.0.0.201612141902 | openHAB Serial Transport Bundle

13

Hi Jürgen,

apologies for the delay in my replying to you… here is my bundle:list below.
In answer to your question the binding seems to work (see log info and lock status below), although I don’t receive any reports from the 5x FHT80 units I have which indicates a problem.

log of FHT/CUL status:

log:display org.openhab.binding.fht

16:57:41.161 [DEBUG] [org.openhab.binding.fht ] - BundleEvent STARTING - org.openhab.binding.fht
16:57:41.178 [DEBUG] [ab.binding.fht.internal.FHTActivator] - FHT binding has been started.
16:57:41.185 [DEBUG] [org.openhab.binding.fht ] - BundleEvent STARTED - org.openhab.binding.fht
16:57:41.492 [DEBUG] [org.openhab.binding.fht ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.fht, component.name=org.openhab.binding.fht.binding, component.id=191, service.id=312, service.bundleid=191, service.scope=bundle} - org.openhab.binding.fht
16:57:41.507 [DEBUG] [org.openhab.binding.fht ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.fht.FHTBindingProvider}={component.name=org.openhab.binding.fht.genericbindingprovider, component.id=192, service.id=311, service.bundleid=191, service.scope=bundle} - org.openhab.binding.fht
16:57:41.876 [DEBUG] [nhab.binding.fht.internal.FHTBinding] - Processing 0 waiting FHT temperature commands
16:58:41.884 [DEBUG] [nhab.binding.fht.internal.FHTBinding] - Processing 0 waiting FHT temperature commands

openHAB bundle list:

bundle:list | grep -i openhab

164 | Active | 90 | 2.0.0.201612271013 | openHAB Core
165 | Active | 80 | 2.0.0.201612271013 | openHAB Karaf Integration
167 | Resolved | 80 | 2.0.0.201612271013 | openHAB Sound Support, Hosts: 109
168 | Active | 80 | 2.0.0.201612271013 | openHAB Dashboard UI
176 | Resolved | 80 | 2.0.0.201612271013 | openHAB Basic UI Fragment, Hosts: 174
178 | Resolved | 80 | 2.0.0.201612271013 | openHAB Paper UI Theme Fragment, Hosts: 175
180 | Active | 80 | 2.0.0.201612271013 | openHAB Classic UI Fragment
182 | Active | 80 | 1.9.0.201612250211 | openHAB PanasonicTV Binding
183 | Active | 80 | 2.0.0.201612271013 | openHAB 1.x Compatibility Layer
186 | Active | 80 | 1.9.0.201612250211 | openHAB Weather Binding
189 | Active | 80 | 1.9.0.201612250211 | openHAB MapDB Persistence Bundle
190 | Active | 80 | 3.12.0.a1 | openHAB Serial Transport Bundle
191 | Active | 80 | 1.9.0.201612160210 | openHAB FHT Binding
192 | Active | 80 | 1.9.0.201612250211 | openHAB CUL Transport Bundle

lock files:

ls -l /run/lock
total 24
-rw-r–r-- 1 root root 11 Dec 27 16:56 asound.state.lock
-rw-rw-rw- 5 openhab openhab 11 Dec 27 16:57 LCK…923
-rw-rw-rw- 5 openhab openhab 11 Dec 27 16:57 LCK.C.166.000
-rw-rw-rw- 5 openhab openhab 11 Dec 27 16:57 LCK.C.188.000
-rw-rw-rw- 5 openhab openhab 11 Dec 27 16:57 LCK…ttyACM0
-rw-rw-rw- 5 openhab openhab 11 Dec 27 16:57 LCK…ttyUSB0
drwxrwxr-x 2 root root 40 Dec 27 16:56 lockdev
drwxr-xr-x 2 root root 40 Dec 27 16:56 subsys

some strange lock files are produced, possibly as although I had added CUL transport as a feature after adding the refactored serial transport 3.12.0.a1 into the addons directory together with the FHT bundle 1.90 it automatically installed another serial transport feature 2.0.0 (I guess as a dependency) which I think is an error… I used bundle:uninstall to overcome this error. It did require me then to restart the Pi (OH2 restart didn’t work).

Finally it just isn’t working for me, I don’t have the amount of time to devote to this and the information I have scored many hours for is either sketchy, non-existent or plainly incorrect.

Cheers Vincent

14

High Vincet,

i have the same problem. I have 2 nanoCULs.
One for 433 Mhz Intertechno devices. This on works fine.
One for 868 Mhz FHT and FS 20 devices. With this one i get no messages.
The config is okay. and the log file has no errors.
Both CULs are working with FHEM…
I had the chance to try a original CUL (Busware).
What to say with this one it works!!! So there must be a small difference between the
original and the nanoCUL. Ob both is the firmware 1.67 installed.

Greets from Bavaria

Hans

15

High Johann,

I’m only using a CUL with intertechno (I.e. only listening) , so I probably can’t help much. But some questions.
When you tried the CUL from buswaee, did you have your 433 version in use as well?
Are you sure on the connection with your 866 version, the busware one migth have used another one. For example my busware 866 is connected as ttyACM0, my 433 nanoCUL (not busware) as ttyUSB0.

16

High Jürgen,

in both cases the 433 nanoCul was connected. I am sure that the connections are correct. I have a UDEV Rule (serial number from the FTDI chip) and generate a Symlink for the Culs;; ttycul433 and ttycul868.As i said before with the original
Busware Cul and my 433 nanoCul eveythiny was working.
The nanoCul 868 must differ a little bit in the behaviour from the original.
I already changed the name in the source code from nanoCul to the name
from Busware. No Luck… At the moment i have no idea what to try next…
Any hint is welcome

Hans

17

High,

Status update. Strange behaviour. If i unplug the nanoCUL with the Intertechno binding,
i get errors -> Intertechno Binding and from this CUL …
Just in the same moment the other nanoCUL get correct FHT messages and it works as it should.

All my tries just to use only this CUL fails. No difference wheter Intertechno Binding is installed or not.
The only way is “hardcore unpluging” the Intertechno nanoCUL after the Pi and the system is started.

Maybe someone has an i idea, what and where to search for finding a fix for that.

Greets

Jason0815

18

Hi Hans,

apologies for the late answer… I more or less gave up on the FHT binding :frowning: I am currently thinking about either using the MAX! radiator thermostats with the oh2 binding or HomeMatic ones using HomeGear interfacing to openhab2… no time currently though. I will report back what works best as I move forward (slowly). Greetings also from Landsberg am Lech!

Vincent

19

Hello Vincet,
the binding is faulty in some way… I gave this binding up too.
If the binding is installed, there is no “traffic” anymore on the
internal serial device. I tested this with a serial monitor rule.
If deinstall FHT binding, i can send and receive again over the serial…
Tested with Intertechno binded to the nanoCul too. No problem here!
With binding FS20 it works too.I always can switch RF 433Mhz Poweroutlet via serial commands as long the FHT binding is not installed
So my conclusion, something gets internal broken with installing FHT binding and a nanoCul.

Maybe MAX! is a way out. But if i buy new thermostats i dont like the idea to get old slow and unsecure 868Mhz technologie. And my old (> 10 years) FHT devices still work fine. Its not my way to trash working things

Greetings back from Ingolstadt

Hans

20

Hi Hans thx for the clarification :wink:
Cheers Vincent