Scott, Yes, iotivity-lite will be supported. In face the DeviceBuilder has already tested with this, but there were a few issues such that we were not quite comfortable running the hackathon on iotivity-lite. We will concentrate on this after the hackathon. All of this is open source, so if anyone wants to get involved in supporting different platforms, languages, iotivity-lite, etc. volunteer help would be gladly accepted.
OTGC has common core functionality and code around that for specific platforms. It wasn’t a requirement in the contract to support plug-ins, but it is designed to require minimal work to support new platforms and the full source code for all platforms will be available. So I would say a plug-in architecture could be supported, but it will take some extra work. The intention is definitely to allow production code to be built from the OTGC code as a start. Thanks, -Clarke > On Jun 6, 2018, at 7:07 AM, Scott King <[email protected]> wrote: > > Clarke, > > That’s a lot of exciting stuff in the pipeline! Are there any plans to > support iotivity-lite/constrained as an output of the DeviceBuilder? Also, > are all of the OTGC’s going to be stand-alone native apps or are there plans > to develop plugins for hybrid frameworks like react native/cordova/flutter? > I’m just curious whether these tools are designed to be used by vendors in > production or if they’re simply for testing/prototypes. > > Thanks, > Scott > > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Clarke Stevens > Sent: Wednesday, June 6, 2018 12:22 AM > To: Gregg Reynolds <[email protected] <mailto:[email protected]>> > Cc: Morten Nielsen <[email protected] <mailto:[email protected]>>; iotivity-dev > <[email protected] <mailto:[email protected]>> > Subject: Re: [dev] Where are the devs? > > All, > > Let me jump in here. > > I’m Clarke Stevens, the chair of the OCF tools group. We are at the MVP stage > of some very exciting developer tools. > > Using these tools, I can build a certifiable device in 15 minutes (actually, > it’s more like 3 minutes after you build the IoTivity libraries). This is > what we will use in our hackathon in Chicago in a couple weeks. Also, I have > a presentation on it that will be available in the online version of the IoT > Slam conference on June 21-22. > > Here is what we have (currently running on the Raspberry Pi). > A git repo with the complete installation scripts. > Scripts that install IoTivity, DeviceBuilder (development scripts), and MRAA > libraries. > Scripts that run the development tool chain > gen.sh - Reads the device description file that describes the resources in > whatever you want to build. From that, it reads the needed resource > definitions in oneIoTa and builds the following > Certifiable IoTivity code for the server. > An introspection file > PICS files for testing > An onboarding file for secure access > build.sh - Runs scons to compile and link everything and copy it to the right > directories. > edit_code.sh - Loads the server.cpp source file into the nano editor so you > can add your custom code. > run.sh - Runs the server executable. > reset.sh - Resets the onboarding state to RFOTM (ready for onboarding > transfer method - so, unowned). > Onboarding Tool and Generic Client (OTGC) - This is and Android app (current > MVP, will be available in iOS, Ubuntu and Windows in the fall). It supports a > nice interface to onboard a device. Once the device is onboarded, It reads > the introspection file and automatically generates a GUI with the widgets to > support the identified resources. This client is open source. So you can > build your own certifiable custom client starting from a working interface. > DeviceSpy - This has the same functionality as OTGC, but has a developer’s > interface with the actual editable payloads for messages. > Compliance Test Tool (CTT) - An automated test tool that uses the generated > PICs file to run all the tests to verify your product is OCF compliant. > > As I said, I can run the entire tool chain in 15 minutes on a Raspberry Pi 3 > in about 15 minutes. I will be doing this on stage at the hackathon in > Chicago. > > Here are some other key points. > > oneIoTa is used as the definitive source for all resource models. Any > resources in oneIoTa can be used. If you need something that isn’t available. > You can submit new resources to oneIoTa (oneiota.org <http://oneiota.org/>). > All you need to do to define a complete device is write the device > description file (JSON). All the necessary resources will be automatically > pulled in and all the necessary files automatically generated and put in the > correct directories. > Currently, we are using IoTivity in C/C++, but all of the scripts are > templated, so it’s easy to convert to any language on any platform. We have > currently tested the entire tool chain on Windows, MacOS, Ubuntu and Raspian. > We are looking at a node.js as a possible next language. A couple of BIG > companies are planning to support their own boards that are more likely to be > used in real products. > The OTGC is currently in MVP stage on Android. It will support iOS, Linux and > Windows by this fall. > DeviceSpy is a very powerful developer tool that lets you have perfect > control over the payloads. > CTT lets you run all the tests for certification on your own before you > submit your product to an Authorized Test Lab. > The tools generate logs so you can debug any problems. > > This is an exciting and complete (OK, a debugger isn’t really integrated yet, > but feel free to help set this up). I encourage everyone to try this. The > current example code supports the demo hardware (Pi and EnviroPhat daughter > board) we used for our demo kits at CES. You can see that here: > https://openconnectivity.org/wp-content/uploads/2017/12/OCF-IoTivity-RPi3-GSG.pdf > > <https://openconnectivity.org/wp-content/uploads/2017/12/OCF-IoTivity-RPi3-GSG.pdf> > > Look at the hardware, but don’t use these instructions (they are the old > ones). Instead, install a headless version of Raspian stretch > (https://www.raspberrypi.org/downloads/raspbian/ > <https://www.raspberrypi.org/downloads/raspbian/>), then use the > DeviceBuilder process described here: > https://github.com/openconnectivity/IOTivity-setup > <https://github.com/openconnectivity/IOTivity-setup> Some of this may only be > available to OCF members, so if you aren’t already signed up, you should do > it. There are free levels for individuals and non-profits. > > Unfortunately, the instructions for getting OTGC, DeviceSpy and CTT aren’t > yet clearly written. The will be within the next week or so. > > Also, if you can be in Chicago June 21 and 22. Sign up for the hackathon (see > the OCF site: openconnectivity.org <http://openconnectivity.org/>). It’s free > with free food, cool goodies and bragging rights for having participating in > the first OCF hackathon. > > OK. That’s all I’ve got. > > Thanks > -Clarke > > > On Jun 5, 2018, at 2:26 PM, Gregg Reynolds <[email protected] > <mailto:[email protected]>> wrote: > > > > On Tue, Jun 5, 2018, 3:10 PM Morten Nielsen <[email protected] > <mailto:[email protected]>> wrote: > Short answers to this: > Raspberri isn't a consumer device. I need a lamp, or something else that's a > real-world consumer product. > Let us have cheap real things to play with not dev toys. > > Consumers do not write code. Devs love rpi. If you want devs, make rpi easy. > > That said, how do you want to pick the consumer device? You pick it, I'll > make it trivially easy to use it with Iotivity. > > Second you obviously have a very non-windows approach to things. > > Bazel has excellent windows support. > > Be careful with that attitude. There's a large dev community who likes to > open solutions and hit "run" to compile and build. Don't underestimate the > Visual Studio community. It's huge. Make it easy for them on Windows. > Also many platforms doesn't build the components - they just reference them. > Asking people to build those components first is ridiculous > > There's a misunderstanding here. With Bazel I do not "build iotivity first". > Bazel does that for me - *if* necessary. I just build my app. The first time, > all the deps get built too. Thereafter, only what has changed. > > and yet another step where you lose people. Remember that these people spend > their spare time and want successes quickly or you lose them. > > Bazel overall is the fastest build system I've ever used, and I've used most > of them. > > Sure it's all easy for you, but you live and breathe this every day. > > What's easier than "bazel build myapp"? > > /Morten > From: Gregg Reynolds <[email protected] <mailto:[email protected]>> > Sent: Tuesday, June 5, 2018 3:33:51 PM > To: Morten Nielsen > Cc: iotivity-dev > Subject: Re: [dev] Where are the devs? > > > > On Fri, Jun 1, 2018, 4:18 PM Morten Nielsen <[email protected] > <mailto:[email protected]>> wrote: > AllJoyn seemed to do a little better in this regard. A few things I saw they > did that I feel OCF is lacking: > > 1. A broadly available product like LIFX for developers to play with. > The obvious choice is Raspberry Pi. The problem is tooling. You can find > tutorials on the web but they all involve building Iotivity *on* the pi - a > major pain, IMHO, and almost certain to frighten away many devs. > > This is where Bazel solves a problem. Here's how I build an OpenOCF app for > rpi: > > ./bin/rpi_config.sh arm8 > > (unfortunately source config is not - yet - integrated in the build logic) > > bazel build myapp --config=rpi-arm8. > > Of course you have to have a cross-compile toolchain (I use crosstool-NG), > but you only have to do that once, and it's not very hard. > > Then a simple scp command installs the app on the rpi and off you go. > > (BTW I've got everything in resources/ building and running under Bazel, > including tests and examples. Haven't yet added the cross-build stuff. > Working on a draft submission, maybe next weekend.) > > 1. Very easy developer tooling to build devices and clients. > Two things: tools for building and tools for exploring/learning/debugging. > > As for the latter: working on it. A dev-centric app that makes it easy for a > dev to examine an OCF network. Exposes all the gory details of messages, > payloads, etc. so you don't have to rummage around in debug logs. Some of the > example apps do something like this, but as they are undocumented and opaque > I don't find them very helpful. > > Two apps, actually, one with an ncurses interface, one a flutter app (Android > only atm, maybe someday iOS). > > > 1. Pre-compiled bits. Don’t make me compile everything. > I think this is over-rated. It all depends on the tooling. With Scons, yes, a > pain. With Bazel, compiling everything is probably easier and faster (and > definitely more reliable) than downloading and configuring precompiled > binaries. Anyway, with Iotivity's many build options I think precompiled > binaries is not such a good idea. Maybe a security risk too. > > 1. Blog posts. > That'll happen when devs take an interest. > > G > >
