Morten, Thank you for raising your concerns. We do strive to be a welcoming and inclusive community of developers. I apologize that the thread below wasn’t more closely and promptly monitored.
I hope you take a close look at what Clarke provided… it’s really a quantum leap from the older/current development experience especially for new-to-OCF folks trying to get their feet wet and evaluate the technology. I think OCF has a lot to offer as a standard, but we realize the ease of evaluation and introduction to IoTivity needs a lot of work. We are working very hard to improve it, and I believe we are really close to a world class experience with the work Clarke linked to! Please take a look and let us know what you think; we are excited about this improvement and we sincerely value (need!) feedback from developers who aren’t already familiar with the project. Thanks again, Nathan Heldt-Sheller OSWG Security TG Chair OSWG Pro-tem Chair From: iotivity-dev@lists.iotivity.org [mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Clarke Stevens Sent: Tuesday, June 5, 2018 9:22 PM To: Gregg Reynolds <d...@mobileink.com> Cc: Morten Nielsen <m...@iter.dk>; iotivity-dev <iotivity-dev@lists.iotivity.org> 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 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/), then use the DeviceBuilder process described here: 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 <d...@mobileink.com<mailto:d...@mobileink.com>> wrote: On Tue, Jun 5, 2018, 3:10 PM Morten Nielsen <m...@iter.dk<mailto:m...@iter.dk>> 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 <d...@mobileink.com<mailto:d...@mobileink.com>> 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 <m...@iter.dk<mailto:m...@iter.dk>> 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
