Ashok, Replies are inline below.
Assuming that I really understand what you are proposing, I was interested in this idea. However, after thinking about this over the weekend, I think that this is a really bad idea. Here are the big issues that I have: 1) The design is a violation of OIC architecture and design approach. It is not RESTful. 2) The interactions are clearly procedural behaviors. 3) The payload is not a supported format. It is not JSON (or CBOR). 4) The abstraction has issues as any client MUST understand Zigbee or Z-wave commands so standard OIC clients cannot use this feature. 5) The design, as presented, only provides access to local clients to local hardware and most Zigbee and Z-wave developers would prefer to work directly with the hardware SDK APIs. We have a need for Zigbee on v1.0. Based on your design, this will not fulfill our requirements. Any of the above is reason to defer this until the issues are addressed. However, more importantly, we have precious little time to make Iotivity product worthy. So, I must prioritize features that someone wants to productize. Pat From: [email protected] [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of ASHOKBABU CHANNA Sent: Sunday, March 22, 2015 10:56 PM To: Keany, Bernie; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] About ZigBee, Z-Wave Supporting Hi Bernie, There multiple ways to looks application developer's effort here : 1) New developers adapting OIC APIs: A) For ZigBee developer, it's easy to adapt if we provide OIC APIs using encapsulation approach. B) For OIC developer, it's not easy because they have to understand ZigBee specific commands but this is same in PPM approach as well. [PCL, 2015/03/23] I do not think that this is true. An OIC developer does not need to understand Zigbee at all using the PPM. They only need to understand the OIC profile. When they say "turn on the light" as a OIC message, it is the protocol translators' responsibility to understand how to send the message as Zigbee. In this world, a light is a light regardless of whether it is a Hue light bulb or a Zigbee lightbulb. 2) Existing developers adapting OIC APIs: ---> Having PPM approach, ZigBee/Z-Wave app developers need to understand how OIC translate the ZigBee commands and also how the plugin need to be installed for multiple ZigBee profile in the current market scenario even though developer interested in particular ZigBee profile with specific vendor chipset. so app developers effort is much more than second approach. [PCL, 2015/03/23] The goal of OIC is not support Zigbee or Z-wave developers in this way. 3) In both cases target is same. OIC devices interact with non-OIC standard devices. 4) As there are multiple players in ZigBee and each have their distinction of APIs, it might be difficult to select which plugin is suitable by the developer. I personally feel, connectivity's related to radio (WIFI/BT/BLE/Zibgee/Z-Wave/IPv6 ...etc) need to be handled via CA and protocol translations such as AllSeen,UPnP.. etc need to be handled via PPM. There might be Architectural issues but unified approach will help in the long-term for OIC. And having additional benefits such as used of all OIC devices ( Rich/Lite), new use-cases gives second approach a better option. Regards, Ashok ------- Original Message ------- Sender : Keany, Bernie<bernie.keany at intel.com <mailto:bernie.keany at intel.com> > Date : Mar 20, 2015 17:01 (GMT+09:00) Title : Re: [dev] About ZigBee, Z-Wave Supporting Hello Ashok Your final comment to Thiago about increasing the effort on application developers was a point I wanted to make based on my reading of Jinguk's slides (slide 4). I had always believed we were developing the APIs and so that application developers didn't have to know about transports or physical layers. I believe that this goal should be top of mind when it comes to architecture and design decisions; so for that reason I feel the PPM approach is preferred. Regards, Bernie From: ASHOKBABU CHANNA <[email protected] <mailto:ashok.channa at samsung.com> > Reply-To: "ashok.channa at samsung.com <mailto:ashok.channa at samsung.com> " <ashok.channa at samsung.com <mailto:ashok.channa at samsung.com> > Date: Thursday, March 19, 2015 at 7:38 PM To: "Macieira, Thiago" <thiago.macieira at intel.com <mailto:thiago.macieira at intel.com> >, "iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> " <iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> > Subject: Re: [dev] About ZigBee, Z-Wave Supporting Hi, Even though PPM approach is default approach to be considered, Encapsulation (2nd approach) provides additional benefits such as 1) Used by all OIC devices (Rich/Light) . 2) Make unified approach for OIC devices like BT/BLE connectivity's. 3) New use-cases such as handling Zigbee devices at single hop or multi hop with OIC framework. For ex:: If we have 3 devices - A ( OIC Device- BLE) , B ( OIC Device - BLE/Zigbee) , C ( Zigbee device). From A-B , it can be a OIC protocol(payload zigbee command) and from B to C its Zigbee interaction using OIC framework itself. And benefits will come with a cost.. it makes applicationput more effort. But this is valid scenario as application have more idea of Zigbee Profile . In my opinion, encapsulation is also good approach to be considered for better OIC device expansion. Regards, Ashok ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com <mailto:thiago.macieira at intel.com> > Date : Mar 19, 2015 23:13 (GMT+09:00) Title : Re: [dev] About ZigBee, Z-Wave Supporting On Thursday 19 March 2015 06:21:56 JinGuk Jeong wrote: > Dear IoTivity Developers, > > Since I want to technically discuss about a way how to support > ZigBee/Z-Wave, I am sending an email to you. I think this feature is very > important feature because there are so many ZigBee/Z-Wave devices in the > world. However, we need to consider several issues such as chip dependency, > code size, and so on. Currently, there are two approaches for that, and you > can find these approaches in attached file. Plz give your feedback about > this. Hi Jinguk Thanks for sharing the outlines of the two options. I'm probably missing something... it seems quite straightforward to me that the simplest answer would be #1, which is why I think I am missing something. Why would option #2 be considered? My thinking is: 1) the Zigbee/ZWave wire protocol and message format is wildly different from the OIC one (discovery, communication, authentication, encryption, authorisation, etc.). That means the only abstraction that would be common between OIC and a Zigbee device is at the level of a service. That is, a lightbulb is still a lightbulb by any other name. 2) there are probably existing libraries to talk to zigbee adapters and speak zigbee protocols (or zwave), which means we would spend less time trying to abstract them on CA. Instead, we gain time by simply wrapping them at the highest level possible -- the service layer. The only thing that comes to mind about wanting to have CA service zigbee is if we wanted to share the infrastructure between multiple zigbee-capable devices. But isn't that what the zigbee libraries should already be doing? Do such iibraries exist? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [http://www.samsung.net/service/ml/AttachController/201503201138460_QZUWXYH6 .gif?cmd=downdirectly&filepath=/LOCAL/ML/CACHE/a/20150323/93BIV0UVOUUB at namo. co.kr705ashok.channa&contentType=IMAGE/GIF;charset=Windows-1252&msgno=705&pa rtno=1&foldername=INBOX&msguid=71225] </thiago.macieira at intel.com</iotivity-dev at lists.iotivity.org</thiago.macieir a at intel.com</ashok.channa at samsung.com</ashok.channa at samsung.com <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=a89e2f31c590267a8e61892 067e2c10997670b70b8e6dc7ea1889aa8efbbee4713d69ea60670f66e1fac5bf6c61543587bc 8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a 0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150323/e37ae4b4/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150323/e37ae4b4/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150323/e37ae4b4/attachment.p7s>
