goncalomb.com (blog)

My stance on AI writing and coding

goncalomb — Fri, 12 Dec 2025 20:45:47 GMT

The previous iteration of this site, before the Astro rebuild, had a notice on the footer that read:

All content (including code) on this site, attributed to me (Gonçalo MB), was created without the deliberate use of AI tools. I’m making a commitment to keep it that way.

That is still true today.

I’ve used AI tools before, but mostly as a way to search for information, both ChatGPT and Google AI Mode (Gemini). But I’m not an AI/ML developer. I don’t keep up with the latest AI news, models, tools, APIs, etc. And if you ask me about some AI thing, I probably won’t know what you are talking about.

I concede that AI is a very powerful and influential technology, but in addition to all the good that it might bring, there are also many well-documented problems, both technological and cultural.

I don’t want AI to permeate my life, and especially I don’t want it to control my ideas, creations, and memories.

Writing

I’ve never used any AI tools to write or rewrite text, blog posts, comments, emails, notes, etc. I find that idea repulsive at best. If I’m publishing some text with my name attached, I want it to be my words, not those of some machine. My writing might not be the best, but it’s still mine.

I do use normal spell checking to catch any typographical errors, but that has been the standard for decades.

If for some fringe reason I have to post any AI-generated text anywhere, it will be clearly marked as such.

Coding

I’ve always considered coding a creative thing, by this I mean that, for me, code has expression and meaning. It carries the ideas and feelings of its creator, like writing. I can go back to some code that I’ve written and see the intent and ideas behind it. That’s not to say that I consider all code meaningful, I’ve written a lot of purely mechanical code, just to “get it done”. And I know that other people just see code as “a means to an end” and that’s fine.

Also, every programmer knows that, in addition to creating new code, programming requires a lot of searching, studying, reading documentation, tutorials, etc. And sometimes we even directly reuse code and algorithms created by others. For me, up until now, this was the only way I ever programmed anything. But clearly with these “new” AI tools, that is no longer the only way.

I’ve tested AI coding tools before, and I’ve asked ChatGPT for some throwaway snippets of code. But, as of today (2025-12-12), I have never published or committed any AI-generated code to any repositories (public or private) that I have contributed to. This might be about to change.

After much reflection, I have enabled GitHub Copilot on VS Code. These are my commitments now:

Any of my commits with AI-generated code/assets (on any project) will have the author/committer email me+ai@g...mb.com (my normal git email with a +ai sub-address) and additional information in the commit message or comments if necessary. Any of my own projects that include AI-generated code/assets will have a notice (e.g., in the README.md or website).

I will consider code/assets to be “AI-generated” if they were created using AI prompts, AI rewrites/refactoring, “vibe coding”, etc. As for AI “inline suggestions”, I will consider these “AI-generated” (and mark the commit) if they don’t match what I was already going to type (in content, format, style, etc.). Basically, if I don’t feel like I personally created some piece of code, I’ll mark it.

I will also never publish any code that I didn’t read and understand completely.

With these clear commitments, I hope to be able to use these tools and continue to enjoy programming while maintaining control and authorship of my code. I’ll probably continue programming the classic way (i.e., avoiding AI prompts and “vibe coding”) but use AI as an enhancement/alternative to search and for boilerplate code while using AI “inline suggestions” as a way to be faster and more productive.

TL;DR

Writing: no AI-generated text under my name anywhere, any AI-generated text will be clearly marked.

Coding: limited AI use, any of my commits with AI-generated code will have the author/committer email me+ai@g...mb.com, and any of my own projects that include AI-generated code will have a notice.

If my stance on these issues ever changes, I’ll update this post (keeping any previous text).

Now using Astro

goncalomb — Sun, 27 Jul 2025 20:54:25 GMT

Earlier this year I decided to rebuild this website using a modern framework… It’s now powered by Astro!

The background

Ever since I started this website back in 2013, it has always been running on some custom PHP backend. In 2018 I even rebuilt and published the “CMS” on GitHub (asbestos). This CMS only had very basic routing and some HTML utility classes, but it was always good enough to serve a couple of pages.

Then I started the blog. That required implementing proper content management with Markdown files, images, etc. this was never part of the original system. And after my last post gained considerable views from Hacker News, some people started asking for an RSS feed. I knew it was time for a rebuild. I didn’t really want to implement anything else on this old system.

The framework

My basic requirements were TypeScript, React, and static site generation.

At first I considered Next.js, but my (limited) experience with it was not very good. I never liked the way it mixes server and client code, and it always felt too dependent on Vercel. I also tried Gatsby, but it looked too fragmented with too many plugins and configurations.

Ultimately, I couldn’t be happier to have chosen Astro. With Astro basically everything that can, will be rendered as static HTML for improved performance. It also has built-in content management using content collections with TypeScript type-safety, server islands if you want server rendered content, integration with several UI frameworks (e.g. React) and much more.

The rebuild

As for the website itself, the new design very much mirrors the old one, still using Bootstrap and a custom theme, with some minor changes. I had to create a couple of remark/rehype plugins (that’s what Astro uses for Markdown and MDX, unifiedjs), to properly render my old blog posts files, but other than that, it was just a matter of recreating the design using Astro components and moving the files.

Now the blog has a proper RSS feed, year and tag pages, header links and a dash of view transitions.

I also have another site running Astro, the documentation for my Jira Cloud App, WDIScan (wdiscan.com), is built using Starlight, a documentation theme for Astro. Gone are my unmaintainable HTML pages with httpd mod_include (lol).

How I Also Hacked my Car

goncalomb — Tue, 30 Jan 2024 22:14:07 GMT

This blog post is kind of inspired by another that I saw on HN some time ago, “How I Hacked my Car”. After praising the infotainment system of the car, a Hyundai IONIQ, the author ends up hacking it and running custom software on the head unit.

Well, my much cheaper 2023 Dacia Sandero also has a decent infotainment system with navigation and wireless Android Auto.

Even before I got the car, I searched around to see if the system was hackable. I was not surprised to find that a simple USB drive with an autorun.sh script gets run as root. A classic. Various forums around the web use this method to change skins and side-load navigation maps. I was not interested in that, my goal was also to run some custom software.

Well, there is more to the story, otherwise, I would just that autorun.sh “feature”.

The Infotainment System

The system is a MediaNav Evolution from Renault (which Dacia is a subsidiary of), built by LG (FCC ID: BEJLAN5900WR). It’s a Linux box.

Over the years there have been various iterations of this system, the older devices used WinCE.

The navigation part of the software is by a company called NNG (iGO?). Apparently, they provide navigation software for many other devices.

MediaNav Evolution (unofficially called MediaNav 4)

The autorun.sh

Just by looking around on various forums, I knew of 3 special files that when placed on a USB drive would trigger some debug functions:

autorun_bavn/autorun.sh: a script that gets run as root
logfiles_bavn: a directory that gathers various system logs and files
usb_logging: a directory where the system continually dumps dlt files (proprietary log system)

One good thing about the log files is that they contain the Wi-Fi password for the AP. This password can be reset on the UI, but it’s never visible. Knowing the password allows other devices to connect to it (e.g. PC). When using wireless Android Auto it connects automatically, I think it bootstraps using Bluetooth.

I was most interested in the autorun.sh… But it was not working, I couldn’t get the script to run.

The Firmware

At this point, I decided to start inspecting the firmware to see what was wrong, and if there was another way in. My device came with version 6.0.9.9.

I wanted a recent update file, but the official website doesn’t provide a direct download.

It requires installing a desktop application, “Toolbox”, which I ended up doing. The application can be used to buy map updates or download firmware/OS updates for free.

The procedure starts with collecting some information about the system/car to a USB drive. After connecting it to a PC, the “Toolbox” software detects a new update and puts the new update file on the drive.

I didn’t update it, I just wanted the file, it was version 6.0.10.2:

>: file upgrade.lgu
upgrade.lgu: POSIX tar archive (GNU)

I also had an older update file, version 6.0.9.7, that I found in some random forum.

Sometimes even grep can be a great analysis tool. Just by running grep -RF autorun.sh on the contents of both the new and old firmware, I could see that the new one had no matches.

Time to load Ghidra and see what’s going on…

Version 6.0.9.7 has the autorun.sh feature, but it is not present on version 6.0.10.2

Comparing the 2 files it was evident that they had removed the autorun.sh backdoor. Even though I didn’t have the specific firmware for my installed version (6.0.9.9), it was clear that mine didn’t have it and that’s why I could never get it to work.

This miscmanager file is also responsible for the other USB debug features, these are all still there.

The core OS appears to be from GENIVI/COVESA (GitHub: GENIVI/COVESA). I’m not familiar with these systems at all. They have a fair bit of open-source stuff that will probably explore in the future.

I decompiled other binaries to try to look for some other interesting stuff. Found a lot of D-Bus stuff, that will be useful for getting vehicle information when I can run my own software. But my goal was to get root access first.

One way would be to craft a new update file with a backdoor, which would require reverse engineering the whole upgrade procedure, and as expected the update files do have some signature hashes that presumably need to match.

Getting root access directly would be the preferred way.

The Android Update App

Something I noticed on the official website was that they were promoting a new way to update the maps, using an Android phone app.

Could this be my way in?

The description on Google Play promises to “Eliminate the Sneaker Network”, an expression that I had never heard, in reference to not requiring a USB drive.

Of course I didn’t install it, there is no point in that. I just searched the id com.nng.pbmu.dacia on Google to find one of the many sites that offer the .apk file for download.

I’m not an Android developer, I just know that deep inside there is some bytecode that traces its root back to Java, and I know Java. I don’t care about Dalvik, ART, Zygote, or whatever. Just give me those Java classes.

Over the years I’ve decompiled a few Android apps, my preferred way is just to unpack the .apk as a .zip (that’s all it is), get the .dex bytecode files, run them through dex2jar to get some .jar files and open them with good old JD-GUI. Recently I’ve discovered jadx which provides a better experience for decompiling apps.

To my surprise the app was quite complex, it appears to include some sort of native bindings, and most of the functionality is implemented in some kind of proprietary .xs scripts (similar to JavaScript). These are found on the app’s resources.

Android APIs are exported as modules to be used in the .xs scripts

Several native libraries and .xs scripts

It appears that the liblib_nng_sdk.so library is responsible for running these scripts, but I didn’t explore it further. My goal was just to focus on what kind of protocol was used to update the maps on the device.

And I found it in the file nftp.xs.

NFTP!? Is it standard FTP?

No, it’s not standard FTP or any other known protocol that I could find. It’s a new binary protocol for transferring files, implemented on these .xs scripts.

The app then uses Android Open Accessory (AOA) as the transport layer for the protocol. AOA was totally new to me, but after some reading, it was clear that it is just a way of establishing a standard for an accessory to talk USB with an Android device.

The names are confusing, the “accessory” is actually the USB host (in this case, the head unit) and the Android device is the USB peripheral.

The Other Side

The new update file that I had was version 6.0.10.2, which, according to the website, was the version required for the new update app to work. That naturally means that there is some specific service/code on that file to handle the update on the head unit side.

After some digging, I found it. It’s another set of .xs scripts, these run on a native interpreter. There is also a native binary, aoa2sock, that bridges the gap between USB (AOA) and the .xs scripts by providing a pipe for the transfer protocol.

It’s clear that this phone update feature is an afterthought, the binaries/scripts are not part of the standard upgrade filesystem, they are installed separately from a .ipk package file (yellowtool.ipk) when the system is updated. The internal name they use is YellowTool / YellowBox. And this is the only part of the entire system that is coded with these .xs scripts, everything else is just native binaries.

Most of the system uses native binaries and Qt applications

The mobile update app feature uses .xs scripts

Being plain text scripts, it was relatively easy to understand what the protocol does and what kind of access it provides, even though the coding style is atrocious.

Constructing The Backdoor

At this point, just by reading the code, I was pretty sure that it was possible to write arbitrary files under the /navi directory, and that would give me full access if I carefully modified some files.

I just needed to create a fake Android update app and connect using AOA. Well, as I said before, I’m not an Android developer, so I went with the next best thing, the Linux Kernel.

As it turns out I’m also not a kernel developer… But I knew that it has something called gadget mode, where a device running Linux can act as a USB peripheral (instead of a host).

Could I make a Raspberry Pi act as an Android device in AOA mode?

Gadget mode can be configured from userspace using configfs (just by writing specific /sys/kernel/config/ files), this way does not require writing any kernel code, but it’s limited to specific “functions” already implemented in the kernel (e.g. serial port, mass storage, ethernet adapter etc).

Not unsurprisingly, that’s how the guys at Google implemented AOA, they added a new “accessory” function to the kernel. They even tried to push it upstream, but it went nowhere, currently, it’s not part of the Linux Kernel. I don’t think it will ever be, it’s probably too specific, and it’s kind of a weird protocol.

After reading more about AOA, it was clear that it involved a kind of handshake where the accessory asks the Android device for AOA, and after that, the device just acts like a serial port (a “raw” data pipe), and it’s up to the developer to do the rest (this is a simplification, and there are other modes, read more).

So maybe I could use the serial gadget function to fake an Android device already in accessory mode, without implementing the handshake.

I also found the talk where they first announced AOA, back in 2011. It’s a nice talk if you are into USB stuff:

The Testing Setup

The system is something like this:

Android side:
- Update App / “nftp” (.xs scripts) <=> AOA <=> USB
Head unit side:
- USB (host) <=> aoa2sock <=> “nftp” (.xs scripts) <=> [reads/writes system files]

For testing, I used 2 Raspberry Pies.

Because the head unit is ARM-based as is the Raspberry Pi, I was able to run the aoa2sock binary and .xs interpreter from the firmware, this simulated the head unit and acted like a USB host.

The other RPi was the USB peripheral (using the On-The-Go, OTG port), which when configured correctly using the gadget mode, acted like an Android device in AOA mode.

The smaller Raspberry Pi Zero 2 W can be powered from the OTG port and will act as the Android device

After messing about with multiple gadget configurations, I was seeing some promising debug messages from aoa2sock, that’s the binary extracted from the firmware that creates a pipe between the USB AOA and the weird “nftp” protocol (.xs scripts), on the head unit side.

But it was not working…

"No AOA endpoint was found": My fake head unit was not recognizing my fake Android device

>: file aoa2sock
aoa2sock: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=XXXXXXXX, with debug_info, not stripped

After inspecting the aoa2sock binary in Ghidra (thanks for the debug info) and reading the kernel code, I finally found the issue. The kernel serial port gadget uses a different USB subclass from the one used by AOA, and it can’t be changed from userspace.

Is this a bug? I think AOA is correct in using USB_SUBCLASS_VENDOR_SPEC for a generic interface

OK… Let’s patch the kernel

I ended up having to download the kernel source and patch the f_serial.c gadget function to change the USB subclass. After compiling the kernel module and loading it using modprobe, it finally worked and the aoa2sock binary recognized the device.

My fake Android device was finally connected to my fake head unit

Can I call myself a kernel developer now?

All that was left to do was to somehow recreate that “nftp” protocol. I didn’t really want to use the proprietary .xs files implementation, so I wrote my own in Python.

At this point, I had all the pieces and the Raspberry Pi now replaced the Android app:

Raspberry Pi side:
- Python Script (“nftp” implementation) <=> USB Gadget Mode (emulates AOA)
Head unit side (same as before):
- USB (host) <=> aoa2sock <=> “nftp” (.xs scripts) <=> [reads/writes system files]

Creating the backdoor involved issuing “nftp” commands to edit a specific file under the /navi directory and inject a call to a bash script, this bash script (also uploaded using “nftp”) contains the payload that runs as root.

H4cking Time

After much testing with my dual RPi setup, I was confident that it was going to work…

Raspberry Pi Zero 2 W (OTG port) connected to the infotainment head unit

Setting up for an update…

Ready to "Update with Phone", that option is only available after version 6.0.10.2

Waiting for a phone

Time to put the RPi in gadget mode (I was connected to it using SSH)…

Sorry, it's not a phone and we are not sending any maps

Sending and running the payload…

Got it!

Success! I had root access.

That payload is just call to a specific D-Bus method that I found while analyzing the firmware, it shows a popup with custom text and title. The text is the output of the id command.

Finally, after replacing the payload with something more useful, a simple socat bind shell and connecting back to it using Wi-Fi, I had full access.

Give me that root shell

If you didn’t follow it all the way, here’s a summary:

I used a Raspberry Pi in USB gadget mode to simulate an Android device connected to the head unit. The head unit thinks it’s accepting a navigation maps update from the “phone”, but because the update protocol allows for arbitrary file changes, I can issue commands to modify a specific file and inject a call to a bash script that gets run as root.

Code Please

Everything is on GitHub with more detailed instructions (it contains no proprietary code).

The key pieces are my implementation of the “nftp” protocol and the gadget configuration.

What’s Next?

This is just the beginning, now it’s time to really explore the system.

First, I’ll probably end up restoring the autorun.sh functionality, with a custom service, because I think that’s the easiest way to load software. That way I can keep all the new stuff on the drive and make as few changes to the system as possible.

One of the main things I would like to do is record car parameters, stuff like speed, fuel, location etc. It remains to be seen if I can easily access that information through D-Bus, or if I need to go deeper. I’m not interested in adding anything that requires my attention while driving.

But that’s for another time…

Some Extras (Could I have used SSH?)

Two ports are open by default on the head unit, an SSH server, and some Apple service, probably related to CarPlay (Server: AirTunes/320.17.6), I didn’t really explore that.

But I tried cracking the /etc/shadow root password from the update file using hashcat / john with some rules and password lists. I’m not an expert doing this at all, I don’t even know if I was doing it right, and was not successful.

Not that it matters now, I could just change the root password or add a new user.

SSH on port 22 / AirTunes/320.17.6 on port 7000

Domus40 HA - Part 2 - Teardown

goncalomb — Sat, 15 Jul 2023 21:48:17 GMT

Domus40 HA series: Part 1 / Part 2 / Part 3 (TBA).

Here we go, let’s take apart some Domus40 devices.

Domus40 / Boxes

Domus40 / Push buttons, gateway and smart plug

Gateway

Also known as Installation Key (ref. 40925).

Starting with the gateway, the first thing I did was plug it into my Linux machine. Here’s the dmesg output:

[23756.561987] usb 1-5: new full-speed USB device number 10 using xhci_hcd
[23756.712637] usb 1-5: New USB device found, idVendor=0451, idProduct=16c8, bcdDevice= 1.00
[23756.712651] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[23756.712657] usb 1-5: Product: CC2538 USB CDC
[23756.712661] usb 1-5: Manufacturer: Texas Instruments
[23756.809695] cdc_acm 1-5:1.0: ttyACM0: USB ACM device
[23756.809771] usbcore: registered new interface driver cdc_acm
[23756.809774] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

We get some good information, it’s based on a TI CC2538 IEEE 802.15.4 IC and exposes a USB serial port. Not unexpected for a Zigbee gateway, but it’s an older IC, newer alternatives are available (see TI Zigbee Selection Guide, 2018).

Teardown of the gateway

Good construction, but also very hard to take apart without breaking, I had to shim it at the slide point from both sides. It’s intact but not without scratches.

Gateway PCB top (high-res)

Gateway PCB bottom (high-res)

Gateway PCB bottom, with ICs visible (high-res)

Gateway PCB top, MicroSD card (high-res)

Gateway PCB bottom, ICs close up (high-res)

As expected we have the CC2538SF53 as the main IC with a CC2592 RF front end and MCP73871 for battery management. Having a built-in battery is definitely the defining feature of this gateway.

The MicroSD card

The MicroSD card was a surprise, but I think it makes sense. I suspect that the SD card holds the Zigbee network information to allow the gateway to work while disconnected from the host (PC).

The card contains a FAT32 partition, with a single System Volume Information directory. So it was connected to a Windows PC at some point, it’s dated April 2022.

4A21-0000:
total 32
drwxr-xr-x 2 32768 2022-04-13 12:37:26.000000000 +0100 System Volume Information

4A21-0000/System Volume Information:
total 64
-rw-r--r-- 1 76 2022-04-13 12:37:28.000000000 +0100 IndexerVolumeGuid
-rw-r--r-- 1 12 2022-04-13 12:37:26.000000000 +0100 WPSettings.dat

I tried pairing it with another device to see if something changed but was unable to make it work. This is something to explore in the future.

The USB serial port

Something to also explore later is the serial port and its unknown protocol. I tried using Zigbee2MQTT, but it could not communicate with the gateway. I know that Zigbee2MQTT uses TI’s Z-Stack Monitor and Test API / Z-Stack ZNP, but I’m not familiar with these APIs at all. It remains to be seen if I can get it to work using the stock firmware.

Push buttons

Also known as Wireless 4-Gang Push Button (ref. 40227).

Teardown of the push buttons

Push buttons PCB top (high-res)

Push buttons PCB bottom (high-res)

It’s based on a CC2530 IC, powered by a coin cell. Nothing special, similar to other Zigbee buttons, well constructed. Some pads are not populated.

Connecting to Zigbee2MQTT

As expected, it’s not supported by Zigbee2MQTT out of the box, this should be just a missing configuration. But we get some information.

Push buttons connected to Zigbee2MQTT (using a generic CC2531 adapter)

Cover

Just as a side note, these buttons are made to be used with a cover, sold separately. They can be made to match other switches around the house. But they also work fine as a portable device.

Push buttons cover

Smart plug

Also known as Mobile Schuko Socket 10A with Metering (ref. 40961).

The smart plug teardown

Again, good construction but hard to take apart. The screws are only visible after removing the front bezel.

An internal metal tab for the earth connection broke after I bend it to remove the PCB. I removed the earth contact to avoid future issues, if I end up using this plug it will be only for testing or low-power stuff without an earth connection.

The smart plug teardown

A small piece of PCB material was loose inside (see previous image), not broken from the main PCB.

Smart plug PCB

It uses a very interesting layout with 3 PCBs to make use of every bit of space. It’s probably not a cheap device to manufacture (the final price is also not cheap). The main PCB is also multilayer.

The power supply for the low-voltage circuit it’s inside the plug connector on the 2 smaller PCBs, it’s a non-isolated design using an LNK302DG IC.

Smart plug PCB top (high-res)

Smart plug PCB bottom (high-res)

It uses the same main IC as the gateway, a CC2538SF53 with a CC2592 RF front end. This is expected, being a mains-powered device, it also acts as a Zigbee router not just an end device. The other 2 ICs are an SST25VF020B serial flash and CS5490-ISZ for power measurement.

As with the other devices, the debug header is exposed. But it’s not safe to use while powered by AC because of the non-isolated design.

Connecting to Zigbee2MQTT

Not supported by Zigbee2MQTT at the moment, the same as the push buttons.

Smart plug connected to Zigbee2MQTT (using a generic CC2531 adapter)

Are these old designs?

I noticed that these devices appear a few years old, even though they were first released in late 2021.

Markings on all PCBs (2014?)

Date stamps on gateway (04/2022) and plug (07/2016)

The PCBs, according to the markings, were possibly designed sometime in 2014, which also explains the use of older ICs. Then we have some plastics from 2016 and 2022, some firmware from 2017, and the filesystem on the gateway SD card is dated 2022.

So the gateway that I have is from last year, but the other devices appear to be older. The coin cell that came with the buttons is almost expired (12/2023). Weird.

What’s Next?

Getting these devices connected with Zigbee2MQTT is my main goal.

The gateway is by far the most interesting device. I would like to retain the function of pairing devices while away from the host (PC), which probably requires keeping the stock firmware. Knowing the serial port protocol is key make it work with Zigbee2MQTT and it will require some research on my part (I don’t have the Home Server, which is the official way to use the gateway, see part 1). Let’s hope it uses some standard TI API (Z-Stack ZNP?).

The other 2 devices can already be semi-recognized by Zigbee2MQTT, they might need some extra configuration, but should not require custom firmware.

Updating the firmware would be nice. But that’s probably done automatically by the Home Server. EFAPEL does not publish the firmware on their website and discovering some unknown repository URL without inspecting the Home Server is probably impossible.

I have no affiliation with EFAPEL, all opinions are my own.

Domus40 HA series: Part 1 / Part 2 / Part 3 (TBA).

Domus40 HA - Part 1 - Introduction

goncalomb — Fri, 16 Jun 2023 18:51:30 GMT

Domus40 HA series: Part 1 / Part 2 / Part 3 (TBA).

Recently I’ve discovered a new line of home automation (HA) devices called Domus40.

These devices are from a local Portuguese company, EFAPEL, that makes products for electrical installations.

If you visit a newly renovated home here in Portugal there is some chance that it uses EFAPEL sockets and switches, in place of other more established brands like Legrand or Schneider.

In this series of posts, I want to explore this new line of devices, show some internals and see if they are a good alternative to other devices like the Shelly.

Domus40 / Domus40 Technical Manual

Devices, Documentation and Price

From the Domus40 page, I’ve compiled the list of connected devices (see original page for images):

Ref.	Name	Price €	Manual
40930	Home Server	208.49
40925	Installation Key	42.95	PDF
40213	Single Pole Switch with Metering	61.03	PDF
40214	Double Pole Switch with Metering	65.37	PDF
40218	Blinds Control Switch with Metering	69.08	PDF
40215	250VA RLC Electronic Dimmer with Metering	74.23	PDF
40217	1-10V 50mA Electronic Dimmer with Metering	77.35	PDF
40260	Schuko Socket 16A with Metering	47.68	PDF
40961	Mobile Schuko Socket 10A with Metering	62.72	PDF
40226	4-Gang Push Button	41.34	PDF
40227	Wireless 4-Gang Push Button	24.73	PDF
40235	Multifunction Sensor	51.44	PDF
	Domus40 Catalog (in Portuguese)		PDF
	Domus40 Technical Manual (in Portuguese)		PDF
	EU Declaration of Conformity		PDF

The prices are from EFAPEL’s price table (2023-05-03).

The devices only appear on the Portuguese version of EFAPEL’s website, hinting at the fact that they may not be available outside Portugal at the moment.

Most devices use the standard recessed style box used in home installations in Portugal and other EU countries.

The “private network”

What piqued my interest was the fact that, according to EFAPEL’s weird one-PDF-per-question FAQ (in Portuguese), they use a “private network of 2.4 GHz” and “it’s only possible to guarantee reliable communication between Domus40 devices”.

Well, I suspect it’s Zigbee. And some posts on the CPHA forum (in Portuguese) also point to that.

In contrast, other brands like Legrand (Netatmo), with similar devices, don’t hide the fact that they use Zigbee.

The Home Server (ref. 40930)

The system uses a proprietary Home Server as the control unit. It apparently provides a web interface and connects to the internet for cloud and mobile access.

The Domus40 Technical Manual has very little information about the server. It shows a device with 8 ports in the back, but only the 5V in, 2 USBs and RJ45 are mentioned in the manual, the others appear to be an HDMI, Micro USB, some other 7-pin port and an unknown slot. If the images are to scale, then looking at the size of the ports, the server must be very small.

The Home Server is also missing from the EU Declaration of Conformity, maybe it’s just a rebranded mini/embedded PC not produced by EFAPEL with custom firmware.

Home Server / Domus40 Technical Manual - Some generic mini/embedded PC?

The Installation Key (ref. 40925)

The Installation Key appears to be a USB gateway to connect all the wireless devices to the Home Server. The cool thing is that it has an internal battery, supposedly you go around to all the devices, pair them with the key, and then connect the key to the server.

If the protocol is indeed Zigbee, then it’s the only commercial Zigbee gateway that I’ve seen with an internal battery. In contrast, for Z-Wave, we have the Z-Stick Gen5+ that also has a battery and works the same way.

Installation Key / Domus40 Technical Manual - A Zigbee gateway?

What’s Next?

Well, I’ve already ordered 3 devices: the Installation Key (gateway), the Mobile Schuko Socket (smart plug) and the Wireless 4-Gang Push Button (smart switches). None of these are for permanent mains installation.

As much as I would like to inspect and take apart the Home Server, I can’t justify buying one, seeing that I don’t actually want to use the system.

In the next series of posts, I will take apart these devices, inspect them and ultimately try to connect them to a Home Assistant instance.

If anyone from EFAPEL is reading this, send me a Home Server and I’ll tear it down. ;)

I have no affiliation with EFAPEL, all opinions are my own.

Domus40 HA series: Part 1 / Part 2 / Part 3 (TBA).

[2023] Low-effort dark mode

goncalomb — Fri, 24 Mar 2023 17:34:02 GMT