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.

3d print switch cover

Solving Smart Bulb Problems with 3D Printing

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

If you ask the question “should I go for smart bulbs or smart switches?” on pretty much any home automation forum and you’ll undoubtedly get a mixture of answers. Most likely many of these will come down on the side of smart switches as the superior technical solution. This is generally because they replace the existing switch and so can be actuated manually. Also, you don’t have pesky switches that aren’t supposed to be touched, lest the smarts go out of your smart bulbs.

For a variety of reasons (pretty colours among them!), I only have smart bulbs in my house. I’ve written before about how I’ve added manual control back to some of these where required. Of course this still leaves me with certain switches in the house which “shall not be pressed”. I’ve had a nice non-invasive solution in mind for this for a while, but I’ve only been able to realise it since getting a 3D printer.

People Problems

I actually see this problem as less of a technical one and more of a people one. In the normal operation of our house, it rarely occurs that a smart bulb is turned off at the switch. This is because we are used to the way the house works and trust that the automation system will do the right thing.

Of course, when we have guests this all falls apart. People just can’t help flicking a switch if one is presented to them. Even if they just entered a room where the light came on automatically, they will switch it off on exiting. The only solution is to remove the temptation by removing or covering the switch.

The low tech/ugly solution to this would have been a piece of tape with “do not switch off” scrawled on it in marker pen. However we can do better than that. There are little plastic widgets available which can be stuck over the top of a switch and will restrict its use. I haven’t seen any that will fit the switches here in NZ, which are more square in comparison with British or US switches. So I decided to make my own.

OpenSCAD to the Rescue

As a programmer, it’s probably not a surprise that my 3D modelling software of choice is OpenSCAD. I’ve dabbled in using is before and managed to learn the basics before getting my 3D printer. However, this is the first physical object I’ve actually attempted to produce with it. I’m actually really happy with the result.

Note: the first version of these had the logo flipped for some reason. I’ve since updated the files in GitLab and Thingiverse (links below). The photos below show the original versions with the reversed logo. Thanks to @templarian on Twitter for pointing this out.

3d print switch cover
Yes, these are Home Assistant themed! My way of saying “don’t touch, HASS will take care of it”!
3d print switch cover
Mount the cover by sticking double sided tape or blu-tack to the tabs
The covers look pretty good once mounted. Note the Zigbee switch above for automation override (if needed).

This has been made for my PDL-600 series switches, but the design is parametric, so should be trivially adaptable to other NZ/Australian switches, since most of these seem to maintain the squarish form factor. I’ve also made a double switch cover for two switches arranged horizontally. This was done by elongating one side and centring the logo.

3d print switch cover
Parametric modelling FTW!
3d print switch cover
I made the tabs slightly narrower here so that the cover would fit onto the switch plate
Just fits!

Model Parameters

The model parameters are available at the top of the OpenSCAD source and have comments, which allows the software to present you will a nice dialog for editing the parameters. You can even set presets and switch between them. I’ve already included the presets for my single and double switches.

The available parameters are as follows:

  • wall_thickness – The thickness of the main wall around the switch. Defaults to 1mm and you probably won’t need to change it;
  • button_length – The length of the cover (from top to bottom as you look at it mounted, since the reference is to the flat surface as it’s printed). Adjust depending on the size of your buttons;
  • button_width – The horizontal width of the cover, to allow for non-square buttons and also multi-button arrangements. I doubled this to produce the double cover;
  • button_height – The height of the button from the switch plate. Used to create the internal cavity to cover the switch;
  • logo_x_offset – X coordinate offset of the logo. Use this to move it around if you change the cover dimensions above;
  • logo_y_offset – Y coordinate offset of the logo. Use this to move it around if you change the cover dimensions above;
  • tab_width – the width of the mounting tabs on either side;
  • tab_height – the thickness of the mounting tabs.

Wait, I want some of these…

If you have a 3D printer you can download the OpenSCAD file and STLs (for the variations I’ve printed) on GitLab or Thingiverse. I’ve also included GCode files for the Ender-3 in the Git repo, but I recommend you slice the models yourself with your own settings. You’ll need to print with supports enabled for the internal cavity, but these pop out quite nicely.

If you don’t have a printer, you are welcome to use any of the available 3D printing services online, but I’m afraid I can’t recommend one. I also found them rather expensive when I looked into it.

If there is sufficient demand I might put up a Tindie or Etsy store for these and charge a couple of dollars (plus shipping of course!). Let me know in the comments if you’d be interested in this.

Conclusion

I’m really happy with these, especially considering they are my first custom 3D printed object. They’ve actually solved a real world problem for me, since we recently had guests again and nobody switched off any of the smart lights!

I’m interested to hear if anyone else has used 3D printing to solve smart home annoyances like this. There seems to be a lack of HA related designs on Thingiverse. Let me know if you’ve come up with anything useful!

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:

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 rubbish collection

Quick Project: Follow up to my Home Assistant Rubbish Collection Panel

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

Last month, I wrote a quick post about the Home Assistant Rubbish Collection panel I made for the Lovelace UI. Well, it looks like amaximus was inspired to create his own custom card to do a similar thing. [NOTE: the author of this card hasn’t contacted me directly (I came across it via HACS), I’m only claiming to be the inspiration based on the relative dates].

This card has a couple of cool capabilities that my previous panel didn’t have. Specifically, you can set colour coded icons for your different bins and the icon will change style and colour (to red) when the bin is due to go out in the next day. You can also hide the card completely if a bin is not due to go out within X days.

home assistant rubbish collection
Cards for all four of my sensors, with colour coded icons
home assistant rubbish collection
If the collection is the next day the icons change to red

Installation and Setup

I installed the card by adding a git submodule to my configuration repository in the www/plugins directory, but you can also install directly from HACS. I’m switching over to adding all my custom components and cards as submodules in order to make my config more easily deployable.

After installation, you need to add the path to the garbage-collection-card.js file in the resources section of your Lovelace UI config:

Once that’s done you can add cards to the UI. I just put mine in a vertical stack to group them together:

…and that’s it! If you want to hide a card for bins that don’t need to go out soon use hide_before: x (where x is the number of days). I’ll probably use this to hide bins that don’t need to go out in the current week, but I wanted to show all the cards in the screenshots 😉

Conclusion

I think this is a great improvement on my previous panel, so I’m going to stick with it. Thanks to the author another contributors for taking the time to make it!

It’s kinda cool to think that this blog may have inspired someone else to go out and write some code! If you are inspired to make and share something as a result of one of my posts, please get in contact! Your work will most likely get featured in a future blog post.

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.

continuous integration home assistant

Continuous Integration for Home Assistant, ESPHome and AppDaemon

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

Recently I set up continuous integration and deployment from my Home Assistant configuration. This setup has been nothing short of awesome! It’s liberated me from worrying about editing my configuration – all I do is git push and relax. Either HASS will notify me when it restarts or I’ll get an email from Gitlab telling me the pipeline failed.

I wanted to take this configuration further and expand it to other parts of my Home Automation infrastructure. In this post I’ll cover expanding it to perform deployments of my HA stack with Docker, building and deploying to ESPHome devices and unit testing and deploying my AppDaemon apps.

Let’s get on with it!

Automating Docker Deployment

I’d originally held off doing this because I wasn’t looking forward to building custom Docker images in Gitlab CI. However, I managed to complete the original pipeline without having to add any extra dependencies to the HASS containers (such as git which I thought may be required). This makes the job of deploying my HA stack much easier, especially as I already had it mostly scripted. The first step was to add my update.sh script to my repo and tweak it to suit:

This is a pretty simple modification to my previous script. The main additions are that I use the -p argument to set the project name used by docker-compose. By default this is taken from the directory name, but I wanted it to match the name of my previous project even though the directory has changed from ha to home-assistant. The other main modification is that I’ve added the --remove-orphans argument to clean up any lingering containers. This is useful if I remove a container from the docker-compose.yml file. In addition I’ve removed the apt commands and cleaned up the script a bit so that it passes my shellcheck job.

The next step was simply to add the docker-compose.yml file to the repo. Then I continued by editing the CI configuration.

Updated Home Assistant CI Jobs

I first split up my previous deployment job into two jobs. The first of these is the main deployment job which pulls the new configuration. The second restarts HASS. The restart job goes in a new pipeline stage and will only be run when the docker-compose.yml or update.sh files haven’t changed:

I then added another job (again in another pipeline stage) which performs our Docker deployment. This will be run only when either the docker-compose.yml or update.sh files changes:

continuous integration home assistant
A full pipeline run with a deployment of the Docker containers running in the final stage.

With that in place I can now redeploy my HA stack by modifying either of those files, committing to git and pushing. In order to facilitate HASS updates with this workflow, I changed the tag of the HASS Docker image to the explicit version number. That way I can simply update the version number and redeploy for each new release.

Continuous Integration for ESPHome

Inspired by the previous configs I have seen for checking ESPHome files, I wanted to implement the same checks. However, I wanted to go further and have a full continuous deployment setup which would build the relevant firmware when its configuration was changed and send an OTA update to the corresponding device. As it turned out this was relatively easy.

I started out by importing my ESPHome configs into Git, which I hadn’t previously done. You can find the resulting repository on Gitlab. For the CI configuration I first copied over the markdownlint and yamllint jobs from my Home Assistant CI configuration.

I then borrowed the ESPHome config check jobs from Frenck’s configuration. These check against both the current release of ESPHome and the next beta release. The beta release job is allowed to fail and is designed only to provide a heads up for potential future issues.

Then I came to implement the build and deployment job. Traditionally these would be performed in separate steps, but since ESPHome can do this in a single step with it’s run subcommand I decided to do it the easy way. This also removes the requirement to manage build artifacts between steps. I created the following template job to manage this:

Most of the complexity here is in unlocking the git-crypt repository so that we can read the encrypted secrets file. I opted to store the git-crypt key in the repository, encrypted with openssl. The passphrase used for openssl is in turn stored in a Gitlab variable, in this case $OPENSSL_PASSPHRASE. Once the decryption of the key is complete, we can unlock the repo and get on with things. We remove the key after we are done in the after_script step.

Per-Device Jobs

Using the template configuration, I then created a job for each device I want to deploy to. These jobs are executed only when the corresponding YAML file (or secrets.yaml) is changed. This ensures that I only update devices that I need to on each run. The general form of these jobs is:

Of course you need to replace my_device with the name of your device file.

continuous integration home assistant
A run of the ESPHome pipeline with deployments to two devices

With these jobs in place I have a full end-to-end pipeline for ESPHome, which lints and checks my configuration before deploying it only to devices which need updating. Nice! You can check out the full pipeline configuration on Gitlab. I now no longer have need to run the ESPHome dashboard, so I’ve removed it from my server.

Continuous Integration for AppDaemon

I mentioned previously that I wanted to split out my AppDaemon apps and configuration into a separate repo from my HASS config. I did this as a prerequisite step of this setup and you can again find the new repo on Gitlab.

The inspiration for this configuration came mostly to @bachya on the HASS forum, whose post in reply to my earlier setup provided most of the details. Thanks for sharing!

I started out by copying across the now ubiquitous markdownlint and yamllint jobs. I then added jobs for pylint, mypy, flake8 and black:

Although this ends up being very verbose, I decided to implement these all as separate jobs so that I get individual pass/fail states for each. I’m also pretty sure the mypy job doesn’t do anything right now, because I’m not using any type hints in my Python code. However, the job is there for when I start adding those.

Unit Testing AppDaemon

Another thing that @bachya introduced me to was Appdaemontestframework. This provides a pytest based framework for unit testing your AppDaemon apps. Although I’m still working on the unit tests for my so far pretty minimal AD setup I did manage to get the framework up and running, which was a little tricky. I had some issues with setting up the initial configuration for the app, but I managed to work it out eventually.

The unit testing CI job is pretty simple:

All we do here is install the requirements that I need for the tests and then call py.test. Easy!

The deployment job for AppDaemon was also trivial, since it is pretty much a copy of the HASS one. Since AD detects changes to your apps automatically, there’s no need to restart. For more details you can check out the full CI pipeline on Gitlab.

continuous integration home assistant
A run of the AppDaemon pipeline – lots of preflight checks here!

Conclusion

Phew, that was a lot of work, but it was all the logical follow on from work I’d done before or that others had done. I now have a full set of CI pipelines for the three main components of my home automation setup. I’m really happy with each of them, but especially the ESPHome pipeline. As an embedded engineer in my day job I find it really cool that I can update a YAML file locally, commit/push it and then my CI takes over and ends up flashing a physical device! That this is even possible is a testament to all the pieces of software used.

Next Steps

I’m keen to keep going with CI as a means of automating my operations. I think my next target will be sprucing up my Ansible configurations and running them automatically from CI. Stay tuned for that in the hopefully near future!

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.