[SOLVED] [Zwave, Zigbee, ...] RFC2217 remote serial port HowTo?

Honestly I don’t know with OH3. I tested it some time ago with OH2.5 and there it did not work (as PaperUI only offered the physical COM-Ports and would not allow any alternative entry for the Port). As it worked fine with a textual .things-file I kept this solution.

Unfortunately I am not happy with that. After a network interruption I have to restart the Z-Wave binding. Otherwise it won’t recover by itself.
The revocery was better with the previous solution I had with ser2net on a RPI (serving as “antenna”) and hub4com on my Windows OH server.
But now I anyhow changed again the setup and also run OH3 on the “Antenna”-RPI and connect to the items via the new Remote-OH-Binding (and no longer user RFC2217). The advantage with this new setup is that my Z-Wave networks can run through when I update the main OH instance and are immediately available after upgrade (no discovery, no initialization of devices etc.)

Yes, absolutely. That was also exactly my reason to use it. Especially as I need 3 ZWave antennas within my installation.

2 Likes

Many thanks Rafal,
happy to hear that. Even though I started this thread, I still have my remote serial
adaptors on a socat/ser2net combination after of some initial issues with rfc2217.

Because of the promising posts here I currently reconsider moving to rfc2217 while migration to openHAB3 (of course :wink: )

That’s very similar to my setup and mainly for the same reasons :wink:
Just additional Zigbee and Bluegiga (unused currently) and as said yet - with socat instead of the built-in rfc2217. It has been very stable for years! Admittedly, I dealt with some scripts to solve the re-connect in case the tcp connection got lost.

So from the stability perspective I could stay with socat. But rfc2217 would help me getting rid of some aditional scripts and systemd services and therefore slim down the setup :wink:

Therefore:
May I ask You too about your re-connect experiences when using rfc2217 ?

1 Like

Mmmh. That’s what I feared :frowning:

Good point! Maybe I should consider this too… :thinking:

Only drawback would be, that my “Antenna-Pi’s” no longer can run off a read-only filesystem…

Anyway: Thank’s for sharing your experiences! :+1:

2 Likes

Hmm, I guess I have not been “lucky” enough to experience enough disconnections over the 6 months to notice any issues. I blame my networking. On the other hand, clearly the rfc2217 experience @vossivossi had was much poorer than mine—I am sorry to hear. I suppose it all depends on other aspects of the set-up. :slight_smile:

1 Like

:rofl:

Fully agree. Same here … usually :wink:

But you know, bad things happen always at the worst time…
Means for my setup: “When I’m not available to fix it quickly”

So some sort of “auto-recovery-procedure” is needed…

1 Like

At least in the released version of OH3, yes, it does. I have just done that in the z-wave thing GUI.
For it to work, on the remote system where the z-wave interface is connected, just make sure you define everything correctly in the /etc/ser2net.conf file, as per post 31 above ([SOLVED] [Zwave, Zigbee, ...] RFC2217 remote serial port HowTo? - #31 by mvbergen)

Has anyone gotten this to work with Zigbee? I’m testing OH3 in a docker container in a VM on my server and while the ZWave binding works great connecting to rfc2217://192.168.0.5:3001, the Zigbee binding configured for rfc2217://192.168.0.5:3002 gives me this in the debug log. The box at 192.168.0.5 is a PC that currently has my OH2 installation (OH2 service stopped) and has ser2net running with this config and I have verified with netstat that both ports 3001 and 3002 are open and listening

3001:telnet:0:/dev/ttyUSB-ACM0:115200 8DATABITS NONE 1STOPBIT remctl
3002:telnet:0:/dev/ttyUSB0:57600 8DATABITS NONE 1STOPBIT remctl

Debug log:

2021-01-13 15:32:59.995 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - ZigBeeNetworkManager shutdown: networkState=OFFLINE
2021-01-13 15:32:59.996 [DEBUG] [atabase.ZigBeeNetworkDatabaseManager] - Data store: Deferred Write Time set to 0ms
2021-01-13 15:32:59.997 [DEBUG] [atabase.ZigBeeNetworkDatabaseManager] - Data store: Deferred Write Time set less than Max Deferred Write Time
2021-01-13 15:32:59.998 [DEBUG] [atabase.ZigBeeNetworkDatabaseManager] - Data store: Max Deferred Write Time set to 0ms
2021-01-13 15:32:59.999 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Network state is updated to SHUTDOWN
2021-01-13 15:33:00.000 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=SHUTDOWN
2021-01-13 15:33:00.000 [DEBUG] [atabase.ZigBeeNetworkDatabaseManager] - Data store: Shutdown
2021-01-13 15:33:00.000 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Shutdown
2021-01-13 15:33:00.001 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Shutdown frameHandler is null
2021-01-13 15:33:00.001 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction Manager: Shutdown
2021-01-13 15:33:00.004 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Broadcast: Queue shutdown
2021-01-13 15:33:00.004 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Multicast: Queue shutdown
2021-01-13 15:33:00.005 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee network [zigbee:coordinator_ember:40e943dd3b] closed.
2021-01-13 15:33:00.005 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_ember:40e943dd3b].
2021-01-13 15:33:00.005 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel 11
2021-01-13 15:33:00.009 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - PANID XXXX
2021-01-13 15:33:00.012 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - EPANID XXXX
2021-01-13 15:33:00.013 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key XXXX
2021-01-13 15:33:00.013 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key XXXX
2021-01-13 15:33:00.013 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Config: zigbee_initialise found, initializeNetwork=false
2021-01-13 15:33:00.013 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key String XXXX
2021-01-13 15:33:00.015 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network key final array XXXX
2021-01-13 15:33:00.015 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key String XXXX
2021-01-13 15:33:00.015 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link key final array XXXX
2021-01-13 15:33:00.016 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - Initializing ZigBee Ember serial bridge handler.
2021-01-13 15:33:00.016 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - ZigBee Ember Coordinator opening Port:'rfc2217://192.168.0.5:3002' PAN:XXXX, XXXX, Channel:11
2021-01-13 15:33:00.038 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - Ember end device poll timeout set to (169 * 2^9) = 86528 seconds
2021-01-13 15:33:00.040 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
2021-01-13 15:33:01.040 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
2021-01-13 15:33:01.041 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
2021-01-13 15:33:01.042 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Default: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=1, interTransactionDelay=50, maxRetries=2]
2021-01-13 15:33:01.042 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Broadcast: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=2, interTransactionDelay=4000, maxRetries=0]
2021-01-13 15:33:01.042 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Multicast: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=3, interTransactionDelay=1200, maxRetries=0]
2021-01-13 15:33:01.043 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - ZigBeeNetworkManager initialize: networkState=UNINITIALISED
2021-01-13 15:33:01.043 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Network state is updated to INITIALISING
2021-01-13 15:33:01.050 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Initialize with protocol ASH2.
2021-01-13 15:33:01.050 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Connecting to serial port [rfc2217://192.168.0.5:3002] at 57600 baud, flow control FLOWCONTROL_OUT_XONOFF.
2021-01-13 15:33:01.051 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - No communication ports found, cannot connect to [rfc2217://192.168.0.5:3002]
2021-01-13 15:33:01.051 [ERROR] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Unable to open serial port
2021-01-13 15:33:01.051 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Network state is updated to OFFLINE
2021-01-13 15:33:01.052 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=INITIALISING
2021-01-13 15:33:01.053 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=OFFLINE

Here’s my Zigbee coordinator thing config as well. I’ve matched everything but the port to match what they were in my OH2 config.

UID: zigbee:coordinator_ember:40e943dd3b
label: Ember EM35x Coordinator
thingTypeUID: zigbee:coordinator_ember
configuration:
  zigbee_port: rfc2217://192.168.0.5:3002
  zigbee_initialise: false
  zigbee_channel: 11
  zigbee_concentrator: 0
  zigbee_trustcentremode: TC_JOIN_SECURE
  zigbee_extendedpanid: XXXXXX
  zigbee_flowcontrol: 2
  zigbee_baud: 57600
  zigbee_panid: XXXXXX
  zigbee_powermode: 1
  zigbee_txpower: 0
  zigbee_networksize: 25
  zigbee_linkkey: XXXXXXX
  zigbee_childtimeout: 86400
  zigbee_networkkey: XXXXXX
  zigbee_meshupdateperiod: 86400

I have just done a couple of restarts of my Pi, which runs the ZStick and RFXCOM antennas, to see if and how rfc2217 ZWave recovers. I am pleased to say that in the current version (OH2.5_11) both ZWave and RFXCOM have recovered well. RFXCOM has always been rock-solid, so this is more of a confidence vote for ZWave over rfc2217. Log does not show ZWave losing the connection, but it shows the restart. RFXCOM shows both:

2021-01-23 17:14:38.370 [ERROR] [internal.handler.RFXComBridgeHandler] - Error occurred: End of stream
2021-01-23 17:15:25.093 [INFO ] [nternal.connector.RFXComTcpConnector] - Connecting to RFXCOM at openhab-relay:2002 over TCP/IP
2021-01-23 17:15:31.036 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2021-01-23 17:15:31.036 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.

Other than simulating the disconnections, I have not experienced any issues with RFC2217 for many months now.

1 Like

Can someone summarize the situation regarding OH3?

I am quite sure that restarting either the openhab machine as well as the ser2net machine causes a loss of connection between OH3 and a zwave stick. Am I correct?

My setup is so far:

  • OH 3.0.1 ReleaseBuild on a rpi4 running buster
  • Z-Wave Serial Controller configured to “rfc2217://remoteusb:3001” through the UI
  • ser2net on a rpi1 (hostname “remoteusb”) running buster with “3001:telnet:0:/dev/ttyACM0:115200 8DATABITS NONE 1STOPBIT remctl” in my /etc/ser2net.conf

Rebooting one of these machines leeds to a connection loss that I can only heal by clicking onto “Synchronize Network” in the OH3 UI.

Is there a workaround or did I mix some things up or miss a detail?

@curlyel Could you remove [SOLVED] from the title as there are obviously still todos regarding OH3?

@FrankR , you decided to post your question in a very old thread … certainly to reach out to others which have contributed/posted here and therefore - for sure - are interested in RFC2217-related stuff.

So you got the intended audience - perfectly fine with me :wink:

But you should have noticed that my initial questions had nothing to do with openHAB3 - and were answered/solved meanwhile.

So: It’s absolutely o.k. for me to proceed here with RFC2217 questions.

But if you feel the topics headline is not matching your issue, then it might be better opening a new thread instead and hoping for enough attention there to get it solved too.

You are right and I agree that the title is appropriate.

Thats what I did: Remote serial connection fails after rebooting OH3

According to the recent add of mDNS discovery for rfc2217 serial ports (see: Add ser2net mDNS USB serial discovery by wborn · Pull Request #2519 · openhab/openhab-core · GitHub), I decided to give it a new try :wink:

I’ve prepared a fresh Raspberry Pi with Pi OS Bullseye and the new version of ser2net which supports mDNS. My config is currently:

%YAML 1.1
---

define: &banner \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n

connection: &Zigbee
  accepter: telnet(rfc2217),tcp,2222
  connector: serialdev,
    /dev/zigbee,
    57600n81 local xonxoff
  options:
    mdns: true
    mdns-sysattrs: true

derived from my former ser2net setting in the old ser2net.conf:

10003:raw:0:/dev/zigbee:**57600** 8DATABITS NONE 1STOPBIT XONXOFF

Unfortunately, the Zigbee coordinator thing remains offline:

The tcp connection to the remote Pi with the Zigbee stick connected got established but it seems, that openHAB cannot “open” that remote serial port yet…

Has anybody yet a working setup with rfc2217-connected Zigbee coordinator? Preferably Ember based? If so, would you share your ser2net.yaml and openHAB thing configuration for it?

EDIT:
Just found this:

Some change in the Zigbee was needed to make it work with rfc2217:

image

Since this has been merged back in October, it’s not included in my 3.1.0-RELEASE setup…

So: Somebody out there who had tried it on 3.2 already?

AFAICT, the combination RFC 2217/openHAB Zigbee Binding 3.2.0 snapshot/Ember Coordinator does not work - for a detailed low level discussion see:

Workaround: use socat instead of RFC 2217, see step 12:

1 Like

On rasperry pis, I use ser2net and socat to bring a remote aeotech zwave stick serial to my rpi running openhab, I’ve been noticing that occasionally openhab crashes in the RTXPortMonitor thread from time to time. I think maybe socat is restarting occasionally and causing it. In reading through this thread I’m not clear if I should try RFC2217 to access a remote zwave stick or not?

The jvm crashes look like this:

Current thread (0x6cd27000):  JavaThread "RXTXPortMonitor(/dev/ttyNET0)" daemon [_thread_in_Java, id=11557, stack(0x61aaf000,0x61aff000)]

Stack: [0x61aaf000,0x61aff000],  sp=0x61afd960,  free space=314k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 6726 c2 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(J)J java.base@11.0.9.1 (181 bytes) @ 0xb3e4667c [0xb3e46250+0x0000042c]
j  java.util.concurrent.ThreadPoolExecutor.awaitTermination(JLjava/util/concurrent/TimeUnit;)Z+57 java.base@11.0.9.1
j  org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.shutdown()V+120
j  org.openhab.binding.zwave.internal.protocol.ZWaveController.shutdown()V+15
j  org.openhab.binding.zwave.handler.ZWaveControllerHandler.stopNetwork()V+110
j  org.openhab.binding.zwave.handler.ZWaveSerialHandler.onSerialPortError(Ljava/lang/String;)V+65
j  org.openhab.binding.zwave.handler.ZWaveSerialHandler$ZWaveReceiveThread.serialEvent(Lorg/openhab/core/io/transport/serial/SerialPortEvent;)V+17
j  org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(Lgnu/io/SerialPortEvent;)V+17
j  gnu.io.RXTXPort.sendEvent(IZ)Z+397
j  gnu.io.RXTXPort$MonitorThread.run()V+42
v  ~StubRoutines::call_stub
C  0x61afdd90
C  0x6cd27000


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000

Thanks.

There is a success story for RFC 2217/Z-Wave Binding:

But AFAICT there is no success story for RFC 2217/ZigBee Binding.

Thanks! I converted over to that and so far it seems to be working.
I did have to manually define the thing even in the new UI (OH 3.1).
If anyone has Zwave security make sure to grab the security key first before you delete the old device in the UI (if switching to a text file)
I’ll see how it goes…

Will rfc2217 also work for a network usb device server? for example
https://www.seh-technology.com/services/downloads/download-deviceserver/myutn-250.html
my OH3 is in a docker container. how can it be setup to see the network usb z stick?

It all depends on what the USB device server supports. It looks like the particular model you’ve linked to does not. It seems to depend on its own proprietary drivers for creating virtual serial ports to access the remote serial ports.

When using virtual serial ports for accessing remote devices, you add a device mapping for that port to the Docker container (similar to socat/ser2net).