Azure IoT DevKit – External Connectivity

Beyond the sensors built into the board the possibilities are endless when you consider attaching external devices. As I mentioned in my previous post, the DevKit has an edge connector with a number of input/output pins as well as power. You’ll need an “edge connector breakout” like this to make use of them.

I found this excellent post by Jeremy Lindsay which included a table of the pin numbers and how they map to Arduino pin names – you need this so that you can refer to a physical pin on the edge connector breakout to a pin in your Arduino sketch.

From this it’s possible to rig up an LED or similar on a breadboard and set it from code. One of the things I wanted to try out was using an ultra-sonic distance sensor and this is where I hit a snag. Unlike many Arduino boards there is no 5v output (even though it is driven from a USB 5v input) and the sensor I am using requires one. I’ve had to order a few more parts before I can make progress on this project. Essentially I’ll need a separate 5v supply to my breadboard and will have to convert the output from the sensor down to the 3.3v expected by the DevKit board.

First Steps with Azure IoT DevKit

The Azure IoT DevKit is an Arduino compatible board which is ready to use in conjunction with Azure IoT Hub to build an end-to-end IoT system. Code running on the board is native C and you deploy to the board using Visual Studio Code over the included USB cable. Then your device uses WiFi to establish a connection back to Azure where you can process data received from the device in a number of ways. Two-way messaging is supported so you can respond to the device and send commands to control it. Basically the possibilities are endless!

mxkit

The board itself has a number of sensors – temperature, pressure, humidity, movement and an RGB LED and a small (but very clear) display for output. Other inputs and outputs are possible by attaching to the edge connector which is the same as the microbit. The package consists of the board and USB cable in a neat little cardboard box.

Everything you need software-wise is explained on this GitHub site along with a number of sample apps. It’s even possible to deploy the required IoT Hub and services to your Azure account automatically.

There are three suppliers listed on the “Get a Kit” page and at the time of looking only Plugable had stock but don’t ship internationally. Luckily I was able to find Mouser who had stock and ship to the UK. It only took a couple of days to ship from the US.

I’ll revisit this when I look at setting up the software and provisioning a working program.

 

Bluetooth with Xamarin Mac

I’ve been working on adding macOS support to 32feet.NET and there are two frameworks in macOS for Classic Bluetooth – IOBluetooth and IOBluetoothUI. I soon discovered that neither of these had bindings in the standard Xamarin.Mac package which is referenced by all Xamarin Mac applications. I decided to build binding libraries for both APIs and publish the code as part of 32feet.NET. This means you can either use the IOBluetooth lower-level APIs yourself or later use the platform-agnostic 32feet API.

Today I’ve published the first release of the InTheHand.IOBluetoothUI package. There are fewer APIs than IOBluetooth and I’ve already begun the manual process of simplifying and making it more “.NET friendly”. There is also documentation to add, though even Apple’s documentation on IOBluetooth is rather thin at best…

These are by no means final and there will be changes to the APIs as names are cleaned up and more is tested and fixed. If you’d like to try them in your projects please let me know your feedback via GitHub. Those NuGet packages are:-

https://www.nuget.org/packages/InTheHand.IOBluetooth/

https://www.nuget.org/packages/InTheHand.IOBluetoothUI/

 

Bluetooth from Unity

An ongoing issue with 32feet.NET is that it wouldn’t work inside Unity. The reason is that the System.Net.Sockets classes behave slightly differently in the Mono runtime to the desktop .NET framework and you can’t create a Socket using the Bluetooth specific address family.

In order to work around the issue it was necessary to P/Invoke into the native winsock functions, essentially rebuilding a subset of the Socket class. In parallel to this work I’ve been rebuilding 32feet with a more modern API which is less tied to Sockets (primarily just used on desktop Windows) and able to map onto a range of platforms. Another big change for this version is support for Bluetooth LE alongside classic Rfcomm on supported platform. Currently this library supports Xamarin Android and iOS along with UWP, Windows desktop .NET 4.6 and Mono .NET 2.0 for Unity. I’m working on a macOS implementation too. The API is essentially designed to be a more friendly version of the UWP API. In order to support such an old version of .NET, the Unity version is entirely synchronous whereas most of the API is normally async.

In order to test this I wrote a very simple script for Unity which picks a specific paired device, connects to a serial port service over Rfcomm and sends a string. Yes that’s right I have a 3d game that I can print from!

This is currently in preview (but available on NuGet now). There is a lot still to finish including generating the documentation. I’m hoping for some useful feedback, particularly on the Unity work but also any of the other current platforms. Feel free to join in the discussions on GitHub.

More on Xamarin Insights Migration

Since the original release of InTheHand.AppCenter.Insights just over a week ago there have been a few hundred installs, which is nice. There has also been a major change at App Center and logging handled exceptions is now supported. Therefore the latest update (version 1.5) takes full advantage of this and utilises this new API so we don’t lose vital stacktrace information and these are correctly shown as errors rather than events with some of the exception properties. This is a great move from Microsoft as it brings the App Center functionality into parity with Xamarin Insights which has just three weeks remaining before it is shut down.

If you have a project currently using Xamarin Insights I recommend you install my library to quickly switch over before the deadline. If you’re already using my library I highly recommend you update to the latest version for the full exception reporting support.

From Xamarin Insights to Visual Studio AppCenter

If you haven’t already heard about Visual Studio AppCenter then you should check out this blog post introducing it. Microsoft have had multiple devops technologies which all lived in separate silos. Along with its own Azure Insights it inherited Xamarin Insights and Test Cloud when it acquired Xamarin and also HockeyApp. There was obviously a lot of overlap and a mammoth task of building a unified solution.

In terms of crash reporting and analytics AppCenter owes much to HockeyApp, there’s even built in handling of viewing HockeyApp data from AppCenter. No such luck from Xamarin Insights and you’ll need to find your own time to migrate across before Xamarin Insights is retired on March 31st. I had an idea that as a stop-gap solution it would be useful to have the same API as Xamarin Insights but move to the AppCenter back-end. Thus was born InTheHand.AppCenter.Insights. This is now available on NuGet and the rest of this post will look into switching over to it and a bit of information about finding the data in the AppCenter website.

The library exposes the same API as the original Xamarin.Insights package but AppCenter doesn’t support 100% of the functionality so there are some gotchas when using it. You shouldn’t need to modify any of your code and when you are ready you can start calling the AppCenter API directly and eventually phase out the wrapper.

To start, open your existing solution and remove the Xamarin.Insights NuGet package from your projects. Next add the InTheHand.AppCenter.Insights package. It is a .NET Standard 1.0 library for maximum compatibility, it could have been higher for the supported platforms but it doesn’t need any APIs beyond 1.0. Rebuilding your app now and it should all build without any errors against the new library.

I’ve used the Obsolete attribute on methods/properties which are not supported, calling them will just be a no-op but you can remove these calls if you don’t want the warnings.

Now we’re not quite finished – your code still uses an API key for Xamarin Insights. You’ll need to create a new App on AppCenter for the required platform(s) and this will give you a new key (a Guid string) and you’ll need to replace the old Xamarin API key with this one where you callĀ Insights.Initialize in each head project.

Once you’ve done this and rebuilt your app you’ll have working crash reporting and analytics going through to AppCenter and you haven’t had to re-write any code yet.

[Updated 8th March 2018] As of version 1.5 the Report method now supports logging exceptions to AppCenter as this functionality was recently added to AppCenter. You’ll see stack traces etc fully preserved in your App Center dashboard.

Remember I mentioned some gotchas earlier? Well there is one big gotcha – AppCenter doesn’t allow you to send handled exception reports – the Report method. So when the library processes these they are tracked analytics events with various properties of the Exception added. This means the presentation in AppCenter is not as good as the true crash reports. Unfortunately currently only the first 64 characters of the stack trace are preserved.

[Updated 28th February 2018] As of version 1.1 the library also supports Identify and will set these values using AppCenter’s SetCustomProperties feature. The unique ID you assign is given the name “Unique ID”.

AppCenter doesn’t natively support logging events with timing so the ITrackHandle implementation writes the total duration in seconds as part of the key/value data for the event.

A full crash entry looks like this in AppCenter:-

forcedCrash

An event generated by a reported exception looks like this:-

reportedException

The problem of course is that you don’t get reports logically grouped into exceptions thrown by the same code, instead you get a single “event” with the exception name and then properties which may indicate totally different stack traces. This is obviously not ideal but the danger of creating separate events using both the stack trace and exception is that there is a limit of 200 unique events. If you don’t manually delete ones you’ve finished working on as you might mark a crash as Closed you could hit this limit and lose data. I hope it is something that gets added to AppCenter soon, Microsoft promised this functionality would be in place before the Xamarin Insights shutdown but the deadline is fast approaching. When the API becomes available obviously I’ll update the wrapper as required. This is after all a temporary solution to help with the transition.

NuGet: InTheHand.AppCenter.Insights