Decoding and parsing JSON using NewtonSoft

So you are working with JSON, you get a JSON message and you want to retrieve some values from it. How?

Let’s suppose you get something like (this is an example take from here):


The backslashes, the escape characters, are only for C# to know which double quotes are part of the message. It’s not necessary but you can remove them and then you have:


Well, it’s always good to check the message is proper JSON. You can check it with a ‘tool’ like


This is a valid message, if we format the structure, it looks a lot better:

  "port": 1,
  "counter": 504,
  "payload_raw": "+QA=",
  "payload_fields": {
    "errorCode": 0,
    "numberOfCycles": 249
  "metadata": {
    "time": "2017-01-10T23:31:06.087189682Z",
    "frequency": 868.1,
    "modulation": "LORA",
    "data_rate": "SF7BW125",
    "coding_rate": "4/5",
    "gateways": [{
      "gtw_id": "eui-b827ebffffc19ca8",
      "gtw_trusted": true,
      "timestamp": 3771642998,
      "time": "1754-08-30T22:43:41.128654848Z",
      "channel": 0,
      "rssi": -80,
      "snr": 9,
      "latitude": 51.46018,
      "longitude": 5.61902,
      "altitude": 10}]

There are several ways to get values from this JSON message.

Doorgaan met het lezen van “Decoding and parsing JSON using NewtonSoft”


The Things Network bridge revisited

A few month ago, I wrote about how to collect telemetry from The Things Network back-end and send them to an Azure IoT Hub.

The code was simple and it only provided telemetry for one device. But the technology used, was working.

Last month, I was involved in creating a workshop for the TechDays 2016 in Amsterdam. The two-hour workshop gives a good impression how to build an IoT Backend in Azure. During this workshop, we used a NodeJs bridge to pass the telemetry to Azure.

This bridge is available at using the NPM package installer: npm install –save ttn-azure-iothub@preview

I got inspired by this bridge and now I have rebuilt my bridge to handle multiple devices and more!

Doorgaan met het lezen van “The Things Network bridge revisited”

Access The Things Network Lora telemetry using C# M2Mqtt

Somewhere in December 2015, I was made aware of this Lora initiative called The Things Network. Since then, as an IoT enthusiast, I am researching how to implement this platform in my other IoT projects.

Update 8-11-2016: this blog gives an introduction to MQTT and accessing the TTN network. A full implementation of a C# TTN->Azure bridge is available at GitHub. More details are available here.

Lora stands for Long Range and it fills a gap between Wifi and GMS, thinking about wireless connectivity for IoT sensor boards:


At the moment there are two serious implementations of Lora in The Netherlands. KPN is offering a commercial solution so it’s reliable but it does not come free. And then there’s The Things Network, a Kickstarter solution. It offers free connectivity :-).


What they ‘sell’ are gateways. These come fairly cheap (starting at ~ 250 euros) but with their gateway, you can connect up to 5 kilometers (keep on dreaming about 10 :-)) around your house with Arduino’s, ESPs, RaspberryPi etc. And with a couple of these gateways, you can cover your village or city. So get your friend involved!

The telemetry of the nodes (say twenty bytes of date every minute) are received by the gateways and forwarded to the TTN backend. But you have to do ‘something’ yourself to get the data from the backend. I will tell you how to do that using C# all the way.

Doorgaan met het lezen van “Access The Things Network Lora telemetry using C# M2Mqtt”

Reading IBeacons using a UWP app on your Raspberry Pi

As you probably know, Bluetooth low energy (BT LE)  is a wireless personal area network technology which uses a minimum of power to broadcast messages to receivers nearby.

Bluetooth LE is a common standard but it is most popular under the name of IBeacons. IBeacons is a protocol coming from Apple, so it is just a class of Bluetooth low energy (LE) devices that broadcast their identifier to nearby portable electronic devices.

IBeacons can basically exchange two parts of data: that unique identifier and the signal strength. This makes it possible to figure out the (fixed) position of the IBeacon. And if you receive the signals of multiple beacons you can triangulate your own position between them.

In 2015 Google launched a competing, but similar, beacon standard called Eddystone. It has a richer functionality because it can exchange more information.

Far less known is that Windows 10 also supports the beacon technology, it’s not just Apple and Android which are having fun with it. In Windows, there is this Windows.Devices.Bluetooth.Advertisement library:
“It allows apps to send and receive Bluetooth Low Energy (LE) advertisements.”

Doorgaan met het lezen van “Reading IBeacons using a UWP app on your Raspberry Pi”

Nuget “Include Prerelease” not equals “latest version”

Today I stumbled on ‘strange’ behaviour of Nuget. Well, it’s not really strange but more like confusing.

It started when I added Application Insights to an existing website. This can be done in several ways (there is really good tooling inside Visual Studio when creating a new website or with the right-click on the project) but I was adding it by hand.

So I added Application Insights for Web Applications. And version 0.17.0 was added. This is relying on the Application Insights API package 0.17.0.

All went well.


But later on I noticed(*) that there is a even newer version of the SDK package is available: 0.17.1


Well, my assumption is then when I ask for packages, including prereleases, I automatically get all the latest versions. I was wrong.

What did I learn today? Do not take Nuget and it’s release management for granted. After installing a certain package, check for updated and decide if that one is good for you.

* I ran into a problem when I simply added the System Diagnostics listener nuget package. Suddenly my code was not working anymore (and I got this ‘Object reference not set to an instance of an object’ when simply consuming the Telemetry client). I traced it down to a line of code in the Application_Start() method in the App.config. There I add the Application Insights instrumentation key by hand because we want to separate tracing from developers and from testing and from production (we are using an OTAP environment). Just by removing that line, everything was working again. But I lost the iKey choice. In the end, just updating the SDK nuget package fixed this error.



Getting the token expiration date in Azure Mobile Services

Azure Mobile Services support storing the Oauth user credentials token in the PasswordVault of the OS a client app is running in. This is supported in Windows Universal apps, Xamarin, etc.

See here for the details regarding user credentials from the AMS documentation.

And this is a good thing, now the user does not have to supply the Oauth credentials every time the app is started. We can check if the vault contains the credentials we need and this saves a round trip to the server and an extra input screen. If it is not in the vault, just let the user login using Facebook, Google etc.  and store the token.

But wait: these stored credential tokens are not valid until the end of times. For example, Google credentials are valid for 30+ days. After that, the token stored in the vault is worthless.

Therefor, in the AMS example above a simple check is done by calling the AMS service with a trivial request:

  // Try to return an item now to determine if the cached credential has expired. 
  await App.MobileService.GetTable<TodoItem>().Take(1).ToListAsync();
               // <<-- WHY??? 
catch (MobileServiceInvalidOperationException ex) 
  if (ex.Response.StatusCode == System.Net.HttpStatusCode.Unauthorized) 
    // Remove the credential with the expired token. 
    vault.Remove(credential); credential = null; continue; 

Here a simple GET is done to check the validity of the token. If it is not valid, it is deleted and the user must login again.

But this is a web call I do not like.

This is done every time user logs in / starts the app, even in an offline scenario!

In an offline scenario I am not even interested in the expiration date…

Is there a better way?

Well, what we get from the Oauth providers, when the user logs in successfully, is a Json Web Token (JWT). And this token can be decoded following the JWT specifications.

This will result in something like:

public class Token
    [JsonProperty(PropertyName = "ver")]
    public string Ver { get; set; }
    [JsonProperty(PropertyName = "uid")]
    public string Uid { get; set; }
    [JsonProperty(PropertyName = "exp")]
    public string Exp { get; set; }
    [JsonProperty(PropertyName = "nbf")]
    public string Nbf { get; set; }
    [JsonProperty(PropertyName = "aud")]
    public string Aud { get; set; }

This token is available on the server as:


And the token can be decoded using a Nuget package. The only drawback is that this package is not available on the Universal apps client, only on the Azure Mobile Services server, the backend.

So I wrote this extra API controller:

public class DecodeExpirationController : ApiController
  public ApiServices Services { get; set; }
  // GET api/DecodeExpiration
  public DateTime? Get(string token)
    string adminKey;
    if (!Services.Settings.TryGetValue("ADMIN_KEY", out adminKey))
      return null;
      var jsonPayload = JWT.JsonWebToken.Decode(token, adminKey, false);
      var result = JsonConvert.DeserializeObject<Token>(jsonPayload);
      var startOfUtcCount = 
        new DateTime(1970, 1, 1, 0, 0, 0, 0, DateTimeKind.Utc);
      var expirationDate = startOfUtcCount.
      return expirationDate;
    catch (JWT.SignatureVerificationException)
      return null;
    catch (Exception ex)
      return null;

Note the level of authorization, the user should be logged in by now…

And we can call this WebApi GET on the client:

  var parameters = new Dictionary<string, string>();
  var result = await App.MobileService.
        InvokeApiAsync<DateTime?>("DecodeExpiration", HttpMethod.Get, parameters);
  message = result.HasValue ? result.Value.ToString() : "Nothing returned.";
catch (Exception ex)
  message = "Exception: " + ex.Message;

This should work using with every provider.

The Admin Key is coming from the portal. I have added this appsetting to the configuration of the AMS.

Using this call we get the UTC time of the token expiration date. So store this on the client and check this value every time (give or take a few hours due to correct daylight savings when applicable).

Integratie van Knockout in Asp.Net MVC3

In need of an English translation? Please drop me a note!

Wie door mijn blog heen bladert ziet dat ik < understatement >redelijk enthausiast</understatement> over Asp.Net MVC ben. Ik vind het een framework wat echt zijn nut bewijst wat betreft snelheid van ontwikkelen, onderhoudbaarheid en flexibiliteit. Natuurlijk is het nog een redelijk jonge implementatie en kan het altijd beter. En wat ik eigelijk het meest ‘irritante’ vind, dat is de JavaScript.

Nu heb ik altijd geroepen dat JavaScript de plakband is die een controls op een webpagina bij elkaar moeten houden en had er ook een haat-liefde verhouding mee. Met de komst van jQuery en nog enkele andere (open souce) bibliotheken is het toch nog goed gekomen tussen mij en JavaScript.

Maar met de komst van jQuery en het gemak waarmee Ajax calls gemaakt worden, komt er wel een gevaar om de hoek: Al die Javascript, verdeelt over meerdere bestanden en over nog meer functies, kan echt spaghetti worden. Vooral als in de functies weer doorverwezen wordt naar de controls op het scherm…

Maar het kan anders! Opeens kwam KnockoutJs  om de hoek.

KnockoutJs is gebouwd op vier peilers:

  1. Declarative Bindings
  2. Automatic UI Refresh
  3. Dependency Tracking
  4. Templating

Dit maakt het mogelijk om MVVM toe te passen in JavaScript. Klinkt moeilijk, is het ook best wel maar ik heb onderstaand voorbeeld uitgewerkt en dit moet je flink op weg helpen.

En hou in je hoofd: we veranderen niks aan de manier waarop je Asp.Net MVC toepast. Het enige wat we willen voorkomen is spaghetti in JavaScript.

Start dus een nieuw Asp.Net MVC3 project:

We gebruiken de lege template:

Vervolgens werken we even de Nuget packages bij met de laatste versies.

Voor mij was het voldoende om de laatste jQuery te installeren. De gelieerde packages worden gewoon bijgewerkt. De jQuery Visual Studio IntelliSense kan daarna gedeinstalleerd worden, dit is in de originele jQuery package opgenomen. En vergeet niet om ook de Knockoutjs package en de Knockout.Mapping package toe te voegen. Nu moeten de volgende packages geïnstalleerd zijn:

De EntityFramework package en Modernizr package zijn out-of-scope voor deze blog.

Vervolgens moet de _Layout.cshtml bijgewerkt worden. (in MVC2 zou dit de master page zijn geweest)

<!DOCTYPE html>
  <meta charset="utf-8" />
  <link href="@Url.Content("~/Content/Site.css")"
        type="text/css" />
  <script src="@Url.Content("~/Scripts/jquery-1.6.4.min.js")"
   <script src="@Url.Content("~/Scripts/knockout-1.3.0beta.js")"
   <script src="@Url.Content("~/Scripts/knockout.mapping-latest.js")"
   @RenderSection("Scripts", false)

Tip: Controleer nog even of hier de juiste versies van de bestanden genoemd zijn. Er komen regelmatig nieuwe versies uit, tenslotte.

Wat hier opvalt is dat we een extra Scripts sectie toegevoegd hebben. Deze zal straks toegepast gaan worden binnen de View.

Maar eerst gaan we de controller en de ViewModel op de server creeeren.

Als ViewModel heb ik object genomen die een gezin moet voorstellen. Dit gezin woont op een adres:

public class HomeEditViewModel
  public int Id { get; set; }
  public string FamilyName { get; set; }
  public bool IsScary { get; set; }
  public Address Address { get; set; }

public class Address
  public string Street { get; set; }
  public int Number { get; set; }

Omdat ik een scherm wil demonstreren waarin een ViewModel wordt onderhouden, is dit een redelijk normale situatie die wel vaker voorkomt.

Voeg nu  een lege controller toe:

De controller ziet er (ingevuld) als volgt uit:

public class HomeController : Controller
  public ActionResult Edit()
    var model = new HomeEditViewModel();
    model.Id = 42;
    model.FamilyName = "The Adams family";
    model.IsScary = true;
    model.Address = new Address {
            Street = "Cemetery Lane", Number = 1313 };
    return View(model);

  public ActionResult Edit(HomeEditViewModel model)
    if (!ModelState.IsValid)
      // do something with the data provided

    return View(model);

De essentie is hier dat er data verzameld wordt en dat de View hiermee gevuld gaat worden door de ViewEngine. Ik heb de PostBack methode toegevoegd zodat te controleren is of de Submit van een gewijzigde View ook correct verwerkt wordt.

Nu wordt het spannend , we gaan de View aanmaken. Voeg deze toe aan de Edit Methode:

Tot zover is alles nog een redelijk normale MVC3 applicatie.

Laten we nu eens naar de gegenereerde View gaan kijken. Ik heb de standaard gegeneerde view vervangen door onderstaande code:

@model KnockoutMvcApplication.Models.HomeEditViewModel
 ViewBag.Title = "Demo of MVC edit view combined with KnockoutJs (MVVM implemention)";
@section Scripts{
 <script src="@Url.Content("~/Scripts/home.edit.js")"
 <script type="text/javascript">
   var serverViewModel = @Html.Raw(Json.Encode(Model));

<h2>MVC edit view combined with KnockoutJs (MVVM implemention)</h2>

<script src="@Url.Content("~/Scripts/jquery.validate.min.js")"
<script src="@Url.Content("~/Scripts/jquery.validate.unobtrusive.min.js")"

@using (Html.BeginForm()) {
  @Html.HiddenFor(model => model.Id)
  @Html.LabelFor(model => model.FamilyName)
  @Html.TextBoxFor(model =>
    model.FamilyName, new { data_bind = "value: FamilyName" })
  <label>@Html.CheckBoxFor(model =>
    model.IsScary, new { data_bind = "checked: IsScary" })Is scary</label>
  @Html.LabelFor(model => model.Address.Number)
  @Html.TextBoxFor(model =>
    model.Address.Number, new { data_bind = "value: Address.Number" })
  @Html.LabelFor(model => model.Address.Street)
  @Html.TextBoxFor(model =>
    model.Address.Street, new { data_bind = "value: Address.Street" })
  <input type="submit" value="Save" />
  <button data-bind="click : doSomethingNifty">Do something nifty here!</button>

Family info: <span data-bind="text: FamilyInfo"></span>
Full address: <span data-bind="text: FullAddress"></span>

Wat we zien is dat het scherm netjes het ViewModel onderhoudt. De ID is hidden maar de familienaam en adres kunnen gemanipuleerd worden (validatie velden zijn hier weggelaten). We gebruiken hier GEEN gebruik van EditorFor maar van TextBoxFor. Hier is een reden voor! De magie van KnockOut is afhankelijk van de (hier aan de TextBoxFor toegevoegde) HTML5 attribuut DATA-BIND. De ViewEngine liet bij de EditorFor de hier toegevoegde DATA-BIND achterwege. TextBoxFor kent dit probleem niet.

Ook is er met die data-bind iets aan de hand. Zoals je ziet, schijf is die DATA-BIND met een underscore. Dit is een limitatie van Visual Studio, die accepteert geen mintekens in attributen maar een underscore _ wordt door de viewengine automatisch naar een minteken – omgezet.

Vanaf hier begint de knockout implentatie. In dit scherm heb ik drie schermelementen opgenomen die geinteresseerd zijn in wijzigingen op het scherm:

  1. Er is een span opgenomen die geïnteresseerd is in “FamilyInfo”. Die wilt dus bijgewerkt worden als de Familinaam aangepast wordt.
  2. Er is een span opgenomen die geïnteresseerd is in “FullAddress”. Die wilt dus bijgewerkt worden als het adres aangepast wordt.
  3. Er is een button op het scherm (naast de submit button) die op de clickactie de functie “doSomethingNifty” uitvoert

Normaal zouden hiervoor dus drie functies geschreven moeten worden die aan de ‘click’ of ‘change’ van bepaalde controls gehangen zouden worden. Dit zijn dus de controls die de gebruiker aanpast. Welke controls worden er dan gewijzigd? Dat wordt dan in de code bijgehouden…

Enter KnockoutJS. Zoals hier zichtbaar is, hebben we alleen data-bind attributen aan enkele controls toegevoegd.

Dan volgt nu de laatste stap.

We hebben bovenaan in een Scripts sectie (zie de _Layout.cshtml) een verwijzing naar een javascript bestand opgenomen: /Scripts/home.edit.js.

Hier kom ik zo op terug. En we laten de viewengine het totale model omzetten naar een javascript object. Dit is een heel belangrijke stap. De data op van het ViewModel is dus geplaatst in de controls (textboxes, etc.) en het is straks in het browser-geheugen beschikbaar.

Voordat we hier verder op door gaan, wat staat er in de JavaScript:

/// <reference path="jquery-1.6.4-vsdoc.js" />
/// <reference path="knockout-1.3.0beta.debug.js" />
/// <reference path="knockout.mapping-latest.debug.js" />

$(function () {
  var clientViewModel = ko.mapping.fromJS(serverViewModel);

  clientViewModel.FullAddress = ko.dependentObservable(function () {
    return this.Address.Number() + ' ' + this.Address.Street();
  }, clientViewModel);

  clientViewModel.FamilyInfo = ko.dependentObservable(function () {
    return this.Id() + ' ' + this.FamilyName();
  }, clientViewModel);

  clientViewModel.doSomethingNifty = function () {
    if (this.IsScary()) {
    else {
      alert("I could do some Ajax stuff here with Id "
                  + this.Id() + ' and family ' + this.FamilyName());


De referenties bovenaan zijn puur om betere intellisence op de code te krijgen

Wat we hier zien is dat als de webpagina geheel in de browser geladen is, via Knockout Mapping het javascript object met ons server model omgezet wordt naar een Knockout Observable object. Dat is handig en scheelt een hoop handmatig werk.

Aan deze clientViewModel worden twee extra ‘dependent observable’ properties toegevoegd en er wordt een extra functie doSomethingNifty toegevoegd. De functie kan via de ‘this’ bij alle andere properties. Deze drie zagen we ook al genoemd worden bij de bindings op de controls.

En uiteindelijk zien we dat onze clientViewModel dus voor Knockout beschikbaar wordt gesteld. Hierdoor ontstaat binnen de browser een twee-weg binding tussen de inhoud van bv. de textboxen en een verbinding tussen de functie en de button-click.

Alle javascript logica is dus nu gecentraliseerd binnen dit clientviewmodel.

Laten we nu eens kijken of het allemaal werkt. We starten de pagina in de browser

Wat we al gelijk zien is dat de Family info en de Full Address onderaan gesynchroniseerd zijn.

Als we enkele velden wijzigen dan worden de twee spans (en ook alleen die spans) netjes bijgewerkt.

Een click op de extra knop leest ook netjes het Knockout viewmodel uit:

Alles bijbehorende javascript voor deze pagina is dus netjes in één JavaScript bestand beschikbaar met een correcte scheiding tussen de logica (het knockout viewmodel) en de representatie (de controls op de pagina). Geen spaghetti meer!

Hoe nu verder?

Kijk nu nog eens naar de filmpjes

* Helaas kan ik Channel9 filmpjes niet direct integreren 😦

Dus laat je inspireren hoe jij dit framework gaat toepassen.

Er is natuurlijk wel die overhead van een extra object en de mapping. Persoonlijk gebruik ik Knockout vooral op pagina’s waar flink interactief gewerkt wordt, en dit zijn meestal maar een handvol pagina’s binnen een website. De overige pagina’s hebben geen interactie of slechts minimaal, in dat geval is Knockout wat overkill. Maar maak steeds de afweging: als ik nu nog geen Knockout op deze pagina toepas, kan ik het dan straks nog makkelijk integreren?

Succes met KnockOut!

English: Liked the examples but could not understand the Dutch gibberish? Want to know more? Please contact me!