Last year, I began using Textual to develop HumBLE Explorer, a cross-platform, command-line and human-friendly Bluetooth Low Energy scanner. Textual caught my attention because it promised to be a rapid application development framework for Python terminal user interface (TUI) applications. Thanks to Textual, I was able to create an application like this, including scroll bars, switches and tables:

One of Textual's key features is that it's inspired by web development practices. This allows for a clear separation of design and code using CSS files (in the Textual CSS dialect), making the framework both developer-friendly and highly customizable. It also has reactive attributes, as well as a growing library of widgets. Additionally, the framework provides useful tools for debugging and live editing of CSS files during development.

If you want to have an idea about Textual's capabilities, install it from PyPI and run the demo:

pip install textual
python -m textual

In addition, one of Textual's developers maintains a list of Textual-based applications.

As a relatively new project (started in 2021), Textual still experiences occasional breaking changes in new releases. However, the developers are easily accessible for support on their Discord server and provide regular blog updates. Moreover, Textual has excellent documentation. I plan to use Textual again for new terminal user interfaces in Python.

For some more background, read my article Textual: a framework for terminal user interfaces on LWN.

Paulus Schoutsen, founder of the open-source home-automation project Home Assistant, declared 2023 as "the year of voice" for the popular platform. The goal of the initiative is to enable users to control their homes through offline voice commands in their own language.

Voice control is a complex and computationally intensive task, which is usually delegated to the cloud. Companies like Google, Amazon and Apple make us believe that we need their cloud-based services to be able to use voice control. Of course, this comes with downsides: users don't have any control over what happens with their voice recordings, posing a significant privacy risk. But, fundamentally, the problem lies even deeper. It just makes no sense for users to have their voices make a long detour through the internet just to turn on a light in the same room.

In the past, projects like Snips and Mycroft attempted offline voice control but faced business challenges. Rhasspy, an independent open-source voice-assistant project that has been active for a few years now, was quite successful among the niche crowd of tinkerers and those who built their own voice assistants around the flexible services the project offered. [1] However, the core of Rhasspy was mainly developed by one person, and the project wasn't backed financially.

Last month, I wrote an article for LWN.net about these three projects: Hopes and promises for open-source voice assistants. I expressed the hope that Rhasspy would finally give us the ability to control our homes with a user-friendly voice assistant that is both privacy respecting and made from open-source software. Rhasspy's developer, Michael Hansen, has been hired by Nabu Casa, the company behind Home Assistant, and they're tightly integrating Rhasspy into their home-automation software.

In the mean time, OpenVoiceOS, a community that forked Mycroft, has published a FAQ about the future of Mycroft. I already alluded to Mycroft's revival in my article, but the plans were still vague at the time. By now, it looks like Mycroft has a real chance to live on in OpenVoiceOS.

Overall, these are exciting times for open-source voice control.

When it comes to home automation, people often end up with devices supporting the Zigbee or Z-Wave protocols, but those devices are relatively expensive. When I was looking for a way to keep an eye on the temperature at home a few years ago, I bought a bunch of cheap temperature and humidity sensors emitting radio signals in the unlicensed ISM (Industrial, Scientific, and Medical) frequency bands instead. Thanks to Benjamin Larsson's rtl_433 and, more recently, NorthernMan54's rtl_433_ESP and Florian Robert's OpenMQTTGateway, I was able to integrate their measurements easily into my home-automation system.

I wrote an article for LWN.net describing these projects and what you need to integrate them into your home-automation system such as Home Assistant: Using low-cost wireless sensors in the unlicensed bands. The article also describes how I'm migrating from a Raspberry Pi-based setup with RTL-SDR dongle running rtl_433 (as described in my home automation book Control Your Home with Raspberry Pi) towards a more distributed setup with multiple LILYGO boards with 433 MHz receiver and running the OpenMQTTGateway firmware around the house. They have less range than the RTL-SDR dongle, but they are cheap and all send their decoded sensor values to the same MQTT broker, so the result is the same as having a single receiver with a longer range.

The article doesn't go into detail about rtl_433_ESP, but this is a fairly recent and interesting development. While rtl_433 implements signal demodulation in software, rtl_433_ESP uses the transceiver chipset (SX127X on the LILYGO LoRa32 V2.1_1.6.1 433MHz board) to do this. This makes the ESP32 implementation more limited in the signals it can receive, because the transceiver only supports a single modulation scheme at a time. As NorthernMan54 had a lot of devices with OOK (on-off keying) modulation at the time he started the port and not one with FSK (frequency-shift keying) modulation, OOK devices are currently the only ones supported. More specifically, rtl_433_ESP supports rtl_433's Pulse Position Modulation (OOK_PPM), Pulse Width Modulation (OOK_PWM) and Pulse Manchester Zero Bit (OOK_PULSE_MANCHESTER_ZEROBIT) demodulation modules. This limits the available device decoders to 81 of the 234 decoders of rtl_433.

There are other microcontroller implementations of decoders for 433 MHz sensors, but the work NorthernMan54 has done building on rtl_433's code base and making it easy to use it with OpenMQTTGateway is impressive. NorthernMan54 told me he created some scripts that should help automate the port and keep his code synchronized with the roughly annual release cycle of rtl_433.

Earlier this year, I wrote two articles for AlgorithmWatch:

• How Dutch activists got an invasive fraud detection algorithm banned

• In Flanders, an algorithm attempts to make school choice fairer.

Both articles were part of AlgorithmWatch's upcoming report Automating Society 2020, which investigates the applications of automated decision-making in the public sector in various European countries.

The full report will be published this fall, but the abridged versions of both stories that will come in the report have now been published on the website Ethics of Algorithms of the Bertelsmann Stiftung:

• Demands for more transparent data management in Dutch public sector

• Belgium’s quest for fairness in school enrollments

Especially the Dutch story about SyRI, an algorithm cross-referencing personal data from citizens in various databases, makes it clear that algorithmic fraud detection has a lot of pitfalls: the way it was used in the Netherlands there was no transparency (the exact algorithm or risk model was never disclosed), it exacerbated biases and discrimination, and it was used for purposes it wasn't designed for.

The best argument against such systems is actually quite simple: you don't need them. As Ronald Huissen from the Platform Bescherming Burgerrechten said, the government doesn't need this kind of mass surveillance to prevent fraud:

The government already has information about who owns which house, so it could check this before granting the person a rental allowance. For all big fraud scandals in social security we have seen in the past decades it became clear afterwards that they could have been prevented with simple checks beforehand. That happens far too little. It is tempting to look for solutions in secret algorithms analyzing big data sets, but often the solution is far simpler.

It's an issue I see all too often: there's a problem (social fraud, fiscal fraud, crime, a virus outbreak, ...) and the government thinks it has to solve this with a big centralized database, massive surveillance and some technological voodoo (big data, AI, an app, or the next big thing). The solution is often much simpler: everyone just has to do their job instead of outsourcing it to technology.