Part of a series of blog posts:
- Step 1: Taking snapshots
- Step 2: Uploading to the cloud (this post)
- Step 3: this is work in progress

Step 2: Upload to the cloud

For the creation of the timelapse itself, I will be using C# and the code will run on Azure. I've been writing C# almost daily since 2006. So this is what would work for me (and not take too much time doing it either).

There is no integration or service readily available in Home Assistant that will allow you to upload files to Azure Blob storage. RESTful Command is a way to execute HTTP calls, but I didn't see how I could pass the contents of my image as payload (template syntax won't get this far).

I decided to code my way out of this, like any developer would do.

You can upload a file to Azure Blob storage using an official SDK (currently available in 7 languages) or just plain HTTP requests. For simplicity I chose the HTTP request. You could probably swap some parts of the code to upload to other cloud storage that supports HTTP requests.

Unfortunately I haven't written any real Python. But I knew of 2 projects that offer .NET / C# integration in Home Assistant: C# for Home Assistant and NetDaemon. I picked the first, without any reason other than it seemed to be easier to set up.

C# for Home Assistant

Setting up C# for Home Assistant took only a few minutes.

It's detailed on the wiki of the project. In short: install add-on, have samba running (already did), map network drive, open folder in VS Code, add user secrets and start coding.

The code short and simple. Loop through the files, read the content, PUT on Azure and clean up.

[Automation]
[Schedule(Every.Minute, 15)]
public async Task UploadTimeLapsesAsync()
{
    var sasToken = Secrets.GetSecret("TimelapsesSasToken");
    var files = System.IO.Directory.GetFiles("/config/www/timelapse");
    _logger.LogInformation($"Timelapse files found: {files.Length}");
    if (files.Length == 0)
    {
        return;
    }

    var client = new HttpClient();
    foreach (var fi in files)
    {
        _logger.LogInformation(fi);
        var bytes = System.IO.File.ReadAllBytes(fi);
        var fileName = System.IO.Path.GetFileName(fi);
        ByteArrayContent content = new System.Net.Http.ByteArrayContent(bytes);
        content.Headers.Add("x-ms-blob-type", "BlockBlob");
        var response = await client.PutAsync($"https://redacted.blob.core.windows.net/timelapse/{fileName}?{sasToken}", content);
        response.EnsureSuccessStatusCode();
        System.IO.File.Delete(fi);
    }
}

I use a timer as workaround. There is no direct way of starting the C# automation from my 'snapshot automation' (see Step 1) other that using helpers or yet another workaround as described in the wiki. The timer hardly impacts my system.

The add-on has a basic UI to list the automations. It can also show the logs, which I is extremely useful.

Drilling down into the logs we see that 2 images were uploaded.
It took .4 seconds read and upload the first file (513.13 KiB).
The second one was only .2 seconds (276.14 KiB).

The uploaded files in the Azure portal.

In step 3 will we create the timelapse using C#. The post will follow soon.

If you know how I would write this in Python and integrate that in HA, please let me know in the comments.

Part of a series of blog posts:
- Step 1: Taking snapshots (this post)
- Step 2: Uploading to the cloud
- Step 3: (this is work in progress)

I have a Unifi setup at home including some of their cameras. The mobile application has this really great feature where you can scroll through the timeline and the view updates instantly. It's like a fluent timelapse that you control.

This brought me to the idea that I want to created timelapses from snapshots. I have the Unifi integration set up in Home Assistant and my cameras are available as entities already. It shouldn't be that hard to get the job done, right?

Step 1: Taking snapshots

Home Assistant already has a service to take snapshots, and combined with the time pattern trigger you can easily save an image at regular interval.

The only tricky part was to find a place where files could be written. I didn't see any errors with my initial folder, but also didn't see any files created. Must have been a permission issue. After some digging I changed the path to /config/www and step 1 was complete.

Here's the YAML for my automation, where I take snapshots for 2 separate cameras, at an hourly interval.

alias: Timelapse snapshots
description: ''
trigger:
  - platform: time_pattern
    hours: /1
condition: []
action:
  - service: camera.snapshot
    data:
      filename: /config/www/timelapse/carport-{{ now().strftime('%Y%m%d-%H%M%S') }}.jpg
    target:
      device_id: 53d064634f8c8dd6cf8f9f6e2c93aa75
  - service: camera.snapshot
    data:
      filename: /config/www/timelapse/doorbell-{{ now().strftime('%Y%m%d-%H%M%S') }}.jpg
    target:
      device_id: 7abd063efe059580aafef4ee9efaa3d5
mode: single

Continue to step 2 where I upload files from Home Assistant to the cloud.

With the classic UI builds, we could easily access the option to tag source with every build or successful build.

When using Azure YAML Pipelines, this is still possible, but you really have to go out of your way to get to that option. From the YAML edit screen you'll need to go to the Triggers option via the kebab menu icon. After this you'll find the Tag sources option in the same place as before.

Self checkout

However, there is an undocumented way of doing this straight in the YAML.
You'll need to add an explicit step to checkout the code at the end of your build steps. Call the git tag command to add the (lightweight) tag from the command line, followed by a git push. Here's a slimmed down version using PowerShell:

steps:
- checkout: self
  clean: true
  persistCredentials: true

# restore, build, test, pack and push go here

- powershell: |
    Write-Host "Tagging Build: $env:BuildNumber"

    git tag $env:BuildNumber
    git push origin $env:BuildNumber
  env:
    BuildNumber: $(Build.BuildNumber)
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))

Permissions

You need the Git 'GenericContribute' permission to perform this action.

The persistCredentials option is required to allow all steps after the checkout to have access to the auth token for the git push operation.

You'll also need to set the Contribute permission to Allowed for the Build Service user .

A big advantage of placing the tagging inline is that I can now use the same YAML file for CI builds on Pull request and CD builds for approved PRs that go into master.

More information about the checkout step: https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema#checkout

PS: You can use PowerShell Core if you need cross-platform. Or switch to bash.

In this post we'll use Azure Functions as a gateway that recieves a payload from Octopus Deploy (after a deployment to production) and posts a notification to a Microsoft Teams channel.

The Azure Function code for this blogpost can be found at https://github.com/DavidDeSloovere/AzureFunction-OctopusToMicrosoftTeams

Introduction

A few weeks ago Octopus Deploy released version 3.5 of the amazing deployment tool. In this version they introduced 'Subscriptions'. This feature allows you to subscribe to all kinds of events via email or webhook. Together with the release they also published a post, showcasing the use of 'Subscriptions' to send a notification of an Octopus Deploy event to a Slack channel via Zapier. Great idea, we usd Octopus Deploy at Natch, but... we don't use Slack, and I don't want to use Zapier. We did activate Microsoft teams recently, it comes for free with our Office 365 subscription and we are always looking to improve communication and workflow. So I got this idea:

Mission: post a message on a Microsoft Teams channel when Octopus Deploy has deployed an application in production, with Azure Functions in the middle

What is Azure Functions

With the announcement of Azure Functions going GA (General Availability) yesterday (2016-11-16), it seemed like the right time to write this blogpost. Azure Functions is Microsoft's implementation of the serverless computing model on top of Azure. Serverless computing has been the lastest evolution of the cloud. Amazon has had Lambda on AWS for two years already.

Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud.

We've come a long way. It started with buying physical hardware and running servers on them (been there, done that). Then came virtualization, renting resources, and running your VMs (IaaS). Evolving into platforms like Azure Website where you don't even own and maintain VMs anymore (PaaS). IaaS and Paas are still valid models, but you're paying for those resources 24/7 even if your application only runs a few hours a day or is only visited during office hours.

With serverless computing a lot of this changes. You only pay when your code is executed. You only maintain your code. The underlying infrastructure is taken care of for you by the hosting provider.

Microsoft used the WebJobs platform as a starting point for Azure Functions. With the amazing Azure portal, the online editor code-named 'Monaco', source control integration for CD, Azure Functions is set to be a great candidate when exploring options. A Function can be written in C# with Roslyn under the hood, but also Javascript with node under the hood.

What is Microsoft Teams

In short, Microsofts answer to Slack. Released just a few weeks back (2016-11-02).

Microsoft Teams, the new chat-based workspace in Office 365

I believe Slack got a little bit scared, because they released this passive-aggresive 'Welcome Microsoft Teams' press release right after Microsofts announcement.

Flow

To set this all up, we have 3 parts:

• An Octopus Deploy Subscription that posts its payload to a webhook...
• An Azure function that receives the payload, extracts the data and posts a message
• A Microsoft Teams channel with an 'Incoming Webhook' connector

Microsoft Teams

We'll start at the last step of the flow, because we need the webhook url for the Azure Function.

In the channel, add a connector of the type 'Incoming Webhook'.

All you need is a name (ie. Octopus Deploy) and you'll get a webhook url back under the outlook.office365.com domain. You might also want to upload the Octopus logo, because that will be displayed with the message. You'll need the webhook url in the next step, keep it in the clipboard.

Azure Function

In the Azure portal, add a new Function App. This App allows you to add multiple 'functions'. We'll only need one, and we'll use 'GenericWebhookCSharp' as the starting point. This template is configured to run on an incoming http request.

Under the Application Settings of the Funtion App, add a new 'app setting' named 'TeamsWebHookUrl' and paste the O365 webhook url as the value. This app setting will be available as an environment variable when we write our C# code. You don't need to hardcode this setting, so you don't need to put this in source control.

Copy the code from the github project (which I also set up as Continuous Integration source) or this gist.

Previously, without using a service like Zapier, I would have:

• created an ASP.NET MVC/WebApi project -> too much work (lazy developer = good developer)
• hosted it on a webserver (or azure) -> would run all the time (consume too much resources, expensive)

The code is very short and will be called a few times a day at most. Which is a great fit for an Azure Function.

Before we continue to the next step, copy the Function url from the Develop tab.

Octopus Deploy

To activate a 'Subscription' you can either click around in Octopus Deploy until you stumble upon it or give up (yes, it's hidden very well). If you gave up, here iswhere you can find it: Configuration > Audit > Subscriptions (top right).

Create a new subscription. Give it a name, set filters and paste the Azure Function url in the 'Payload URL' field.

Finishing up

Now let's see if our setup works:

• Trigger an Octopus Deploy event that matches the filters of the subscription you have set up.
• In the Azure Portal, navigate to the monitor tab of your function, there is even a 'live event stream'
• Within a few seconds, your Microsoft Teams channel will receive the message that was sent by Octopus Deploy.
• Enjoy.

About writing the function

I started writing the code for the function in the Azure portal. The editor is pretty amazing, considering it's running in the browser. There a handy 'test' feature where you can quickly simulate a request to the function (which is more a webhook). This allows you to iterate quickly without leaving the browser. When the code was done (is code ever done?) I moved it to a github repo and set up the continuous integration option under the Function app settings. Now every commit in the master branch will automatically update the Azure function. So easy. I hadn't tried Azure functions before, nor had I used Octopus Deploy subscriptions or the Microsoft Teams webhook connector. Still I was able to get this all running in under 2 hours. Writing this blog post is actually more work.

Don't hesitate to leave a comment below or fork the github repo.

Some interesting links:

• Azure Functions official site
• Octopus Deploy blogpost - Octopus Deploy event to Slack channel
• Troy Hunt - Azure Functions in Practice
• Slack 'Welcomes' Microsoft Teams
• O365 Connector