30 September 2015

A Microsoft Band client to read temperatures and control a fan on a Raspberry PI2

Part 6 of Reading temperatures & controlling a fan with a RP2, Azure Service Bus and a Microsoft Band

Intro
In the final post of this series I will show how the Microsoft Band client in this project, that is used to actually read temperatures and control the fan, is created and operated. The client has a tile and a two-page UI, looks like this and can be seen in action in this video from the first blog post:

To recap - the function of the Band client is as follows

  • WhenI tap the tile on the Band, the UI is opened and shows the latest data, that is:
    • The temperature as last measure by the Raspberry PI2
    • A button I can use to toggle the fan. The text on the button reflects the current status of the fan (i.e. it shows "Stop fan" when it's running, and "Start fan" when it is not
    • Date and time of the last received data.

The classes involved
As you can see in the demo solution, there are three classes, and one interface, all living in the TemperatureReader.ClientApp's Models namespace - that have something to do with the Band:

  • BandOperator
  • BandUiController
  • BandUiDefinitions
  • IBandOperator

I showed a little bit of it in the previous post that described the Windows 10 UWP app itself, but to recap: the app is put together using dependency injection, so every class gets everything (well, almost everything) it needs passed via the constructor, and only knows what it gets via an interface (not a concrete class). In addition, most communication goes via events.

Start it up
If you look in the MainViewModel's CreateInstance method, you will see the BandOperator first spring into life:

public static MainViewModel CreateNew()
{
  var fanStatusPoster = new FanSwitchQueueClient(QueueMode.Send);
  fanStatusPoster.Start();
  var listener = new TemperatureListener();
  var errorLogger = SimpleIoc.Default.GetInstance<IErrorLogger>();
  var messageDisplayer = SimpleIoc.Default.GetInstance<IMessageDisplayer>();
  var bandOperator = new BandOperator(fanStatusPoster);
  return (new MainViewModel(
    listener, bandOperator, 
    messageDisplayer, errorLogger));
}

I grayed out the stuff that is not so important here, but you see the BandOperator uses the FanSwitchQueueClient (see explanation in this post) to defer sending data on Azure Service bus to, and then it's passed to the MainViewModel. Apparently some other mechanism is used to deliver temperature data from the Azure Service bus, and that code is found in the Start method of MainViewModel:

private async Task Start()
{
  IsBusy = true;
  await Task.Delay(1);
  _listener.OnTemperatureDataReceived += Listener_OnTemperatureDataReceived;
  _listener.OnTemperatureDataReceived += _bandOperator.HandleNewTemperature;
  await _listener.Start();
  await StartBackgroundSession();
  await _bandOperator.Start();
  await _bandOperator.SendVibrate();
  IsBusy = false;
}

You can see the listener - being a ITemperatureListener, see also this post - simply passes the event to the BandOperator, starts it, and makes the Band vibrate. So you see - the actual code that operates the Band is very loosely coupled to the rest of the app. But what you also see - the Band does not listen to the data coming form the Azure Service Bus, nor does it send data. That app does that interaction, and the Band - in turn - interacts with the app.

Some definitions first
What is important to understand is that the UI lives on the Band, an remains there. Changing it, and responding to events, is essentially a process that runs on your phone, not on the Band, and you are interacting with a process that sends data over Bluetooth - but that is mostly abstracted away. Building a Band UI is also vastly different from what you are used to, using XAML. You are basically writing code to build the structure of the UI, then fill it with data using even more code. There is no such things as data binding. All UI elements have to be defined using unique identifiers - no such things as easily recognizable names. It harkens back to ye olden days from even before Visual Basic.

Anyway, there is this separate definition class that contains all the necessary ids:

using System;

namespace TemperatureReader.ClientApp.Models
{
  public static class BandUiDefinitions
  {
    public static readonly Guid TileId = 
      new Guid("567FF10C-E373-4AEC-85B4-EF30EE294174");
    public static readonly Guid Page1Id = 
      new Guid("7E494E17-B498-4610-A6A6-3D0C3AF20226");
    public static readonly Guid Page2Id = 
      new Guid("BB4EB700-A57B-4B8E-983B-72974A98D19E");

    public const short IconId = 1;
    public const short ButtonToggleFanId = 2;
    public const short TextTemperatureId = 3;
    public const short TextTimeId = 4;
    public const short TextDateId = 5;
  }
}

So we have three main UI ids - the tile, and both 'pages', that need to have a GUID. I just generated a few using Visual Studio, what GUID you use does not really matter - they need to be different from each other and refrain from re-using them - even over projects. Then there's five user interface elements.

  • On the first page - the one you see when you tap the tile: the thermometer icon, the button to turn the fan on or off (also used to show the current fan status), and the label that shows the temperature as measured by the Raspberry PI2
  • On the second page two label fields, that show the time and the date of the last received update from the Azure Service Bus as received by the App.

The UI looks like this:

IMG_2288
The tile that you can tap

IMG_2289
The first page, with icon, temperature reading and button. The button now says "Start fan", so apparently the app has already received date from the Raspberry PI2, and it indicated the fan is off. Notice a little part of the second page is already visible on the right, alerting the user there's more to be seen and encouraging him to scroll to the right - a UI pattern in use since the very early days of Windows Phone 7.

IMG_2290

The second page (with date and time of last received data)

The user interface element ids are just just integers, but I make them globally unique - that is, unique in the app. The fact that they are spread over two 'pages' comes from the fact that the Band has a very small display, and you will need to make use of it's multi-page features if you want to show anything but the most trivial data. Fortunately, once you understand how it works, that is not very hard to do.

Building the Band client UI
I have separated the actual operating building and manipulating of the Band UI from the 'business logic' concerning the interaction with events coming from the Azure Service Bus. So we have the BandUiController and the BandOperator. A crude and not completely correct analogy could define the BandUIController as the view, and the BandOperator as a kind-of-viewmodel. I did this because at one point I had a class approaching 300 lines and things got very confusing. So I split it up. I show only a little excerpt of the BanOperator before I start explaining the BandUIController first.

The BandUIController needs access to a IBandClient to be able to work on the Band's UI. You need to retrieve one first. How this works, you can see in the BandOperator's GetNewBandClient method:

var pairedBands = await BandClientManager.Instance.GetBandsAsync();
if (pairedBands != null && pairedBands.Any())
{
  return await BandClientManager.Instance.ConnectAsync(pairedBands.First());
}

And this IBandClient is injected into the BandUIController via the constructor. We have seen this pattern before in this series

public class BandUiController
{
  private readonly IBandClient _bandClient;

  public BandUiController(IBandClient bandClient)
  {
    _bandClient = bandClient;
  }
}

The next important thing to understand is that although both occur from code, defining the Band interface and actually displaying stuff in it are two separate actions. The public interface of the BandUIController actually only has four methods - and one of them is an overload of another:

public async Task<bool> BuildTile();
public async Task RemoveTile();
public async Task SetUiValues(string timeText, string dateText, 
                              string temperature, string buttonText);
public async Task SetUiValues(string temperature, string buttonText);

The first one builds the tile (and the rest of the UI), the second one removes it. The third one sets all the UI elements' value, the second one only that of the elements on the first page - that is used for when you press the button to switch the fan on or off. So let's have a look at BuildTile first.

public async Task<bool> BuildTile()
{
  if (_bandClient != null)
  {
    var cap = await _bandClient.TileManager.GetRemainingTileCapacityAsync();
    if (cap > 0)
    {
      var tile = new BandTile(BandUiDefinitions.TileId)
      {
        Name = "Temperature reader",
        TileIcon = await LoadIcon("ms-appx:///Assets/TileIconLarge.png"),
        SmallIcon = await LoadIcon("ms-appx:///Assets/TileIconSmall.png"),
      };

      foreach (var page in BuildTileUi())
      {
        tile.PageLayouts.Add(page);
      }
      await _bandClient.TileManager.AddTileAsync(tile);
      await _bandClient.TileManager.RemovePagesAsync(BandUiDefinitions.TileId);
      await _bandClient.TileManager.SetPagesAsync(BandUiDefinitions.TileId, 
        BuildIntialTileData());
      return true;
    }
  }
  return false;
}

imageFirst thing you need to do is check remaining tile space capability. There's only room for up to 13 custom tiles, so chances are there's not enough room. If there is no space, this client silently fails. But if there's room, the tile is created with the designated GUID, a big and a small icon. The big icon appears on the tile, the small icon is typically used on notifications, but both can be used otherwise (as we will see later). "Large" is maybe stretching it a little as it's only 46x46 (the small one is 24x24). "LoadIcon" is a little routine that loads the icon and I nicked those from the Band samples. Then the tile UI pages are being built using BuildTileUi, and are added to the tile's PageLayout collection. So far, so good. Then things get a little murky.

  • First we add the tile - with page definitions - to the Band UI. By default, it is added to the very right side of the tile strip - just before the settings gear tile.
  • Then we remove any possible data possibly associated with the pages using RemovePagesAsync. Remember, this is not the structure, just what is being displayed on it. I am not 100% sure this line of code is actually needed, but I just left it while experimenting
  • Then we are adding the default data to display on the tile pages' UI elements using SetPagesAsync

Let's first have a look at BuildTileUi

private IEnumerable<PageLayout> BuildTileUi()
{
  var bandUi = new List<PageLayout>();
  
  var page1Elements = new List<PageElement>
  {
    new Icon {ElementId = BandUiDefinitions.IconId, 
Rect = new PageRect(60,10,24,24)},
new TextBlock {ElementId = BandUiDefinitions.TextTemperatureId, Rect = new PageRect(90, 10, 50, 40)}, new TextButton {ElementId = BandUiDefinitions.ButtonToggleFanId, Rect = new PageRect(10, 50, 220, 40), HorizontalAlignment = HorizontalAlignment.Center} }; var firstPanel = new FilledPanel(page1Elements) {
Rect = new PageRect(0, 0, 240, 150) }; var page2Elements = new List<PageElement> { new TextBlock {ElementId = BandUiDefinitions.TextTimeId, Rect = new PageRect(10, 10, 220, 40)}, new TextBlock {ElementId = BandUiDefinitions.TextDateId, Rect = new PageRect(10, 58, 220, 40)} }; var secondPanel = new FilledPanel(page2Elements) {
Rect = new PageRect(0, 0, 240, 150) }; bandUi.Add(new PageLayout(firstPanel)); bandUi.Add(new PageLayout(secondPanel)); return bandUi; }

Now this may look a bit intimidating, but it's actually not so hard to read.

  • First we create the UI elements of the firstpage - an Icon, a TextBlock, and a TextButton, all with location and size defined by a PageRect, relative to the panel they are going to be in.
  • Then we create the first panel, add the list of the UI elements created in the previous step on it, then define it's size and location by a PageRect as well. I am not exactly sure what the maximum values are for a panel, but 240, 150 works out nice and leaves enough space to the right to make the next page visible
  • Then we create the UI elements of the second panel - two TextBlocks of identical size, the second one right under the first
  • Then we create a second panel with the same size as the first panel
  • Finally, we create a PageLayout  from both panels and add those to the list.

As we could see in the BuildTile method the result of the BuildTileUi method is added the tile's PageLayouts collection:

foreach (var page in BuildTileUi())
{ tile.PageLayouts.Add(page); }

At this point, we have only defined the structure of what is to be displayed on the Band. It still does not display any data.

Showing data on a Band UI
Let's have a look at BuildTile again. It's using this line of code to display data

 await _bandClient.TileManager.SetPagesAsync(BandUiDefinitions.TileId,
BuildIntialTileData());
BuildIntialTileData. that just shows some default strings, in turn calls this method
private List<PageData> BuildTileData(string timeText, string dateText, 
                                     string temperature, string buttonText)
{
  var result = new List<PageData>
  {
    BuildTileDataPage2(timeText, dateText),
    BuildTileDataPage1(temperature, buttonText)
  };
  return result;
}

And then we come to the heart of the matter (as far as displaying data is concerned) - that is, these two little methods:

private PageData BuildTileDataPage1(string temperature, string buttonText)
{
  return 
    new PageData(
      BandUiDefinitions.Page1Id, 0, 
      new IconData(BandUiDefinitions.IconId, 1),
      new TextButtonData(BandUiDefinitions.ButtonToggleFanId, buttonText),
      new TextBlockData(BandUiDefinitions.TextTemperatureId, $": {temperature}"));
}

private PageData BuildTileDataPage2(string timeText, string dateText)
{
  return 
    new PageData(BandUiDefinitions.Page2Id, 1,
      new TextBlockData(BandUiDefinitions.TextTimeId, $"Time: {timeText}"),
      new TextBlockData(BandUiDefinitions.TextDateId, $"Date: {dateText}"));
}

Let's first dissect BuildTileDataPage2 as that is the most simple to understand. This says, basically: for page with Page2Id, which is the 2nd page on this UI (the page numbering  is zero based) set a text on a TextBlock with id BandUiDefinitions.TextTimeId, and set another text for BandUiDefinitions.TextDateId. The third parameter of the PageData constructor is of type params PageElementData[] so you can just go on adding user interface value settings to that constructor without the need of defining a list.

In BuildTileDataPage1 we do something similar - bar that the page index now is 0 in stead of 1, a text on a TextButton needs to be of TextButtonData in stead of TextBlockData. and the first item is an IconData. Notice that it adds an icon with index 1. That is the small icon. Remember this piece of code in BuildTile?

var tile = new BandTile(BandUiDefinitions.TileId)
{
  Name = "Temperature reader",
  TileIcon = await LoadIcon("ms-appx:///Assets/TileIconLarge.png"),
  SmallIcon = await LoadIcon("ms-appx:///Assets/TileIconSmall.png")
};

That was added as second, but of course that's zero based as well. You can also add additional icons to the UI but that's not covered here.

Now there is one important final piece of information that you may not have noticed. In BuildTileData I first add the second pagedata to the list, and then the first. I found it necessary to do it that way, or else the UI appears in reverse order (that is, the page with the date/time is displayed initially, and you have to scroll sideways for the page with the button and the temperature. Sometimes, just sometimes it happens the wrong way around anyway. I have not been able to determine what causes this, but if you add the pagedata in reverse order, it works most times - like in, I saw it go wrong two or three times, and only during heavy development.

The public methods to change the UI values are very simple wrappers around code we have already seen:

public async Task SetUiValues(string timeText, string dateText, 
                              string temperature, string buttonText)
{
  var pageData = BuildTileData(timeText, dateText, temperature, buttonText);
  await _bandClient.TileManager.SetPagesAsync(BandUiDefinitions.TileId, pageData);
}

public async Task SetUiValues(string temperature, string buttonText)
{
  await
    _bandClient.TileManager.SetPagesAsync(BandUiDefinitions.TileId,
       BuildTileDataPage1(temperature, buttonText));
}

The first one refreshes the whole UI, the second only the first page. So that is what is necessary to create a UI and display some data on it. Four UI elements, two pages. Really makes you appreciate XAML, doesn't it? ;)

Handling Band interaction
The BandOperator bascially only has the following functions:

  • When a tile is pressed, show the Band UI with the most recent data received from the Azure Service bus
  • When the toggle button is pressed fire off a command on the Azure Service bus
  • When the fan status change is confirmed by the Raspberry PI2, toggle the text on the button

... and yet, it's almost 250 lines long. A lot of that has to do with problems I encountered when a suspended app was resuming. I have tried to fix that using quite an elaborate method to get and create a Band client (the GetBandClient method) - that and it's helper methods are 60 lines in itself. So I will skip over that, but have a look at it in the demo solution to see how I tried to solve this. I am still not quite satisfied with it, but it seems to work. Most of the times.

Moving to the BandOperator's Start method, you can see how the interaction is set up

public async Task<bool> Start(bool forceFreshClient = false)
{
  var tilePresent = false;
  var bandClient = await GetBandClient(forceFreshClient);
  if (bandClient != null)
  {
    var currentTiles = await bandClient.TileManager.GetTilesAsync();
    var temperatureTile = currentTiles.FirstOrDefault(
      p => p.TileId == BandUiDefinitions.TileId);
    if (temperatureTile == null)
    {
      var buc = new BandUiController(bandClient);
      tilePresent = await buc.BuildTile();
    }
    else
    {
      tilePresent = true;
    }

    if (tilePresent)
    {
      await bandClient.TileManager.StartReadingsAsync();
      bandClient.TileManager.TileOpened += TileManager_TileOpened;
      bandClient.TileManager.TileButtonPressed += TileManager_TileButtonPressed;
    }
  }
  IsRunning = tilePresent;
  return tilePresent;
}

Basically this methods tries to either find an existing tile, and failing that, create a BandUiController to make one. bandClient.TileManager.StartReadingsAsync then activates listening to Band events - and by attaching events to TileOpened and TileButtonPressed the handler methods will be called - if the tile on the Band UI button is pressed, or if a button on the custom UI of the tile is pressed.

private async void TileManager_TileOpened(object sender, 
  BandTileEventArgs<IBandTileOpenedEvent> e)
{
  var bandClient = await GetBandClient();
  if (bandClient != null)
  {
    if (e.TileEvent.TileId == BandUiDefinitions.TileId && _lastTemperatureData != null)
    {
      var buc = new BandUiController(bandClient);
      await buc.SetUiValues(
        _lastTemperatureData.Timestamp.ToLocalTime().ToString("HH:mm:ss"),
        _lastTemperatureData.Timestamp.ToLocalTime().ToString("dd-MM-yyyy"),
         $"{_lastTemperatureData.Temperature}°C",
         GetFanStatusText());
      await bandClient.NotificationManager.VibrateAsync(
         VibrationType.NotificationOneTone);
    }
  }
}

So the funny thing is - this method gets called when a tile is pressed on the Band. Any tile, not necessarily the one just created. So first we have to determine if it was actually our tile that was being pressed, by checking the tile id against the id of our tile. When that is the case, we create a BandUIController and update the UI values with the last received data from the Azure Service bus. And then we send a single vibration, so the Band wearer knows new data was received immediately (without checking the date and time on the 2nd page of our custom UI).

A similar procedure goes for the handling of the fan button press:

private async void TileManager_TileButtonPressed(object sender, 
   BandTileEventArgs<IBandTileButtonPressedEvent> e)
{
  var te = e.TileEvent;
  if (te.TileId == BandUiDefinitions.TileId && 
    te.PageId == BandUiDefinitions.Page1Id && 
    te.ElementId == BandUiDefinitions.ButtonToggleFanId)
  {
    if (!_isProcessing)
    {
      _lastToggleUse = DateTime.UtcNow;
      _isProcessing = true;
      var cmd = new FanSwitchCommand(_lastFanStatus, true);
      Debug.WriteLine($"Sending fan command {cmd.Status}");
      await UpdateFirstPageStatus();
      await _fanStatusPoster.PostData(cmd);
    }
  }
}

First, we need to check if the button was pressed on our custom layout  - in theory, that would have been enough as there is only one button on it, but for good measure you can also check for the page and the element id in that page. What then basically happens is that text of the button is changed to "Processing" and a FanSwitchCommand is sent to the Raspberry PI2.

The changing of the text on the button is done via UpdateFirstPageStatus, that in turn uses GetFanStatusText

private async Task UpdateFirstPageStatus()
{
  var bandClient = await GetBandClient();
  if (bandClient != null)
  {
    var text = GetFanStatusText();
    var buc = new BandUiController(bandClient);
    await buc.SetUiValues($"{_lastTemperatureData.Temperature}°C", text);
  }
}

private string GetFanStatusText()
{
  return _isProcessing ? "Processing" : 
    _lastTemperatureData.FanStatus == FanStatus.On ? "Stop fan" : "Start fan";
}

The logic behind this is as follows:_isProcessing used to prevent the user from pressing the toggle button multiple times in a row. When you press the button, one of the first things that happens is that _isProcessing is set to true, effectively barring you from doing something with the button again. The text on the button changes to "Processing". The BandOperator is now waiting for the Raspberry PI2 to confirm it has actually toggled the fan. But you cannot change the value of one UI element on a Band page - you have to refresh all of them. So I call the BandUiController's SetUiValues overload with both the new button text and the last received temperature.

So how is the loop closed? How does the BandOperator know the Raspberry PI2 has indeed toggled the fan? The answer lies in the HandleNewTemperature method that receives new temperature data from the rest of the app (remember that it was wired up in MainViewModel.Start?)

public async void HandleNewTemperature(object sender, TemperatureData data)
{
  Debug.WriteLine(
    $"New temperature data received {data.Temperature} fanstatus = {data.FanStatus}");
  _lastTemperatureData = data;
  _lastTemperatureData.Timestamp = DateTimeOffset.UtcNow;
  if (_lastFanStatus != _lastTemperatureData.FanStatus && _isProcessing)
  {
    _isProcessing = false;
    _lastFanStatus = _lastTemperatureData.FanStatus;
    await UpdateFirstPageStatus();
  }
  else if (_lastToggleUse.IsSecondsAgo(Settings.FanSwitchQueueTtl) && _isProcessing)
  {
    _isProcessing = false;
    _lastFanStatus = _lastTemperatureData.FanStatus;
    await UpdateFirstPageStatus();
  }
  else if (!_isProcessing)
  {
    _lastFanStatus = _lastTemperatureData.FanStatus;
  }
}

So, the received temperature data does not only contain temperature but also the current status of the fan. But if this method was to accept the fan status right away after we had sent off a command to toggle the fan, the button text would immediately flip back to the old text - because the command had not reached the Raspberry PI2 yet, and it would not have time to react and send a confirmation.

So what we do is - when new temperature data arrives, _isProcessing is true (so the user has recently clicked the toggle button) and the received data indicates a status flip - then the Raspberry PI2 has received the toggle command and has acted upon it. So the button is updated from "Processing" to a value according the new fan status. If there is no status change, but the last toggle button use was longer ago then the message time-to-live of the FanSwitchQueue - we assume the command has never reached the Raspberry PI2, we update the _lastFanStatus to the old status, and update the button accordingly. In any other cases, if the user has not pressed the button recently, we just keep the last fan status. This has not much to do with the Band or the UI itself - it's just dealing with possible delays from message delivery (and possible messages not being received by the other party).

Conclusion
Making a custom Band UI is doable, but you do need to pay a lot of attention to detail to get things right. It's definitely more challenging than creating a UI using Blend, as you basically need to keep seeing the whole UI in your mind - there is no way of visually designing it or even make it visible short of running the app and checking the result on the Band. Debugging is a time and battery consuming activity. Acting upon events and having code interact with remote devices has some particular challenges too. And sometimes things just go wrong - but it is not always clear if those things were caused by me doing things wrong or not understanding the finer details of the Band UI API, the fact that I am using it on Windows 10 mobile (which is still in preview at this moment) or bugs in the various APIs (Band or otherwise) that I use to stitch things together. On the bleeding edge is where you suffer pain - but you have the most fun as well.

And yet, the potential use cases are pretty appealing and  are giving a nice idea of how the (very near) future of device coding with Windows CoreIoT looks like. And it has practical appliances too. Recently I was on a holiday in Neustadt an der Weinstraße (where amongst others this blog post was written so the sample location was not entirely random :) ) I had this contraption running at home - but I had put in in my study at home and had connected it to a powerful spot light in stead of a fan. I had my Lumia 1520 and Band with me - and although being physically in Germany, I was able to turn on a light at home (and get confirmation it was actually on or off) by clicking a button on my Band. Thus hopefully convincing potential burglars the house's resident geek was at his computer and the house was occupied. Not that there's much worth stealing anyway, but it's not fun to get home and find broken windows and stuff. If it had any effect - I don't know, but our house was left alone during our absence.

Well, this marks the end of a rather epic and quite voluminous blog post series.I encourage you one final time to download and check the demo solution - and build kick *ss stuff yourself with CoreIoT and/or the Band. Even Doctor Who is into wearable technology these days, and so should we all be :D

23 September 2015

A Windows 10 UWP app to receive temperature data from a Raspberry PI2 and control a fan using the Azure Service Bus

Part 5 of Reading temperatures & controlling a fan with a RP2, Azure Service Bus and a Microsoft Band

imageIntro
You cannot deploy apps to a Microsoft Band directly, so there is always a kind of app running on the device to which it is paired on which the code is actually running. Typically this is a phone, but there since this is a Universal Windows App, there is no reason why it could not run on a PC, like this screenshot shows :). Yet, I have found out that although you can pair a Band to a PC, it will insist on connecting to the app before showing a UI, so you cannot actually use it with a PC. So for the time being, you should use a phone.

This blog post will talk about the setup of the app itself, actually excluding most of the stuff related to the Band - and concentrate on how to setup a reasonably componentized app.

This app also uses dependency injection, as discussed in my post about the app on the Raspberry PI2, but this one makes full use of the MVVM pattern - to be more specific, MVVMLight, by my fellow MVP (although I can barely stand in his shade)  Laurent Bugnion. I make use of his ViewModelBase and Messenger, as well as SimpleIoC for some inversion of control, and DispatcherHelper to get help me solve potential issues with background processes having effects on the UI.

Basic app setup
The app starts (of course) in App.xaml.cs, of which I show a little excerpt:

public App()
{
  SimpleIoc.Default.Register<IMessageDisplayer, Toaster>();
  SimpleIoc.Default.Register<IErrorLogger, ErrorLogger>();
  InitializeComponent();
  Suspending += OnSuspending;
  UnhandledException += SimpleIoc.Default.
    GetInstance<IErrorLogger>().LogUnhandledException;
  UnhandledException += App_UnhandledException;
  Resuming += App_Resuming;
}

private void App_Resuming(object sender, object e)
{
  Messenger.Default.Send(new ResumeMessage());
}

private void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
  SimpleIoc.Default.GetInstance<IMessageDisplayer>().
    ShowMessage ($"Crashed: {e.Message}");
}

protected override void OnLaunched(LaunchActivatedEventArgs e)
{
  DispatcherHelper.Initialize();
  MainViewModel.Instance.Init();
  // stuff omitted
}

The first two lines mean that whenever something requests something implementing an IMessageDisplayer, send him a Toaster. A similar thing goes for IErrorLogger. Retrieving something is a easy as using GetInstance - see App_UnhandledException. Toaster is a simple class to show a toast message, ErrorLogger is something I wrote for logging errors in local storage - for long running processes. Notice also the use of the Messenger in the App_Resuming. This is all part of making the viewmodel aware of things it needs to know, which ever making a direct dependency

If you use MVVMLight's DispatcherHelper, don't forget to initialize it (I always do for some reason, fortunately the error message is clear enough) and then I initialize my main viewmodel. Which, since this is a simple app, is the only viewmodel as well ;)

Bootstrapping the viewmodel
The part of the viewmodel that handles startup and initializing is this:

using System;
using System.Globalization;
using System.Threading.Tasks;
using Windows.ApplicationModel.ExtendedExecution;
using Windows.Devices.Geolocation;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Ioc;
using GalaSoft.MvvmLight.Messaging;
using GalaSoft.MvvmLight.Threading;
using TemperatureReader.ClientApp.Helpers;
using TemperatureReader.ClientApp.Messages;
using TemperatureReader.ClientApp.Models;
using TemperatureReader.ServiceBus;

namespace TemperatureReader.ClientApp.ViewModels
{
  public class MainViewModel : ViewModelBase
  {
    private readonly ITemperatureListener _listener;
    private readonly IBandOperator _bandOperator;
    private readonly IMessageDisplayer _messageDisplayer;
    private readonly IErrorLogger _errorLogger;

    public MainViewModel(ITemperatureListener listener, 
      IBandOperator bandOperator, 
      IMessageDisplayer messageDisplayer, 
      IErrorLogger errorLogger)
    {
      _listener = listener;
      _bandOperator = bandOperator;
      _messageDisplayer = messageDisplayer;
      _errorLogger = errorLogger;
    }

    public void Init()
    {
      Messenger.Default.Register<ResumeMessage>(this, 
        async msg => await OnResume());
    }
    
    // lots omitted

    private static MainViewModel _instance;

    public static MainViewModel Instance
    {
      get { return _instance ?? (_instance = CreateNew()); }
      set { _instance = value; }
    }

    public static MainViewModel CreateNew()
    {
      var fanStatusPoster = new FanSwitchQueueClient(QueueMode.Send);
      fanStatusPoster.Start();
      var listener = new TemperatureListener();
      var errorLogger = SimpleIoc.Default.GetInstance<IErrorLogger>();
      var messageDisplayer = SimpleIoc.Default.GetInstance<IMessageDisplayer>();
      var bandOperator = new BandOperator(fanStatusPoster);
      return (new MainViewModel(
        listener, bandOperator, 
        messageDisplayer, errorLogger));
    }
  }
}
And here you see once again creation of a number of independent objects that will only be loosely connected. I could have gone further and let these also be created by having them registered in SimpleIoC, but the constructor will also allow me to 'inject' these objects into the viewmodel. Anyway, we see being created:
  • a FanSwitchQueueClient, that will transport the command to switch the fan on or off to the Raspberry PI2 via the Azure Service bus. It's details were explained in the 2nd post of this series. It's now in Send mode, as opposed to the app on the Raspberry PI2.
  • TemperatureListener listens to temperature data coming from the Raspberry PI2. It's a thin wrapper around TemperatureQueueClient (also explained in in the 2nd post of this series)
  • An ErrorLogger, which I will describe in a future blog post
  • A MessageDisplayer - it's implementation being something that shows a toast, as already mentioned
  • A BandOperator - a class that handles all interactions with the Microsoft Band as far as this app is concerned. This will be handled in detail in the next blog post. Notice it takes a FanSwitchQueueClient as a parameter - the BandOperator itself will handle the posting of the fan switch command (and defer the actual execution to the FanSwitchQueueClient).

For now, it's good enough to know the BandOperator has a very limited public interface, that looks like this:

public interface IBandOperator
{
  Task<bool> Start(bool forceFreshClient = false);
  Task SendVibrate();
  Task Stop ();
  Task RemoveTile();
  void HandleNewTemperature(object sender, TemperatureData data);
  bool IsRunning { get; }
}

TemperatureListener
This is basically a very thin wrapper around the TemperatureQueueClient, that only adds 'remembering' the queue's status to the basic functionality:

public class TemperatureListener : ITemperatureListener
{
  private readonly TemperatureQueueClient _client;
  public TemperatureListener()
  {
    _client = new TemperatureQueueClient(QueueMode.Listen);
    _client.OnDataReceived += ProcessTemperatureData;
 }

  private void ProcessTemperatureData(object sender, 
    TemperatureData temperatureData)
  {
    OnTemperatureDataReceived?.Invoke(this, temperatureData);
  }

  public async Task Start()
  {
    await _client.Start();
    IsRunning = true;
  }

  public bool IsRunning { get; private set; }

  public void Stop()
  {
    _client.Stop();
    IsRunning = false;
  }

  public event EventHandler<TemperatureData> OnTemperatureDataReceived;
}
Note that it puts the TemperatureQueueClient in Listen mode - this is again exactly the mirror image from what is happening on the Raspberry PI2

The view model's public interface - aka what is used for data binding
These 5 properties - and the one method - are the only things that are available to the 'outside world' as far as the main view model is concerned:

public async Task RemoveTile()
{
  IsBusy = true;
  await Task.Delay(1);
  await _bandOperator.RemoveTile();
  IsBusy = false;
}

public bool IsListening
{
  get
  {
    return _listener?.IsRunning ?? false;
  }
  set
  {
    if (_listener != null)
    {
      if (value != _listener.IsRunning)
      {
        Toggle();
      }
    }
  }
}

private string _temperature = "--.-";
public string Temperature
{
  get { return _temperature; }
  set { Set(() => Temperature, ref _temperature, value); }
}

private string _lastDateTimeReceived = "--:--:--   ----------";
public string LastDateTimeReceived
{
  get { return _lastDateTimeReceived; }
  set { Set(() => LastDateTimeReceived, ref _lastDateTimeReceived, value); }
}

private string _fanStatus = "???";
public string FanStatus
{
  get { return _fanStatus; }
  set { Set(() => FanStatus, ref _fanStatus, value); }
}

private bool _isBusy;
public bool IsBusy
{
  get { return _isBusy; }
  set { Set(() => IsBusy, ref _isBusy, value); }
}

The method "RemoveTile" is called to remove the custom tile from the Band and is bound to the button labeled as such. IsListening is bound to the toggle switch, IsBusy is bound to the progress ring and the semi-transparent overlay that will appear while you switch the toggle, and the rest of the properties are just display properties.

There is a single call to the BandOperator - later we will see more. The public interface for a BandOperator is very limited, as are the interface for all the classes in this project:

public interface IBandOperator
{
  Task<bool> Start(bool forceFreshClient = false);
  Task SendVibrate();
  Task Stop ();
  Task RemoveTile();
  void HandleNewTemperature(object sender, TemperatureData data);
  bool IsRunning { get; }
}

And that is all you need to know from the BandOperator for this blog post.

MVVMLight aficionados like me might notice that our good friend RelayCommand is MIA. This is because in the XAML I use the new x:Bind syntax, as you might have seen in this StackPanel in MainPage.xaml that show most of the text being displayed:

<StackPanel Grid.Row="2" Margin="0,0,0,16" Orientation="Vertical">
  <TextBlock  HorizontalAlignment="Center" FontSize="30" Margin="0"  >
    <Run Text="{x:Bind ViewModel.Temperature, FallbackValue=--.-, Mode=OneWay}" />
    <Run Text="°C" />
  </TextBlock>
  <TextBlock  HorizontalAlignment="Center" FontSize="15" Margin="0"  >
    <Run Text="Fan is" />
    <Run Text="{x:Bind ViewModel.FanStatus, FallbackValue=--.-, Mode=OneWay}" />
  </TextBlock>
  <TextBlock Text="{x:Bind ViewModel.LastDateTimeReceived, 
           FallbackValue=--:--:--   ----------, Mode=OneWay}" 
           FontSize="10" HorizontalAlignment="Center"></TextBlock>
</StackPanel>
This new way of binding allows to directly binding public viewmodel methods to events happening in the user interfaced, so we don't need a command anymore:
<Button Grid.Row="5" Click="{x:Bind ViewModel.RemoveTile}"  
  Content="Remove tile from Band" HorizontalAlignment="Center"/>

Detailed information on how to bind events directly to events can be found here. In order to be able to use x:Bind, the object to bind to needs to be a public property of the code behind class. This you can see in MainPage.xaml.cs:

public MainViewModel ViewModel
{
  get { return MainViewModel.Instance; }
}

Starting and stopping
As you can see from IsListening, there should be a Toggle method that is kicked off when the IsListening property is set. There is one indeed, and it - and it's friends - are implemented like this:

private async Task Toggle()
{
  if (_listener.IsRunning)
  {
    await Stop();
  }
  else
  {
    await Start();
  }
  RaisePropertyChanged(() => IsListening);
}

private async Task Start()
{
  IsBusy = true;
  await Task.Delay(1);
  _listener.OnTemperatureDataReceived += Listener_OnTemperatureDataReceived;
  _listener.OnTemperatureDataReceived += _bandOperator.HandleNewTemperature;
  await _listener.Start();
  await StartBackgroundSession();
  await _bandOperator.Start();
  await _bandOperator.SendVibrate();
  IsBusy = false;
}

private async Task Stop()
{
  IsBusy = true;
  await Task.Delay(1);
  _listener.OnTemperatureDataReceived -= Listener_OnTemperatureDataReceived;
  _listener.OnTemperatureDataReceived -= _bandOperator.HandleNewTemperature;
  _listener.Stop();
  await _bandOperator.Stop();
  _session.Dispose();
  _session = null;
  IsBusy = false;
}

private void Listener_OnTemperatureDataReceived(object sender, 
  Shared.TemperatureData e)
{
  if (e.IsValid)
  {
    DispatcherHelper.CheckBeginInvokeOnUI(() =>
    {
      Messenger.Default.Send(new DataReceivedMessage());
      Temperature = e.Temperature.ToString(CultureInfo.InvariantCulture);
      LastDateTimeReceived = 
        e.Timestamp.ToLocalTime().ToString("HH:mm:ss   dd-MM-yyyy");
      FanStatus = e.FanStatus == Shared.FanStatus.On ? "on" : "off";
    });
  }
}

Start basically kicks the whole thing off. I have found out that unless you specifiy the Task.Delay(1), setting IsBusy does not have any effect on the UI. Once, and I am literally talking the previous century here, I used DoEvents() in Visual Basic (6, yes) that had exactly the same effect ;) - now you get to see the progress ring and the overlay on the rest of the UI. Both this viewmodel and the bandoperator are made to listen to incoming temperature events on the TemperatureListener, and that TemperatureListener is started then. The bandoperator can do with it whatever it wants. Then we start a 'background session' to keep the app alive as long as possible. Then the band operator is started - this will in effect create a tile and a user interface on the connected Band, if that is not already there, and the Band will be made to vibrate. The application is running now.

Finally, in the viewmodel's Listener_OnTemperatureDataReceived method the data is put on the phone's screen and then passed around in a message to interested parties

Stop, of course, neatly disconnects all events again and stops all the components.

Flow of events
Summarizing: temperature data flows like this:
TemperatureQueueClient.OnDataReceived -> TemperatureListener.OnTemperatureDataReceived ->
MainViewModel.Listener_OnTemperatureDataReceived + Messenger + BandOperator.HandleNewTemperature

And commands to switch of the fan flow like this:
BandOperator -> FanSwitchQueueClient.PostData

And the rest is done via data binding. How the BandOperator exactly works merits a separate blog post, that will end this series.

Keeping the app alive
If you hit the ToggleSwitch that is labeled "Get temperature data" you will notice Windows 10 mobile asks you to allow the app to track your location. This is in essence a trick to keep the app alive as long as possible - as I said before, the code to make the Band UI work runs on your phone but only does so to as long as the app is running ( and not suspended). I use ExtendedExecutionSession to trick your phone to think this app is tracking location in the background and should be kept alive as long as possible.

private ExtendedExecutionSession _session;
private async Task<bool> StartBackgroundSession()
{
  if (_session != null)
  {
    try
    {
      _session.Dispose();
    }
    catch (Exception){}
  }
  _session = null;
  {
    _session = new ExtendedExecutionSession
    {
      Description = "Temperature tracking",
      Reason = ExtendedExecutionReason.LocationTracking
    };
    StartFakeGeoLocator();

    _session.Revoked += async (p, q) => { await OnRevoke(); };

    var result = await _session.RequestExtensionAsync();
    return result != ExtendedExecutionResult.Denied;
  }
  return false;
}

private async Task OnRevoke()
{
  await StartBackgroundSession();
}

I think using ExtendedExecutionSession was first described by my fellow MVP Morten Nielsen in this article. I also got some usage guidance on this from my friend Matteo Pagani. In this demo I am clearly misusing ExtendedExecutionSession, yet it kind of does the trick - the app is not suspended right away (as happens with a lot of normal apps) but is more or less kept alive, until the phone needs the CPU and/or memory and suspends it after all. So this trick only delays the inevitable, but for demo purposes it is good enough. A probably better way is described in this article by James Croft, which uses a DeviceUseTrigger.

The StartFakeGeolocator does nothing special but creating a Geolocator that listens to location changes but does nothing with it. Have a look at the sources in the demo solution if you are interested.

Suspend and resume
If the suspend request then finally comes, I neatly shut down the BandOperator for if I don't, all kinds of errors regarding accessing of already disposed native objects pop up. But it also shows a message (that is, a toast) that, when tapped, can be used to easily restart the app again and then OnResume kicks in.

public async Task OnSuspend()
{
  if (_bandOperator != null && _bandOperator.IsRunning)
  {
    await _bandOperator.Stop();
    await _messageDisplayer.ShowMessage("Suspended");
  }
}

public async Task OnResume()
{
  if ( IsListening && _bandOperator != null)
  {
    try
    {
      IsBusy = true;
      await Task.Delay(1);
      await StartBackgroundSession();
      await _bandOperator.Start(true);
      await _bandOperator.SendVibrate();
      IsBusy = false;

    }
    catch (Exception ex)
    {
      await _errorLogger.LogException(ex);
      await _messageDisplayer.ShowMessage($"Error restarting Band {ex.Message}");
    }
  }
}

Upon resuming , I only need to restart BandOperator again (and a fake Geolocator for good measure).

BlinkBehavior
As I already showed, TemperatureData is also broadcasted on the MVVMLight Messenger when it is received. This is for good reasons - I want the circle in the middle blink up in accent color when data is received. That is accomplished by a behavior listening to that very message:

using System.Threading.Tasks;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Media;
using Windows.UI.Xaml.Shapes;
using GalaSoft.MvvmLight.Messaging;
using Microsoft.Xaml.Interactivity;
using TemperatureReader.ClientApp.Messages;

namespace TemperatureReader.ClientApp.Behaviors
{
  public class BlinkBehavior : DependencyObject, IBehavior
  {
    private Shape _shape;
    private Brush _originalFillBrush;
    private readonly Brush _blinkBrush = 
      Application.Current.Resources["SystemControlHighlightAccentBrush"] as SolidColorBrush;

    public void Attach(DependencyObject associatedObject)
    {
      AssociatedObject = associatedObject;
      _shape = associatedObject as Shape;
      if (_shape != null)
      {
        _originalFillBrush = _shape.Fill;
        Messenger.Default.Register<DataReceivedMessage>(this, OnDateReceivedMessage);
      }
    }

    private async void OnDateReceivedMessage(DataReceivedMessage mes)
    {
      _shape.Fill = _blinkBrush;

      await Task.Delay(500);
      _shape.Fill = _originalFillBrush;
    }

    public void Detach()
    {
      Messenger.Default.Unregister(this);
      if (_shape != null)
      {
        _shape.Fill = _originalFillBrush;
      }
    }

    public DependencyObject AssociatedObject { get; private set; }
  }
}

It is not quite rocket science: listen to the DataReceivedMessage, and if one is received, set the color of the attached Shape (a circle in this case) to the accent color, then return it to it's original color. The effect can be seen in the video in the first post of this series.

Conclusion
Quite a lot going on in this app, and then we haven't even seen what is going on with the Band. Yet, but using MVVMLight and neatly seperated components, you can easily wire together complex actions using simple patterns using interfaces and events. In the final episode of the series I will show you in detail how the Band interface is made and operated. In the mean time, have a look at the demo solution

20 September 2015

Controlling a fan using a UWP on a Raspberry PI2 remotely

Part 4 of Reading temperatures & controlling a fan with a RP2, Azure Service Bus and a Microsoft Band

Intro
This article shows you how to control a device attached to a Raspberry PI2 remotely - that is, the Universal Windows App on the PI2 listens to commands coming off an Azure Service Bus queue.I have explained several details already in the previous posts in this series - I will go over some things more quickly than before.

The fan is controlled using a Keyes SRD-05VDC-SL-C switch, as displayed here to the right. This is a relay that controls mains power. The Raspberry PI2 is a very low power device operating in the 5V range, so controlling mains power (100-250V depending where you live) requires there be something in between the Raspberry and the actual mains power - this little device here. Connecting the mains power directly to the poor PI2's GPIO pins would most likely result in a spectacular but rather short fireworks, so that's quite inadvisable to do.

Basic app setup
As I explained before, I have set up this app using dependency injection, basically creating a set of very loosely couples objects that interact only through interfaces and/or events - an getting objects of which they are dependent on supplied via their constructor, in stead of newing them up themselves.

So, once again we have a look an the MainPage_Loaded in MainPage.xaml.cs of the TemperatureReader IoT app, and I have grayed out everything that is does not play a role in controlling the fan.

var gpioService = new GpioService();
var fanSwitch = new SwitchDevice(gpioService, Settings.SwitchPinId);
var controller = new AnalogTemperatureSensorController(gpioService);
var thermometer = new Thermometer(gpioService, controller);
var poster = new TemperatureQueueClient(QueueMode.Send);
var fanCommandListener = new FanSwitchQueueClient(QueueMode.Listen);
await fanCommandListener.Start();

fanCommandListener.OnDataReceived += (cs, cmd) =>
{
  Debug.WriteLine(
    $"Fanswitchcommand received {cmd.Status}; current status fan on = 
      {fanSwitch.IsOn} at {DateTime.Now}");
  fanSwitch.SwitchOn(cmd.Status == FanStatus.On);
};

The amusing thing about this, as attentive readers will see, is that I am using no new objects whatsoever. All the object types in this are already described in previous posts of this series.

So how does this work?
As soon as the app is loaded, the GpioService, which I already explained in my previous post - is created. Then the fanSwitch object is created. This is a SwitchDevice - also already explained in the previous post as a base class for a class that controls an LED, and that now controls a SRD-05VDC-SL-C - by virtue of using a different GPOI pin. Then there is a FanSwitchQueueClient created - that listens to commands coming from the Azure Service bus. The working of this class is explained in the second post of this series.

Then finally, an event handler is attached to the FanSwitchQueueClient OnDataReceived - a very little piece of code that sets the switch to the status as requested by the command coming from the Azure Service Bus.

There is also this little piece of code reports back not only the temperature but also the current fan status back to whoever is listening to the other service bus

thermometer.OnTemperatureMeasured += async (thObject, data) =>
{
  data.FanStatus = fanSwitch.IsOn ? FanStatus.On : FanStatus.Off;
  await poster.PostData(data);
};

And that, my friends, is basically all. Nothing new - just reuse what is already been built. So why 'waste' a whole blog post on it? Mostly to show that with the right architecture you can make very easily reusable and connectable components - kind of like IoT hardware.

One more thing
There is an oddity to the SRD-05VDC-SL-C in relation to Windows 10 on Raspberry PI2: as soon as you open the pin to which it is connected and set its drive mode  to output, the SRD-05VDC-SL-C switches itself on. A very undesirable state of affairs. This is why the constructor of SwitchDevice contains a statement to switch it off immediately:

public SwitchDevice(IGpioService gpioCtrl, int pinId)
{
  _pinId = pinId;
  _gpioCtrl = gpioCtrl;
  SwitchOn(false);
}

Sometimes you can briefly see the red status LED of the SRD-05VDC-SL-C blink red when it is initialized like this. Be aware that there may be a short power spike in the attached mains power, and be sure the device that run on mains power can handle it.

Check the demo solution here.

17 September 2015

Measuring temperatures using an UWP on a Raspberry PI 2

 

Part 3 of Reading temperatures & controlling a fan with a RP2, Azure Service Bus and a Microsoft Band

Intro
In this article I will show how you can measure temperature on a Raspberry PI2 using an Universal Windows Platform App. To this extent we will use a Keyes Analog-temperature sensor and an ADC0832 analog-digital-convertor, as well as a 2-color (red-yellow) LED to show what's happening (and whether anything is happening at all) when running headless



The hardware configuration has already been detailed in the first post of this series, this post will only detail a part of software.

Basic app setup
I have built this app using dependency injection, although not a very fancy sort, inspired by a colleague and some things I saw recently in code. The app that is intended to run on the Raspberry PI2  is called TemperatureReader (I have never been good at original names) and (mostly) TemperatureReader.Logic. You can find all the code in the demo solution. But of course I will highlight the way it's done.

All the UI that ss in the app it this single big TextBlock showing the temperature:

<Grid >
  <TextBlock Name="TemperatureText" 
             VerticalAlignment="Center" 
             HorizontalAlignment="Center" FontSize="100"></TextBlock>
</Grid

for I assume this device to run headless, but if it does not, it is nice to see something, right. In earlier post I already alluded to setting up this app as the default apps on a Raspberry PI2, which implies that whatever it does, it should start automatically. And although the UI does not amount to much, I have used the MainPage.xaml.cs to create all objects that are necessary and 'connect the dots' between them. You will see there's actually very little functionality there. In the MainPage_Loaded I first create all 'actors' in this dance of IoT controlling objects:

var gpioService = new GpioService();
var fanSwitch = new SwitchDevice(gpioService, Settings.SwitchPinId);
var controller = new AnalogTemperatureSensorController(gpioService);
var thermometer = new Thermometer(gpioService, controller);
var poster = new TemperatureQueueClient(QueueMode.Send);
var fanCommandListener = new FanSwitchQueueClient(QueueMode.Listen);

I have grayed out two lines, as they will be part of the next blog post. Then, a little bit lower, you see how these objects interact:

thermometer.OnTemperatureMeasured += async (thObject, data) =>
{
  data.FanStatus = fanSwitch.IsOn ? FanStatus.On : FanStatus.Off;
  await poster.PostData(data);
};

await poster.Start();
await thermometer.Start();

I use a bit of primitive dependency injection here, and keep the separate tasks - well, separated - and use only events and/or interfaces to loosely couple these objects. You will see all major objects have interfaces defined on them, and are only accessed using those interfaces - for instance, the constructor of the AnalogTemperatureSensorController expects an IGpioService, not a GpioService.

Anyway,  I first create a base object GpioService, that will allow for some low level access to the Gpio pin. Then I create a low-level controller for the analog temperature controller, which is also pretty low level - and actually more controls the A/D converter than the temperature sensor itself. This uses the Gpio service (via it's interface) so it does not have to new up all that stuff itself. The Thermometer class is the class that actually exposes the temperature to the outside world, and also gives an indication of things happening using the LED. Finally, the TemperatureQueueClient, connected to the Thermometer by an OnTemperatureMeasured event subscription, simply posts temperature data on the Azure Service Bus queue as explained in the previous blog post

You will also notice there's another method in MainPage.xaml.cs is connected to the Thermometer.OnTemperatureMeasured but that is only used to display the temperature on the screen, and make the text in red and show some debug data when new data is received (so you can even see it's still posting data when the temperature has not changed):

private async void OnTemperatureMeasured(object sender, TemperatureData e)
{
  Debug.WriteLine(
   $"MainPage.OnTemperatureMeasured {e.Temperature}: {e.IsValid} at {DateTime.Now}");
  if (e.IsValid)
  {
    await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
    {
      var brush = TemperatureText.Foreground;
      TemperatureText.Text = $"{e.Temperature}°C";
      TemperatureText.Foreground = new SolidColorBrush(Colors.Red);
      await Task.Delay(250);
      TemperatureText.Foreground = brush;
    });
  }
}

The Gpio Service
This is actually a very simple class, and it's intent is to remove the necessity of calling Windows.Foundation.Metadata.ApiInformation‏.IsTypePresent every time you need a GpioController. You can now simply check whether the Controller property isn't null, which is a bit easier and shorter.

using Windows.Devices.Gpio;

namespace TemperatureReader.Logic.Devices
{
  public class GpioService : IGpioService
  {
    public GpioService()
    {
      if (Windows.Foundation.Metadata.ApiInformation‏.IsTypePresent(
        "Windows.Devices.Gpio.GpioController"))
      {
        if (Controller == null)
        {
          Controller = GpioController.GetDefault();
        }
      }
    }
    public GpioController Controller { get; private set; }
  }
}

The Controller property unfortunately is defined as it's implementing class type in stead of an interface - there is, in fact an IGpioController class but that's internal. I have no idea why.

The AnalogTemperatureSensorController
This is the heart of the beast, the crux of the matter, or however you want to call this. A Raspberry PI2 cannot do much with an analog temperature sensor, as it is essentially a digital device. So as I explained before in the first blog post, we need to place an Analog/Digital converter in between and talk to that. And this converter is what this class talks to. It tries to read a temperature every five seconds and does this by

  • Initializing a read session
  • Initializing the the A/D converter
  • Read two sequences of data from the converter
  • If the result of those sequences are equal, a successful temperature reading was made
    • The value is converted into degrees Celsius (sorry folks in the USA)
    • The temperature is sent to all subscribers of the OnTemperatureMeasured event.
First things first. The constructor looks like this:
public AnalogTemperatureSensorController(
  IGpioService gpioCtrl, 
  int adcCsPinId = Settings.AdcCsPinId, 
  int adcClkPinId = Settings.AdcClkPinId, 
  int adcDigitalIoPinId = Settings.AdcDigitalIoPinId, 
  int delayMilliSeconds = Settings.DefaultTemperaturePostingDelay, 
  int maxRetries = Settings.MaxReadRetry)
{
  _gpioCtrl = gpioCtrl;
  _adcCsPinId = adcCsPinId;
  _adcClkPinId = adcClkPinId;
  _adcDigitalIoPinId = adcDigitalIoPinId;
  _delayMilliSeconds = delayMilliSeconds;
  _maxRetries = maxRetries;
  IsMeasuring = false;
}

And all you have to provide is the Gpio service. The rest has default values that come out of the Settings definitions. You will see three pins connected to the A/D converter (5, 6 and 13, see the first blog post), the time between temperature reading (5000, or 5 seconds) and the maximum number of retries the component should try before admitting failure and telling that the outside world.

The "start" method kicks the whole process off

public bool Start()
{
  if (_gpioCtrl?.Controller != null)
  {
    IsMeasuring = true;

    if (_adcDigitalIoPin == null)
    {
      _adcCsPin = _gpioCtrl.Controller.OpenPin(_adcCsPinId);
      _adcClkPin = _gpioCtrl.Controller.OpenPin(_adcClkPinId);
      _adcDigitalIoPin = _gpioCtrl.Controller.OpenPin(_adcDigitalIoPinId);
    }

    if (_task == null)
    {
      _cancellationTokenSource = new CancellationTokenSource();
      InitReadSession();
      _task = new Task(async () => 
        await ExecuteMeasuring(_cancellationTokenSource.Token));
      _task.Start();
    }
  }
  return IsMeasuring;
}

It basically initializes the pins the component needs, then creates a task that runs indefinitely and measures the temperature every 5 seconds:

private async Task ExecuteMeasuring(CancellationToken cancellationToken)
{
  while (!cancellationToken.IsCancellationRequested)
  {
    var timePassed = DateTimeOffset.UtcNow - _lastExecutionTime;
    if (timePassed > TimeSpan.FromMilliseconds(_delayMilliSeconds))
    {
      var retries = 0;
      var readStatus = false;

      while (!readStatus && retries++ < _maxRetries)
      {
        readStatus = ReadData();
        _lastExecutionTime = DateTimeOffset.UtcNow;
      }

      if (retries >= _maxRetries)
      {
        OnTemperatureMeasured?.Invoke(this, new TemperatureData {IsValid = false});
      }
      _lastExecutionTime = DateTimeOffset.UtcNow;
    }
    else
    {
      var waitTime = _delayMilliSeconds - timePassed.TotalMilliseconds;

      if (waitTime > 0)
      {
        await Task.Delay(Convert.ToInt32(waitTime), cancellationToken);
      }
    }
  }
}

It looks rather complicated, but all it does is run indefinitely (until cancelled). It reads data (temperature) every five seconds. If reading fails, it tries again for 10 times (_maxRetries, supplied by constructor) and if it still fails, it will notify the outside world. In any case, it will wait for the rest of the _waitTime (5 seconds) before a new cycle of trying to read temperature again.

The ReadData method then is implemented as follows:

private bool ReadData()
{
  int sequence1 = 0, sequence2 = 0;
  _adcCsPin.Write(GpioPinValue.Low);

  InitReadSession();
  var waiter = new SynchronousWaiter();
  InitAdConverter(waiter);

  //Read the first sequence
  for (var i = 0; i < 8; i++)
  {
    _adcClkPin.Write(GpioPinValue.High);
    waiter.Wait(2);
    _adcClkPin.Write(GpioPinValue.Low);
    waiter.Wait(2);
    sequence1 = sequence1 << 1 | (int)_adcDigitalIoPin.Read();
  }

  //Read the second sequence
  for (var i = 0; i < 8; i++)
  {
    sequence2 = sequence2 | (int)_adcDigitalIoPin.Read() << i;

    _adcClkPin.Write(GpioPinValue.High);
    waiter.Wait(2);
    _adcClkPin.Write(GpioPinValue.Low);
    waiter.Wait(2);
  }

  _adcCsPin.Write(GpioPinValue.High);

  if (sequence1 == sequence2)
  {
    OnTemperatureMeasured?.Invoke(this,
      new TemperatureData { IsValid = true, Temperature = 
        Math.Round(((255 - sequence1) - 121) * 0.21875,1) + 21.8, 
        Timestamp = DateTimeOffset.UtcNow});
    return true;
  }

  return false;
}

It is important to understand that the A/D converter spits out data digital - but can do so only one bit at a time. So the whole stuff is done serially, that is: first one bit, than the other, via the _adcDigitalIoPin. But what you see are two loops. The _adcClkPin is turned on, then we wait for two milliseconds, then we turn it off again, then we wait for two milliseconds again, and then we read the _adcDigitalIoPin pin's value. We do that for every of the 8 bits. As a kind of parity, the second byte is read in the same way, but shifted in a different way into the resulting sequence variable. When the resulting integer values (sequence1 and sequence2) are the same, we have successfully read a temperature. I am not a bit shifting hero myself, so don't ask me the details, but this works. Now we only need to convert that to degrees Celsius.

From the Sunfounders manual I took a bit of code to do that, and got totally bizarre results. So I took a digital thermometer, made measurements on different times of the day and on different temperatures, and found out that the formula at the bottom of the ReadData method quite adequately converts the value the A/D converter spits out into temperatures (albeit it's mostly like 0.5-1 °C too high, but that's details. If you rebuild this with your own sensor, you might have to get some measurements yourself first to correct conversion values.

There are two important methods left: the InitReadSession method, that sets the drive mode for the three pins of the A/D converter to output

private void InitReadSession()
{
  _adcClkPin.SetDriveMode(GpioPinDriveMode.Output);
  _adcCsPin.SetDriveMode(GpioPinDriveMode.Output);
  _adcDigitalIoPin.SetDriveMode(GpioPinDriveMode.Output);
}

no rocket science there, just standard Windows 10 CoreIoT stuff - and then this gem, that is basically translated from C code in the Sunfounders manual

private void InitAdConverter(SynchronousWaiter waiter)
{
  _adcCsPin.Write(GpioPinValue.Low);
  _adcClkPin.Write(GpioPinValue.Low);
  _adcDigitalIoPin.Write(GpioPinValue.High); waiter.Wait(2);
  _adcClkPin.Write(GpioPinValue.High); waiter.Wait(2);

  _adcClkPin.Write(GpioPinValue.Low);
  _adcDigitalIoPin.Write(GpioPinValue.High); waiter.Wait(2);
  _adcClkPin.Write(GpioPinValue.High); waiter.Wait(2);

  _adcClkPin.Write(GpioPinValue.Low);
  _adcDigitalIoPin.Write(GpioPinValue.Low); waiter.Wait(2);
  _adcClkPin.Write(GpioPinValue.High);
  _adcDigitalIoPin.Write(GpioPinValue.High); waiter.Wait(2);
  _adcClkPin.Write(GpioPinValue.Low);
  _adcDigitalIoPin.Write(GpioPinValue.High); waiter.Wait(2);

  _adcDigitalIoPin.SetDriveMode(GpioPinDriveMode.Input);
}

Presumably, this in some way programs the A/D converter. The three pins get turned on and off and then there is a wait period of 2 milliseconds. What kind of instructions it gets - I have really no idea. I am guessing the 2 milliseconds have the same function as a semicolon in C# - end of statement. I hope that someone who reads this blog can enlighten me. But if you initialize the A/D converter this way, it will read temperature data in a intelligible way - that is, one that is compatible with what ReadData needs.

SynchronousWaiter
During the previous paragraph you may have noticed there are several calls to a SynchronousWaiter class. This is because I struggled with timings using await Task.Delay, but waiting for 2 milliseconds using that isn't really 2 milliseconds - it's usually more because of the callback overhead that's hidden under the hood of the await keyword. So here's SynchronousWaiter, a class the really only waits for the allotted number of milliseconds

using System.Diagnostics;

namespace TemperatureReader.Logic.Utilities
{
  class SynchronousWaiter
  {
    readonly Stopwatch _stopwatch;
    public SynchronousWaiter()
    {
      _stopwatch = Stopwatch.StartNew();
    }

    public void Wait(double milliseconds)
    {
      var initialTick = _stopwatch.ElapsedTicks;
      var desiredTicks = milliseconds / 1000.0 * Stopwatch.Frequency;
      var finalTick = initialTick + desiredTicks;
      while (_stopwatch.ElapsedTicks < finalTick)
      {

      }
    }
  }
}

and I won't pretend I wrote this myself - I was stuck on Task.Delay problems (albeit for a different sensor) and then a Microsoftie came to help

Thermometer
This class is best described as a wrapper hiding the intricacies of the AnalogTemperatureSensorController - and it handles the 'display' too, that is - it shows when data is read by blinking a LED either green or red, depending whether the temperature was successfully read or not. In addition, it shows a red/green blinking sequence when it starts up. The constructor follows the pattern we have already seen - most of what it needs (GpioService,and AnalogTemperatureSensorController) is injected to it from outside, and the pinsettings and other settings are optional and imported from the Settings class.

  public Thermometer(IGpioService gpioService, 
    IAnalogTemperatureSensorController temperatureSensorController, 
    int errorPinId = Settings.ErrorPinId, int dataPinId = Settings.DataPinId, 
    int longFlashTime = Settings.LongFlashTime, 
    int shortFlashTime = Settings.ShortFlashTime)
  {
    _gpioService = gpioService;
    _errorPinId = errorPinId;
    _dataPinId = dataPinId;
    _longFlashTime = longFlashTime;
    _shortFlashTime = shortFlashTime;
    _temperatureSensorController = temperatureSensorController;
  }

The start method initializes two pins for the LED, calls the ShowStartup method, then waits a few seconds, connects an event to the AnalogTemperatureSensorController and starts said controller (it assumes it is not started yet)

public async Task Start()
{
  _errorLed = new StatusLed(_gpioService, _errorPinId);
  _dataPinLed = new StatusLed(_gpioService, _dataPinId);

  await ShowStartup();
  await Task.Delay(WaitTimeBeforeStartup);

  _temperatureSensorController.OnTemperatureMeasured +=
     HandleTemperatureMeasured;
  _temperatureSensorController.Start();
}

The HandleTemperatureMeasure of the Thermometer class is basically just passing along the event to the outside - and blinks the LED according to the data provided by the AnalogTemperatureSensorController

async void HandleTemperatureMeasured(object sender, TemperatureData e)
{
  if (e.IsValid)
  {
    await _dataPinLed.Flash(_longFlashTime);
    OnTemperatureMeasured?.Invoke(this, e);
  }
  else
  {
    await _errorLed.Flash(_longFlashTime);
  }
}

The ShowStartup method, finally, shows the startup sequence.

private async Task ShowStartup()
{
  for (var c = 0; c < 3; c++)
  {
    _errorLed.SwitchOn(true);
    await Task.Delay(_shortFlashTime);
    _dataPinLed.SwitchOn(true);
    _errorLed.SwitchOn(false);
    await Task.Delay(_shortFlashTime);
    _dataPinLed.SwitchOn(false);
    await Task.Delay(_shortFlashTime);
  }
}
That is, it blinks the LED red-green for a couple of times. Note this is a yellow-red light, so turning the R pin only makes it red, turning on both both pins makes it green.

SwitchDevice
This is a class that is a logical wrapper for a 1-pin device that can be either turned on or off. It sports a constructor that turns the device off by default, a Switch method that sets the device to the desired state, a Toggle method that switches state, and an IsOn property that will allow you to check whether it's on or not:

using Windows.Devices.Gpio;

namespace TemperatureReader.Logic.Devices
{
  public class SwitchDevice
  {
    private readonly int _pinId;
    private readonly IGpioService _gpioCtrl;
    private GpioPin _pin;

    public SwitchDevice(IGpioService gpioCtrl, int pinId)
    {
      _pinId = pinId;
      _gpioCtrl = gpioCtrl;
      SwitchOn(false);
    }

    public void SwitchOn(bool @on)
    {
      GpioPin pin;
      if ((pin = GetPin()) != null)
      {
        pin.Write(@on? GpioPinValue.High : GpioPinValue.Low);
      }
    }

    public void Toggle()
    {
      SwitchOn(!IsOn);
    }
    
    public bool IsOn
    {
      get
      {
        GpioPin pin;
        if ((pin = GetPin()) != null)
        {
          var currentPinValue = pin.Read();
          return currentPinValue == GpioPinValue.High;
        }
        return false;
      }
    }
    
    protected GpioPin GetPin()
    {
      if (_pin == null)
      {
        if (_gpioCtrl?.Controller != null)
        {
          _pin = _gpioCtrl.Controller.OpenPin(_pinId);
          _pin.SetDriveMode(GpioPinDriveMode.Output);
        }
      }
      return _pin;
    }
  }
}

The private method GetPin makes sure the pin is initialized and sets it to the right (output) mode. But as you can see, I don't use a SwitchDevice, but a StatusLed.

StatusLed
A very simple child class of SwitchDevice that has an extra method Flash that turns on a LED for a certain number of milliseconds, then turns it off again. Easy as cake.

using System.Threading.Tasks;

namespace TemperatureReader.Logic.Devices
{
  public class StatusLed : SwitchDevice
  {
    public StatusLed(IGpioService gpioCtrl, int pinId) : 
       base(gpioCtrl,pinId)
    {
    }

    public async Task Flash(int milliseconds)
    {
      SwitchOn(true);
      await Task.Delay(milliseconds);
      SwitchOn(false);
    }
  }
}

Conclusion
As you can see, by using loosely coupled high level components you can hide a lot of the low level complexity that is going on under the hood and let those components play together in a way that makes you can still understand after returning to your code after a while. Having said that, the low level things themselves can be quite daunting and I must admit that for some things I just clung to examples in C that worked - and then translated then to C#. It does not really matter - I quite often use software libraries a well whose inner workings I don't quite understand, but I feel a bit like threading on thin ice.

Yet, I still find it awesome I can just deploy this app to a Rasbperry PI2 that is connected via WiFi, remote, directly from Visual Studio, and debug it while it runs on the device. Be aware, though, that doing so while running time-critical code like in the AnalogTemperatureSensorController will introduce all kinds spectacular error. TL;DR - don't put breakpoints in that kind of code ;)

Thanks to Jesse Caplan for his explanation of issues with Task.Delay in time-critical code and the SynchronousWaiter sample.

Check the demo solution for all code running together.

Edit 18-09-2015 - simplified SwitchDevice.Toggle method considerably after comment from @robvanu - thanks!

16 September 2015

Using system accent color brush from code in Windows 10 UWP

A very short one this time. I wanted to give some UI element the same color as the accent color, but I wanted to use it from code, not from XAML, as written for instance here.

Turns out it's called "SystemControlHighlightAccentBrush" and you can use it like this:

Brush _blinkBrush = 
  Application.Current.Resources["SystemControlHighlightAccentBrush"] 
    as SolidColorBrush;

And of course, once you know it's called "SystemControlHighlightAccentBrush" you can find it everywhere, like on Stack Overflow. So I am writing this down as much as a personal reminder as for you ;)

I used in my latest IoT demo solution that you can find here. It's in project TemperatureReader.ClientApp, class Behaviors.BlinkBehavior.

13 September 2015

Using an Azure Service bus queue for two-way (IoT) communication

 

Part 2 of Reading temperatures & controlling a fan with a RP2, Azure Service Bus and a Microsoft Band

Intro
In this post I will explain how the Windows 10 device to which the Band is paired and the Raspberry PI2 'talk' to each other. As the previous post (and the title of this post) already shows, this is done using an Azure Service Bus queue. The code for this is in two of the five projects in the demo solution

  • TemperatureReader.Shared contains the data objects shuttled over the Azure Service Bus queue, as well as all the global definitions
  • TemperatureReader.ServiceBus contains the actual code for the Service Bus code.

Getting started
Before you can get the code working, you will need to define an Azure Service Bus, because you cannot use mine - I like to keep it for demos myself and keep my Azure bill reasonable, thank you :). If you look into the TemperatureReader.Shared project in the demo solution you will find a class "Settings" that, amongst other things, has the following pretty long and rather cryptic definition:

public static readonly string TemperatureBusConnectionString =
"Endpoint=sb://yournamespacehere.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=XXXXXXXXXXXXXXXXXYOURKEYHEREXXXXXXXXXXXXXXXX";

To be able to use queues in a Service Bus, you must first claim a namespace. Doing so currently is only supported by the 'old' Azure Portal, so you need to go there to create it:
image

image[33]You need to select the tab "Service Bus" below, then hit the "Create" button. Then you get the pop-up as displayed on the right. Make up a nice namespace name (Azure will tell you if it's available or not), then select a region. As I am living in the Netherlands, I typically choose "West Europe" but feel free to choose otherwise. The rest of the settings can be left as they are - although you might consider setting the message tier to 'basic'. Hit the check mark, and you get the image below.

 

 

image

 

 

Your Azure Service bus namespace has been been created. This is stage 1 - now the actual queues need to be created. From the code in Settings.cs you can see there will need to be two queues on this Service Bus:

public static readonly string TemperatureQueue = "temperaturedatabus";
public static readonly int TemperatureQueueTtl = 10;

public static readonly string FanSwitchQueue = "fanswitchcommandbus";
public static readonly int FanSwitchQueueTtl = 10;

The first one is for sending temperature data from the PI2 to the Windows 10 device (and ultimately the Band) and the second one to send commands to switch the fan on and off. I have set the time to live (TTL) for messages on each queue at 10 seconds, meaning that any data older than 10 seconds can be discarded if it's not picked up. You can go ahead and click the arrow that I emphasized using a red box next to "thisisademo" and imageconfigure the queue manually, or just let the code (see below) to take care of it. There is only one more thing you will need to do: select the Azure Service Bus namespace that you just have created, then hit "Connection Information" at the bottom. By hovering over the text that starts with "Endpoint=sb://" you get a blue "copy" icon at the right and if you click that, that whole connection string gets put into the clipboard for your convenience.Then you can paste that into the TemperatureBusConnectionString constant in Settings.cs
image

A base queue client
In any project that you want to use Azure Service Bus in, you will need to use the NuGet package "WindowsAzure.Messaging.Managed" (assuming your are using a managed language like C# or VB.NET).
image
Then it's important to know that any client (and with that I mean an object of type Microsoft.WindowsAzure.Messaging.Queue) can both put objects in the queue as well as read them - and doing so is pretty stupid as I found out the hard way. A Queue object that does both basically eats his own messages - most of the time, but not all of the time. Happy debugging. Anyway, I wanted a queue client that

  • I could either ask to read from the queue or put data on the queue, but not both
  • could only send or receive data of a specified type
  • would automatically create a queue on the service bus if it does not exists

I came up with this:

using System;
using System.Diagnostics;
using System.Threading.Tasks;
using Microsoft.WindowsAzure.Messaging;

namespace TemperatureReader.ServiceBus
{
  public class QueueClient<T> : IQueueClient<T>
  {
    private readonly string _queueName;
    private readonly string _connectionString;
    private readonly int _messageTimeToLive;
    private readonly QueueMode _queueMode;
    private Queue _queue;
    
    public QueueClient(string queueName, string connectionString, 
      QueueMode mode = QueueMode.Send, int messageTimeToLive = 10)
    {
      _queueName = queueName;
      _connectionString = connectionString;
      _queueMode = mode;
      _messageTimeToLive = messageTimeToLive;
    }

    public async virtual Task Start()
    {
      try
      {
        var settings = new QueueSettings 
          { DefaultMessageTimeToLive = TimeSpan.FromSeconds(_messageTimeToLive) };
        await Queue.CreateAsync(_queueName, _connectionString, settings);
        Debug.WriteLine($"Queue {_queueName} created");
      }
      catch (Exception)
      {
        Debug.WriteLine($"Queue {_queueName} already exists");
      }

      _queue = new Queue(_queueName, _connectionString);
      if (_queueMode == QueueMode.Listen)
      {
        _queue.OnMessage(message =>
        {
          var data = message.GetBody<T>();
          OnDataReceived?.Invoke(this, data);
        });
      }
    }

    public virtual async Task PostData(T tData)
    {
      if (this._queueMode == QueueMode.Send)
      {
        await _queue.SendAsync(tData);
      }
      else
      {
        throw new ArgumentException(
          "Cannot send data using a QueueMode.Listen client");
      }
    }

    public void Stop()
    {
      if (_queue != null)
      {
        _queue.Dispose();
        _queue = null;
      }
    }

    public event EventHandler<T> OnDataReceived;
  }
}

If a QueueClient object is created, it accepts the name of the queue, the queue connection string (that impossible long string in Settings.TemperatureBpusConnectionString), a message time-to-live and a QueueMode (can be either Send or Listen). Notice it has a type parameter - that is the type of object you are allowed to put on the queue - or can expect to come off it.

To get the thing going, you will need to call Start. This first tries to create the queue. Unfortunately I have not been able to find out how to check if a queue exists first, so I have resorted to the rather crude method of swallowing an exception if creating the queue fails - and assume that the exception was caused by an already existing queue. Then it will create an actual Queue object (Microsoft.WindowsAzure.Messaging) - and if it's a Listen QueueClient, it will attach an anonymous method to the OnMessage method of that queue. That method will hoist the data object from the queue and pass it on to whoever is subscribed to the OnDataReceived event of the QueueClient itself.

The QueueClient's post method is basically a typed wrapper on the Queue PostData method, except that it will prohibit from posting if this is a Listen client - to prevent it swallowing it's own message.

Finally there is the Stop method, that just disposes the queue.

Using specific implementations
Both TemperatureQueueClient and FanSwitchQueueClient are child classes, providing specific implementations of a queue client. For instance, TemperatureClient just handles temperature data and all you have to do is provide an override constructor to prevent you from having to set all that properties every time you use them:

using TemperatureReader.Shared;

namespace TemperatureReader.ServiceBus
{
  public class TemperatureQueueClient : QueueClient<TemperatureData>
  {
    public TemperatureQueueClient(QueueMode mode = QueueMode.Listen) :
      base(Settings.TemperatureQueue, 
        Settings.TemperatureBusConnectionString, mode, 
        Settings.TemperatureQueueTtl)
    {
    }
  }
}

The only thing there is left to set is the QueueMode, since you typically want to create one listening and one sending queue client.

If you now look in the MainPage_Loaded in MainPage.Xaml.cs in TemperatureReader (the IoT project) you will see a TempeatureQueueClient, processing temperature data, being set up as Send queue client while a FanSwitchQueueClient is a Listen queue client - which makes sense, as the Raspberry PI2 sends temperature data, but listens for commands to switch on or off the fan (ultimately coming from a Microsoft Band, somewhere in the world).

private async void MainPage_Loaded(object sender, Windows.UI.Xaml.RoutedEventArgs e)
{
// stuff omitted var poster = new TemperatureQueueClient(QueueMode.Send); var fanCommandListener = new FanSwitchQueueClient(QueueMode.Listen);

In the client app that is intended for a Windows 10 device to which the Band is paired (typically a phone) it's the other way around. In MainViewModel.CreateNew you will see

public static MainViewModel CreateNew()
{
  var fanStatusPoster = new FanSwitchQueueClient(QueueMode.Send);

Indicating the queue client FanSwitchQueueClient is sending here, while the TempeatureQueueClient - embedded in TemperatureListener - is created in the constructor as a Listen client:

public TemperatureListener() 
{ 
  _client = new TemperatureQueueClient(QueueMode.Listen); 
  _client.OnDataReceived += ProcessTemperatureData; 
}

Conclusion
An Azure Service Bus client is a great way for simple one-to-one real time connections that can allow for some lag to happen between connected devices. It's very simple to use, can partly be created from code, is secured by default and does no require you to deploy a separate website to Azure to host a connection hub - the queue is hosted on Azure itself. And the awesome thing is - the code runs on both a Phone and a Raspberry PI2. It's in the same assembly. That is the power of the Universal Windows Platform.

Next time I will show how to actually measure temperature on a Raspberry PI2.

11 September 2015

Reading temperatures & controlling a fan with a RP2, Azure Service Bus and a Microsoft Band (1)

Part 1 - Idea, architecture, hardware shopping list and hardware configuration

Sometimes simple ideas have a tendency to balloon almost out of control, and this is one of them. In essence I wanted 'the other way around' compared with my previous IoT project - in stead of using the Band as a sensor device and the Raspberry PI2 as a 'display unit', I wanted to use the Band as controller. The idea was I could

  • Measure temperature using my Raspberry PI2 running Windows 10 CoreIoT
  • See the current temperature on my Band, including the date and time it was measured
  • Send a command to my Raspberry PI2 to switch on a fan if I find things are getting too hot
  • See on my Band the fan has actually switched on
  • Switch the fan off again if I feel like doing so.

Some pictures of the resulting contraption on my desk:

IMG_2040

IMG_2034

IMG_2032

I will say you this my friends: playing around with IoT stuff takes the phrase "spaghetti code" to a whole new level :D

The details
On my phone (or more precisely, the Windows 10 device to which my Band is paired) there is an app than can

  • listen to temperature data coming from the Raspberry PI2,
  • build a tile with a custom UI on my Band,
  • listen to and act on events coming from that Band UI.

If I open the custom tile on my Band, the app on my phone gets a signal to transmit the last received data from my Raspberry PI2 (the temperature, last received update date and time, and whether the fan is on or off) to the Band, followed by a single vibrate. If I tap the fan toggle button on the custom UI on my Band, the app should respond to that as well, send back a signal over the Azure Service bus queue - and display on the Band the fan is on (and can now be switched off).

On the Raspberry PI2 is a CoreIoT app that measures temperature and sends data over the Azure Service bus queue every five seconds, and also listens for fan switch on/off commands. It should also display it's 'health' by letting the connected two-color LED flash in green when a correct temperature is measured and transmitted, or red when something goes wrong. I also included a sequence on which the led rapidly blinks red/green to indicated the app is starting up. This is very handy when you set the app to be the default app - that way it's automatically started after the PI2 has booted Windows 10 CoreIoT and you can then see the app is actually starting up, even if there's no display connected.

The net result you can see on this video below:

Thanks to the Azure Service Bus being ‘somewhere’ in the cloud, I can read the temperature in my study on my Band where ever I am in the world. And while that may not be the most useful thing to do, I actually have used this contraption for real when I was on holiday in Germany for the past 1.5 weeks - in stead of a fan, I connected a spotlight to it, enabling me to turn on a light at home at random times in the evening, in order to confuse potential burglars. Like I said,Windows 10 CoreIoT will always try to keep the default app running - after there's a power failure or a crash, it automatically (re)starts that app. A very useful feature when you are hundreds of kilometers from home and cannot hit a reboot button.

How this will be blogged
As this is quite a big project, I have decided to split the explanation into six blog posts:

  1. Idea, architecture, hardware shopping list and hardware configuration
  2. Using an Azure Service Bus queue for two-way communication between IoT devices
  3. Measuring temperatures using an UWP on a Raspberry PI 2
  4. Controlling a fan using an UWP on a Raspberry PI2 remotely
  5. A client app to show temperature data and control a fan
  6. A Microsoft Band client to read temperatures and control a fan

The idea I just described, so now we go on with the architecture

Architecture
For my previous IoT project - displaying heart rates using an LED connected to a Raspberry PI2 - you might recall I used an Azure hosted Signal/R Hub. This time, as I already said, I decided to go with a queue on an Azure Service Bus. Signal/R worked pretty well in the previous setup, but it has a few disadvantages:

  • It requires you to deploy a web site, while the infrastructure for a Service Bus is 'hosted' by Azure itself.
  • Signal/R signals can only be delivered real time - that is the nature of Signal/R. If you missed it, you missed it. Tough boots. A queue makes it possible to receive data for a little while after it's been sent.
  • Security is a bit iffy - everyone who knows the address of my previous Signal/R hub solution can listen in on the data. Of course, I can encrypt that, or do access security - it's all kind of a hassle and it feels a bit roll-your-own.

There is also a disadvantage - unlike with Signal/R, there is basically only one client possible - that is the nature of a queue. If a client picks up the message, it's removed from the queue. A second client listening won't get it. So a 'broadcast' scenario is not possible. But since this is exactly what I wanted, this suited me perfectly. And my good friend Matteo Pagani from Italy had played with if before, and was kind enough to provide me with some starter code so I could go off to a flying start.

This is a high level overview of the setup:blogplaatjeCalling this 'architecture' is a bit rich I think, but it is intended as a global overview. Although it is not entirely correct, as this picture suggest signals go between phone and PI2 (and back) over a single channel, while in fact there are two queues - one for each direction. Temperature data goes from PI2 to phone over one queue, the command to toggle the fan over the other.

Contrary to most of my demo solutions, this is a more architected solution. It uses separate components connected by dependency injection, and the Windows 10 (mobile) client is a fully fledged MVVMLight app. This is because I wanted to show a little more of how to do things in a more robustly architected way. It also makes it easier to split the blog post into manageable pieces. This is not just a simple demo - it's a complete setup.

The demo solution contains the following projects:

  • TemperatureReader - the CoreIoT UWP app running on a Raspberry PI2 that actually reads the temperature data and displays it on a screen - if one is attached, sends data over the Service Bus and waits for commands to switch the fan on or off. Or actually, just the very limited UI that bootstraps the whole process - all the logic is in
  • TemperatureReader.Logic - contains all of the logic of reading temperature, flashing the LED and controlling the relay using the GpioController class.
  • TemperatureReader.ClientApp is the Windows 10 UWP application that acts as intermediary between the Band and the Raspberry PI2, listening to the signals coming from the PI2 and acting on commands and/or event from the Band. It has it's own user interface to show data and initialize the Band.
  • TemperatureReader.ServiceBus code handling communications via the Azure Service Bus.
  • TemperatureReader.Shared - contains the data objects that are shuttled over the Service Bus, as well as a global definitions class that defines pins used on the bread board, Azure access keys, and stuff like that - because I don't like magic strings and numbers.

Hardware shopping list
To run this project, you will need the following hardware:

  • 1 Raspberry PI2 running the latest Windows 10 CoreIoT build
  • 1 Microsoft Band
  • 1 device running Windows 10 (mobile or otherwise - as long as a Band can be paired to it)
  • 1 Keyes two-color Common-Cathode LED 1
  • 1 Keyes Analog-temperature sensor 2
  • 1 ADC0832 analog-digital-convertor 3
  • 1 Keyes SRD-05VDC-SL-C switch 4
  • 1 breadboard + flat cable connecting it to the Raspberry PI2
  • 14 connection wires (I hope I counted them correct ;) )
  • 3 barrier strip units 5 (The things we call ‘kroonsteentjes’ in Dutch)
  • 1 piece of mains cord
  • 1 mains plug
  • 1 mains socket plug
  • Some duct tape

Pictures of some assorted items:

ledtemperaturesensoradconverterrelaykroonsteentje

Configuration
A word of warning: the hardware configuration uses a relay switch to control mains power. Depending on where you live, that's between 100 and 250 Volts. We are not talking battery power here - this is the stuff that comes out of your wall plugs, drives the washing machines, refrigerators, air conditioners and whatnot, has serious oomph behind it - and can seriously hurt you if you mess around with it. In my sample I have cut a mains cord, reconnected one part via the relay and reconnected the rest using barrier strips. I sealed the connections using duct tape. At the ends of the mains cord are a mains plug and a main socket, so it can be used to control any mains power driven device. Be sure that you are careful with live wires and be aware that whatever I show you most likely would not get approval from a skilled electrician. If you re-create my setup with your own hardware, I cannot accept any responsibility for things going wrong. I also strongly suggest not letting the setup connected to the mains power unsupervised. This is a test/demo project, not a production unit.

The LED
This is an easy one. I have connected "R" to GPIO12, "Y" to GPIO16, and "G" to GND (of course).

The SRD-05VDC-SL-C switch
A bit more complicated, as the are no markings on the pins of this device. If you hold it the way that you can read the text on the blue block and the pins are sticking out to the right (as in picture 4) I have connected the top pin to GND, the middle pin to 5V,  and the bottom pin to GPIO18.

On the other side, the part with the screws on it - I connected the mains wire. I cut this first, then reconnected to mains using three terminal strip units - an sealed the stuff with duct tape. As already stated - follow this advice at your own risk. Basically one wire goes straight trough, the other part goes through the switch. Now it's not easy to see, but if you hold the switch like displayed on picture 4 (and below), you will see screws on the left side, and you  can just about read "NO" under the top screw, and "NC" under the bottom screw. This stands for "Normal Open" and "Normal Closed". You fix one of the mains wire to the NO screw, and the other under the middle screw.

imageimage

The Analog temperature sensor
I have connected the middle pin to 3.3V, the "-" pin to GND, and "S" pin to 2 of the AC-converter (see below). That converter is the hardest part.

The ADC0832 analog-digital-convertor
I'll be the first one to admit that I actually have no idea how this works, I nicked the idea from the Sunfounders manual. I understand the principle of an A/D converter, I just have no idea why it needs to be connected in this specific way, and I understand even less of the programming 'sequence' (that will be described in a later post) imagethat goes into it. Anyway, this A/D converter is a chip and if you hold it the way that you can actually read the text on it, the pins are numbered this way. Why? I really don't know, having no formal background in electronics. Now this pins also have labels attached to them which are:

1 = CS
2 = CH0
3 = CH1
4 = GND
5 = DI
6 = DO
7 = CLK
8 = VCC

These names we will see back later in the sample solution. So, more or less following lead of the Sunfounders manual, I made the following connections

  • 1 to GPIO5
  • 2 to the "S" pin of the Analog temperature sensor
  • 3 to nothing
  • 4 to GND
  • 8 to 3.3V
  • 7 to GPIO6
  • 5 and 6 to GPIO13

Running the sample solution
If you want to run the sample solution, you will at least need to

  • Create an Azure Service bus
  • Paste the key into Settings.cs in TemperatureReader.Shared
  • Deploy the TemperatureReader app on a Raspberry PI2 running Windows 10 CoreIoT with all the named hardware attached
  • Deploy the TemperatureReader.ClientApp to a Windows 10 device with a Microsoft Band to it.

The next episode in this series will explain how the Azure Service bus is utilized as an IoT communication conduit.