Refactor NetworkManager about zigbee4java HOT 6 CLOSED

I totally agree. In the long term it would be great if the current API project and jar could be split in:

• an API project with no implementation
• an implementation which is dongle independent
• a common dongle interface API
• different dongle implementations of the dongle API

We want to integrate zigbee4osgi in the Eclipse Kura project http://www.eclipse.org/kura/.
Kura runs in an OSGi framework and the above separation is very common in OSGi.

from zigbee4java.

Interesting. I'm working on eclipse SmartHome which is also osgi.

Generally I'm aligned with your thinking - maybe some room for small change but not when I'm typing on a phone! :)

from zigbee4java.

For your information this project is forked from zb4osgi project which might already provide what you need:

http://zb4osgi.aaloa.org/

from zigbee4java.

@tlaukkan, I know but that project in not very active and it's unlikely that the bugs and improvements of zigbee4java will be merged in zb4osgi. They use SVN so collaboration is more difficult.
For the same reason zb4osgi could be used by Eclipse SmartHome but it's not.
There is no problem repackaging (monolithically) zigbee4java in an OSGi bundle or plugin.
Indeed you could also slightly change your pom.xml to generate a jar file whose MANIFEST contains the necessary OSGi headers, this would be simple, so that it can be immediately consumed by an OSGi framework

from zigbee4java.

@cdjackson I don't think ZDO_BIND_REQ is strictly tied to the TI ZNP protocol:

ZDO_BIND_REQ(ZToolAddress16 nwkDst,
ZToolAddress64 ieeeSrc, int epSrc,
DoubleByte cluster, int addressingMode,
ZToolAddress64 ieeeDst, int epDst) {

We could just remove references to ZTool and it would become the container for the parameters of the Bind_req Command (2.4.3.2.2 of the spec). On top of that if you have a class for the request's parameters you can keep these are around (queued), for example when directed to sleeping end devices.

However I agree that the TI ZNP API should be kept internal and should not "leak" around.
In my opinion we should create new classes, for example ZdoBindRequest, and refactor the NetworkManager API to only expose these. A first step would be to create the Zdo interface accordingly to the ZigBee spec.

Another important thing is the configuration of the NetworkManager. For example:
setZigBeeNodeMode() should be changed to setLogicalDeviceType().
setZigBeeNetwork(byte ch, short panId) should be split in setPanId() and setChannelMask(). Internally these values should be initialized accordingly to the spec (random PAN ID) and channel mask as described by the profile.

The security interface is totally missing. We will end up with a lot of getters and setters.
Sticking to the names as spelled in the spec (where it does not collides with the Java name conventions, for example the '_') would be a plus (but less friendly).

For porting to a different module/dongle we need to design a Driver interface and pass an instance to the NetworkManager (instead of passing a ZigBeePort). Finding the interface requires studying the existing protocols, like the TI ZNP, Freescale ZTC (used by the Jemma project), Telegesis, Silabs/Ember and getting their intersection. I expect that the Driver interface implements many of the interfaces of the NetworkManager so that many calls to the NetworkManager (like the ZdoBindRequest above) are simply delegated to the Driver.

While writing this I wonder what the role of the NetworkManager is. If it does not do anything useful over the Driver we could just drop it.

This is a lot of work. Is there any roadmap available for ZB4J?

from zigbee4java.

You can now implement support for other hardware by implementing ZigBeeDongle interface. This is only supported with experimental SimpleZigBeeApi which is not tightly coupled with the old message serialization implementation.

from zigbee4java.