Category Archives: Home Automation

Window Open / Closed Contact Sensors

Posted on by
Reply

One thing I sometimes wish I’d hard-wired for before plastering the House is contact sensors to report the open / closed state of the (openable) windows – mostly so that the automations which close the roller blinds can be ‘blocked’ if a window is open. The sensors could also provide a useful confirmation that the building is secure when nobody is home. (There are already sensors as part of the intruder alarm system, but those respond to ‘shock’ impact from any attempt to force open windows or doors and do not report open / closed status.)

The workaround is to fall back to battery-powered radio-connected sensors. While I’m not generally a fan of battery-powered devices, they’re OK for non-critical uses like this – especially when they provide accurate reporting of battery status so battery failure can be predicted (or at least reported).

From a brief trial of one IKEA MYGGBETT door / windows sensor I’m happy those will work well enough to invest in a few more of them:

  • They are powered by a single AAA battery and specifically recommend rechargeable batteries (such as the IKEA LADDA)
  • They use Matter over Thread for communications and management and so integrate very nicely with Home Assistant – especially since I’ve got a working Matter over Thread ecosystem in both the Outbuildings and the House
  • They’re fairly compact – given they have to accommodate a AAA battery
  • They’re competitively priced; £7 each in 2026 (although that seems slightly expensive compared to £5 for a TIMMERFLOTTE temperature & humidity sensor) – whereas similar devices from other brands tend to be £20 or more
    • That price does not include the battery, which is another £1 (actually £4 for a pack of 4)
  • They report battery status both as a voltage and as “percent charged” figure (to the nearest 1%)

On the tilt-and-turn windows it’s best to mount the sensors at the top, so they report ‘open’ no matter whether the window is tilted back or hinged open (like a door).

IKEA MYGGBETT door and window sensor mounted at the top of a tilt-and-turn window

These MYGGBETT sensors have a unique Matter ID printed along one side and I elected to mount them so that remains visible. There’s also a printed QR code used for commissioning but that’s only visible when the sensor is unclipped from its backplate.

If I was doing this again, I would at least install the wiring for hard-wired sensors – which would mean checking which windows have opening sections (about half of them) and whereabouts on the opening windows the sensor would be located. I would wire them with 4-core ‘alarm’ cable back to a central point, with the plan to connect them to a KNX binary input module – something like the MDT BE-16000.02 Binary Input Module for Potential-Free Contacts. Note that costs £200 for 16 channels, i.e. £12.50 per input. In addition, there would be the cost of the cable (roughly £1 for a 5m run) and the magnetic / reed-switch sensor itself (about £2 each for a basic ‘Grade 1’ sensor) which works out at about £16 per window (assuming a 7.5m cable run) so actually the battery-powered sensors are roughly half the price – but need ongoing attention to their batteries. (Arguably a proportion of the cost of the Thread Border Router required to receive the Matter over Thread signals should be included in the cost of the battery-powered sensors, but that was only £35 and covers all other Matter over Thread devices too.)

Alternative Firmware for GL.iNet GL-S20 Thread Border Router

Posted on by
Reply

By using non-vendor-managed firmware for the GL.iNet GL-S20 Thread Border Router, the Thread network is no longer limited to 3 or 4 devices and a few of the more minor annoyances with the standard firmware have been addressed:

  • The new Web UI no longer constantly requires the Admin password to be entered. Now it doesn’t ever require any password – which could be considered a security risk, although that can be addressed by restricting access to the TCP/IP network it’s connected to.
  • The Web UI now includes a Thread network Topology viewer which shows how the End Devices are connected to the Leader and any other Router nodes.

As a bonus, the TBR now supports Thread version 1.4 and it didn’t require the Thread network to be re-created following the installation of the new firmware; the previous details must have been saved in Non-Volatile Storage.

A very minor issue is that the wired network interface is using a very different MAC address and so is no longer matching the DHCP lease reservation assigned to the old one. Also, it was probably unreasonable to expect the Factory Rest button press to continue to restore the original factory firmware, so reverting to the GL.iNet-managed firmware would be more involved, perhaps most easily accomplished using the Windows firmware installation tool.

The source code for this alternative firmware comes from https://github.com/EPinci/ep-s20-otbr – where the ‘heavy lifting’ is done by links to the standard Espressif IoT Development Framework (IDF) and Thread Border Router (Thread-BR) SDK GitHub repositories. There’s then a fairly ‘thin’ add-on layer (based on some code previously released by GL.iNet) which is specific to the GL-S20 hardware.

The IDF runs perfectly happily on a Linux (Fedora) desktop which had no issues connecting over a USB cable to the USB-C port on the GL-S20. (The first installation of the alternative firmware must be done via a USB cable, although subsequent updates can be done over the network.)

The main issue I hit was a difference in the sizing of the Non-Volatile Storage (nvs) partition on the GL-S20: on my device this was previously sized at 0x10000 (ten thousand) bytes and by default the new firmware was mapping it as 0x6000 (six thousand) bytes, which triggered an error check for ‘no free pages’ (and a constant reboot cycle). Fortunately I’d saved a dump of the boot log when running the GL.iNet 2.0.1-B1 firmware which included the original partition table sizing, which I was then able to match with a small edit to partitions.csv. I added much more detail on this in Sizing of ‘nvs’ partition; ESP_ERR_NVS_NO_FREE_PAGES error (fixed) #1 in the Issues log on the GitHub repo.

The Thread Topology viewer is a feature that is almost essential for managing a Thread network with more than a very few nodes.

A screenshot from the Web UI for the Espressif Thread Border Router. The main body of the image shows a set of coloured circles connected by pale grey solid and dashed lines. The largest circle is coloured Blue and the Key shows this is the 'Leader' of the Thread network. Two small Green circles are linked to the Blue circle by dashed lines, showing these are 'children' of the Leader. A mid-sized Cyan circle represents a Router, linked to the Blue circle (Leader) by a solid line. Three small Green circles represent Child nodes, connected to the Router by dashed lines.
Example of the Thread Network Topology view

The example Topology view above shows the Thread network Leader (the GL-S20) in Blue, with one Router (an IKEA GRILLPLATS smart plug) in Cyan. The ‘Child’ (i.e. non-Router) devices are in Green.

This Topology view introduces a set of node identifiers I had not come across before; IDs like 0xb402 are Thread network Routing Locator (RLOC) identifiers – strictly speaking RLOC16 identifiers (since these are just the last 16 bits of the full RLOCs) which identify the placement of nodes within the Topology graph. It is implicit in the naming that Node 0xb402 is a Child of Router 0xb400. Clearly these identities must change as the Topology changes – which is why alternative identifiers are also in play.

As yet I’ve not tried Commissioning a new Matter-over-Thread device with the TBR running this alternative firmware, but given that all the Thread credentials appear to have been preserved there’s no reason why that shouldn’t work the same as before.