Protosystem Blog

ASP.Net Core Hello World on Raspberry Pi

Wed, 29 Nov 2017 10:32:08 GMT

Overview

In a previous post I showed you how to install the .Net Core 2.0 on a Raspberry Pi running Raspbian so that you could run dotnet Core applications on this wonderful device. We didn't really run any applications in the previous post but we did prove that the dotnet core was installed properly. In this post I will walk you through creating an ASP.Net Core 2.0 Hello World Web Application and deploy it onto the Raspberry Pi. You will create this project on your developer machine and target the ARM processor for deployment to a Raspberry Pi. This post will only cover doing this on a Windows machine.

Setup

You are going to need to make sure you have the .Net Core SDK on your developer workstation before you write some code. Well I don't need to show you how to do that on my blog as it has already been done here. So stop procrastinating and get it installed.

Just to double check that the .Net Core 2.0 SDK is installed open up a comman prompt and execute the following:

dotnet --info

You should see something like the following output:

Create the Web App

Back on your developer workstation in that CMD prompt, create a new directory to hold your web application.

 mkdir hello-world

Then jump into that new directory.

 cd hello-world

Then create a new web application.

 dotnet new web

This created a simple web application that we can test on our developer workstation to make sure it works.

dotnet run

You should see something like the following output:

Go ahead I know you are dying to open up a browser and navigate to http://localhost:5000 and see this new start of the art application!

You should see something like the following:

Ok this is pretty bare bones but I did say we were going to create a hello world web application. But wait the real fun part is getting this to run on the Raspberry Pi. Go ahead and kill the development web server in the CMD prompt using Ctrl+C. First we need to change the code so that it will bind to more IP addresses then the localhost one. Edit the Program.cs class and change the following to add the UseKestrel and telling the web server to listen on all IP Addresses:

       public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup()
                .UseKestrel(options =>
                {
                    options.Listen(IPAddress.Any,5000);
                })
                .Build();

Now lets publish this web application to a linux ARM platform.

dotnet publish -r linux-arm

The output of this commend looks something like this:

This command generated all the files you need to copy over to the Raspberry Pi. This is where you need to figure out the best way to copy the files to the Raspberry Pi. One way to do this is to run an FTP server on the Pi and open up a FTP client (such as FileZilla) on your developer workstation and upload the files. I like to use the Python library called pyftpdlib as it allows you to serve up files in any folder on the Pi and it is a temporary FTP server. I didn't really want to focus this post on setting up an FTP server so I thought using this library will be the path of least resistance. I am going to assume you already know how to SSH into your Raspberry Pi with something like Putty so go ahead and do that.

On the Raspberry Pi install the python FTP library.

pip install pyftpdlib

Once the library is installed you need create a folder on the Raspberry Pi that will hold the hello-world web application. On the Raspberry Pi issue the follwoing command:

mkdir hello-world

Then navigate into that directory

cd hello-world

Then start up the FTP server so we can upload the files. On the Raspberry Pi execute the following command.

python -m pyftpdlib -w

On your developer workstation start up your favorite FTP client (such as FillZilla) and connect to the Raspberry Pi using anonymous/anonymous as the useranme/password. Upload the files located in bin\debug\netcoreapp2.0\linux-arm\publish folder to the Raspberry Pi.

Once the files are uploaded you can stop the FTP server on the Pi by using Ctrl+C in the SHH terminal. Next we need to set the right permissions on the executable. Execute the follwing command on the Raspberry Pi.

chmod 755 hello-world

Now lets execute the application to serve up the files, so execute the following on teh Raspberry Pi:

./hello-world

The program should start up and let you know the port it is serving the web site on.

Open up a browser on your developer workstation and put in http://x.x.x.x:5000 where x.x.x.x is the IP address of your Raspberry Pi. You should see the hello-world web application in your browser.

Conclusion

As you can see it is pretty easy to create a web application on your development machine and target the linux-arm platform so that the application can be copied over to the Raspberry Pi and executed. We only did a simple web application but you can also create an mvc application and expose a Web API from the Pi. Just execute the following:

dotnet new mvc

Next up I will look into remotely debugging an application from your developer workstation on the Raspberry Pi.

ASP.Net Core on Raspberry Pi

Fri, 10 Nov 2017 04:16:05 GMT

Overview

I just started playing around with .Net Core since it has hit the 2.0 release. Since I have used Raspberry Pi’s on many projects I thought it was time to do a hello world Asp.Net Core project that is served up on a Raspberry Pi using Raspbian for the OS. Here is how I got that going.

My goal was to create the default out of the box ASP.Net Core MVC application on my Windows 10 developer machine and publish it targeting ARM and see if I could get that running on the Raspberry Pi. I do not intend to compile applications on the Raspberry Pi as I believe that would just be slow going. I have longer term goals like being able to debug on the Pi from my Dev machine but lets take baby steps first.

Setting up the Raspberry Pi

At the time of writing this post it wasn’t real clear to me how to get .Net Core running on my Raspberry Pi with the latest Raspbian OS. On the Dotnet Core Docs site, there were instructions that targeted specific Linux distros but nothing that I saw specifically for Raspbian. However I did find another blog post by Jeremy Lindsay that got me to the point that .Net Core 2 was installed on my Raspberry Pi. I am not going to go into deep details on how to get Raspbian installed and how you shell into a terminal on a linux box as that is covered on many other posts (including Jeremy’s).

Run the following commands in a terminal window on the Raspberry Pi:

 
# Update the Raspbian Jessie install 
sudo apt-get -y update 

# Install the packages necessary for .NET Core 
sudo apt-get -y install libunwind8 gettext 

# Download the nightly binaries for .NET Core 2 
wget https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.0.0/dotnet-runtime-latest-linux-arm.tar.gz

# Create a folder to hold the .NET Core 2 installation 
sudo mkdir /opt/dotnet 

# Unzip the dotnet zip into the dotnet installation folder 
sudo tar -xvf dotnet-runtime-latest-linux-arm.tar.gz -C /opt/dotnet 

# set up a symbolic link to a directory on the path so we can call dotnet 
sudo ln -s /opt/dotnet/dotnet /usr/local/bin

At this point you should be able to test the install by executing the following in a terminal window on the Raspberry Pi:


dotnet --info

And you should get something back that tells you what version on dotnet core you have.

Conclusion

As you can see getting the .Net Core 2 on your Raspberry Pi is pretty easy. Next post I will go into creating an MVC hello world app and running it on the Raspberry Pi.

Halloween Scare 2016

Sat, 04 Nov 2017 22:08:47 GMT

I kicked off another Halloween project this year and I posted it on GitHub for everyone to see and use if they like. This project has focused around building smart devices that are all connected via an MQTT bus. I wanted to have something that I could build on every year. The devices are either actuators or sensors that are smart enough to serve a purpose and can be orchestrated into a bigger animation scene using a workflow engine such as Node-red. Anyways check out the project on Hackster.io and GitHub.

Halloween treat with Windows 10 IoT Core and Raspberry Pi

Sat, 04 Nov 2017 22:08:26 GMT

I wrote another article on Hackster.io that shows how to build an animated ghostly pumpkin using Windows 10 IoT Core. Check it out: Halloween treat with Windows 10 IoT Core and Raspberry Pi.

Windows 10 IoT Core powered garage door

Sun, 22 Nov 2015 21:23:09 GMT

I wrote an article on using the Raspberry Pi 2 Model B for a contest on Hackster.io. This project focuses on using the Alljoyn messaging framework. Head on over to Hackster.io for my Garage door powered by Win 10 and the Raspberry Pi project. Here is a video demo of the project.

Continuous Delivery on a Spark.io

Thu, 06 Aug 2015 09:33:37 GMT

I have always wanted to remotely update my IoT devices when they are in need of a software change. It is really a pain when I have to disassemble a dedicated device just because I need to update the software that is embedded in it. It has been so much of a pain for me I have gone as far as trying to make the device as dumb as possible and leave the smarts in a service located on a computer with an OS that supports remote access. Doing so seems to make the device just a remote I/O extension and not an actual Smart Device.

Continuous delivery takes the remote update one step further. If I have a source control repository that I commit some new code to, then my automated process should be smart enough to pick up that change, compile, test and deploy the new bits to it’s final destination. Wow wouldn’t that be cool!!!

In order to do this the device would need to be smart enough to support a remote update process. That means a device would have to be able to check for updates and automatically apply them. You could write your own remote update process and I have done this many times for desktop applications, but doing this on an embedded device is little more tricky. Sometimes it would require you to actually change the device firmware especially if the device doesn’t support dynamically loaded software. Basically the process to do so would require you to do the following:

Detect if an update exists on some remotely accessible resource
Download the update and unpack it
Unload the current version of the software
Load the new version of the software
Start executing the new version
Do this reliably without bricking the device

Fortunately the Spark.Io platform does all this for you so you don’t have to. The platform even supports an open source backend that will take source code, compile and deploy it. Now that makes it very possible to do continuous delivery for IoT devices. The rest of this blog post will explain how easy it is to set this up.

There are several things you will need to have in order to accomplish this:

A Spark.io account and a device that is connected/registered with the account.
A source control repository that is supported by your CI tool of choice (I am using GitHub)
A build script that can either call restful APIs or can shell out to curl.exe (I am using psake with curl.exe).
A CI tool that watches the source control for commits and kicks off the build process (I am using Team City on a Windows Azure VM).

You can see my source repository over at SparkContinuousDeliveryExample. Feel free to fork it and use it if you like. I used psake as my build scripting language of choice as it is supported by Team City and I find it very easy to understand.

Build script

My build script is called default.ps1.

properties { 
  $deviceId = $env:SparkDeviceId 
  $token = $env:SparkToken 
  $base_dir = resolve-path . 
  $curl = "$base_dir\lib\curl\curl.exe" 
}

task default -depends Deploy

task Clean { 
}

task Deploy { 
  $url = "https://api.spark.io/v1/devices/" + $deviceId + "?access_token=" + $token 
  exec { 
     .$curl -X PUT -F file=@src\helloworld.ino "$url" -k 

  } 
} -depends Clean

task ? -Description "Helper to display task info" { 
   Write-Documentation

The first thing you will notice is that the script takes 4 parameters that are defaulted but also can be overridden by Team City. The $deviceId represents the spark.io device Id and can be found in the spark.io build website after you have logged in and picked one of your devices. The $token is your spark.io access token and can be found in the spark.io build website after you have logged in and selected the settings menu option. You really only have 1 access token for an account but you could have multiple device id’s for an account. The other 2 parameters are really only for executing the curl.exe program that interfaces with the spark.io platform. Since the repository has the curl.exe you wont have to worry about installing it on your build server, but if you don’t like putting EXE’s in your repository you could override these parameters to launch the curl.exe that is installed on your build agent. The Deploy task is the only task in this build script that does anything. Basically it launches curl.exe passing in the device id, token and the file name to upload to the spark.io platform for compilation and deployment. In this case the program source file is helloworld.ino.

Testing the build script locally

You can test the psake build script on your local machine by first setting the environment variables for the $env:SparkDeviceId and $env:SparkToken.

Of course I didn’t include my real Device ID and Token in the example above so make sure you set them using your own Spark.io settings.

Make sure you are in the directory where you cloned the repository and use the Invoke-psake keyword to kick off the build.

Your code will be uploaded to spark.io, compiled and then deployed to your device. As you can see here the process completed successfully.

Setting up Team City:

You will have to follow the instructions on the Team City web site on how to install Team City. It is very easy to do but I wont detail it here. I am also going to ignore the step of setting up Team City to connect to your Github repository. Assuming you have a project created in Team City and you have assigned the VCS root to the project you need a build step added to your project. You want to make sure you select Powershell as the runner type. See the other options I selected in the following screen snapshot:

Make sure you select Source Code as the script type and then type in the powershell script but make sure you replace the YourDeviceId and YourToken.

Here is the script so you can copy and paste it easier.


import-module .\lib\psake\psake.psm1
invoke-psake .\default.ps1 -properties @{"deviceId"="YourID";"token"="YourToken"}
if ($psake.build_success -eq $false) {exit 1} else { exit 0}

Here are the rest of the options to finish off the build step:

And that is all there is to it. You will want to add a Trigger to your build project so that it fires off a build when source is committed to the repository. Also make sure you have the VCS Root pointed to the “master” branch. Now whenever you commit changes to the master branch the build will pick it up and send it off to Spark.io for compile and deploy.

Limitations:

Works on single file source solutions at this time.
If a compile error exists the build does not fail (but the device does not update).
If you edit the readme or any other non-source files and commit it then the device gets updated even though no source changes were made.

Enhancements:

Get this working on a free hosted build platform
Use a Raspberry PI as a build server
Remove the dependency on curl.exe and use powershell to make the REST api calls
Add in multi-file support
If the Spark.io platform is down fail the build
Make sure a compile error fails the build

Conclusion:

That is all I wanted to cover on this blog post. Of course there a million other ways you could set this up and I would also like to hear how others might do this. I have always dreaded pulling devices apart just to upgrade them and therefore I tended to not update them as frequently as I would like. I just need to get the hardware nailed down on some projects so that I can get them installed and hooked up to a build.

Garage door and the Spark Core on github

Sun, 05 Nov 2017 14:16:01 GMT

I just posted my initial code for my Garage door project using the Spark Core on github. This is a work in progress and will evolve over time.

Garage door and the Spark Core

Sun, 05 Nov 2017 14:22:08 GMT

I recently moved to a new home and I now have 2 garage doors to control instead of one. So I decided to revamp my garage door home automation project by using the Spark Core. This is a fascinating device as it is designed to connect to the Spark.IO cloud service without doing a lot of coding to maintain the connectivity to the cloud. The default firmware in the device allows you to remotely connect to it and invoke functions, expose variables to the cloud service as well as perform pub/sub between devices. Make sure you check out their website to gain a better understanding of all the capabilities of this small packaged IoT controller.

My goals in this project was to achieve the following:

know when either garage door is opened or closed.
remotely close or open the garage door.
have the door automatically close when I go to bed.
keep track of how long it takes to open/close the garage door.

if the door starts to take longer to open and close this might be a sign that it needs maintenance.

automatically open the garage door when I arrive home.
automatically close the garage door when I leave my home.
notify me when the door needs maintenance because it has been opened/closed so many times.
monitor the temperature and humidity in the garage.
monitor the garage for motion when the security system is on.
notify me that I left the door open after a specific time of night.

That is certainly a large number of goals and I don’t intend to complete all of them initially but you kind of get the idea of what the possibilities are.

Initially I intended to do all of this for 2 garage doors with one Spark Core, but after thinking about it a bit it made more sense to use at least two Spark Cores.

One thing I decided to do right off the bat is to make sure I have enough sensors that could determine when the door was opened and when it was closed. I have seen other remote garage door projects that simply have one sensor that detects if the door is closed or not. I wanted more inputs so that I could time how long it took for a door to complete it’s open or close command. I want to keep track of this in order to determine if the door will need maintenance when it starts to take longer to open or close. I can also gather a little more analytics around the timing of the door command and the temperature in the garage. I don’t know if I will use this more detailed information for anything or not but I thought it would be fun to play around with.

So I will have 2 magnetic reed switches that I plan on placing on the door track to determine if the door is closed or opened. The status of the door will be 5 different states: opened, closed, opening, closing and unknown. The unknown state will only be for when neither of the sensors are triggered and the device doesn’t know if the door was previously opened or closed. I have most of the code written to handle the basic door operations and I will be sharing that code in a future post.

So stay tuned on future posts on this topic as I move forward with it. Please feel free to give me feedback or ask questions on items I haven’t clarified very well. I am very interested in anyone’s thoughts on the Spark Core as well as home automation in general.

BuilderFaire track at Raleigh Code Camp 2014

Sat, 04 Nov 2017 18:44:28 GMT

I gave a talk at the Raleigh Code Camp called "What can I do with a Raspberry PI". The slide deck is attached to this post for those of you that attended.

Raspberry PIv2.pptx (6.67 mb)

Raleigh Code Camp 2013 Netduino Azure Session

Wed, 30 Oct 2013 18:33:18 GMT

I am presenting two sessions in the Raleigh Code Camp 2013 Builder Faire track on November 9th. The first session is called Building a cloud enabled home security system Part 1 of 2 (the presentation). The second session is Building a cloud enabled home security system Part 2 of 2 (the lab). You really need to come to both sessions as the first session explains what you will be building in the second session. Yes I said that right, if you attend the second session you will be building a Netduino based security system that connects to Windows Azure. Check out the project website for more details at Cloud Home Security.

I hope to see you there!!