Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce an API for serial communication #4465

Closed
kaikreuzer opened this issue Oct 29, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@kaikreuzer
Copy link
Member

commented Oct 29, 2017

We so far do not have any way to allow ESH bindings access to serial ports. Within openHAB, RXTX is used, which is not an option for ESH due to its LGPL license, so any binding that uses serial
and which is developed on the openHAB side is automatically incompatible with ESH. Furthermore, RXTX is not maintained anymore and seems to have several issues, so a different implementation might be helpful.

Some discussion can be found here - let's follow up on that.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented Oct 29, 2017

And as pointed out, most of the other libs use exactly the same API and merely moved it to their own namespace in order to avoid any license/IP issues.

I'm pretty sure there is no license/IP issue here but it's more about them not being compliant to the API. Since afaik sun / oracle created such api/interfaces for others to implement not to restrict it.

Seeing is believing. The issue is that I cannot find any license information about javax.comm - and only a written license will give you any permission, otherwise the strict copyright laws are in place.
But as soda.dk includes the javax.comm APIs and is licensed under the EPL, this might be the safest way to get hold of it for ESH.

@maggu2810

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2017

As soda.dk serial's implementation that is using java.comm API is part of Kura already, shouldn't the Eclipse IP team already have had a look on this one?

@sjka

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2017

Sure, CQ 8156 (by Kura) even was PBing the original CQ 1330 (by OHF). As it was authored by IBM they put it under the EPL and into a org.eclipse.soda.dk.comm bundle.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented Nov 13, 2017

RXTX is used, which is not an option for ESH due to its LGPL license

FTR, as mentioned here: RXTX actually IS an option, since we have an approved CQ 9215 for nrjavaserial as a works-with dependency. Not wanting to judge whether the API itself is a good option or not, but it is the one which has been used extensively so far.

Another option that should be mentioned is OpenJDKs Device I/O. While it was specifically meant as a modern API for hardware access on SBCs, the project is almost dead and hardly anything has happened in the past 2 years, so it might not be a good pick either :-/

@aploese

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

You may have a look at https://github.com/aploese/spsw
Ready build jars are in the snapshot repo (https://oss.sonatype.org/content/repositories/snapshots)
Its OSGi ready...(Service interface and provider implementation)

@aploese

This comment has been minimized.

Copy link
Contributor

commented Dec 22, 2017

If there is an interest I could dual licence (LGPL and EPL) the SPSW api stuff.
Then there would be at least common ground to implement the provider.
The provider itself is forked from jssc, which is under LGPL and not maintained any more too.

For SPSW there is:

  • an interface SerialPortSocket
  • an log wrapper which logs all native port access for SerialPortSocket
  • a mock wrapper for testing
  • a (currently) basic Ser2Net remote port provider
  • logic to distinguish between soft and hard flow on arm and big/little endianess on misp (not tested)
    and said native provider with unit plenty of test from real use cases.

I tried to keep it simple, therefore there are no fancy eventhandlers, just plain Input|Output streams, which behave like the java.net.Socket streams.

I hope this helps

@aploese

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2018

OK,
the API is now EPL-2.0 with secondary license - If anyone cares, one can write a new provider under EPL-2.0 or write a wrapper around an existing implementation.
Junit tests skeletons are provided in the api.test package.

The native part (provider) is LGPL, because its derived from gnu.io/JSSC.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented Apr 9, 2018

A serial API has been introduced as a facade with #5313.

@kaikreuzer kaikreuzer closed this Apr 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.