Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [iot-wg] OSGi EnOcean Driver Reference Implementation
Hello Kai.

On Jan 28, 2015, at 9:40 PM, Kai Kreuzer <kai@xxxxxxxxxxx> wrote:

Hi Marco,

Thanks a lot for your feedback!

So if here at Eclipse the only option for serial access is javax.comm + dkcomm, I wonder about the status of it.
Is it correct that the sources for both are in the Kura project in https://github.com/eclipse/kura/tree/develop/target-platform/org.eclipse.soda.dk.comm ?

A few questions about this:
1. I always thought that javax.comm originates from Sun, but the sources show an IBM copyright under EPL. How is that possible and is this the „true“ source of the API (whose JavaDoc is officially here: http://docs.oracle.com/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/package-summary.html)

I am not sure about this. javax.comm was defined using the JCP process.
I am wondering whether the initial reference came from IBM.

2. So the „soda“ project is archived and thus inactive and you took over the sources? Do you plan to maintain it in some way, e.g. fixing bugs that you find? Having to recompile things for uncommon serial port names is pretty annoying :-(

We pulled in the sources and validated the functionality on the open hardware platforms like Rasp and BBB.
We to not plan to maintain it beside very minor changes like the serial port names support.

3. Is the dkcomm bundle made available by Kura as a jar on some p2 or Maven repo? Or what would be the best way to get hold of javax.comm for the EnOcean base driver to compile against?

We do not publish the bundle in maven or p2 but the bundle is available in the Kura target platform.
After the target platform build you can find the bundle under the following path.
The native libraries are included in the same bundle.
kura/kura/target-definition/common/repository/plugins/org.eclipse.soda.dk.comm_1.2.1.jar

Regards.
-Marco



Best regards,
Kai


Am 28 Jan 2015 um 18:02 schrieb Carrer, Marco <marco.carrer@xxxxxxxxxxxx>:

Hello Kai.

For Kura, we are packing org.eclipse.soda.dk.comm as the default implementation for javax.comm.
As you pointed out, our choice on org.eclipse.soda.dk.comm was driven by the fact that RxTx is GPL licensed.

In our tests, we found javax.comm fairly stable but we did encounter few glitches.
 - We experienced a crash of the dkcomm native library when interfacing with 3g modems connected via USB. The crash was random and not easily reproducible.
 - In long running tests, we experienced a memory leak from the native library.
 - Support for non common serial port names (e.g. ttyACM, …) requires a code change in the native library. RxTx has an external properties file.

Both issues were not experienced when using the javax.comm implementation to RxTx.
Unfortunately, we did not go very far in debugging the dkcomm implementation.

The good news is that we found the two implementation to be quite compatible.

That’s what we know so far.

Regards.
-Marco







On Jan 26, 2015, at 5:27 PM, Kai Kreuzer <kai@xxxxxxxxxxx> wrote:

All,

As a follow-up on our discussion at EclipseCon Europe last year, I would like to inform you that I have received a code contribution (https://github.com/eclipse/smarthome/pull/155) for the reference implementation of OSGi RfC 199 (https://github.com/osgi/design/blob/master/rfcs/rfc0199/rfc-0199-EnOceanDeviceService.pdf?raw=true) implemented by Orange.

I think it is very nice to have one important home automation protocol implementation at Eclipse IoT this way. We will maintain it as a part of Eclipse SmartHome as it didn’t feel to be worth the overhead of an independent project.

There is just one concern that I still have before creating a CQ for the contribution: As EnOcean requires a USB dongle, the driver currently requires an RXTX bundle on the runtime. As RXTX is under LGPL, this is no option for Eclipse. What should I resort to? I see that Kura uses javax.comm as an API and org.eclipse.soda.dk.comm as an implementation. Is this the recommended way? Is this library stable and reliable? In this case I would probably have to ask Orange to change their code to use javax.comm instead of rxtx.

Any hints are welcome!

Thanks,
Kai

_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg

_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg

_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg

Back to the top