How to Build a Smart House Controller Using Raspberry PI 2, MS Windows 10 IoT and Netatmo API

In Windows 10 IoT, the GPIO outputs are managed by the GPIOController class available to C#, C++, JavaScript and Visual Basic developers. The class requires two methods:

1. GetDefault() which returns the default GPIO controller (if any) for the system in question.
2. OpenPin(Int32) or a safer one in terms of exclusion TryOpenPin(), both of which open a connection through a pin with a designated number.

After we open a connection with a pin, we can set its operation, read values from it or write them into a pin (logic zero or logic one).
Here’s an example of code to initialize and use a pin:

// Set number of pin that we want to open 
int number = 4; 
// Open connection to the pin GpioPin 
pin = _gpioController.OpenPin(number);
pin.Write(GpioPinValue.High); 
pin.SetDriveMode(GpioPinDriveMode.Output);

Why do we write the GpioPinValue.High value when initializing the pin, when in fact we would need GpioPinValue.Low to establish logic zero at the output? The reason is the next line where we set the DriveMode to Output. Here’s what MSDN has to say:

“When you setup drive mode to ‘GpioPinDriveMode.Output’ that configures the GPIO pin in strong drive mode, with low impedance.”

This means that the device connected to the pin will switch on when the output value is GpioPinValue.Low.

Later on, having saved the variable with an open pin, you’ll be able to change its value from closed to open and the other way with a single line.

And this is how with a class of 100 – 200 lines, you’ll be able to manage 13 devices. Not that impressive, but good for starters. And don’t forget that you have a spare I2C for 128 devices (theoretically).

Custom HTTP Server: The Great Test Solution Not to be Used in Real Life

Now let’s look at our custom HTTP server. To create one, we need a new project for IoT Core – a BackgroundTask where our web-server will be executed, along with the AppToApp communication service host for communicating with Windows UWP Application on Raspberry, where our BackgroundTask is actually registered and run. When creating a custom HTTP-server, it is very important to add the Package.appxmanifest parameter:

<Capabilities> 
  <Capability Name="internetClient" /> 
  <Capability Name="internetClientServer" /> 
</Capabilities>

For AppToApp communication, we have to add the following extension to the file. The extension should feature a namespace and a class for BackgroundTask. The Name attribute in AppService should feature the communication service name.

<Extensions>
 <uap:Extension Category="windows.appService" EntryPoint="SmartHouse_Netatmo.IoTCore.StartupTask">
 <uap:AppService Name="App2AppComService" />
 </uap:Extension>
</Extensions>

To create the web-server, we need the StreamSocketListener that will listen to the designated port and subscribe to the event of ConnectionReceived which we’ll process when getting GET queries from the front end.

listener = new StreamSocketListener();
port = serverPort;
listener.ConnectionReceived += (s, e) => ProcessRequestAsync(e.Socket);

private async void ProcessRequestAsync(StreamSocket socket)
 {
 try
 {
 // this works for text only
 StringBuilder request = new StringBuilder();
 using (IInputStream input = socket.InputStream)
 {
 byte[] data = new byte[BufferSize];
 IBuffer buffer = data.AsBuffer();
 uint dataRead = BufferSize;
 while (dataRead == BufferSize)
 {
 await input.ReadAsync(buffer, BufferSize, InputStreamOptions.Partial);
 request.Append(Encoding.UTF8.GetString(data, 0, data.Length));
 dataRead = buffer.Length;
 }
 }

 using (IOutputStream output = socket.OutputStream)
 {
 string requestMethod = request.ToString().Split('\n')[0];
 string[] requestParts = requestMethod.Split(' ');

 if (requestParts[0] == "GET")
 await WriteResponseAsync(requestParts[1], output);
 else
 throw new InvalidDataException("HTTP method not supported: "
 + requestParts[0]);
 }
 }
 catch (Exception ex)
 {
 Debug.WriteLine(ex.Message);
 }
 
 }

Then we look at query parameters and manually write a reply into the OutputStream. Here comes the answer to the question, why not to use this approach in real life with real products? A small HTML+CSS+JS page with only a couple of functions generates over a dozen queries every time the page is reloaded. You’ll have to parse everything manually, create a response depending on a query and send it. We tried this approach just for the sake of proving the concept.

Thus, if you need a similar solution with a web service, try to wait for stable betas of ASP.NET MVC and DNX for ARM. You’ll have a range of options and real opportunities to make something much better than simply a concept.

Conclusion

So, what do we have? First, analytical research and a solid working prototype that works with other devices and manages them correctly. BTW, the hardware budget is less than $200, which is cheaper than any other similarly functional smart home solution. Second, we received a Proof of Concept for the software part of the experiment. The solution will last through upgrades, and there’s space for growth in terms of using ASP.NET 5 MVC as a web application & service and a universal app with GUI for data visualisation.

For developers, the experiment was a hands-on experience with Windows 10 IoT, the Netatmo’s web API and ARM apps. It also allowed working with real hardware and trying something new in general, namely creating a DIY solution for smart home written in the favorite language.

If you want to learn more about modern IoT solutions, we will be happy to discuss your needs. Contact our team of IoT experts.