I’m in it for self and community improvement, not easy and fast. Besides, if it were easy, it wouldn’t be as satisfying, or as much fun, would it? :)
Thanks > On Jan 13, 2015, at 5:23 AM, Stefano Lenzi <[email protected]> wrote: > > > Dear Josh and Philipp, > > I agree with Philipp that from the time point of view it is easier to buy > CC2531EMK ( http://www.ti.com/tool/cc2531emk > <http://www.ti.com/tool/cc2531emk> ) or CC2530-Eval-Kit ( > http://www.wvshare.com/product/CC2530-Eval-Kit.htm > <http://www.wvshare.com/product/CC2530-Eval-Kit.htm> ), but if you have time > then it will help you to learn a lot about ZB4O and moreover it will be very > helpfull to the ZB4O community > > So it is up to you :) > > Ciao, > Stefano > > Il 13/01/2015 09:01, Philipp Buluschek ha scritto: >> Hello Josh >> >> Sorry if I sound discouraging, but wouldn't it be easier and faster for you >> to buy a TI ZigBee Stick for USD ~20.- instead of writing a complete ZIC >> including a profound refactoring of ZB4O? Coding and testing such a ZIC is >> wuite some work... >> >> Regards Philipp >> >> On 13.01.2015 03:15, Josh Fornwall wrote: >>> 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> >> >> -- >> ________________________________________ >> >> 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] <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] > http://zb4osgi.aaloa.org/mailman/listinfo/dev
_______________________________________________ Dev mailing list [email protected] http://zb4osgi.aaloa.org/mailman/listinfo/dev
