Testing help needed for CUL refactoring

OK.
Maybe my usage is different.
I did rename the .jar in the Addons folder to .jar.old. That way it shouldn’t be used.

I’m using only the “raw” commands, since I only have switches like Intertechno.

You can see whether its used or not by logging into karaf shell and submit bundle:list. Then you can see which serial binding is being used.

OK, using “bundle:list” I found that I’m still using the org.openhab.io.transport.serial_3.12.0.a1.jar".
Why is that, I did rename it to “org.openhab.io.transport.serial_3.12.0.a1.jar.old” and restarted several times.
Do I have to manualy remove it somehow?

However I did not remove anything from the distribution!

Sorry for the false statement before, that was lack of knowledge!:flushed:

karaf fetches all needed dependencies and puts them into an optimized folder structure. You can find it in the userdata/cache folder. That’s why OH2 needs some time to start for the first time.
As I don’t know how it is prioritized when OH2 finds two jars for the same function, I prefer to use the safe way and uninstall the original io.transport.serial from the distribution to be shure that org.openhab.io.transport.serial_3.12.0.a1.jar is being used.

Having done a complete new install (after deleting the whole openhab-folder) I tried to use the CUL-Stick again without the manually added “org.openhab.io.transport.serial_3.12.0.a1.jar”.
It works!
Binding installed via PaperUI is “binding-intertechno - 1.9.0.SNAPSHOT”.
Bundle:list shows following entries:

204 | Active   |  80 | 1.9.0.201607190111    | openHAB CULIntertechno Binding
205 | Active   |  80 | 1.9.0.201607190111    | openHAB CUL Transport Bundle
206 | Active   |  80 | 2.0.0.201606271614    | openHAB Serial Transport Bundle

I tried to use my CUL stick in a new setup according the OpenHAB 2 documentation. The docs emphasis to run OH as user “openhab”.
I tried that however the CUL-stick didn’t work, although I had made user “openhab” member of the dialout group.
Changing the to user to run OH to “root” resulted in a working CUL-stick.

Do I need to run as root?

same for me, it only works when i start openhab2 as root.
my setting is a clean openhab2 beta5 installation.
bindings used:

  • fs20, 1.9 SNAPSHOT
  • fht, 1.9 SNAPSHOT
  • cul transport 1.9 SNAPSHOT
  • serial transport (installed as openhab2 feature)

user openhab is added to dialout group.
moreover i added -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0 to my setenv-file without any success.

does anyone have a hint on this? is this a bug or just my unsufficient unix skills? :stuck_out_tongue:

[ERROR] [io.transport.cul.CULLifecycleManager] - Can’t open CUL
org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException
at org.openhab.io.transport.cul.internal.serial.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:100)

Caused by: gnu.io.NoSuchPortException
at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273)

Unexpected problem updating configuration org.openhab.fs20
java.lang.NullPointerException
at org.openhab.io.transport.cul.CULLifecycleListenerListenerRegisterer.open(CULLifecycleListenerListenerRegisterer.java:21)

This issue is solved, however only for the recent nigthly snapshots and not for the beta5 version . Sorry.

I’m using Openhabian and the build #677

Do you know the particular change that solved the issue?
To my mind there are only 3 commits to master since beta5:

Maybe this change ? The part where the cusom.properties is changed ?
Sadly applying that patch (possible as only configuration files are changed) to my current installation won’t work.

Nope, it was a change discussed in Here

ah i see, thanks for your info.
i’ll keep up with running as root until the next beta i.e. the final openhab2 is released.

back to topic:
with compatibility mode the 1.9 bindings work like a charm with openhab2.
i can confirm that FHT and FS20 are working in parallel with one CUL stick.
thanks for your effort @tarioch. If you need any assistance or further tests keep in touch.

I have a recent OH 2.1 SNAPSHOT installed. I use stick CULv3 (868) USB Stick with it. I have following bindings installed:

193 | Active   |  80 | 1.10.0.201702010211   | openHAB CULIntertechno Binding
194 | Active   |  80 | 1.10.0.201702010211   | openHAB CUL Transport Bundle
195 | Active   |  80 | 1.10.0.201702022206   | openHAB S300TH Binding'

Intertechno

Intertechno commands work perfectly fine. I did not have to start as root and use the apt-get installation on a raspberry. What I had to do is to add Java extra option for the serial ports:

pi@raspberrypi:~ $ cat /etc/default/openhab2 
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyACM1"

( In my setup ttyACM0 is a zwave stick and ttyACM1 is the CUL )

S300TH

But S300TH readings do not seem to work. So I have following questions:

  1. The S300TH binding was not available via Paper UI nor via feature list in karaf. I had to checkout the openhab1-addons repo and build it locally via maven. Why is this binding not available?

  2. When I use the screen command to put the CUL in listening mode (X21 command), I see the sensor readings of my 2 sensors ( ASH2200 ):

    111462450F
    0123524329
    111462450F
    0122524327
    1115624517
    012152432A

Also after setting the CUL io to package to debug I get following logs:

09:45:17.707 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: K1115924814
09:45:17.710 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
09:45:17.733 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 21  900
09:45:17.735 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 900
09:47:23.164 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: K011712462C
09:47:23.167 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
09:47:23.190 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 21  900
09:47:23.192 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 900
09:51:10.720 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: K111592480F
09:51:10.724 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
09:51:10.747 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 21  900
09:51:10.751 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 900

However, the S300TH binding seems not to be called. Do I need to configure something to get the S300TH binding added as listener to the CUL io add-on ?

my items:

Number ASH2200Temp2 "AS2200 (2) Temperatur [%.1f C]" 	<temperature>		{s300th="address=2;datapoint=TEMPERATURE"} 
Number ASH2200Temp1 "AS2200 (1) Temperatur [%.1f C]" 	<temperature>		{s300th="address=1;datapoint=TEMPERATURE"} 

Any help about the S300TH readings would be highly appreciated. Thx

OK, solved myself. My stupid error was to forget to configure the s300th binding. So in /etc/openhab2/services I added now a file called s300th.cfg with follwowing content:

device=serial:/dev/ttyACM1

Then then the binding registers itself on the already existing cul device and reacts on messages as expected :slight_smile:

However, one question stays… Why is the s300th binding not part of the official distribution, respectively indexed as add-on to be installed via paper ui!?

For this to be automatically installable, there needs to be a feature for it, it would be great if you could create a pull request similar to https://github.com/openhab/openhab1-addons/pull/3988/files for s300th.

Note that 1.x binding feature names must have a “1” appended, like here:

Hi,
I had a lot of problem getting my CUL to work. Solution was to add a line in /usr/share/openhab2/start.sh

echo "X21\n" > /dev/ttyUSB0

It seems like the init sequence in the cul code doesn’t work…

Hope this helps someone.

BTW, I’m running a standard OH2 release on Ubuntu 16.04

Regards,
/Martin

Hi, is there an update on a native FS20 binding for OH2?

FS20 does work.
Not working is FHT with nanoCUL

I mean a nativ binding for OH2, not 1.x compatibility.

No!