[discovery] RFC2217 Discovery Service #1511

bodiroga · 2020-06-03T18:06:30Z

After the awesome work done by @wborn in openhab/openhab-addons#7573 and now that many bindings support RFC2217 connections, I propose to add a RFC2217 Discovery Service for openhab-core, giving binding developers similar information to the one provided by org.openhab.core.config.discovery.usbserial.

As no standardized implementation exist for announcing RFC2217 ports, I have created a project called rfc2217-gateway that discovers some well known USB sticks and announces them using mDNS, with the _rfc2217._tpc.local service name. Here you have an example (Enocean USB stick) of the list of properties announced by the service:

{
  "MODEL_ID": "6001", 
  "MODEL": "EnOcean_USB_300_DB", 
  "MODEL_ENC": "EnOcean\\x20USB\\x20300\\x20DB", 
  "MODEL_DB": "FT232 Serial (UART) IC", 
  "VENDOR_ID": "0403", 
  "VENDOR": "Future Technology Devices International, Ltd",
  "VENDOR_ENC": "EnOcean\\x20GmbH", 
  "VENDOR_DB": "Future Technology Devices International, Ltd", 
  "SERIAL": "EnOcean_GmbH_EnOcean_USB_300_DB_FT3MXEB",
  "SERIAL_SHORT": "FT3MXEB"
}

Of course, this should be added to openHAB 3, as openHAB 2.5.x core is frozen.

Would something like this be of any interest for @openhab/core-maintainers? I could try to create the discovery package extending the mdns discovery package, but I may need some help 😄 Anyway, first I need to know if something like this could be accepted and merged.

Many thanks for your work and best regards,

Aitor

The text was updated successfully, but these errors were encountered:

wborn · 2020-06-13T10:06:10Z

I can imagine support being added to openHAB for some popular RFC2217 port discovery methods. Did you have a look at what protocols are used by other implementations that allow for discovering RFC2217 ports? Is this mDNS implementation already used by another implementation? If there's already another nice and commonly used method it may make sense to use that instead creating a new one.

bodiroga · 2020-06-22T20:33:27Z

Hi @wborn!

Many thanks for your answer and for your interest in the topic! 👍

Sadly, as far as I know, there is no announcement mechanism for RFC2217 ports, or at least I have not been able to find one. There was a small talk about the topic in the Eclipse Smarthome repository (eclipse-archived/smarthome#5560 (comment)), but the project mentioned by @gersilex was also started by me, so I think that it doesn't count. Python's pyserial library also has an example that does the same thing and it uses mDNS as the announcement protocol: https://pyserial.readthedocs.io/en/latest/examples.html#multi-port-tcp-ip-serial-bridge-rfc-2217

So... it seems that we are alone. But we can the first ones, can't we? 😉 As @kaikreuzer was also involved in the RFC2217 implementation discussion, it would be awesome if he could express his opinion here.

IMHO, this discovery mechanism can be very interesting for Dockerized environments, because we no longer depend on passing around /dev/tty* devices and we can also rely on TCP/IP.

Thank you for your support and best regards,

Aitor

wborn · 2020-06-22T22:09:34Z

Since everyone is already using ser2net it would be nice if it would also implement such a discovery mechanism out of the box. :-)

bodiroga · 2020-06-23T17:09:53Z

@wborn, I'm not sure what you mean, but I don't know of any discovery service implemented by ser2net. Have you read anything about it? 😕

wborn · 2020-09-14T17:47:14Z

Do you think it makes sense to also add support for a discovery protocol like this in ser2net @cminyard?

cminyard · 2020-09-14T20:11:22Z

Are you talking about a telnet discovery protocol, or an RFC2217 discovery protocol? If you have telnet, discovering RFC2217 is easy, doing discovery is built in to the telnet protocol.

However, if you want to do discovery, it really only makes sense on the client side. If the server has it it will always announce it, the client side can choose to enable and use it. Why would you want to discover it on the server side (ser2net)?

The gensio library that ser2net sits on has client code, and it can do this. It does not currently have a way to discover telnet protocol, but that would be pretty easy to add to the client side if you assume that the first thing you receive from a telnet connection is a telnet negotiation.

If you aren't using the gensio library, it might be nice for you to use. It can do all different sorts of connections (serial, tcp, sctp, udp, pty, stdio, etc.) and provides a common interface for them all. It has upper layer protocols for doing things like reliable deliver or serial ports, encryption (ssl), certificate/password based authentication.

wborn · 2020-09-15T12:55:11Z

Thanks for your reply @cminyard!

This is about clients discovering all the serial ports provided by servers over telnet streams in the local network. Such a discovery protocol would simplify setting up connections on the client side as users would no longer have to configure details such as IPs and ports.

openHAB is home automation software written in Java. A use case for openHAB users would be that they run openHAB on one machine and setup serial devices on another machine. E.g. because openHAB runs on a server and the machine with the serial device is located at a better location for receiving radio signals. Currently users would run ser2net on the other machine and have to manually configure openHAB to use the hostname/port with a particular technology.

By implementing such a discovery protocol openHAB could discover the ports within the local network. When the discovery protocol contains details such as the USB model/vendor ID, openHAB would also know what particular technology is provided by the port. Based on such discovery results, openHAB users would then only have to approve the discovery results to be able to use the serial device without any hostname/port/technology configuration.

Because openHAB is written in Java we also use a Java RFC2217 client implementation (see TelnetSerialPort) so switching to a library like gensio won't be easy. ;-)

cminyard · 2020-09-15T13:34:08Z

On Tue, Sep 15, 2020 at 05:55:28AM -0700, Wouter Born wrote: Thanks for your reply @cminyard! This is about clients discovering all the serial ports provided by servers over telnet streams in the local network. Such a discovery protocol would simplify setting up connections on the client side as users would no longer have to configure details such as IPs and ports. [openHAB](https://www.openhab.org/) is home automation software written in Java. A use case for openHAB users would be that they run openHAB on one machine and setup serial devices on another machine. E.g. because openHAB runs on a server and the machine with the serial device is located at a better location for receiving radio signals. Currently users would run ser2net on the other machine and have to manually configure openHAB to use the hostname/port with a particular technology. By implementing such a discovery protocol openHAB could discover the ports within the local network. When the discovery protocol contains details such as the USB model/vendor ID, openHAB would also know what particular technology is provided by the port. Based on such discovery results, openHAB users would then only have to approve the discovery results to be able to use the serial device without any hostname/server/technology configuration.

So you are saying you would IP and port scan for things implementing telnet? That seems like it would pick up things that you didn't want. And that would just tell you the port. How would you know what was on the other end of the serial port? Plus just opening the serial port could have undesirable side effects. This seems like a bad idea to me. It would seem better to have some sort of multicast that says "Here are the things available on my system" and use that for discovery. Or is that what you are talking about? If so, I am ok with adding something like that to ser2net. You need some generic way to discover what is on the other end of the serial port. And you need to be able to advertise things besides serial ports, I assume. Note that ser2net can do things besides serial ports now. For instance, if you had an application that controlled a GPIO line, you could use ser2net to make a telnet connection to that application. It can even do ptys for applications that expect a real device.

Because openHAB is written in Java we also use a Java RFC2217 client implementation (see [TelnetSerialPort](https://github.com/NeuronRobotics/nrjavaserial/blob/master/src/main/java/gnu/io/rfc2217/TelnetSerialPort.java#L107])) so switching to a library like gensio won't be easy. ;-)

Ah, ok. I'm familiar with the RFC2217 Java code. gensio has swig bindings, so you could create Java wrappers for it, but I'm not sure what that would involve. It only has Python bindings at the moment.

…

-corey

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1511 (comment)

wborn · 2020-09-15T14:01:57Z

It would seem better to have some
sort of multicast that says "Here are the things available on my
system" and use that for discovery. Or is that what you are talking
about?

Yes using some multicast protocol for this such as mDNS is exactly what the idea is and I fully agree we don't want to do any port scanning and opening ports because of all the side effects.

And you need to be able to advertise things besides serial ports, I assume.

Note that ser2net can do things besides serial ports now.

Being able to discover more than just serial ports would be even better. I'm sure some of our contributors in the future will be able to utilize the additional (discovery) features of ser2net as well. :-)

cminyard · 2020-09-15T15:15:00Z

On Tue, Sep 15, 2020 at 07:02:13AM -0700, Wouter Born wrote: > It would seem better to have some sort of multicast that says "Here are the things available on my system" and use that for discovery. Or is that what you are talking about? Yes using some multicast protocol for this such as [mDNS](https://en.wikipedia.org/wiki/Multicast_DNS) is exactly what the idea is and I fully agree we don't want to do any port scanning and opening ports because of all the side effects.

There's SSDP: https://tools.ietf.org/html/draft-cai-ssdp-v1-03 It's part of uPNP, though it was never standardized by the IETF.

…

-corey

wborn · 2020-09-15T16:29:56Z

openHAB already supports discovery using both mDNS and UPnP. Maybe @kaikreuzer (as jmdns/jupnp maintainer) is also able to provide some guidance of what might be a suitable protocol for discovering serial (RFC2217) and other network proxied devices nowadays?

kaikreuzer · 2020-09-18T21:51:23Z

I think mDNS (or to be more precise: DNS-SD) is the best choice for announcing services on a local network. openHAB itself uses it to announce itself as well.
If ser2net would implement this and announce clients that have a telnet port available to connect to, that would be great - openHAB could then easily discover them.

bodiroga · 2020-09-19T21:53:11Z

Thanks to all of you who are participating in this topic and especially to @cminyard for his appearance as the creator of ser2net. I would also choose to use the mDNS protocol to announce the availability of RFC2217 ports, using the _rfc2217._tpc.local service and sending something similar to what was indicated in my first message (MODEL_ID, VENDOR_ID, SERIAL,...) 👍

cminyard · 2020-10-08T00:53:07Z

On Sat, Sep 19, 2020 at 02:53:23PM -0700, Aitor Iturrioz wrote: Thanks to all of you who are participating in this topic and especially to @cminyard for his appearance as the creator of ser2net. I would also choose to use the mDNS protocol to announce the availability of RFC2217 ports, using the _rfc2217._tpc.local service and sending something similar to what was indicated in my first message (MODEL_ID, VENDOR_ID, SERIAL,...) 👍

I've started poking on this a little, and I'm having a hard time understanding why a user would care about the model number, vendor, etc. of the serial port device. That sort of stuff can be added, I suppose, but what would a user do with it? And just about all of it is irrelevant for non-USB/non-PCI serial ports. For those it would be completely empty. I'd also rather not use rfc2217 for the name. What if the user wants a raw port? What if it's a connection to something that's not a serial port? rfc2217 can be in some sort of capability field, but what you are really connecting to is some sort of byte stream. Really, what the user cares about is what is on the other end of the serial port. Like a connection to an alarm, some sensor, etc. with the particular type of device and a meaningful name. Maybe some port settings (rfc2217/telnet/raw, speed, flow control, etc.). And maybe current state (though mDNS doesn't seem to be used for dynamic information). For instance, in a racked system, you could provide the rack number/shelf/slot and server name for a serial port. Now that would be useful. Or in an alarm system, you could name the sensors reasonable names (front_door, back_door, side_window) and easily discover them. Even if you changed hardware, as long as you kept the names the same everything would work. So can you explain why this is needed? I don't want to write a bunch of code to extract all this from sysfs and the various id libraries if it's not going to be useful. I am going to add the other stuff, that way I can add the capability to gensiot for making connections without having to know the port number.

…

-corey

wborn · 2020-10-10T14:56:01Z

That sort of stuff can be added, I suppose, but what would a user do with it?

Based on the model number, vendor, etc. of a device, our code checks if it can add an automatic discovery result for a particular technology. The result will show up in an "Inbox" and then to use it users only need to approve it.

And just about all of it is irrelevant for non-USB/non-PCI serial ports. For those it would be completely empty.

That should be fine too. We can still use such results to populate a list of available serial ports when a user manually adds a device.

rfc2217 can be in some sort of capability field

Sounds good to me. As long as the information is available in some way we should be able to use it.

For instance, in a racked system, you could provide the rack number/shelf/slot and server name for a serial port. Now that would be useful.

Yes that would be useful too. We can use that information when setting a label for the discovery result so the device can be more easily identified by the user. I guess that info will be based on some details in a configuration file?

So can you explain why this is needed?

We already have a mechanism for discovering devices based on sysfs on the system openHAB itself is running on. It provides the information in this UsbSerialDeviceInformation class to discovery participants. It's for instance used to discover an EnOcean USB300 in this EnOceanUsbSerialDiscoveryParticipant class. So that kind of information would be really useful.

cminyard · 2020-10-17T02:44:08Z

On Sat, Oct 10, 2020 at 07:56:13AM -0700, Wouter Born wrote: > That sort of stuff can be added, I suppose, but what would a user do with it? Based on the model number, vendor, etc. of a device, our code checks if it can add an automatic discovery result for a particular technology. The result will show up in an "Inbox" and then to use it users only need to approve it.

I have finished adding the basic mDNS support to gensio and ser2net. It's a lot more convenient than having to remember the port numbers and such. I've added a utility to gensio that dumps all the mDNS information it finds, or lets you search using regex or globs. But anyway, I started looking at all the information you requested, and it's not obvious to me where to obtain all that information. I can see some of the fields in sysfs in the USB directories, but: It's not altogether clear how to get from a serial port to the USB directory. I could figure it out, but if you have any helpful pointers... All the information you requested is not there. There's more with lsusb, but I assume that is looking up information in a database. Do you know how ser2net is supposed to find all that information? You were looking for something like: { "MODEL_ID": "6001", "MODEL": "EnOcean_USB_300_DB", "MODEL_ENC": "EnOcean\\x20USB\\x20300\\x20DB", "MODEL_DB": "FT232 Serial (UART) IC", "VENDOR_ID": "0403", "VENDOR": "Future Technology Devices International, Ltd", "VENDOR_ENC": "EnOcean\\x20GmbH", "VENDOR_DB": "Future Technology Devices International, Ltd", "SERIAL": "EnOcean_GmbH_EnOcean_USB_300_DB_FT3MXEB", "SERIAL_SHORT": "FT3MXEB" } I can find the model id, vendor id,and short serial in sysfs, and I assume those are decoded by lsusb into model and vendor and serial. I don't know where to find anything else, and I'm not too keen on calling lsusb or referencing an external database in ser2net.

…

-corey

wborn · 2020-10-18T10:40:22Z

That sounds like very good progress @cminyard ! :-)

I had a look at how we currently obtain all this info using sysfs.

The process itself is actually pretty well documented in the SysfsUsbSerialScanner that we use for obtaining the information from the local system.

So I had a look at the sysfs files for a USB stick connected as ttyUSB0 on my Ubuntu 20.04 desktop.

Following the symlink you would end up at:

$ readlink -f /sys/class/tty/ttyUSB0
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/ttyUSB0/tty/ttyUSB0

After adding some more logging to the SysfsUsbSerialScanner I saw it was reading these details from the following files:

/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/idVendor
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/idProduct
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/serial
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/manufacturer
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/product
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/bInterfaceNumber
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/interface

cminyard · 2020-10-18T13:36:02Z

On Sun, Oct 18, 2020 at 03:40:35AM -0700, Wouter Born wrote: That sounds like very good progress @cminyard ! :-) I had a look at how we currently obtain all this info using sysfs. The process itself is actually pretty well documented in the [SysfsUsbSerialScanner](https://github.com/openhab/openhab-core/blob/3d88e919529a05e1dce5bf483f0a12c60b91aa4d/bundles/org.openhab.core.config.discovery.usbserial.linuxsysfs/src/main/java/org/openhab/core/config/discovery/usbserial/linuxsysfs/internal/SysfsUsbSerialScanner.java#L36-L56) that we use for obtaining the information from the local system.

Ok, there are things in your original list that are not in the sysfs; I will send what I can get. Any preferences as to txt names? I will add a "devicetype=serialusb" so other things can be added later and so you can tell if it's that or some other type of serial port.

…

-corey

So I had a look at the sysfs files for a USB stick connected as ttyUSB0 on my Ubuntu 20.04 desktop. Following the symlink you would end up at: ``` $ readlink -f /sys/class/tty/ttyUSB0 /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/ttyUSB0/tty/ttyUSB0 ``` After adding some more logging to the SysfsUsbSerialScanner I saw it was reading these details from the following files: ``` /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/idVendor /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/idProduct /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/serial /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/manufacturer /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/product /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/bInterfaceNumber /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/interface ``` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1511 (comment)

wborn · 2020-10-18T14:17:27Z

Ok, there are things in your original list that are not in the
sysfs; I will send what I can get. Any preferences as to txt names?

The original list was provided by @bodiroga. Perhaps he can tell how this data was obtained/generated? It looks like it is part of a data structure within that rfc2217-gateway implementation.

The sysfs details would be enough for discovery and we might be able to rework our existing sysfs discovery mechanism such that it becomes possible to use the same logic for discovering both local and remote ports. As long as the naming is clear and can be related to the sysfs values it should be fine.

I will add a "devicetype=serialusb" so other things can be added later
and so you can tell if it's that or some other type of serial port.

Sounds good to me!

cminyard · 2020-10-23T14:24:33Z

On Sun, Oct 18, 2020 at 07:17:40AM -0700, Wouter Born wrote: > Ok, there are things in your original list that are not in the > sysfs; I will send what I can get. Any preferences as to txt names? The original list was provided by @bodiroga. Perhaps he can tell how this data was obtained/generated? It looks like it is part of a data structure within that [rfc2217-gateway implementation](https://github.com/bodiroga/rfc2217-gateway/tree/master/src/gateway_devices).

Ok, these are all in at the end of the master git tree for gensio and ser2net. I haven't done a release yet with all this in, but you can try it out.

…

-corey

The sysfs details would be enough for discovery and we might be able to rework our existing sysfs discovery mechanism such that it becomes possible to use the same logic for discovering both local and remote ports. As long as the naming is clear and can be related to the sysfs values it should be fine. > I will add a "devicetype=serialusb" so other things can be added later > and so you can tell if it's that or some other type of serial port. Sounds good to me! -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1511 (comment)

wborn · 2020-10-25T14:57:58Z

Many thanks for your efforts @cminyard! The docs look good and with some trial and error I was even able to build both gensio and ser2net in a Debian 10 Docker container. I will give it a test to see if my build efforts were successful. :-)

It failed to compile gensio on Debian 10 when libopenipmi-dev was installed. Is that a known issue?

  CC       gensio_ll_ipmisol.lo
gensio_ll_ipmisol.c: In function 'sol_disable':
gensio_ll_ipmisol.c:1217:2: warning: implicit declaration of function 'ipmi_sol_force_close_wsend'; did you mean 'ipmi_sol_force_close'? [-Wimplicit-function-declaration]
  ipmi_sol_force_close_wsend(solll->sol, 0);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
  ipmi_sol_force_close
gensio_ll_ipmisol.c:1218:13: error: 'ipmi_con_t' {aka 'struct ipmi_con_s'} has no member named 'disable'
  solll->ipmi->disable(solll->ipmi);
             ^~
make[2]: *** [Makefile:599: gensio_ll_ipmisol.lo] Error 1
make[2]: Leaving directory '/root/gensio/lib'
make[1]: *** [Makefile:449: all-recursive] Error 1
make[1]: Leaving directory '/root/gensio'
make: *** [Makefile:381: all] Error 2

After removing it the build did succeed. Maybe I need to install something more/else for that.

cminyard · 2020-10-25T15:29:12Z

On Sun, Oct 25, 2020 at 07:58:11AM -0700, Wouter Born wrote: Many thanks for your efforts @cminyard! The docs look good and with some trial and error I was even able to build both gensio and ser2net in a Debian 10 Docker container. I will give it a test to see if my build efforts were successful. :-)

I'm looking forward to the results. Even without the stuff you are doing, it's really nice to not have to worry about enabling all the proper things when using ser2net and connection with the gensio tools. It just works, which is really nice.

It failed to compile gensio on Debian 10 when `libopenipmi-dev` installed. I that a known issue?

Yes, you need the newest version of openipmi to everything to work right. I could make it compile with backwards compatability, but I couldn't make it work, so it's better for it to not compile. Thanks,

…

-corey

``` CC gensio_ll_ipmisol.lo gensio_ll_ipmisol.c: In function 'sol_disable': gensio_ll_ipmisol.c:1217:2: warning: implicit declaration of function 'ipmi_sol_force_close_wsend'; did you mean 'ipmi_sol_force_close'? [-Wimplicit-function-declaration] ipmi_sol_force_close_wsend(solll->sol, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~ ipmi_sol_force_close gensio_ll_ipmisol.c:1218:13: error: 'ipmi_con_t' {aka 'struct ipmi_con_s'} has no member named 'disable' solll->ipmi->disable(solll->ipmi); ^~ make[2]: *** [Makefile:599: gensio_ll_ipmisol.lo] Error 1 make[2]: Leaving directory '/root/gensio/lib' make[1]: *** [Makefile:449: all-recursive] Error 1 make[1]: Leaving directory '/root/gensio' make: *** [Makefile:381: all] Error 2 ``` After removing it the build did succeed. Maybe I need to install something more/else for that. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1511 (comment)

bodiroga · 2020-10-25T16:52:05Z

Amazing work @cminyard, thank you very much!

The original list was provided by @bodiroga. Perhaps he can tell how this data was obtained/generated? It looks like it is part of a data structure within that rfc2217-gateway implementation.

All the information is collected by the pyudev module and the predefined values that you see in https://github.com/bodiroga/rfc2217-gateway/tree/master/src/gateway_devices are just to check which device type has been discovered, in case one device needs to read more specific information (the Home ID of the Z-Wave network, for example). So, in my case, the key is the UDEV service.

wborn · 2020-10-27T00:13:48Z

I did some testing with my own build and I was still able to make rfc2217 connections. I also had a look at the mdns configuration and it is nice that there is a lot that can be configured! But for some reason my build has issues to start the mdns @cminyard.

When I launch ser2net it logs:
Unable to start mdns: Out of memory

Do you know what might be causing this? It could also be due to that I run it in a Docker container or I am missing some kind of package. Does it need the Avahi daemon to be running? I tried that but it doesn't help.

cminyard · 2020-10-27T02:04:55Z

On Mon, Oct 26, 2020 at 05:14:01PM -0700, Wouter Born wrote: It did some testing with my own build and I was still able to make rfc2217 connections. I also had a look at the mdns configuration and it is nice that there is a lot that can be configured!

Indeed, probably too much! :-)

But for some reason my build has issues to start the mdns @cminyard. When I launch ser2net it logs: `Unable to start mdns: Out of memory` Do you know what might be causing this? It could also be due to that I run it in a Docker container or I am missing some kind of package. Does it need the Avahi daemon to be running? I tried that but it doesn't help.

Hmm, I have no idea. It's supposed to be configured so that it will come up even if avahi is not running, but it will have to have avahi running to actually do anything. I'm assuming that this is due to avahi_client_new() failing, but I neglected to add a debug log for the error code if that fails. In the function gensio_alloc_mdns, you can see that the last parameter to avahi_client_new() is a NULL. I should pass in a pointer to an integers. I just pushed up a change to gensio to generate a log. You can run: ser2net -d -l -l -c <config file> and it will send logs to stderr; hopefully that will give some more information.

…

-corey

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1511 (comment)

wborn · 2020-10-27T22:54:16Z

hopefully that will give some more information.

I recompiled the code but unfortunately it didn't give any more info. But I think it was some kind of Docker related issue because after I setup a regular Debian 10 VM it does work as expected. :-)

This configuration worked nicely to setup a FTDI stick:

%YAML 1.1
---
connection: &con01
  accepter: telnet(rfc2217),tcp,2222
  connector: serialdev,/dev/ttyUSB0
  options:
    mdns: true
    mdns-sysattrs: true
    mdns-name: mydevicename

After that I was able to query all the details using mDNS:

$ avahi-browse --ignore-local --resolve --terminate _iostream._tcp
+  wlan0 IPv4 my-device-name                                _iostream._tcp       local
=  wlan0 IPv4 my-device-name                                _iostream._tcp       local
   hostname = [debian.local]
   address = [192.168.1.226]
   port = [2222]
   txt = ["product=FT232R USB UART" "manufacturer=FTDI" "serial=XXXXXXXX" "idVendor=0403" "idProduct=6001" "interface=FT232R USB UART" "bInterfaceNumber=00" "devicetype=serialusb" "gensiostack=telnet(rfc2217),tcp" "provider=ser2net"]

So many thanks for helping us @cminyard! 👍

Now we only have to add some Java code for this and hope all the distros quickly update to this version when it is released. :-)

* Add support for using multiple UsbSerialDiscovery services * Add Ser2NetUsbSerialDiscovery that can use mDNS to discover ser2net RFC2217 serial ports * Use discovered USB ports in SerialConfigOptionProvider mDNS discovery is supported in ser2net 4.3.0 and newer. E.g. you can install a ser2net version that provides this using APT in Ubuntu 21.04 and Debian 11. Example ser2net YAML configuration that allows a serial port to be discovered using mDNS discovery: %YAML 1.1 --- connection: &con01 accepter: telnet(rfc2217),tcp,2222 connector: serialdev,/dev/ttyUSB0 options: mdns: true mdns-sysattrs: true mdns-name: devicename Closes openhab#1511 Signed-off-by: Wouter Born <[email protected]>

* Add ser2net mDNS USB serial discovery * Add support for using multiple UsbSerialDiscovery services * Add Ser2NetUsbSerialDiscovery that can use mDNS to discover ser2net RFC2217 serial ports * Use discovered USB ports in SerialConfigOptionProvider mDNS discovery is supported in ser2net 4.3.0 and newer. E.g. you can install a ser2net version that provides this using APT in Ubuntu 21.04 and Debian 11. Example ser2net YAML configuration that allows a serial port to be discovered using mDNS discovery: %YAML 1.1 --- connection: &con01 accepter: telnet(rfc2217),tcp,2222 connector: serialdev,/dev/ttyUSB0 options: mdns: true mdns-sysattrs: true mdns-name: devicename Closes #1511 Signed-off-by: Wouter Born <[email protected]>

williamblair333 · 2022-09-19T13:29:27Z

hopefully that will give some more information.

I recompiled the code but unfortunately it didn't give any more info. But I think it was some kind of Docker related issue because after I setup a regular Debian 10 VM it does work as expected. :-)

This configuration worked nicely to setup a FTDI stick:
%YAML 1.1
---
connection: &con01
  accepter: telnet(rfc2217),tcp,2222
  connector: serialdev,/dev/ttyUSB0
  options:
    mdns: true
    mdns-sysattrs: true
    mdns-name: mydevicename
After that I was able to query all the details using mDNS:
$ avahi-browse --ignore-local --resolve --terminate _iostream._tcp
+  wlan0 IPv4 my-device-name                                _iostream._tcp       local
=  wlan0 IPv4 my-device-name                                _iostream._tcp       local
   hostname = [debian.local]
   address = [192.168.1.226]
   port = [2222]
   txt = ["product=FT232R USB UART" "manufacturer=FTDI" "serial=XXXXXXXX" "idVendor=0403" "idProduct=6001" "interface=FT232R USB UART" "bInterfaceNumber=00" "devicetype=serialusb" "gensiostack=telnet(rfc2217),tcp" "provider=ser2net"]
So many thanks for helping us @cminyard! 👍

Now we only have to add some Java code for this and hope all the distros quickly update to this version when it is released. :-)

Did anyone find a workaround so that ser2net will run in a Docker container?

edit: I think i have it working after I went back and re-read this page and another page... I'll post a github repo of how I set it up after testing. edit again.. I think it's working now after udev is setup: https://github.com/williamblair333/ser2net

cminyard · 2022-09-20T01:30:28Z

On Mon, Sep 19, 2022 at 06:29:38AM -0700, William Blair wrote: > > hopefully that will give some more information. > > I recompiled the code but unfortunately it didn't give any more info. But I think it was some kind of Docker related issue because after I setup a regular Debian 10 VM it does work as expected. :-) > > This configuration worked nicely to setup a FTDI stick: > > ```yaml > %YAML 1.1 > --- > connection: &con01 > accepter: telnet(rfc2217),tcp,2222 > connector: serialdev,/dev/ttyUSB0 > options: > mdns: true > mdns-sysattrs: true > mdns-name: mydevicename > ``` > > After that I was able to query all the details using mDNS: > > ```shell > $ avahi-browse --ignore-local --resolve --terminate _iostream._tcp > + wlan0 IPv4 my-device-name _iostream._tcp local > = wlan0 IPv4 my-device-name _iostream._tcp local > hostname = [debian.local] > address = [192.168.1.226] > port = [2222] > txt = ["product=FT232R USB UART" "manufacturer=FTDI" "serial=XXXXXXXX" "idVendor=0403" "idProduct=6001" "interface=FT232R USB UART" "bInterfaceNumber=00" "devicetype=serialusb" "gensiostack=telnet(rfc2217),tcp" "provider=ser2net"] > ``` > > So many thanks for helping us @cminyard! 👍 > > Now we only have to add some Java code for this and hope all the distros quickly update to this version when it is released. :-) Did anyone find a workaround so that ser2net will run in a Docker container?

You can give https://github.com/jippi/docker-ser2net a try.

* Add ser2net mDNS USB serial discovery * Add support for using multiple UsbSerialDiscovery services * Add Ser2NetUsbSerialDiscovery that can use mDNS to discover ser2net RFC2217 serial ports * Use discovered USB ports in SerialConfigOptionProvider mDNS discovery is supported in ser2net 4.3.0 and newer. E.g. you can install a ser2net version that provides this using APT in Ubuntu 21.04 and Debian 11. Example ser2net YAML configuration that allows a serial port to be discovered using mDNS discovery: %YAML 1.1 --- connection: &con01 accepter: telnet(rfc2217),tcp,2222 connector: serialdev,/dev/ttyUSB0 options: mdns: true mdns-sysattrs: true mdns-name: devicename Closes openhab#1511 Signed-off-by: Wouter Born <[email protected]> GitOrigin-RevId: 917e268

bodiroga mentioned this issue Aug 22, 2020

Add RFC2217 discovery using mDNS openhab/org.openhab.binding.zwave#1388

Open

wborn mentioned this issue Oct 11, 2021

Add ser2net mDNS USB serial discovery #2519

Merged

cweitkamp closed this as completed in #2519 Nov 12, 2021

Remarknl mentioned this issue Jan 11, 2022

Unable to start mdns: Out of memory cminyard/ser2net#63

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[discovery] RFC2217 Discovery Service #1511

[discovery] RFC2217 Discovery Service #1511

bodiroga commented Jun 3, 2020

wborn commented Jun 13, 2020

bodiroga commented Jun 22, 2020

wborn commented Jun 22, 2020

bodiroga commented Jun 23, 2020

wborn commented Sep 14, 2020 •

edited

Loading

cminyard commented Sep 14, 2020

wborn commented Sep 15, 2020 •

edited

Loading

cminyard commented Sep 15, 2020 via email

wborn commented Sep 15, 2020

cminyard commented Sep 15, 2020 via email

wborn commented Sep 15, 2020

kaikreuzer commented Sep 18, 2020

bodiroga commented Sep 19, 2020

cminyard commented Oct 8, 2020 via email

wborn commented Oct 10, 2020

cminyard commented Oct 17, 2020 via email

wborn commented Oct 18, 2020

cminyard commented Oct 18, 2020 via email

wborn commented Oct 18, 2020

cminyard commented Oct 23, 2020 via email

wborn commented Oct 25, 2020 •

edited

Loading

cminyard commented Oct 25, 2020 via email

bodiroga commented Oct 25, 2020

wborn commented Oct 27, 2020 •

edited

Loading

cminyard commented Oct 27, 2020 via email

wborn commented Oct 27, 2020 •

edited

Loading

williamblair333 commented Sep 19, 2022 •

edited

Loading

cminyard commented Sep 20, 2022 via email

[discovery] RFC2217 Discovery Service #1511

[discovery] RFC2217 Discovery Service #1511

Comments

bodiroga commented Jun 3, 2020

wborn commented Jun 13, 2020

bodiroga commented Jun 22, 2020

wborn commented Jun 22, 2020

bodiroga commented Jun 23, 2020

wborn commented Sep 14, 2020 • edited Loading

cminyard commented Sep 14, 2020

wborn commented Sep 15, 2020 • edited Loading

cminyard commented Sep 15, 2020 via email

wborn commented Sep 15, 2020

cminyard commented Sep 15, 2020 via email

wborn commented Sep 15, 2020

kaikreuzer commented Sep 18, 2020

bodiroga commented Sep 19, 2020

cminyard commented Oct 8, 2020 via email

wborn commented Oct 10, 2020

cminyard commented Oct 17, 2020 via email

wborn commented Oct 18, 2020

cminyard commented Oct 18, 2020 via email

wborn commented Oct 18, 2020

cminyard commented Oct 23, 2020 via email

wborn commented Oct 25, 2020 • edited Loading

cminyard commented Oct 25, 2020 via email

bodiroga commented Oct 25, 2020

wborn commented Oct 27, 2020 • edited Loading

cminyard commented Oct 27, 2020 via email

wborn commented Oct 27, 2020 • edited Loading

williamblair333 commented Sep 19, 2022 • edited Loading

cminyard commented Sep 20, 2022 via email

wborn commented Sep 14, 2020 •

edited

Loading

wborn commented Sep 15, 2020 •

edited

Loading

wborn commented Oct 25, 2020 •

edited

Loading

wborn commented Oct 27, 2020 •

edited

Loading

wborn commented Oct 27, 2020 •

edited

Loading

williamblair333 commented Sep 19, 2022 •

edited

Loading