Connect a Sensibo Sky to HomeKit via Homebridge

Very few smart thermostat / smart air conditioner controls are available in Australia, and exactly none of them work with HomeKit out of the box. I have a Sensibo Sky in my lounge room, and with the help of some Homebridge tomfoolery – it works brilliantly with HomeKit!

Here’s how it works:

Configure controller

You need to be able to control your air conditioner via the Sensibo app before anything is going to work with Homebridge. Use the included instructions to download the app, connect the Sensibo Sky to your WiFi network and set things up.

Next, log into https://home.sensibo.com/, click the hamburger menu and select Create API Key. The API is how the Homebridge plugin communicates with the Sensibo servers and ultimately controls your air conditioner.

Homebridge plugin and config

First, you should definitely check out my guide for getting Homebridge up and running – come back here once you’re done:

Configure Homebridge as a Service on Debian

There are a number of Homebridge plugins for controlling Sensibo devices – the one I’ve had the most success with is Homebridge Sensibo Sky 7 modes Plugin:

sudo npm install -g homebridge-sensibo-sky-7modes
Once the plugin is installed, use the configuration below – all you should need to do is add your own API key, but you can adjust settings to taste:

"platforms": [
    {
        "platform": "SensiboSky",
        "name": "Sensibo",
        "apiKey": "YOURAPIKEYGOESHERE",
        "timeLapse": 5,
        "ai": false,
        "hideFan": false,
        "hideHumidity": true,
        "fixedState": "auto"
    }
]

Keep in mind this is just a snippet and needs to be added to your Homebridge config.json file. If you’re not 100% sure you have the right syntax, check it at JSONLint.

Time to restart Homebridge:

sudo systemctl restart homebridge

After a few moments you should have two new icons in the Home app:

  1. A thermostat icon with the temperature
  2. A fan icon that allows you to set the fan speed

I’ve set it up this way because I’ve had very little luck with letting Homebridge control the fan speed automatically. It’s possible that it’s just my air conditioner; you may have better luck in using the automatic fan settings with yours.

Automation

Once the Sensibo Sky is working with Homebridge, you can set up some pretty cool automation! I’ve got “Auto Cool” and “Auto Heat” scenes that automagically turn the air conditioner on and off to maintain a consistent temperature in the room.

To set this up yourself, you need to use a 3rd party HomeKit app – I use Home. At A$22.99 it’s quite an expensive app, but it’s definitely been one of my better buys.

The magic trick is using “Any Change” in temperature as detected by the Sensibo Sky as the trigger event. I’ve tried (and failed) to make this work using other triggers, but this one actually works!

The remaining steps are fairly straight forward: use current temperature and power state of the air conditioner as conditions, then finally set the power state to on or off as the action.

Notes

Placement of the Sensibo Sky is critical! If you still use the regular remote control, the Sensibo Sky has to be somewhere where it can “see” the infrared commands that the remote sends. Even when it can, it will occasionally get out of sync with the actual state of the air conditioner – the only time I actually use the Sensibo app is to get it back in sync again.

UniFi IPv6 and Dual Stack PPPoE

 

Internode offers Dual Stack IPv4/IPv6 connectivity to their broadband customers and has done so since 2011; sadly, said connectivity doesn’t work very well out of the box with the UniFi Security Gateway router.

The problem? UniFi’s router firmware (version 4.4.22.5086045) and cloud controller (version 5.8.30) configure DHCPv6 Prefix Delegation on both the WAN interface and the PPPoE interface; the outcome of which is that the router obtains an IPv6 address – but nothing else in the network does.

This bug manifests itself with any ISP who authenticates customers via PPPoE and provides dual stack connectivity on the PPPoE interface (and assigns a customer-end IPv6 address range via Prefix Delegation) – not just Internode.

Configure IPv6

In case you haven’t already done so, configure IPv6 in the Controller. Internode’s general instruction for IPv6 is that you get given a dynamic /64 for the PPP interface and a static /56 for your LAN, distributed via Prefix Delegation. So far, so easy.

In the Controller, select the site, then Settings -> Networks -> WAN. In the IPv6 section:

  • Connection Type: Using DHCPv6
  • Prefix Delegation Size: 56

Save, then select the local network you want to enable for IPv6. In the Configure IPv6 Network section:

  • IPv6 Interface Type: Prefix Delegation
  • IPv6 Prefix Delegation Interface: WAN (this is the giveaway for where the problem lies..)
  • IPv6 Prefix ID: 56 (unsure whether this is necessary)
  • IPv6 RA: Enable IPv6 Router Advertisement checked (leave settings at the default)
  • DHCPv6/RDNSS DNS Control: Auto

Save and then wait for everything to provision. In theory, this would be enough for everything to just work, but it’s not. If you SSH into the USG and run show interfaces, you’ll see that the ethx interface that corresponds to the local network you configured above doesn’t have an IPv6 address:

Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description
---------    ----------                        ---  -----------
eth0         -                                 u/u  WAN
eth1         192.168.1.1/24                    u/u  LAN
eth2         -                                 A/D
lo           127.0.0.1/8                       u/u
             ::1/128
pppoe0       my.public.ipv4.address            u/u
             2001:my:public:ipv6:address:d32f/64

Fix Stuff

Knowing that the problem relates to Prefix Delegation being configured on the WAN interface rather than the PPPoE interface, you need to create a script which disables DHCPv6 Prefix Delegation on the WAN interface and restarts DHCPv6-PD on the PPPoE interface.

SSH into the USG and create /config/scripts/post-config.d/dhcp.sh:

#!/bin/vbash
# Script is started on reboot and via a cronjob created during provisioning

readonly logFile="/var/log/postprovision.log"

source /opt/vyatta/etc/functions/script-template

configure > ${logFile}

# Delete cronjob that called this script
delete system task-scheduler task postprovision >> ${logFile}

# Remove DHCPv6-PD from eth0 (WAN)
delete interfaces ethernet eth0 dhcpv6-pd >> ${logFile}
commit
exit

# Obtain IPv6 addresses for Prefix Delegation
release dhcpv6-pd interface pppoe0 >> ${logFile}
delete dhcpv6-pd duid >> ${logFile}
renew dhcpv6-pd interface pppoe0 >> ${logFile}

Make the script executable: sudo chmod +x /config/scripts/post-config.d/dhcp.sh

SSH into the Controller and either create or update the file [unifi_base]/data/sites/site_ID/config.gateway.json – on Debian, and assuming the site ID is “default”, the config.gateway.json file is located at /usr/lib/unifi/data/sites/default/:

{
  "system": {
    "task-scheduler": {
      "task": {
        "postprovision": {
          "executable": {
            "path": "/config/scripts/post-config.d/dhcp.sh"
          },
          "interval": "2m"
        }
      }
    }
  }
}

Always check that the file contents are valid JSON using JSONLint – this will prevent problems with provisioning the USG.

Finally, force a provision of the USG – log into the Controller, select the site, then Devices -> USG -> Config -> Manage Device -> Provision.

Once provisioned, IPv6 should be working on your network!

Note: If your ISP requires a VLAN tag on the WAN interface, there are slightly different steps required – see the first source below.

Sources:
https://spflug.de/?p=175
https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-USG-Advanced-Configuration

Auto archive in Matomo

As I’ve discovered, setting up auto archival of Matomo reports makes Matomo faster (and also helps automate downloading of the geolocation databases). Generally speaking, follow the official auto-archiving guide .. BUT the cron job instructions don’t put things in the “correct” cron.hourly folder, and my OCD needed to fix that. 😉

Create the following file: /etc/cron.hourly/matomo-archive

#!/bin/sh
# Script to automate Matomo report archival

/usr/bin/php /path/to/matomo/console core:archive --url=https://matomo.example.com/ > /var/log/matomo-archive.log

Update the bits in yellow to whatever is appropriate for you. Run the cron job manually – it may take quite some time! Afterwards, make sure you’ve disabled browser triggers for Matomo auto archival (per the official guide).