As I did a bigger refactoring around CUL, I could use some more people trying out if everything still works for them:
It’s affecting:
- intertechno
- em
- fht
- fs20
- hms
- maxcul
- s300th
1 Like
Thanks very much for doing this. Could you provide a handy link to a set of test JARs here?
Patrick,
I am running your bindings now for some time and it seems to work fine with openHAB 1.8.1.
My items are FS20 switches, FHT heating controls, s300th temp/humidity sensors with a CUL USB stick.
openhab.cfg is like:
fht:device=serial:/dev/ttyACM0
fht:housecode=DC69
fht:baudrate=38400
fht:parity=NONE
fs20:device=serial:/dev/ttyACM0
fs20:baudrate=38400
fs20:parity=NONE
s300th:device=serial:/dev/ttyACM0
s300th:baudrate=38400
s300th:parity=NONE
no entries for CUL needed.
Unfortunately, the bindings do not work with the openHAB 2 beta:
2016-03-03 12:43:33.851 [INFO ] [b.core.service.AbstractActiveService] - FHT Refresh Service has been started 2016-03-03 12:43:33.863 [INFO ] [b.core.service.AbstractActiveService] - FHT Refresh Service has been shut down 2016-03-03 12:43:33.871 [ERROR] [inding.s300th.internal.S300THBinding] - Can't open CUL handler for device serial:/dev/ttyACM0 org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:257)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:152)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:171)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:88)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:52)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.binding.s300th.internal.S300THBinding.openCUL(S300THBinding.java:82)[12:org.openhab.binding.s300th:1.8.1] at org.openhab.binding.s300th.internal.S300THBinding.setNewDeviceName(S300THBinding.java:77)[12:org.openhab.binding.s300th:1.8.1] at org.openhab.binding.s300th.internal.S300THBinding.updated(S300THBinding.java:141)[12:org.openhab.binding.s300th:1.8.1] at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8] at java.lang.Thread.run(Thread.java:744)[:1.8.0] Caused by: gnu.io.NoSuchPortException at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273)[156:org.openhab.io.transport.serial:2.0.0.201603021555] at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:236)[155:org.openhab.io.transport.cul:1.9.0.201603030213] ... 14 more 2016-03-03 12:43:33.879 [INFO ] [b.core.service.AbstractActiveService] - S300TH Refresh Service has been started 2016-03-03 12:43:33.881 [INFO ] [b.core.service.AbstractActiveService] - S300TH Refresh Service has been shut down 2016-03-03 12:43:33.889 [INFO ] [rt.cul.internal.CULSerialHandlerImpl] - Update config, baudrate = 38400 2016-03-03 12:43:33.898 [INFO ] [rt.cul.internal.CULSerialHandlerImpl] - Update config, parity = NONE (0) 2016-03-03 12:43:33.903 [ERROR] [ab.binding.fs20.internal.FS20Binding] - Can't open cul device org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:257)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:152)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:171)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:88)[155:org.openhab.io.transport.cul:1.9.0.201603030213] at org.openhab.binding.fs20.internal.FS20Binding.getCULHandler(FS20Binding.java:78)[10:org.openhab.binding.fs20:1.8.1] at org.openhab.binding.fs20.internal.FS20Binding.updateDeviceSettings(FS20Binding.java:72)[10:org.openhab.binding.fs20:1.8.1] at org.openhab.binding.fs20.internal.FS20Binding.updated(FS20Binding.java:200)[10:org.openhab.binding.fs20:1.8.1] at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8] at java.lang.Thread.run(Thread.java:744)[:1.8.0] Caused by: gnu.io.NoSuchPortException at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273)[156:org.openhab.io.transport.serial:2.0.0.201603021555] at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:236)[155:org.openhab.io.transport.cul:1.9.0.201603030213] ... 13 more 2016-03-03 12:43:33.913 [ERROR] [org.apache.felix.configadmin ] - Cannot use configuration org.openhab.fs20 for [org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService, id=414, bundle=153/mvn:org.openhab.binding/org.openhab.binding.fs20/1.9.0-SNAPSHOT]: No visibility to configuration bound to file:/opt/openhab2/addons/org.openhab.binding.fs20-1.8.1.jar 2016-03-03 12:43:33.917 [INFO ] [b.core.service.AbstractActiveService] - FS20 Refresh Service has been started 2016-03-03 12:43:33.931 [INFO ] [b.core.service.AbstractActiveService] - FS20 Refresh Service has been shut down
This error
2016-03-03 12:43:33.913 [ERROR] [org.apache.felix.configadmin ] - Cannot use configuration org.openhab.fs20 for [org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService, id=414, bundle=153/mvn:org.openhab.binding/org.openhab.binding.fs20/1.9.0-SNAPSHOT]: No visibility to configuration bound to file:/opt/openhab2/addons/org.openhab.binding.fs20-1.8.1.jar
looks like you also have the features installed. Can you make sure that you have
the following features UNINSTALLED
- features for the bindings
- openhab-transport-cul
and the following features INSTALLED
- openhab-runtime-compat1x
- openhab-transport-serial
The other error
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Thread.java:744)[:1.8.0]
Caused by: gnu.io.NoSuchPortException
at
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273)[156:org.openhab.io.transport.serial:2.0.0.201603021555]
at
org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:236)[155:org.openhab.io.transport.cul:1.9.0.201603030213]
could be related to Replace nrjavaserial with RXTXcomm and https://github.com/openhab/openhab/issues/3257 and actual the root issue being https://github.com/NeuronRobotics/nrjavaserial/issues/60 Is it working with the old jars/features?
I’m trying to setup my homemade cul to switch some intertechno devices. Using openHAB 1.8.2. Unfortunately I get some errors:
2016-03-29 11:02:41.256 [DEBUG] [.o.io.transport.cul.CULManager] - Trying to open device serial:/dev/ttyUSB0 in mode SLOW_RF
2016-03-29 11:02:41.268 [DEBUG] [.o.io.transport.cul.CULManager] - Searching class for device type serial
2016-03-29 11:02:41.326 [DEBUG] [o.i.t.c.i.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/ttyUSB0
2016-03-29 11:02:41.593 [ERROR] [.o.b.i.i.CULIntertechnoBinding] - Can’t open CUL
org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException
at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:257) ~[na:na]
at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:152) ~[na:na]
at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:171) ~[bundlefile:na]
at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:88) ~[bundlefile:na]
at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:52) ~[bundlefile:na]
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.bindCULHandler(CULIntertechnoBinding.java:99) [bundlefile:na]
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.setNewDeviceName(CULIntertechnoBinding.java:92) [bundlefile:na]
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.updated(CULIntertechnoBinding.java:201) [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]
Caused by: gnu.io.NoSuchPortException: null
at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273) ~[na:na]
at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:236) ~[na:na]
… 9 common frames omitted
2016-03-29 11:02:41.618 [INFO ] [.service.AbstractActiveService] - CULIntertechno Refresh Service has been started
I added org.openhab.binding.intertechno-1.9.0-SNAPSHOT.jar and org.openhab.io.transport.cul-1.9.0-SNAPSHOT.jar in the addon folder and removed the 1.8.2 versions.
What is wrong?
See last response:
could be related to Replace nrjavaserial with RXTXcomm and https://github.com/openhab/openhab/issues/32573 and actual the root issue being https://github.com/NeuronRobotics/nrjavaserial/issues/60
Thanks for your reply, I allready read the response, but I thought that this error is related only to openHAB 2.0 and version 1.8 works. But it looks like I have exactly that problem as I utilize a raspberry version 2 with debian jessie. As I’m not a native java developer and I’m quite new to openHAB I don’t see an easy solution for my problem. Is it possible to change the referenced serial lib which to my understanding is the cause for the problem. To my understanding the standard java serial lib RXTX does not have that problemm and at the moment I don’t understand the reason for using the other lib. Maybe it has other advantages I don’t see.
Anyway, thanks for looking.
From the issue report https://github.com/NeuronRobotics/nrjavaserial/issues/60 it looks like one built a fixed library that you should be able to use and replace the used one
I think https://github.com/dennisausbremen was able to get the fix running, maybe he is able to provide the exact steps.
I followed the settings from https://github.com/dennisausbremen and have the same findings. I started with a fresh install of 2.0.0-SNAPSHOT and first installed the three jars in addon folder: did not work, same NullpointerException, then I removed culintertechno-binding-jar from addon folder and installed with feature:install: also works!
Thank you all.
After some time of running this configuration I would like to add some findings:
- it is still necessary to start a screen session with screen /dev/ttyUSB0 38400 to initialize the CUL correctly
- after several restarts of openhab for me it is necessary to hard reset the CUL by unplug and replug
So I think with the modified code we still have a problem, at least with installations on raspberry pi with debian jessie. Unfortunately …
edit 20.04.2016:
As of today I made a new effort: I used the SNAPSHOT online-build from today and only put org.openhab.io.transport.serial_3.12.0.a1.jar into the addon folder and moved my configuration into conf-folder. The jar is the build of the transport.serial jar against nrjavaserial 3.12.0 which fixed the issue with locks under debian jessie on a raspberry pi. For me it works out of the box. No more external serial port initialization with screen is needed.
Trying to test this too. But I can’t actually find openhab-runtime-compat1x
added those 1.9.0 snapshot jars but still getting locking file errors and cant seem to find the CUL433.
Tried with both OH1 and OH2
edit: trying to get that intertechno stuff working, if that matters
cheers
Yeah this change is unrelated to the serial issue, that is handled by someone else.
Hi,
I got my install on OH2 made by DennisausBremen, however in here only the “org.openhab.io.transport.serial_3.12.0.a1.jar” is in the .addon folder.
I’m using a Cul866 and it’s working with ELRO- and REV-Type devices (the later are real old ones, with hardcoded codes). My CUL-stick is in the first floor, the power-plugg(s) are in groundfloor, I do NOT see a limited range!
This is a bit off topic but I need some help. I own some really old REV switches, REV Typ 8462, with two switches for the code A-P and 1-16. Are these the same as yours? Can you tell what raw command you use to switch?
Which firmware version is your cul? I have some slightly younger REV switches that work properly, but not the above mentioned.
Thanks.
I can’t say if my REV Switches are of your type, however look into Link here for my findings.
Since I got my CUL only 4 weeks ago, it should be the actual Firmware (I’m in the Office, can’t tell by now)
My switches look like these. Interesting thing about your findings: In general original intertechno devices have fixed codes 0F on position 8 and 9. Not so in your findings. I will test a bit.
Funny, I can’t remember a Change to that rule while doing the tests on all Switches. Let me doublecheck (not sure if I can do it tonight). I’m only a human!
In which way are you testing those devices, using the Screen command made testing the sending from CUL to Switch a lot easier!
However, since this Topic is really OFFTOPIC we should discuss amongst us.
Everything was running well, until I did the update using the nigthly-build #345.
Now I get following Error:
20:58:54.554 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘REV_A’ received command OFF
20:58:54.569 [INFO ] [marthome.event.ItemStateChangedEvent] - REV_A changed from ON to OFF
20:58:54.575 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Exception during event dispatch [org.osgi.service.event.Event [topic=openhab/command/REV_A] | {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.culintertechno, component.name=org.openhab.binding.intertechno.binding, component.id=324, service.id=504, service.bundleid=193, service.scope=bundle} | Bundle(org.openhab.binding.intertechno_1.9.0.201606070111 [193])]
java.lang.NullPointerException
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.internalReceiveCommand(CULIntertechnoBinding.java:113)[193:org.openhab.binding.intertechno:1.9.0.201606070111]
at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97)[189:org.openhab.core.compat1x:2.0.0.201606060102]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:42)[189:org.openhab.core.compat1x:2.0.0.201606060102]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[3:org.apache.karaf.services.eventadmin:4.0.4]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[3:org.apache.karaf.services.eventadmin:4.0.4]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
I’m still using the “org.openhab.io.transport.serial_3.12.0.a1.jar” as an addon, which worked on the previous instal of OH2 Beta3
Magic selfrepair after Restart. Sorry
There still shouldn’t be a NullPointerException though. Do you think there should be an issue in github?