home assistant wall mounted tablet

Home Assistant Wall Mounted Tablet Update

This post may contain affiliate links. Please see the disclaimer for more information.

This is an update to my previous post on my wall mounted Home Assistant tablet. There have been quite a few changes, so I thought it was worth another post on the subject. Let’s get into it…

Power Failure

I’ll start with the big issue which has plagued this project – power. Since the battery in the original tablet was completely exhausted I had built a wired power supply to replace it. Unfortunately, this wasn’t powerful enough and the tablet would power off sometimes under high load. This problem seemed to get worse until the tablet would power off after just a few minutes, thus becoming pretty much useless.

home assistant wall mounted tablet
The new PSU all wired up (difficult to capture in a photo!)

I mentioned previously that I had ordered a 5A power supply to fix this problem, but even that didn’t work. The tablet must pull transient currents of more than 5A, which a battery can supply quite easily. Unfortunately the fixed power supply cannot. This is a real shame because I put a lot of effort into the new power supply – I even printed a case for it based on a modified version of the parametric PCB case I used in my recent MySensors build.

Even with the failure of the new power supply, the exercise in building this has demonstrated the utility of a wall mounted tablet in our household. The decision was therefore taken to replace the old broken tablet with a new one.

The New Tablet

The new tablet is the Lenovo Tab E8 (link is to Amazon, but ours came from a local retailer), chosen solely because it was the cheapest 8 inch tablet available!

home assistant wall mounted tablet
The new tablet mounted on the wall, complete with new brackets

The tablet seems pretty good overall, at least for the price. The build quality is fine, although the case is very plastic-y. It’s a little slow after boot up as it loads up everything, but in normal usage as a wall mounted dashboard it performs perfectly well. The shipped operating system is Android 7.0, which is up to date enough to not present any problems with app support.

The biggest issue with this device is that it charges really slowly, even from the provided charger. I even had cases when setting it up that the battery would still drain when plugged in to the charger. I was a little concerned that the tablet battery would become discharged over time during normal use, due to wake ups from the motion sensing. However, once the tablet was mounted on the wall and left overnight it charged to 100% and has remained there since.

Fixing the Brackets

I printed new brackets for the tablet with a reduced front lip. This removes the issue with the brackets obscuring the screen. The right bracket (left from the point of view of the tablet and in the STL files) also has a cut out in it’s side to allow the USB cable to pass through. I made these edits in OpenSCAD, by first importing the original STL files. I then created an object which represents the material I wanted to remove. Then a difference operation between the two gives the final object. I’m pretty pleased with them. The only thing I wasn’t able to reproduce was the rounded internal edges on the cut out sections.

Wall Panel MQTT Integration

With the power issues solved, I can integrate the tablet fully with Home Assistant (without fear that the extra load will cause it to power off). I’ve integrated in the sensors available on this device (pretty much just the power status). The full YAML code for this is available on GitLab. This pretty much went according to the WallPanel documentation. However, I did find that I needed to specify a value_template in order to extract the battery value:

sensor:
  - platform: mqtt
    state_topic: "wallpanel/kitchen/sensor/battery"
    name: "Kitchen WallPanel Battery Level"
    unit_of_measurement: "%"
    value_template: '{{value_json.value}}'
    device_class: battery

To extract the boolean status for the charging state sensors, the template gets a little more complex:

binary_sensor:
  - platform: mqtt
    state_topic: "wallpanel/kitchen/sensor/battery"
    name: "Kitchen WallPanel Charge State"
    value_template: '{% if value_json.charging %}ON{% else %}OFF{% endif %}'
    device_class: power

  - platform: mqtt
    state_topic: "wallpanel/kitchen/sensor/battery"
    name: "Kitchen WallPanel AC State"
    value_template: '{% if value_json.acPlugged %}ON{% else %}OFF{% endif %}'
    device_class: plug

I also integrated in the motion, face detection and QR code sensors, although I’m not using the face detection or QR code sensors and have since disabled them in WallPanel.

sensor:
  - platform: mqtt
    state_topic: "wallpanel/kitchen/sensor/qrcode"
    name: "Kitchen QR Code"
    value_template: '{{value_json.value}}'

binary_sensor:
  - platform: mqtt
    state_topic: "wallpanel/kitchen/sensor/motion"
    name: "Kitchen Motion"
    payload_on: '{"value":true}'
    payload_off: '{"value":false}'
    device_class: motion

  - platform: mqtt
    state_topic: "wallpanel/kitchen/sensor/face"
    name: "Kitchen Face Detected"
    payload_on: '{"value":true}'
    payload_off: '{"value":false}'
    device_class: motion

The final integration I did was to add a switch to turn on and off the camera streaming. However, in general usage this seems a bit flakey, with the camera stream not usually becoming available until after a WallPanel restart. Here’s the YAML used for the switch anyway:

switch:
  - platform: mqtt
    command_topic: "wallpanel/kitchen/command"
    name: "Kitchen Camera State"
    payload_on: '{"camera": true}'
    payload_off: '{"camera": false}'
    optimistic: true
    retain: true

Dashboard Improvements

home assistant wall mounted tablet
My Current Dashboard

I’ve improved my dashboard somewhat since my last post. However, it’s still a long way from some of the awesome dashboards I’ve seen posted. It’s still a work in progress!

The main changes have been to switch to the animated weather custom card for the weather forecast and to add Custom Header to my install to compact the header. I then added more buttons, some media controls and a gauge showing the progress of my 3D prints. The vacuum buttons call some custom scripts to start the vacuum with our preferred settings. This is necessary to work around a bug in HASS with the Botvac D3:

script:
  spot_clean:
    alias: "Spot Clean"
    sequence:
      - alias: "Start spot clean"
        service: vacuum.neato_custom_cleaning
        data:
          entity_id: vacuum.marvin
          mode: 2
          category: 3

  house_clean:
    alias: "House Clean"
    sequence:
      - alias: "Start house clean"
        service: vacuum.neato_custom_cleaning
        data:
          entity_id: vacuum.marvin
          mode: 1
          category: 2

It should be noted that I’m running a slightly older version of HASS at the moment. In newer versions the service name changed to neato.custom_cleaning. Also, using a category value of 3 for spot cleaning appears to be undocumented, but if you look at the library, that’s what it’s doing.

Conclusions

This setup is now working perfectly and all the problems with the previous iteration have been resolved. It’s unfortunate that this was done by throwing money at the problems, but sometimes things just don’t work out as we hope!

Overall, I’m really happy with the finished product. The dashboard will be continually developing as I come up with ideas and work out what’s useful and what isn’t. Feel free to share your ideas again via the feedback channels.

If you liked this post and want to see more, please consider subscribing to the mailing list (below) or the RSS feed. You can also follow me on Twitter. If you want to show your appreciation, feel free to buy me a coffee.

power supply connected

Salvaging a Broken Tablet for a Smarthome Dashboard

This post may contain affiliate links. Please see the disclaimer for more information.

I’ve never been massively convinced in the utility of a wall mounted smarthome dashboard. It’s always seemed like there are easier ways of controlling the smart home, for example Zigbee buttons. I guess one advantage could be their use as an information radiator for your home. However, I tend to have a good eye on what’s going on around the home and have notifications set up for all the important non-obvious stuff.

Basically, I was never convinced enough to go out and buy a tablet for this purpose. Especially as the decent tablets in NZ are pretty expensive, we don’t seem to get the cheap Amazon Fire ones which are popular for this application. However, the opportunity arose to use a defunct tablet for this purpose. So I thought I would give it a try – if I could get it to work.

Powering The Tablet

The tablet in question is a Samsung Galaxy Tab Pro 8.4, which is several years old and would not power on due to a completely exhausted battery. After doing a bit of research on YouTube, I was able to determine that it should be possible to disconnect the old battery and use the connector to power the tablet from the wall, with the cable running out through the back of the device.

Once I had the correct tools to pry apart the case without damaging the screen I was able to remove the battery without any problems. I then snipped off the connector on the battery, leaving enough cable to solder some new cables to the positive and negative terminals.

Then I built up a power supply to provide the required 3.8-4.2V via the battery connector. I used a small adjustable voltage regulator to provide power. As it turned out this wasn’t enough to power the tablet by itself. However it did power up when the USB cable was additionally attached.

power supply during testing
The power supply during testing
power supply finished
Power supply once finished off with tape and heatshrink
power supply connected
The power supply sitting in the battery cavity
cutting a hole in the back of the tablet
Since the power supply wouldn’t fit flush, I needed a larger hole than I originally intended in the back of the tablet!
taped up hole
There I fixed it!

Unfortunately, it’s still a bit flakey and will sometimes power off due to a brown out. It’s OK in normal (very light) use as a dashboard, but can’t cope with much more. I’ve ordered a power supply which can supply more current (up to 5A). Hopefully once I have that installed I can drop the USB cable and only need a single connection.

Mounting

I 3D printed the mounting brackets for the tablet from a ready made model. These brackets are nice and easy to print, however I found on installing the tablet that they obscure the bottom corners of the screen quite a bit. I also can’t rotate them so the short sides are along the bottom due to the USB connection. I’m hoping I’ll be able to modify the design in order to reduce the size of the bottom tabs, but I haven’t got around to this yet.

mounting brackets
The mounting brackets once mounted to the wall (they are level, I just can’t hold the camera straight!)

Updating the OS

Aside from the power issue, the main issue with this tablet being so old is the version of Android it was running – 4.4.2! This is pretty ancient and means a lot of apps aren’t available any more. Also the browser app which I wanted to use (WallPanel) uses Android WebView and the version available won’t render Home Assistant’s Lovelace UI. Unfortunately WebView isn’t upgradable in this version of Android either.

With all this in mind I set out to upgrade the tablet. I knew that it was supported by Lineage OS at some point in the past. With a bit of fiddling (and compiling Heimdall from source), I was able to get TWRP running on it. I then installed an old version of Lineage OS (13), OpenGApps Nano and Magisk on it. This gave me Android 6.0 and full root access. Not great, but not awful. I wouldn’t recommend this setup on a device your going to use as a daily driver, since it hasn’t had any security updates in a while.

Smarthome Dashboard and Other Apps

tablet smarthome dashboard
The tablet showing my smarthome dashboard so far

On that base, WallPanel (with an upgraded WebView) works great with HASS. I’ve also installed the prime version of Nova Launcher to give me a nice home screen for launching other apps from (I needed to prime version to scale up the icons for easier casual use). A secondary purpose of this tablet will be for firing things off to the Chromecast quickly without having to use one of our phones, so launching of Netflix and other streaming apps are required.

tablet launcher
The launcher with quick access to other apps

I really like WallPanel, especially the MQTT and camera integrations. However, I’ve currently got most of the advanced features turned off to save power and prevent brown outs! I really need to fix that power supply! I am making use of the motion detection to wake the tablet up though. Tasker and Termux are also installed, but I’m so far not doing much with them.

As you can see from the photos, I’ve begun work on a smarthome dashboard view in Lovelace for this, but I haven’t got too far. Part of the reason for this post is to get others to share their dashboards and give me some inspiration.

Conclusion

It seems like this project has had more than it’s fair share of issues and road blocks. I definitely wouldn’t call it finished, but the proof of concept is there and there is a clear path for what needs to be improved.

So far the tablet has been on the wall for a couple of days and I’m already finding it useful. Since the tablet will wake up as you walk past it will generally catch your eye and convey some useful information (such as when it’s going to stop raining!). I think I’ll focus on the informational/status aspect in my dashboard design going forward.

Next Steps

I’ve documented most of the next steps above, but as a recap:

  1. Replace the power supply with one that can provide more current;
  2. Modify the mounting bracket design to not obscure the tablet screen;
  3. Turn on the advanced features of WallPanel and integrate into HASS;
  4. Finish the Lovelace dashboard.

I’ll also probably do some more integration/automation using Tasker. One feature I would like would be to re-launch the dashboard when the tablet becomes idle, in case someone left it on a different screen.

I hope you’ve enjoyed following this journey of me giving new life to some old hardware. It’s always nice to do that rather than making yet more e-waste! Please feel free to share your own smarthome dashboard projects in the comments and feedback channels, I definitely need more inspiration.

If you liked this post and want to see more, please consider subscribing to the mailing list (below) or the RSS feed. You can also follow me on Twitter. If you want to show your appreciation, feel free to buy me a coffee.

home assistant android shortcut

Quick Home Assistant Shortcuts for Android

This week’s post is going to be a little shorter than normal, since I’ve been working on projects which aren’t ready to share yet. However, I did want to share a quick, but useful approach to controlling smart devices directly from the home screen of your Android device via some Android shortcuts and Home Assistant.

home assistant android shortcut
The home screen housing my HASS shortcuts

Let’s Get Started

The app I’m using to do this is called HTTP Shortcuts. It’s both free (as in beer) and Open Source. You could accomplish the same thing with Tasker and even though I also use Tasker, I still use this app. This is because it’s just a nice simple app that does one thing well. You can also execute these shortcuts from within Tasker if you would like.

home assistant android shortcut
Our HTTP Shortcuts variables

Before we create a shortcut, we’re going to add a couple of variables to make life a bit easier when creating multiple shortcuts. To do this press the {} icon in the top left corner. We are going to add two variables, one for the the HASS server name and another for the authentication token.

The first of these is easy, simply add a new variable with the plus icon and enter the key as ha_server. Leave the type as constant and add the hostname of your HASS server as the value. Make sure to not include the URL scheme here (http:// or https://) since this appears to throw off the regex validation when creating the shortcut.

For the second variable follow the same process, however you’ll want to insert the value of the long lived access token you get from your Home Assistant user’s profile page in the value field.

Creating Shortcuts

With that bit of prep done we can navigate back to the main page. Here we will add a new shortcut by again clicking the plus icon. First give your shortcut a name and description. These are only for your own use. You might also want to choose an icon at this point.

Next, hit the ‘Basic Request Settings’ item to and set the method to POST. In the URL field we enter the value:

https://{ha_server}/api/services/[domain]/[service]

Here you’ll replace [domain] with the entity type e.g. switch and [service] with the service name, e.g. turn_on. I find that using the toggle service is the most useful for these shortcuts, since you are usually using them in visual range of the device and it basically gives you two shortcuts in one.

The {ha_server} notation should be left as it is. This is using the variable we created earlier. Variables can actually be easily inserted with the {} button so there is no need to type it. You’ll also want to adjust my example above if you are using plain HTTP rather than HTTPS.

Adding Headers

The next stage of this is to add a custom header to our request. This is the Authorization header which has the value Bearer {ha_auth_token}. You’ll see here that we use the other of our variables to include the authentication token.

home assistant android shortcut
Our HTTP Header

Request Body

Finally we come to the request body. Here we set the request body type to ‘Custom Text’. The content type field here should again be set to application/json and the value should be the JSON to pass to the service. In the simple case this would just contain the entity ID you want to operate on, e.g {"entity_id": "switch.myswitch"}. Of course this might contain more data depending on the service you are calling. The data is exactly the same as that passed to the services developer tool in HASS, so you can test your calls there and then copy the data over.

home assistant android shortcut
Our finished shortcut

Final Steps

Once you’ve finished you can add the shortcut to the home screen via the long press menu on the main listing page. You can also export a copy of all your shortcuts via the settings page for use on another device. I don’t think this exports the values of your variables unless you checked the ‘Allow Share…’ advanced setting for the variable itself. This is most likely a good thing, since you’re going to want to use a different authentication token on each device.

I hope you’ve found this useful. I use these shortcuts every day and find them invaluable. The app has quite a bit more functionality which I haven’t covered here, including cURL import/export and processing of responses using Javascript.

For my regular readers, I apologise for the shorter post. It’s going to be a busy month coming up, but hopefully I’ll be back to my usual schedule soon. Thanks for sticking with me!

Home Assistant NFC Script

Home Assistant Automation in Depth: Multi-function NFC Tags

This post may contain affiliate links. Please see the disclaimer for more information.

This post is part of my “Home Assistant Automation in Depth” series. Here is the series index:

Welcome to the latest installment in my Home Assistant Automation in Depth series! In this article we’re going to explore how I’m using NFC tags with Home Assistant to control various aspects of my home automation. Specifically, I’m going to show my approach to making an NFC tag perform different actions depending on context.

I’m not going to dive headlong into an explanation of what NFC is. If you managed to somehow arrive at this page without knowing that, go and read the Wikipedia page! For our purposes it is sufficient to say that we can scan these little tags with our phone and some code will react to the scanning event.

How is NFC useful in Home Assistant?

Hopefully, you are already joining the dots in seeing how this is useful. Basically an NFC tag is a nice way to provide an input to a system. Think of it like a magic wireless button, that doesn’t need batteries! (assuming you charge your phone of course).

There is actually a little more to it than that. Since we won’t store anything sensitive on the tag itself we can safely leave them in public places. For example you could place one outside your front door. Only a phone which has been pre-configured with our setup will be able to execute the actions we have specified. Also, Android phones must be unlocked to scan the tags giving an extra layer of security.

There is a wrinkle with this, however. If someone knows the location of your tag they could potentially re-write it with some other (malicious?) data. There appears to be a way to write protect tags in the NFC Tools app I use below. However, I haven’t tried it yet. Make sure you do this if you want to place tags in areas where someone untrusted may have access!

Of course, the price of this is that you must have your phone on you which isn’t such a big deal. It may mean that you might not want to use these for tasks which need to be done very quickly or potentially with your hands full.

Connecting to HASS

There are at least two ways to connect NFC tags into Home Assistant. We can either use a dedicated app, or we can use Tasker with a plugin to accomplish the same thing. I’m going to describe the Tasker route, since I already had this in place before the HASS NFC app became available. Tasker is also allows you to do much more, so is a good app to have in any case.

The plugin we need for Tasker is called NFC Tasks and is free. In addition, we’ll need it’s companion app NFC Tools (also free) to configure our tags. You’ll also need Tasker and some NFC tags (obviously). I like the sticker variety (alternative link) for home automation purposes. However, they come in all kinds of shapes and sizes.

Once you have all the software installed it’s time to start connecting things up. First we’re going to want to setup Tasker to talk to Home Assistant via the REST API. This has got a little more complex if you want to use the new authentication system. However, there is a useful tutorial on the Home Assistant forum (thanks to @bokub for that!). This involves creating a specific task which can be re-used to talk to HASS. Go away and follow the instructions to do that now!

Welcome Back!

Once you’ve done that, you’ll need to set up another task (as detailed in the tutorial) which will be called when our NFC tag is scanned. I’m going to call a script, so mine looks like the screenshot below, but you can call any service in Home Assistant.

Home Assistant NFC
My task to be called when the tag is scanned

At this point you can test your task by executing it in Tasker and making sure it calls the right thing in HASS. You’ll then need to back right out of Tasker in order for it to apply the settings. If you don’t do this the task won’t show up later. Press the back button until you land back at the home screen, don’t just press the home button!

Writing the Tag

For the next part, we open the NFC Tools app and head to the tab called ‘Tasks’. Click the ‘Add a Task’ button, then navigate to ‘Various’ and ‘Tasker’. Hit the magnifier/search icon next to the task name input, then select the task you just created from the pop-up and press the ‘OK’ button. When you’re done, you should land at a screen like the one below. Hitting the write button will prompt you to scan the tag to write it.

Home Assistant NFC
Ready to write to the tag

If you now exit the NFC Tools app and scan the tag, you should see that your Tasker task is executed. This in turn performs your Home Assistant action.

At this point it should be noted that you can execute more than one task from a single tag. NFC Tool/Tasks also have a whole load of tasks built in, most of which I’ve not tried. Feel free to have a play around!

UPDATE: /u/databoy2k on reddit suggested an alternative way of doing this, which centralises more of the logic on the HASS server and so scales better to more tags/phones. I haven’t had time to try it fully yet, but I’ll probably switch over to it in future.

On the Home Assistant side

So now we have an NFC tag which can perform an action in Home Assistant. I’m now going to share how I’m using one particular tag as a multi-function switch for different modes in my house. I’ll start with an input_select to define the different modes I want:

input_select:
  home_mode:
    name: "Home Mode"
    options:
      - "None"
      - "Coffee Time!"
      - "Lunchtime"
      - "Bedtime"
      - "Night"

I’ve placed my tag on the door frame of the door between our kitchen/living area and the rest of the house. This means I can scan the tag when I go through the door to select a different mode.

The question now is, how does the system know which mode to select? I’m doing this based on time of day, since my modes are mostly based around different events which fit within a rough timeframe. You can use pretty much any state or information from Home Assistant via a template. Here is my script which achieves this:

script:
  home_mode:
    alias: Home Mode Switch
    sequence:
      - alias: Select Home Mode
        service: input_select.select_option
        data_template:
          entity_id: input_select.home_mode
          option: >
            {% if now().hour < 7 %}
            Bedtime
            {% elif now().hour < 12 %}
            Coffee Time!
            {% elif now().hour < 18 %}
            Lunchtime
            {% else %}
            Bedtime
            {% endif %}

The keen eyed among you would have noticed that this is the script which is being called when my NFC tag is scanned. Here I simply set the value of the input select based on time of day. You’ll see that ‘Bedtime’ appears twice in order to handle the before and after midnight cases. With this setup:

  • Scanning the tag between 7am and 12pm will set the mode to ‘Coffee Time!’
  • A scan of the tag between 12pm and 6pm will set the mode to ‘Lunchtime’
  • Scanning at any other time will set the mode to ‘Bedtime’.

Handling the Modes

I handle each mode via an automation. Firstly, let’s go with the ones for my coffee and lunchtimes:

automation:
  - alias: Coffee/Lunchtime Lights
    trigger:
      - platform: state
        entity_id: input_select.home_mode
        to: "Coffee Time!"
      - platform: state
        entity_id: input_select.home_mode
        to: "Lunchtime"
    action:
      - service: light.turn_on
        entity_id: light.kitchen_downlights

  - alias: End of Coffee/Lunch Time
    trigger:
      - platform: state
        entity_id: input_select.home_mode
        to: "Coffee Time!"
        for:
          minutes: 10
      - platform: state
        entity_id: input_select.home_mode
        to: "Lunchtime"
        for:
          minutes: 30
    action:
      - service: light.turn_off
        entity_id: light.kitchen_downlights
      - service: input_select.select_option
        data:
          entity_id: input_select.home_mode
          option: None

This basically implements some timed lighting for my break times during the day. I was always forgetting to turn off the kitchen lights when going back to work, so now I don’t have to. The timed lights also serve as a nice reminder that it is actually time to go back to work!

Since we already stored the state in the input_select we can use this as the timed trigger for the lighting off rule. This avoids the need for an external timer. Once we are done, we set the mode back to ‘None’

Next, we’ll tackle the bedtime mode. This is pretty simple, it just calls a script which turns off the lights and other appliances:

automation:
  - alias: Bedtime
    trigger:
      - platform: state
        entity_id: input_select.home_mode
        to: "Bedtime"
    action:
      - service: script.turn_on
        entity_id: script.bedtime
      - service: input_select.select_option
        data:
          entity_id: input_select.home_mode
          option: Night

Conclusion

So there we have it – a multi-functional NFC tag which triggers different actions in Home Assistant, depending on the time of day. This approach has been working really well for me for quite some time. I’ve only recently upgraded it to the new authentication scheme, but it works flawlessly.

With the power of Home Assistant scripts, particularly the templating options, this approach could be taken a lot further than the simple examples I’ve shown here. One idea would be to turn on or off different appliances dependent on the state of other sensors. Another is to perform different actions depending on who is home at the time.

There are also probably further extensions, like doing different actions depending on the phone which scans the tag. I suspect the logic for this would have to be built into the Tasker task on the phone. For example each phone could call a different script on the server.

I’d also like to give these a try for outdoor use, with the write protect enabled of course. I think I might need to find some more durable tags for that experiment however, the stickers don’t feel very weather proof.

I’m interested to see what else people are doing with NFC and Home Assistant. Please get in touch via the comments and Twitter to let me know!

If you liked this post and want to see more, please consider subscribing to the mailing list (below) or the RSS feed. You can also follow me on Twitter. If you want to show your appreciation, feel free to buy me a coffee.

Self Hosted Push Notifications Server UI

Self Hosted Push Notifications with Gotify and Home Assistant

This post may contain affiliate links. Please see the disclaimer for more information.

Notifications, that bane of modern existence! Most people only have to deal with getting too many. However, if you’re running a smarthome or any other kind of moderately complex computer setup you need to decide how you are going to send and receive them too. Many notification systems rely on “trusted” third parties (a.k.a Apple or Google) to handle the delivery of notifications through to the current communications device of choice – the smartphone. Of course, this breaks my fully self hosted ethos and is to be avoided. Luckily it’s now possible to achieve self hosted push notifications with Gotify.

The Backstory

Pretty much since starting my smarthome journey (and really even before), I’ve had trouble with notifications. For a long time email was the goto solution – especially with my nicely self hosted email setup. Then I tried XMPP, then Rocket.Chat (I even wrote the Rocket.Chat notification platform for Home Assistant). There were probably a few more notification systems that I tried and definitely many more that I looked into. Nothing really stuck. Most were too complex to setup and maintain for the benefit that they provided. I mean, who really wants to run a whole chat server just for sending a few notifications?

Then Home Assistant implemented HTML5 notifications. These were cool, but not without downsides. For a start the full capabilities of the platform are only really supported by Chrome on Android. The notifications also go through – you guessed it – Google. However, the notification content is end-to-end encrypted between the HASS instance and the device. You can also do cool things like including images inline and having action buttons to press (actionable notifications).

If I’m honest, HTML5 notifications never really fit into the easy to set up basket either. The set up process is quite involved and requires creation of a project via Google Cloud Services and verification that you own the domain in question. However, once I got it working they worked well for quite some time.

Why can’t you get this right, Google?

After a while things started to have problems. First, I would quite often get delayed notifications. Sometimes to the point where the notification would not come through until you picked up and unlocked the phone. This negates the point of the notification entirely! Why is it that my self hosted email server can push messages in real time to k9mail running on the same phone, but Google’s own system has issues? I thought GCM/FCM was made of magic that simultaneously allowed it to be more reliable than anything else and consume no battery!?! /s

The next nail in the coffin was Google’s incessant pestering and breaking of things. First they wanted me to set up payment details, even though they weren’t going to charge me (why?). Then they said they were shutting down the GCM APIs used by my (admittedly somewhat outdated) version of HASS on May 29th this year. I assume that I could have fixed that by updating HASS (which I have since done). However, by this point I’d had enough and shut down the whole thing.

I initially fell back to SMTP/email notifications from HASS, which I still had running for a few lower priority things. However, I was on the look out for a replacement. I’d already heard of Gotify via /r/selfhosted, so I decided to give it a try. Since some of my other projects are starting to pay off and my smarthome is getting smarter, having a reliable notification system is becoming more pressing for me.

Deploying the Server

My ideal notification system would just use MQTT to push notifications to an app running on my phone. This wouldn’t require me to set up anything else but the app since I have everything else to support that. However, the designers of Gotify decided to use Websockets so an extra piece of server software is required.

Luckily, this software is written in Go (hence the project name). It also comes in a handy Docker container for easy deployment. Being written in Go makes it both fast and means it consumes barely any resources.

One consideration when deploying this is that you probably want it to be somewhere externally accessible, so that your phone can connect to it when not on your wifi. I installed it on an already accessible host that runs a few other dockerised services. I followed the official instructions, but came up with this to add to my docker-compose file for that server:

gotify:
  image: gotify/server
  volumes:
    - /mnt/docker-data/gotify/data:/app/data
  ports:
    - 9080:80
  restart: always

Well, that was easy.

Further configuration can be accomplished via config file or environment variables. However, I found the default settings to be fine for me.

Further Setup

I also needed to set up my reverse proxy to route requests through and set up TLS via Let’s Encrypt. I’m not going to go through that here. There are instructions (for the Gotify part) for nginx and apache available. Also, if you’ve already set up TLS for HASS then you can follow the same process. The Gotify app will show large warnings if you don’t use TLS. However, it will allow it so you don’t need to do this if you are only doing a bit of local testing.

Self Hosted Push Notifications Server UI
Gotify has a nice web interface, for configuration and receiving/viewing notifications on the desktop

After that I installed the app from F-Droid and added an exception in the battery optimisation page of my Android phone settings. This is different on every phone, but you need to make sure Gotify is listed as “Not optimised”. If you don’t do this Android will kill the app during sleep and you won’t receive notifications. For those that are going to bang on about how this will give you horrible battery life, I haven’t noticed a difference. Admittedly, I was already running a few apps unoptimised, such as k9mail and OwnTracks.

Setting up an Application

Before we can send notifications we need to create an application on the Gotify server. Applications map to individual streams of notifications on the recipient devices. One minor issue is that (as of the time of writing) applications are user specific, there is no way to share an application between users. This isn’t such an issue for us since we will need to set up individual notification platforms in HASS for each user anyway.

Self Hosted Push Notifications Application Setup
Our Application Screen

I set up my application as “Home Assistant” (surprise, surprise). I also uploaded the HASS logo which will be displayed in the notifications. Once the application is configured you will be given a secret token/key that can be used to send notifications via the REST API. You’ll need to copy this for use later.

Configuring Home Assistant

I played around for quite a while sending notifications with cURL as per the documentation and also some more complex messages via the RESTED Firfox addon. However, I’m going to skip straight to how to integrate this will Home Assistant, since that’s probably why you’re here!

Gotify has a simple REST api for sending notifications. Therefore we can use the REST notification platform in HASS to integrate it without a custom component:

- name: gotify_1
  platform: rest
  resource: https://my.gotify.server/message
  method: POST_JSON
  headers: 
    X-Gotify-Key: !secret gotify_key
  message_param_name: message
  title_param_name: title

This goes wherever you have your other notification platforms set up, for me this is in my notify.yaml file. After restarting HASS you should have the notify.gotify_1 service available. The reason for numbering it is that we will need more notification services to extend this to other users. You’ll need to update the resource key to the URL of your Gotify server and the X-Gotify-Key header value to the key you generated for your application earlier (which I recommend keeping in your secrets.yaml file, as I’m doing).

Sending Notifications

Sending self hosted push notifications
Sending a notification from Home Assistant

We should now be able to send notifications via the services developer tool in Home Assistant. It should be noted that you need to encode the data to send in JSON here for it to work. The data should contain ‘title’ and ‘message’ fields, exactly the same as any other notification platform. For example:

{
    "title": "Hello World!",
    "message": "Hello from Home Assistant via Gotify"
}

Once you hit the ‘CALL SERVICE’ button, you should immediately see a notification on your phone from Gotify:

Self hosted push notification received
Receiving our first notification

Again, that was easy (wasn’t it?).

Advanced Notifications

So far, we can send simple text notifications from Home Assistant via Gotify. However, Gotify also supports sending markdown formatted notifications, which opens up many more options.

To configure this, we edit our REST notification platform to the following:

- name: gotify_1
  platform: rest
  resource: https://my.gotify.server/message
  method: POST_JSON
  headers: 
    X-Gotify-Key: !secret gotify_key
  message_param_name: message
  title_param_name: title
  data:
    extras:
      client::display:
        contentType: "text/markdown"

Don’t forget to update the resource and X-Gotify-Key values as before. This updated configuration adds some extra data as per the Gotify documentation to indicate that the message payload should be rendered as markdown.

So let’s send a markdown formatted message. In the services dev tool again, select your notification service and use the following data:

{
    "title": "Markdown message", 
    "message": "#This is Markdown\n*Now* we can do all kinds of stuff!"
}

And you should get:

Self hosted push notifications with markdown
Yay markdown!

Neat.

Using that for Something Useful

Markdown formatting is all well and good, but not all that useful just for making silly (but well formatted) messages. We’d like to actually put it to good use.

I’ve thought about including links in various notifications which could be used to trigger a Home Assistant webhook. This could then perform some action, but I’m still not convinced on the usability of it and haven’t had a chance to try it out.

One very useful option is including an image in the notification. This is particularly interesting if this image could come from a camera in Home Assistant. As it turns out this is relatively easy thanks to some minor templating:

{
    "title": "Camera Image", 
    "message": "![Camera Image](https://my.hass.server{{ states.camera.beach_webcam.attributes.entity_picture }})"
}

Here I’m including the latest image from a local beach webcam that I have set up in HASS as a generic IP camera. All we need to do is use the entity_picture attribute to get the path of the image on the HASS server and join it to the base URL to build our image source. The resulting message is shown below:

Self Hosted Push Notifications with images
Looks like a nice day down at the beach (even though it’s winter down here)

Obviously, this could be very useful for security alerts, etc.

Conclusion

Overall, I’m pretty impressed with Gotify. Although the project is still young, it works as advertised and I haven’t had any functional issues. There are a few rough edges, but no showstoppers. I’m looking forward to seeing the feature set improve over time. I’d particularly like to see actionable notifications, which would set it up as a full alternative to HTML5 notifications in HASS.

I’ve been able to integrate Gotify into HASS up to the level of it’s current feature set. This is thanks to the well thought out REST API and the flexibility of the REST notification platform in HASS. So far I haven’t needed a custom/official component. As the Gotify API becomes more featureful, it’s likely that a component will be needed in order to unlock it’s full potential. However, as it stands the REST notification platform works just fine.

I’ve had no problems so far with delayed or missed notifications – which is better than Google can do! That in itself is an achievement the Gotify developers should be proud of.

If you liked this post and want to see more, please consider subscribing to the mailing list (below) or the RSS feed. You can also follow me on Twitter. If you want to show your appreciation, feel free to buy me a coffee.