Support for hardware from multiple vendors

[tlaukkan]

Which would be good USB connected ZigBee controller devices to integrate to zigbee4java?

What are software design options to support multiple devices with completely different serial interfaces or another integration technology altogether considering current implementation approach?

[d1g2w3]

Hi Tommi,

Proof of concept projects like integration with a home assistant (on
github) type gateway.

Also a good idea having two serial devices that access the HA and Smart
energy network.

A project I like the idea of is a media centre that changes the colour of
lights depending on the most common colour of the video e.g. A horror film
with red blood that changes the lights to red.

Maybe trying to integrate with xbmc.

Just a random idea that I thought would be cool

Kind regards,

Danny Watson
On 25 Mar 2015 17:40, "Tommi S.E. Laukkanen" notifications@github.com
wrote:

Which would be good USB connected ZigBee controller devices to integrate
to zigbee4java?

What are software design options to support multiple devices with
completely different serial interfaces or another integration technology
all together considering current implementation approach?

—
Reply to this email directly or view it on GitHub
#22.

[tlaukkan]

Lets focus first on dongle hardware. If you have come across good ZigBee dongles which can act as controllers then please post a link here.

Best regards,
Tommi

[tlaukkan]

XBee Explorer USB with XBee Pro ZB S2B Wire Antenna would be one interesting option at least.

Did NXP have ZigBee Pro dongle with serial interface, HA profile support and ability to act as controller?

[d1g2w3]

Hi Tommi,

We do have an internal source for Zigbee pro stack device but it's just
that, internal which means I can't release it.

We have another device but it has the ZCL on the device. If integration was
to happen the ZCL from zigbee4java may have to be bypassed.

It is possible that the ZCL could be ignored and could be used just for a
pro stack but I need to look at the serial code and it could be possible
that some features are restricted (I'm not full sure yet)

I am planning to look at the application note tomorrow night when I get
some time to myself.

A shim layer could be added to catch it before it goes into the java ZCL
but then the device goes up a layer and becomes convoluted. It would also
lead to inconsistencies between an NXP and TI device which would be awful.

Like I said I will look at this tomorrow and get more information.

Kind regards,

Danny Watson
On 26 Mar 2015 18:14, "Tommi S.E. Laukkanen" notifications@github.com
wrote:

XBee Explorer USB with XBee Pro ZB S2B Wire Antenna would be one
interesting option at least.

Did NXP have ZigBee Pro dongle with serial interface, HA profile support
and ability to act as controller?

—
Reply to this email directly or view it on GitHub
#22 (comment).

[d1g2w3]

Hi,

So I have been looking into developing a ZigBee pro stack JN516x device.
There's some work that needs doing to get it to a usable state.

I am going to work on doing that preparation tonight so I can then start
adding the interface in Zigbee4java.

I'm going to be working on an in house release candidate for our next
public release so I cannot release the source on github until the public
release. I will be able to release the binary when compiled though. But at
least there wouldn't be any porting activity when the release is out.

One step at a time though. I have to remove all ZCL serial protocol out of
the current NXP application and add addition low level zigbee pro APIs to
the serial protocol.

Let me know if you have any concerns or requests.

Kind regards,

Danny Watson
On 26 Mar 2015 18:26, "danny watson" d1g2w3@gmail.com wrote:

Hi Tommi,

We do have an internal source for Zigbee pro stack device but it's just
that, internal which means I can't release it.

We have another device but it has the ZCL on the device. If integration
was to happen the ZCL from zigbee4java may have to be bypassed.

It is possible that the ZCL could be ignored and could be used just for a
pro stack but I need to look at the serial code and it could be possible
that some features are restricted (I'm not full sure yet)

I am planning to look at the application note tomorrow night when I get
some time to myself.

A shim layer could be added to catch it before it goes into the java ZCL
but then the device goes up a layer and becomes convoluted. It would also
lead to inconsistencies between an NXP and TI device which would be awful.

Like I said I will look at this tomorrow and get more information.

Kind regards,

Danny Watson
On 26 Mar 2015 18:14, "Tommi S.E. Laukkanen" notifications@github.com
wrote:

XBee Explorer USB with XBee Pro ZB S2B Wire Antenna would be one
interesting option at least.

Did NXP have ZigBee Pro dongle with serial interface, HA profile support
and ability to act as controller?

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

[d1g2w3]

Quick question. The ZDO classes, are they sending frames in spec format or are they just parameters passed to the TI device for the device to format into the ZDO spec. I'm just trying to work out if i can remove all the ZDO out of the NXP device and be a complete slave to any ZDO and ZCL frames?

[presslab-us]

Look at the Z-Stack Home file \Texas Instruments\Z-Stack Home xxx\Documents\API\Z-Stack Monitor and Test API.pdf. This shows the format that the ZDO classes use to send to the TI Coordinator over the "ZStack MT" protocol. From what I can see most everything is according to ZigBee spec but there are a couple things that are a little different here and there.

[d1g2w3]

Great stuff, just installed and looked at the document.

Right i understand the big picture now.

zigbee4java.zigbee-api.src.main.java.org.bubblecloud.zigbee.network

will become

zigbee4java.zigbee-api.src.main.java.org.bubblecloud.zigbee.vendor.nxp
and
zigbee4java.zigbee-api.src.main.java.org.bubblecloud.zigbee.vendor.ti

Under vendor will be an interface class of all the override functions
(changed from classes to functions) which will implement there vendor
specific protocol.

On 27 March 2015 at 23:32, presslab-us notifications@github.com wrote:

Look at the Z-Stack Home file \Texas Instruments\Z-Stack Home
xxx\Documents\API\Z-Stack Monitor and Test API.pdf. This shows the format
that the ZDO classes use to send to the TI Coordinator over the "ZStack MT"
protocol. From what I can see most everything is according to ZigBee spec
but there are a couple things that are a little different here and there.

—
Reply to this email directly or view it on GitHub
#22 (comment).

[mcous]

Just stumbled across this repo and this issue, and I figured I mention the CEL MeshConnect ZigBee USB dongle. It uses a Silicon Labs EM357 and a SiLabs UART to USB chip under the hood.

I've been using it as a coordinator from a CLI written in C (and provided by SiLabs) but a Java interface would be really cool (not to mention useful for a certain Scala project I have at work).

[cdealti]

• Telegesis, via AT-like commands
• XBee, via AT-like commands, for which a Java library is already available [1] with the Mozilla Public License Version 2.0 (compatible?)
• Freescale (now Freescale-NXP) used to provide a ZTC (ZigBee Test Client) UART interface with their dongles. The only other ZigBee Java project [2] I'm aware of uses an MC1322x-based (quite dated) dongle. NXP has now the Kinetis platform and offer a dongle [3] as a sniffer. I assume it can be loaded with a ZTC firmware binaries like in the past.

[1] https://github.com/digidotcom/XBeeJavaLibrary
[2] http://ismb.github.io/jemma/
[3] http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m/w-series/ieee-802.15.4-packet-sniffer-usb-dongle-form-factor:USB-KW24D512

[tlaukkan]

One approach is to wrap the current implementation with generic ZigbeeAPI layer which would allow designing the lower layers freely when implementing support for other vendors.

[cdjackson]

Why wrap the API? My thought was to refactor lower down to make a clean interface to the lower layers. It's been a little while since I looked at this due to working on other things, but I started refactoring the network manager. I beleive that this should provide a good break?
#60

[tlaukkan]

Hi

Certainly one ought to try to maximize code reuse. Wrapper could allow some
maneuvering space under it whether one reaches high reuse of code or not.
Both approaches work for me though.

Br,
Tommi
On 2 Apr 2016 16:04, "Chris Jackson" notifications@github.com wrote:

Why wrap the API? My thought was to refactor lower down to make a clean
interface to the lower layers. It's been a little while since I looked at
this due to working on other things, but I started refactoring the network
manager. I beleive that this should provide a good break?
#60 #60

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#22 (comment)

[DuncanvR]

Hi Tommi,

I noticed that the original ZB4OSGI project lists four supported dongles: the CC2531 that is listed as prerequisite for this project, plus three alternatives based on the CC2530. This eval kit is the cheapest of those, at $18.99, which is significantly less compared to the $49+$49 for the CC2531 dongle plus debugger.
Would that CC2530 kit also work with zigbee4java?

Cheers,
Duncan