Philipp, I agree.
> On Jan 20, 2015, at 9:26 AM, Philipp Buluschek <[email protected]> > wrote: > > Hello Josh > > About the use of ZDO_Response/Request. This is not very userfriendly, as the > responses will need to be cast to the correct sub class to allow using it. > With generics, there is a nice solution, but we don't have that (yet? hint > hint) > Have a look at http://stackoverflow.com/questions/20515720 > <http://stackoverflow.com/questions/20515720> This does seem the best way to address typing things, but of course that requires moving to Java 5. Is that a move the group is ready to make? > > Regarding decoupling messages from ZToolPackets. Yes this really makes sense. > But in addition, all those message classes need a refactoring. I think of: > hide private parts, make messages immutable, decouple from the byte stream > representation, allow for expressive logging including textual Status codes > etc. etc. > > In addition, (and this is really a problem in the whole of ZB4O), we need > consistent data types. Those need to be defined in a separate package > ("common") which is available to everybody. They need to be problem-specific > (eg. make a data type for "Network Address", and one for "Manufacturer ID", > although both are just a pair of bytes), immutable and the only point in the > whole project where a conversion should take place is upon reading and > writing the serial byte stream. Ideally, yes. I would think the org.aaloa.zb4osgi.zigbee.common bundle, within a new util package? Some refactoring around standard, consistent types would go a long way, but we need to answer the question of using generics before being able to refactor much further. Another alternative may be implementing a Chain-of-Command pattern..? > > Regards Philipp > > > On 20.01.2015 15:09, Josh Fornwall wrote: >> Hello all, >> >> I’ve been looking through the interface some more, and trying to understand >> the operation behind the Z-Stack versus how communication works with XBee, >> while trying to keep an open mind about any other hardware implementations >> that may come along. I think the best area to target is around the AF_ and >> ZDO_ classes used within the SimpleDriver. >> >> I would propose decoupling the AF_* classes from the ZToolPacket. Most of >> the fields are relevant to building Zigbee frames, and should be kept within >> the class, with perhaps an adapter within the driver that maps them to the >> appropriate hardware structures. >> >> Similar as above the ZDO_* classes should be decoupled with the ZToolPacket. >> Further, the SimpleDriver interface itself could be simplified through the >> use of a ZDO_Response sendZDORequest(ZDO_Request request) function. Note the >> generic ZDO_Response and ZDO_Request classes, from which the existing ZDO_* >> classes could inherit. Again, the buildPacket functionality should be left >> as an exercise for the driver implementer. >> >> Thoughts? >> >> Thanks >> >> >>> On Jan 13, 2015, at 5:16 AM, Stefano Lenzi <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Josh, >>> >>> I'm glad that you are working on XBee :) >>> >>> It is part of our plan to remove dependencies between SimpleDriver and TI >>> Z-Stack (aka ZTool, ZNP) API so please provide your proposal and we can >>> easily come up with an adapation of the SimpleDriver. We never had the time >>> resource to work on that because most of our user decided to buy Z-STack >>> compatibile platform (i.e. based on TI CC2530 or TI CC2531 chipset ) >>> >>> So you feel free to discuss details here! >>> >>> Have a nice porting, >>> Stefano >>> >>> Il 13/01/2015 03:08, Josh Fornwall ha scritto: >>>> Hello All, >>>> >>>> I’ve started work on an XBee ZIC, as that’s the hardware I have, and >>>> stumbling across various previous attempts, I don’t see that anyone has >>>> made progress on this. I’ve read through some of the material in your >>>> wiki, and spent about a week looking over your code. The general idea >>>> seems relatively straight forward, starting wtih essentially the >>>> implementation of the SimpleDriver interface. Using your TI drivers as a >>>> template, I’ve made some decent progress. But I’m running into trouble >>>> with methods like this; >>>> >>>> public ZDO_NODE_DESC_RSP sendZDONodeDescriptionRequest(ZDO_NODE_DESC_REQ >>>> request); >>>> >>>> These methods are invariably tied to the ZTool framework/API, which is >>>> similar to, but not equivalent to what’s needed to communicate with an >>>> XBee. My thought would be to create some generic interfaces, defining the >>>> underlying (ZDO/ZCL) packet fields that could be jointly implemented by >>>> the various ZICs, making it easier to implement non-TI hardware. What are >>>> your thoughts on this, and how can I help? Does this make sense, or is >>>> there another approach we (I) can take? >>>> >>>> Thanks! >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://zb4osgi.aaloa.org/mailman/listinfo/dev >>>> <http://zb4osgi.aaloa.org/mailman/listinfo/dev> >>> >>> >>> -- >>> Dr. Stefano Lenzi >>> OSGi Invited Researcher >>> Tel: +39 050 621 2844 >>> Fax: +39 050 315 2811 >>> Skype: kismet-sl >>> Istituto di Scienza e Tecnologie dell’Informazione “A. Faedo” >>> Consiglio Nazionale delle Ricerche >>> Via Moruzzi, 1, 56124 - Pisa - Italy - Stanza C66 >>> <stefano_lenzi.vcf>_______________________________________________ >>> Dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://zb4osgi.aaloa.org/mailman/listinfo/dev >>> <http://zb4osgi.aaloa.org/mailman/listinfo/dev> >> >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] <mailto:[email protected]> >> http://zb4osgi.aaloa.org/mailman/listinfo/dev >> <http://zb4osgi.aaloa.org/mailman/listinfo/dev> > > > -- > ________________________________________ > > Philipp Buluschek, Dr.-Ing. > Adhoco AG > Althardstr. 70 > CH-8105 Regensdorf > > Phone: +41 52 264 5081 > Mobile: +41 79 800 8218 > ________________________________________ > _______________________________________________ > Dev mailing list > [email protected] > http://zb4osgi.aaloa.org/mailman/listinfo/dev
_______________________________________________ Dev mailing list [email protected] http://zb4osgi.aaloa.org/mailman/listinfo/dev
