How to send Azure IoT commands back to NodeMcu

Microsoft is has made their IoT platform very open. There are lots of ways to connect to it, using various protocols like HTTP, MQTT and AMQP. And Microsoft provides multiple SDKs to connect to their IoT platform using languages like Python, .Net, Java, Node JS and C. So it’s not that hard to connect to the platform whatever your development platform is.

If you follow my blog, you will notice that I normally connect to the platform using UWP. It’s great for testing purposes and it even runs on a Raspberry Pi using Windows 10 Core. I also connect a lot using ‘special’ Arduino’s. Although these are not connected to the Internet by default, I have a couple of The Things UNO boards which have wireless connectivity using Lora. The Arduino’s connect to the Azure IoT platform using the The Things Network Lora platform.

I also connected using a Photon, using the Particle cloud. This works almost out of the box but for now, it’s only one way; I can only send telemetry to the Particle cloud. I hope to see the ability for receive commands,  arriving at the Photon, in the near future.

Currently I have some NodeMCU laying around and a friend showed me how to connect to the Azure IoT Platform using the Azure IoT for C SDK.

nodemcu-lua-cp2102-1

It’s not that hard to get it to send some telemetry, once you know what to do (thanks, Jan Willem 🙂 ) but retrieving commands is less straight forward. In this blog, we take a closer look.

Continue reading “How to send Azure IoT commands back to NodeMcu”

Waarom F# prima met C# combineert

Op mijn huidige project moet ontzettend veel met getallen gegoocheld worden. De klant heeft bakken vol met berekeningen en formules om daar fantastische dingen mee te doen. Ik vind dit zeer intrigerend. Zo’n bedrijf bouwt al jaren zijn producten en heeft hierbij een hele afdeling voor softwareontwikkeling opgetuigd. Binnen het bedrijf komen en gaan de ontwikkeltools, de operating systemen, de nieuwste ideeën over software-architectuur maar er is één constante. Juist, die berekeningen?

Komt dit bekend voor?

Ik durf te stellen dat voor eigenlijk alle bedrijven hun formules (ik denk aan financiële instellingen zoals banken en verzekeraars en aan productiebedrijven met krachten, uitvloeiing van kunststof of draaicirkels) gerust als de kroonjuwelen kunne beschouwen. Iedere investering hierin om ze nog beter, sneller en betrouwbaarder te maken is een juiste keuze.

Dit betekent dus dat er een goed versiebeheer moet zijn voor de formules, een goede distributie van de gereedschapskisten waar ze inzitten (dll’s of services) en ik stel me voor dat er ook een complete geautomatiseerde teststraat (lees buildserver met minimaal unittests en een code coverage van 100 procent) voor draait. Waarom 100 procent terwijl dat een hele opgave is? De kosten tegen verkeerde resultaten uit formules wegen niet op tegen de kosten van de enorme stap van 80 procent naar 100 procent. Er kunnen bedrijven failliet gaan of zelfs mensenlevens op het spel staan.

Dus…

Formules schrijven lijkt simpel maar het kan al snel ingewikkeld worden J

Nu heb ik zelf regelmatig formules mogen implementeren en dan ga je aan de gang met static methodes om stateless te gaan rekenen en je wordt overweldigd met reeksen en complexe structuren om door te werken. En dat wordt dan dus het ijdele handwerk in C# code.

Maar de laatste weken heb ik mijn tijd doorgebracht met de PluralSight presentaties over F#. En ik vind het kijken van inhoudelijke filmpjes over een nieuw stuk technologie zowiezo heel nuttig (Het kost veel tijd om zoiets op te zetten en daarom rolt er meestal uiteindelijk echt de essentie van een onderwerp uit) maar ik ben nu heel enthousiast over F#.

F# is gewoon een extra ontwikkeltaal voor .Net en wat het speciaal maakt, is dat het een functionele taal is. Dit soort talen is juist geschikt voor zaken als recursiviteit, reeksen, enz. Alles dus waar je óf van houdt óf wat je haat 🙂

F# is vooral interessant omdat eigenlijk alles types immutable zijn. En hierdoor kan er tijdens parallelle uitvoering geen conflict optreden waarbij de ene thread een gezamenlijke waarde overschrijft.

Helaas heeft Microsoft voorheen F# vooral willen postioneren als een programmeertaal waarin je ook Winforms apps kunt maken en waarmee je ook een WPF app in elkaar kunt draaien. Persoonlijk had ik hier geen trek in, dat kon ik al met C# en ik zag niet het nut in om een nieuwe taal te leren om hetzelfde te kunnen doen wat ik al kon.

Maar F# is superieur als aanvulling op C# als het om berekeningen gaat. Kijk maar eens naar de volgende vier F# functies:


module Functions

let Func1 (x) = 2*x*x + 5*x + 3
let Func2 (x) = x*x + x
let Func3 (x) =  x*x*x - x*x + x
let Func4 (x) =  x*x*x*x + x*x*x - x*x + x

Dit is de hele inhoud van een F# file in een F# library project. En ja, dit zijn gewoon vier functies. Sterker nog, dit zijn vier methodes. Om dit te bewijzen, heb ik deze aangeroepen vanuit C#.

Het enige wat ik moest doen was een reference leggen vanuit mijn C# console app naar de F# library:

class Program
{
  static void Main(string[] args)
  {
    Console.WriteLine("CSharp Host");

    for (int i = -5; i <= 5; i++)
    {
      Console.WriteLine("Result of Func1 {0} = {1}", i, Functions.Func1(i));
    }

    for (int i = -5; i <= 5; i++)
    {
      Console.WriteLine("Result of Func2 {0} = {1}", i, Functions.Func2(i));
    }

    for (int i = -5; i <= 5; i++)
    {
      Console.WriteLine("Result of Func3 {0} = {1}", i, Functions.Func3(i));
    }

    for (int i = -5; i <= 5; i++)
    {
      Console.WriteLine("Result of Func4 {0} = {1}", i, Functions.Func4(i));
    }

    Console.WriteLine("Press a key...");

    Console.ReadKey();
  }
}

De uitkomst is dan:
F#01
Dit kan natuurlijk ook met een unit test gecontroleerd worden. F# is tenslotte een volwaardige .Net taal dus MSUnit is al voldoende:

[TestClass]
public class UnitTest1
{
  [TestMethod]
  public void TestMethod1()
  {
    // ARRANGE
    var x = 5;
    var expected = 78;

    // ACT
    var actual = Functions.Func1(x);

    // ASSERT
    Assert.AreEqual<int>(expected, actual);
}

[TestMethod]
public void TestMethod2()
{
  // ARRANGE
  var x = 5;
  var expected = 30;

  // ACT
  var actual = Functions.Func2(x);

  // ASSERT
  Assert.AreEqual<int>(expected, actual);
}

[TestMethod]
public void TestMethod3()
{
  // ARRANGE
  var x = 5;
  var expected = 105;

  // ACT
  var actual = Functions.Func3(x);

  // ASSERT
  Assert.AreEqual<int>(expected, actual);
}

[TestMethod]
public void TestMethod4()
{
  // ARRANGE
  var x = 5;
  var expected = 730;

  // ACT
  var actual = Functions.Func4(x);

  // ASSERT
  Assert.AreEqual<int>(expected, actual);
}
}

Dit is wederom simpel en werkt direct:
F#02

En de code coverage is ook 100% 🙂

F#03

Zoals je ziet wordt alles als types ook goed ingevuld. F# kent dus geen variants maar alles wordt inferred, afgeleid. Dit maakt de functies compact en flexibel.

De F# functie blijkt met integers te willen omgaan:

F#04

 

En C# snapt dit:

 

F#05

 

En:

F#06

Dus doe eens gek en ga eens naar http://www.tryfsharp.org/ en speciaal naar http://www.tryfsharp.org/Learn/getting-started . Hier kun je online in de browser kennis maken met F#.

F#07

En kijk anders eens de hilarische video op Channel 9 van Luca Bolognese

Prima entertainment en je steekt er ook nog wat van op. Al is het maar om je behoefte te vervullen om jaarlijks een programmeertaal te leren.

Meer inhoudelijke informatie over F# is te vinden op: http://fsharp.org/

 

 

 

Eenvoudig PDF printen in C#

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

Printen in het .Net framework is op zich niet zo lastig. En met de komst van WPF en de bijbehorende XpsDocumentWriter kan bv. handig gebruik gemaakt worden van de FlowDocument klasse en de PrintQueue klasse met bijbehorende CreateXpsDocumentWriter methode. Hiermee kun je zelf je templates opmaken, mergen en printen.

Maar specifiek een aangeboden PDF printen is een stuk lastiger. Met de hand lijkt dit eenvoudig, je start gewoon Adobe Reader of iets dergelijks.

Maar een PDF vanuit code uitprinten is niet eenvoudig. De opmaak binnen PDF’s wordt niet direct door de meeste printers herkend. Op het internet zwerven veel oplossingen rond allemaal met hun eigen voor- en nadelen. Adobe Reader is bv. gratis maar geeft een ‘nag’ screen en er zijn commerciële oplossingen maar die zijn niet bepaald goedkoop.

Voor mijn huidige project heeft het team gekeken naar de mogelijkheid om GhostScript te gebruiken. Dit is een bibliotheek om PDF naar ‘niet-postscript’ om te zetten. We zijn met name geïnteresseerd in PCL, dit kunnen de meeste (HP) laserprinters wel aan. Op GhostScript zit een GNU licentie met beperkt commercieel gebruik.

En wat blijkt, in slechts enkele stappen komt het printen van PDF ook voor .Net ontwikkelaars binnen bereik!

Stap 1: Download GhostScript en installeer deze lokaal. De 32 bits versie is een prettige keuze, vooral in combinatie met de andere benodigdheden. Deze werkt ook met een 64 bits Windows7. Refereer naar de gsdll32.dll in je C# project.

We zijn dus geïnteresseerd in die gsdll32.dll en deze is geschreven in C . Gelukkig heeft Matthew Ephraim al de moeite genomen om deze in C# te verpakken. Deze bibliotheek heet heel toepasselijk GhostScriptSharp. De broncode kan je ophalen bv. op GitHub.

Deze wrapper rond de 32 bits GhostScript dll is heel aardig. Er is via de methode GenerateOutput() de mogelijkheid beschikbaar om een PDF om te zetten naar PCL. Als onderdeel van de instellingen moet wel een ‘Device’ meegegeven worden. Hier heb ik een simpele aanpassing moeten maken op GhostScriptSharp. De GhostscriptDevices enum krijgt nu de extra ljet4 voor PCL support want die ontbrak. Waarom deze in de huidige versie niet aanwezig is, is mij onbekend.

Stap 2: download nu de GhostScriptsharp code, integreer deze in je eigen code en breid de enum even uit met de keuze ‘ljet4’. Zie dat die broncode standaard naar de 32 bits versie van GhostScript refereert.

Als laatste moet nu de, door GhostScript uit de PDF, gegenereerde PCL naar de printer gestuurd worden. Jouw printer dient dus wel PCL te ondersteunen :-).

Hiervoor gebruiken we een voorbeeld op de MSDN van Microsoft zelf. Dit voorbeeld gebruikt de Win32 Spooler Application Programmer Interfaces (APIs) en dit werkt ook prima samen met Windows7. De in het voorbeeld genoemde RawPrinterHelper klasse is prima. Er zitten wel enkele geheugenlekjes in (geen usings op de FileStream en de BinaryReader) dus een kleine aanpassing is gewenst.

Stap 3: Integreer de voorbeeldcode van Microsoft in je project en repareer even de RawPrinterHelper.SendFileToPrinter() methode.

Nu wordt het mogelijk om alles bij elkaar te brengen in één aanroep:

string pdfFileName = "test.pdf";
string tempFileName =
    Path.Combine(Path.GetTempPath(), Path.GetRandomFileName());
GhostscriptSettings gss = new GhostscriptSettings
{
  Size = new GhostscriptPageSize() { Native = GhostscriptPageSizes.a4 },
  Device = GhostscriptDevices.ljet4,
  Resolution = new Size(600, 600)
};

GhostscriptSharp.GhostscriptWrapper.GenerateOutput
    (pdfFileName, tempFileName, gss);
RawPrinterHelper.SendFileToPrinter(printerName, tempFileName);
File.Delete(tempFileName);

Eerst stellen we een naam samen voor een tijdelijk bestand. Vervolgens laten we via GhostScript vanuit een aangeboden PDF dit tijdelijk bestand vullen met PCL code (op A4 formaat met een resolutie van 600 dpi). En vervolgens laten we dit PCL bestand ruw naar de printer sturen. En achteraf verwijderen we natuurlijk nog even het tijdelijk bestand.

Dit moet voldoende zijn. Natuurlijk moet deze oplossing uitvoerig getest worden doordat het een heleboel zaken integreert… Maar in onze testopstelling functioneert het heel aardig. Persoonlijk had ik liever niet met een tijdelijk bestand op schijf gewerkt, maar met bijvoorbeeld een memorystream.