Recompiling and testing openhab-core: guidance please

Development
21

I just tried connecting to my Dutch smartmeter over rfc2217 using the DSMR binding by @Hilbrand while also being connected to a Plugwise Stick on Ubuntu. In the end I got them both working at the same time. :slight_smile:

I used a .things file for configuring the rfc2217 connection for the DSMR Thing:

Bridge dsmr:dsmrBridge:smartmeter [serialPort="rfc2217://192.168.1.26:3000"] {
    Things:
        device_v5 dsmrV5Device [channel=-1]
        electricity_v5_0 electricityV5 [channel=0]
}

The UI wouldnā€™t allow me to enter a port because it only allows for selecting known serial ports. Adding them using gnu.io.rxtx.SerialPorts will probably not work because these rfc2217:// URL prefixes are an openHAB convention.

Another issue with these rfc2217 connections is that not all serial port operations properly work. For the DSMR binding it would throw an exception:

23:02:41.156 [DEBUG] [.device.connector.DSMRSerialConnector] - Port does not support requested port settings (invalid dsmr:portsettings parameter?): rfc2217://192.168.1.26:3000
org.eclipse.smarthome.io.transport.serial.UnsupportedCommOperationException: gnu.io.UnsupportedCommOperationException
	at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:157) ~[?:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.open(DSMRSerialConnector.java:158) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.open(DSMRSerialConnector.java:119) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRSerialAutoDevice.start(DSMRSerialAutoDevice.java:152) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRSerialAutoDevice.restart(DSMRSerialAutoDevice.java:162) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRDeviceRunnable.run(DSMRDeviceRunnable.java:82) [bundleFile:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: gnu.io.UnsupportedCommOperationException
	at gnu.io.rfc2217.TelnetSerialPort.enableReceiveThreshold(TelnetSerialPort.java:948) ~[?:?]
	at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:155) ~[?:?]
	... 6 more

After I commented those incompatible operations, and used the updated/recompiled binding no exceptions were thrown and the connection using rfc2217 with ser2net properly worked.

I see that the ZWave Binding by @chris is using the same operations that will throw exceptions when used with rfc2217 connections.

There are others too, see UnsupportedCommOperationException in this nrjavaserial TelnetSerialPort.java

So my conclusions are:

  • it should be possible to get physically connected devices and rfc2217 devices working at the same time
  • there are Paper UI limitations that currently make it difficult to use these rfc2217 connections and itā€™s probably best to configure them using .things files
  • itā€™s not guaranteed that all operations on normal serial ports also work on rfc2217 connections, thus they are currently not transparent or a drop in replacement for a normal serial port
3 Likes
22
3 Likes
23

Congratulations on having rfc2217 run with the DSMR binding. I would have wanted to see the same with ZWave, but I must agree with both of you that rfc2217 is not a transparent/drop-in replacement for a normal serial port.

Regrettably, I will have to leave this for others to resolveā€”but based on the comments from @chris, I assume this is unlikely to get looked at by OH developers. Unfortunately, this issue, combined with the locking-related abort traps when using the ZWave binding on FreeBSD is a blocker for my move towards OH 2 or 3ā€”having the ZWave stick on a remote machine, away from the server, is a must for my installation.

I would still be happy to occasionally test things if anyone needs that, please ping me.

Above all: thank you for your help. Much appreciated.

24

There are other ways to access a zwave controller over IP, so no need to give up. Do you have a post about your installation and why you require this?

1 Like
25

I have first tried with a locally socatā€™ed port. Unfortunately, that does not work, because the binding throws Abort traps under FreeBSD. I have gone to the lengths of debugging it down to nrjavaserial to eliminate the library as the source of the aborts. I found that nrjavaserial works fine as of 5.1.1+ (some issues got fixed). However, running OH 2.5 with the new version of the library still breaks the runtime.

I was hoping to just connect ZWave binding to the remote ser2net just like RFXCOM binding does it, but @chris has wisely explained that it would not be possible to make ZWave do that, as instead the ZWave binding must rely on the rest of OH for serial port functionality, with or without RFC2217. He also explained that very few users need the RFC2217 and so it is not going to happen. I am of the opinion that having a location remote from the server for any antenna-like devices is essential, but that is only my opinion, I suppose.

Since RFC2217 is essentially broken/incomplete in OpenHAB as of now, and since I cannot use ZWave over a socatā€™ed port on FreeBSD that gives me no other options that I could think of.

For completeness, ZWave is also not working on FreeBSD using a locally plugged-in ā€œrealā€ USB stick, see this long-running discussion, in which a good number of other users went through the same iterations as I did, eventually giving upā€”I just tried to debug it a bit further, I suppose. :slight_smile:

26

What devices do you have, what are the distances between them, and what materials are the walls/floors separating them?

OH runs very well on other distributions. Why not use something else?

27

Approx 40 ZWave switches, sockets and a couple of rollers. Walls are stone, approx 1.5m in thickness, mostly 19th century. ZWave works very well for me when the antenna is in the attic. I do not want my server to be there.

Because I like FreeBSD and I have substantial experience of it. I no longer want to run OH 1.8.3 on a Pi with a Linux. If I cannot run OH 2/3 on FreeBSD I would rather not use OH anymore.

28

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.