Here are my notes on the implementation details and reasons for why I eventually decided to not use it:

1. It relies on data attributes on the script tag for passing the configuration (script ID, delayed loading, etc.) instead of using a global array collector like window.dataLayer = [] for configuration and impression/event context (see source code). This complicates the setup and will not be flexible in the long-run (can’t inline the tracker JS, values can be only strings).
2. You can’t attach additional context or meta data about the initial page view event (view source code). The only option is to completely disable the default impression tracking (which can only be done using the data-auto-track="false" attribute and then configure a custom one.
3. Tracking outbound link clicks is really complicated — you have to add data-umami-event attribute to all external links to use the built-in tracking (source code) or implement a custom solution that captures all link events, accounts for all the modifier logic (new tab, mouse up) and sends a custom event.

In many countries the fiber connections to homes are shared resource that can be used by multiple ISPs (to encourage competition) so this is often very legal and within your rights. However, the fiber signaling is shared between dozens of users (your neighbors) so doing things incorrectly will impact everyone using the same connection.

Up until recently I was using ODI Realtek DFP-34X-2C2 (AliExpress) to replace the Huawei HG8145V5 terminal supplied by the ISP but it stopped working after software upgrades to ONT on the ISP side (which distribute the fiber signal) in the early 2025.

Huawei SmartAX MA5671A

So I decided to try out an official Huawei SFP which would hopefully match the behavior of the original terminal. After a bit of research I ordered Huawei MA5671A on eBay for around $20 (probably used) which appeared to be documented extensively on the wiki.

Turns out it is the same hardware as Nokia G-010S-P, SourcePhotonics SPS-34-24T-HP-TDFO, Hilink HL23446, Dasan H650SFP and probably many more which all use the same Intel Lantiq PEB98035 chip (no longer manufactured) and run a custom build of OpenWRT. The configuration for each vendor is stored in a flash chip while the operating system is exactly the same.

The original manufacturer of this SFP stick appears to be SourcePhotonics SPS-34-24T-HP-TDFO based on this comment from a person who apparently worked on it. That particular module also has full root access over SSH which allows you to skip the soldering and rooting over the UART on the SFP connector.

Configuring GPON Serial Number

All of the GPON client equipment comes pre-configured with a unique identifier which is used to enable your internet access and to set the connection speed. Some ISPs also use PLOAM password and/or Software IDs reported by the device for additional verification.

We must fake the identify of the original modem to authenticate with the ISP and keep using the internet. Normally these parameters shouldn’t be configured by users (they are serving as identify after all) so we must find a way to do that anyway. Generic modules like that DFP-34X-2C2 (which I was using before) provide completely unlocked SSH interface and tools to configure the GPON parameters.

However, Huawei MA5671A is completely locked down and it only has a very limited “minishell” available over SSH which can’t be used to override any of these parameters. That is not the case for the SourcePhotonics SPS-34-24T-HP-TDFO version of this, though.

Unlock Root Access

Luckily, there is an UART connection (baud 115200) exposed on the SFP pins (non-standard) so we can use those to connect to the device and:

1. unlock it’s U-boot bootloader and
2. change the shell for the root user in /rom/etc/passwd from /opt/lantiq/bin/minishell to /bin/ash which has full permissions.

Unfortunately, connecting to those UART pins on the SFP connector is really hard. You’ll need to buy a 20-pin surface mount SFP connector (which has only 0.8mm spacing between the pins), pull out the unnecessary pins with pliers (to avoid soldering together neighboring pins) and solder four wires for the UART to USB connection (ensure it has 3.3V output instead of 5V):

This was the hardest part in addition to these fails:

• one hour lost because TX was connected to PIN8 instead of PIN7 (because 10 minus 7 is actually four pins instead of three).
• two hours lost due to a loose connection of the TX pin which prevented all outgoing messages to the device. I eventually used a multimeter to verify the continuity between the the solder points and the pads on the PCB.

I was able to confirm the RX connection by seeing this UART output during the boot:

ROM: V1.1.4
ROM: CFG 0x00000006
ROM: SFLASH-4
hw fuse format 1

U-Boot 2011.12-lantiq-gpon-1.2.24 (Nov 03 2014 - 22:46:28), Build: falcon_sfp_linux

Board: SFP
DRAM:  64 MiB
Now running in RAM - U-Boot at: 83fc8000
SF: Detected MX25L12805D with page size 64 KiB, total 16 MiB

This is where the output stops because the U-boot has the bootdelay set to 0 seconds and serial output disabled. Luckily they didn’t lock the user input completely and hitting Ctrl+C (or 0x03 in ASCII) immediately after the U-Boot 2011.12... header is printed will actually enable user input.

This is what the “Start Root” script does:

1. waits for U-Boot string in the UART output and immediately starts sending Ctrl+C every 10ms for 2 seconds.
2. It assumes that keyboard input is now enabled and sends various setenv commands that introduce the boot delay and enable serial output (persistently).

Here the commands sent after unlocking input:

setenv bootdelay 5
setenv asc0 0
setenv preboot "gpio set 3;gpio input 2;gpio input 105;gpio input 106;gpio input 107;gpio input 108
saveenv
reset

Afterwards it sends the second part of commands that swap out the default shell for the root user:

mount_root && mkdir -p /overlay/etc && sed "s|/opt/lantiq/bin/minishell|/bin/ash|g" /rom/etc/passwd > /overlay/etc/passwd
umount /overlay && umount -a

Now, after rebooting the device you should see the full boot sequence printed to UART and the root user over SSH (password: admin123) should have full access to the system:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oCiphers=+3des-cbc -o HostKeyAlgorithms=ssh-rsa root@192.168.1.10

root@192.168.1.10's password: 

BusyBox v1.22.1 (2017-05-20 08:54:30 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

 OpenWrt - (14.07_ltq) --- Lantiq Edition for GPON
 ----------------------------------------------
root@SFP:~# 

And here is the dmesg output:

[    0.000000] Linux version 3.10.49 (sean@Lantiq-DEV) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 14.07_ltq) ) #1 Sat May 20 09:01:27 CST 2017
[    0.000000] SoC: Falcon rev A22
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00019556 (MIPS 34Kc)
[    0.000000] MIPS: machine is SFP - Lantiq Falcon SFP Stick

Actually Configuring GPON Serial Number

After getting root access to the device we can use the fw_printenv and fw_setenv commands to adjust the necessary parameters for our device identity as explained in this guide.

Be sure to copy and save the default configuration returned by fw_printenv sfp_a2_info before making any changes.

In my case it was enough to clone the serial number and PLOAM values from the original equipment. After rebooting I was able confirm the values:

fw_printenv nPassword
fw_printenv gSerial

and also the O5 status of the connection:

onu ploamsg
errorcode=0 curr_state=5 previous_state=4 elapsed_msec=4294714448

For example, if the domain of your project is example.com then you could set the A record of local.example.com to 127.0.0.1. But wait — there is more — you can have unlimited subdomains such as *.local.example.com if your DNS provider supports wildcard A records.

Here is a screenshot of the DNS setup in DigitalOcean that I use for *.wpenv.net domains:

The A record for the root level wpenv.net pointing to a GitHub IP for the repository which has the README about the domain. It is like a landing page for the service.

The important bit is the A record for *.wpenv.net pointing to 127.0.0.1.

During registration you’re asked for name and date of birth:

Entering a birthday for an underage person (younger than 18 years old) will only show a picker for @gmail.com addresses:

However, entering a birthday of 18+ will show a custom email input field:

So a feature designed to prevent image retention and uneven brightness ends up causing the flickering and retention of image (ghosting) as confirmed by Dell after years of users complaining and trying every possible workaround.

Here is an approximate visualization of that range of gray:

The root of the problem is the advertised “1.07 billion colors” (10-bit color depth) even though the panel only supports 8-bit color range which it reports to macOS over EDID, which then triggers the YCbCr dithering on macOS GPU output, which in turn triggers the monitor’s Image Compensation Algorithm (ICA) threshold bug.

It might be possible to resolve this with a firmware update for the monitor but none of the recent updates (such as M3F102) have fixed the issue for me.

How to Fix it?

There are two ways to fix this — enforce RGB mode for the monitor video signal input (instead of the default YCbCr) or disable the temporal dithering on the macOS output.

1. Set RGB Input Color Format in Monitor Settings

Use the button at the back to open the monitor settings and set the “Input Color Format” under “Color” to RGB (instead of YCbCr):

Unplug and reconnect the USB-C cable after making the change to enforce a fresh EDID handshake. Consider resetting all settings to factory defaults before making the change.

This will make macOS send a full 10-bit RGB color data on the output instead of the capped 8-bit stream with temporal dithering.

2. Disable macOS Temporal Dithering

Use the Stillcolor app to disable the macOS temporal dithering if you want to keep using the YCbCr mode for some reason. Importantly, the app will not affect the built-in display color rendering (since it supports the full color range) so it can be left enabled at all times.

Impacted Dell Monitor Models

This fix is needed for the following Dell monitor models (I’m using U2723QE from Amazon):

• G series: G3223D
• C series: C1422H, C2422HE, C2722DE, C3422WE
• S series: S2422HZ, S2722DZ, S2722QC, S2723HC, S3423DWC
• P series: P2421DC, P2721Q, P3221D, P2422HE, P2722HE, P3222QE, P2423DE, P2723DE, P2723QE, P3223DE, P3223QE, P1424H, P2424HEB, P2724DEB, P3424WE, P5524QT, P6524QT, P8624QT
• U series: U2421E, U2421HE, U2721DE, U3421WE, U3821DW, U4021QW, U2722D, U2722DE, U2722DX, U2723QE, U2723QX, U3023E, U3223QE, U3223QZ, U3423WE, U4323QE, U2424H, U2424HE, U2724D, U2724DE, U3224KB, U3824DW, U4924DW

Best Dell Monitor for Mac

Having a monitor that can also charge your computer and serve as a USB hub over a single USB-C cable is really convenient. If buying today, I would get the 27-inch Dell U2725QE which is also Amazon best-seller and an updated model of what I have currently:

• same 3840×2160 resolution
• higher refresh rate at 120Hz (previously 60Hz)
• higher contrast of 3000:1 (previously 2000:1)
• higher USB-PD output power of 140W (previously 90W)

Using the available downstream USB-C port you can also power a charging station/stand for your iPhone, Apple Watch and AirPods such as this Belkin 25W 3-in-1 charger (foldable and great for travel). Note that there are a lot of cheaper options available but all of them have slower charging speeds (7W vs. 15W or 25W) and most are not Apple MFi-certified which will cause your phone to show a warning message every time you put it down for charging.

Ideally, the treatment would:

1. achieve the desired look and
2. preserve the wood as much as possible.

The best option is thermally modified wood where the boards are literally heated in large ovens to remove all moisture and then cooled down while using steam to re-introduce water in a controlled way.

I wanted to find an alternative which would be cheaper and could be applied to the most basic wood available locally.

The Magic of Iron (II) Sulphate

Iron (II) sulphate (FeSO₄) can be used to accelerate the natural greying of wood to create a nice weathered patina look way faster than waiting for years. It works by removing with the tannins, lignin and the natural sugars in the wood (see this research paper on Staining Effect of Iron (II) Sulfate on Nine Different Wooden Substrates). It doesn’t help with preserving the wood or protecting it against weather, UV radiation or fungi, though.

Iron (ii) sulphate is a green powder which available in most gardening stores (usually known as Iron Vitriol) as a fertilizer for grass and loans, and to get rid of moss:

Our Experiment with 4% Iron Sulphate Solution

Here are photos of spruce siding being treated with a 4% solution of iron sulphate using a garden sprayer. It is important to note that the siding was installed 8 month earlier so the effect of treatment is faster and more visible than if it was applied right after the installation (when the boards were recently sawn).

Conclusions

The 4% solution is ideal for soft woods like spruce and pine. The color change is visible right away as long as the wood has been exposed to light for 3 to 6 month. Other spices of wood might require different amounts to achieve the same result.

Important: using 10% and 20% solution leaves behind unreacted salts (iron compounds and sulfates) which migrate to the wood surface with moisture and crystalize as white residue:

Improving Wood Resistance

Could we mix the iron sulphate with additional components to actually help preserve the wood? Turns out there a bunch of other readily available components that can help with that:

• Sodium silicate or liquid glass is used to seal concrete and does something similar to wood.
• Potassium silicate is used to harden wood when making violins.
• Calcium hydroxide or “slaked lime” to help lock silica inside the wood.
• Borax protects against fungi growth and insects.

I’m planning to experiment with the following solution (for 1 liter):

• 600ml warm water at 40C.
• 100ml sodium silicate solution (30%).
• 50ml potassium silicate solution (30%), if available (or use more sodium silicate).
• 10g iron sulphate.
• 10g borax.
• 1-2g of calcium hydroxide (if available).
• 0.5g or a pinch of lime as citric acid.
• 3 drops of mild dish soap.

This blend integrates:

• Silicate blend (sodium + potassium) penetrates the wood and forms a silica network within the cell walls. As the solution dries the silicates polymerize into insoluble silica gels, creating a mineralized surface layer that hardens the wood and makes it less attractive to fungi.
• Catalyst (iron sulphate) helps fix the silicates by crosslinking them into less soluble forms while also reacting with lignin and tannins to form iron–tannate complexes that give the characteristic grey patina.
• Bioprotection (borax) provides long-term resistance against fungi and insects by diffusing into the wood and disrupting their metabolic processes.
• Fixation control (lime or citric acid) adjusts the highly alkaline silicate solution to a more favorable pH. A small addition of lime encourages the formation of calcium silicate hydrates, while a touch of citric acid can guide gelation and precipitation inside the fibers, preventing salts from crystallizing on the surface.
• Wetting agent (soap) reduces surface tension, allowing the solution to spread and absorb more evenly into the wood instead of beading or leaving untreated patches.

AI is suggesting the following additions which I might consider as well:

• Colloidal silica (10ml of 30% solution) or a concrete densifier contains ultra-fine silica particles that penetrate more deeply into the wood and bond with the silicate network, improving hardness and reducing surface bloom.
• Isopropyl alcohol (200ml, 70–99%) as a partial water replacement to lower surface tension. This helps the treatment wet the fibers more effectively, improves penetration in resinous pine, and speeds up drying.

This kind of treatment is expected to increase the lifetime of wood siding by 100% taking it from approximately 12 years to 25 years.

Related Resources

• The Staining Effect of Iron (II) Sulfate on Nine Different Wooden Substrates (PDF)
• Sodium silicate coated wood (PDF)

Comments and Suggestions

Have you done any experiments with this? Please share them in the comments!

Version 1.0 of the WordPress integration plugin introduced package signatures verification (in this pull request). That means that WordPress sites can now cryptographically confirm that a downloaded plugin or theme really came from the claimed publisher (as long as you trust the keys reported by plc.directory).

Full signature verification isn’t trivial. To check a did:plc identity properly you have to walk the entire chain of signed operations all the way back to the genesis operation where the DID is anchored.

That requires some pretty heavy crypto for a WordPress host (where the client plugin is installed):

• multibase / base58 decoding
• DAG-CBOR + CID recomputation
• ECDSA (secp256k1, P-256) signature checks

Not every shared host is going to have PHP extensions for all of that. The protocol does elegantly handle key rotation but the burden of verification falls entirely on the consumer.

Just “trusting” whatever keys come back from plc.directory for each package DID identifier isn’t secure. You have to validate the full audit log yourself because otherwise you’re open to tampering. 

So the standard is promising but until FAIR bakes in real signature checks, WordPress users aren’t getting the security guarantees this model could deliver. 

The rest of plugin features are really nice for privacy and general data protection — you no longer report all published content to Ping-o-Matic or send every admin dashboard request to WP-org servers. Here is a report of all external calls made by standard WordPress installs.

How FAIR Works?

A plugin author publishes a WordPress plugin with a PLC:DID identifier such as:

did:plc:deoui6ztyx6paqajconl67rz

The FAIR client plugin fetches the JSON metadata for the DID from the plc.directory URL:

https://plc.directory/did:plc:deoui6ztyx6paqajconl67rz

which returns:

{
	"@context": [
		"https://www.w3.org/ns/did/v1",
		"https://w3id.org/security/multikey/v1",
		"https://w3id.org/security/suites/secp256k1-2019/v1"
	],
	"id": "did:plc:deoui6ztyx6paqajconl67rz",
	"alsoKnownAs": [],
	"verificationMethod": [
		{
			"id": "did:plc:deoui6ztyx6paqajconl67rz#fairpm",
			"type": "Multikey",
			"controller": "did:plc:deoui6ztyx6paqajconl67rz",
			"publicKeyMultibase": "zQ3shjiQmfcvNg5ExJuCcX8Bfzaa77y3yxD9iPMYmeRYbk4Vf"
		}
	],
	"service": [
		{
			"id": "#fairpm_repo",
			"type": "FairPackageManagementRepo",
			"serviceEndpoint": "https://fair.git-updater.com/wp-json/minifair/v1/packages/did:plc:deoui6ztyx6paqajconl67rz"
		}
	]
}

where the key parts are:

1. the public keys defined under verificationMethod with type equal to Multikey and the id containing #fairpm.
2. the package URL under serviceEndpoint with type FairPackageManagementRepo and id containing #fairpm_.

In order to ensure that the publicKeyMultibase value is actually a valid public key belonging to the DID, you need to parse the full DID activity log and verify that each operation is signed and derived from the previous one, including the DID itself at the genesis operation.

It then fetches the resolved serviceEndpoint URL with the Accept: application/json request header:

https://fair.git-updater.com/wp-json/minifair/v1/packages/did:plc:deoui6ztyx6paqajconl67rz

which returns:

{
    "@context": "https://fair.pm/ns/metadata/v1",
    "id": "did:plc:deoui6ztyx6paqajconl67rz",
    "type": "wp-plugin",
    "name": "Handbook Callout Blocks",
    "slug": "handbook-callout-blocks",
    "filename": "handbook-callout-blocks/handbook.php",
    "description": "The make.wordpress.org blog has wonderful callout blocks but they seem to be baked in as part of the WP.org Handbook plugin.\nI was able to \u2026",
    "authors": [
        {
            "name": "WordPress.org, Andy Fragen",
            "url": ""
        }
    ],
    "license": "GPL-2.0-or-later",
    "security": [],
    "keywords": [
        "wporg",
        "handbook",
        "callout"
    ],
    "sections": {
        "description": "<p>The make.wordpress.org blog has wonderful callout blocks but they seem to be baked in as part of the WP.org <a href=\"https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/handbook\">Handbook plugin</a>.</p>\n<p>I was able to strip out the relevant parts of the Handbook plugin retaining only the callout blocks.</p>\n<h3>Special Thanks</h3>\n<ul>\n<li><a href=\"https://profiles.wordpress.org/ipstenu/\">@Ipstenu</a> for her terrific sleuthing skills.</li>\n<li><a href=\"https://profiles.wordpress.org/Clorith\">@Clorith</a> for bringing code up to current standards and best practices.</li>\n</ul>",
        "changelog": "<p>[unreleased]</p>\n<ul>\n<li>add support for <code>core/list</code></li>\n<li>refactor for current standards and practices courtesy of @Clorith</li>\n<li>make editor padding match</li>\n<li>load dashicons for non-logged in users</li>\n<li>initial release</li>\n<li>add composer.json</li>\n</ul>"
    },
    "releases": [
        {
            "version": "1.0.3",
            "requires": {
                "env:php": ">=7.4",
                "env:wp": ">=5.9"
            },
            "suggests": {
                "env:wp": ">=6.7.2"
            },
            "provides": [],
            "artifacts": {
                "icon": [
                    {
                        "url": "https://s.w.org/plugins/geopattern-icon/handbook-callout-blocks.svg",
                        "content-type": "image/svg+xml",
                        "height": null,
                        "width": null
                    }
                ],
                "package": [
                    {
                        "url": "https://api.github.com/repos/afragen/handbook-callout-blocks/releases/assets/274184925",
                        "content-type": "application/octet-stream",
                        "signature": "AcKSOVp2EHQCSWBO5LZCDv4puOpvJILsovIynQkf-hcpBOGpkuc4aaLi5NC9Gd4s3IBNzbqFzM75a6lcx4kk_w",
                        "checksum": "sha256:bb2f21d4f5b3e6a8daa361abb75b366d90059a7e1a15c18100ca3492cdb252af"
                    }
                ]
            }
        }
    ]
}

which is now used to render all the information about the plugin in the WP admin before the installation and during upgrades. The signature of the package ZIP file can now be verified using the public key extracted from the first step.

FAIR Branding

While researching this, I also did some exploration for the possible FAIR project and package manager logo/icon. Since the FAIR branding needs to apply to multiple initiatives, it would be easy to go with a shared icon + wordmark for each project. The isolated FAIR letters represent the distributed and decoupled nature of this project.

Contributions

As part of this research I also create the following issues and suggestions:

• Protocol clarification: verificationMethod type MUST be Multikey or Multibase
• Missing signature verification for did:… packages
• Diagrams explaining the DID package install and upgrade workflow

WordPress comments are missing critical functionality to really embrace engagement and community — there are no notifications when your comment is approved or gets a reply, which prevents any kind of continued discussion.

In this video I’m demonstrating an update to the Comment Approval Notifications plugin (which hasn’t been touched in 10 years) to extend the notifications to comment approvals, replies and new comments in general.

Jetpack comments has some of these features but I wonder if there is a place for a decentralized solution?

An alternative to email is the Fediverse which supports replies across WordPress sites and other ActivityPub clients. In addition, it also handles notifications nicely in the mobile apps.

What do you think?

So I configured remote logging to capture the events that happen in the lead up to the issue since the logs on the disk get rotated very quickly due to the shear volume of the messages. Turns out that setting up the remote logging in RouterOS is way more involved so I wrote this guide to note some of the undocumented behaviors and features.

Logging in RouterOS

Logging can be configured under “System → Logging” where you define Rules about which log events (topics) trigger which log Actions:

Most of these rules are pre-configured by default.

Each rule has two parts:

1. Topics which is either log severity — critical, error, warning, info, debug or a specific component targeting — lte, firewall, etc.
2. Action for where the log entry is sent — echo for terminal output, memory for RAM, disk for writing to flash, email for email and remote for what we’re after.

And here is the individual rule configuration:

Important: the topic selection is ANDed together — specifying multiple topics will make the rule apply only if the log event belongs to all of the selected topics!

The Regex filtering can be applied to the log string contents to narrow down the selected events even further. Each rule can have only one action!

Funny how RouterOS is glass half-empty with the “NOT INVALID” flag.

Remote Log Action

We need to configure the remote log action which is enabled by default but without the remote address defined. Here are the available configuration options:

It supports three remote log formats:

• default — a custom Mikrotik format that matches the RouterOS log strings.
• BSD syslog — which is actually the legacy RFC 3164 standard (replaced with RFC 5424).
• CEF or Common Event Format with pipe-delimited fields with syslog prefix.

which can be transported over UDP or TCP with additional customization for the timestamp format:

• BSD (example: Mar 16 17:43:09)
• ISO8610 (example: 2025-03-16T17:48:26.0000+0200)

Here are examples of a log messages in each format:

Default Format

Note how it doesn’t include the event timestamp:

system,info log action changed by macintosh-intel-mac-os-x/web:admin@10.200.200.16 (/system logging action set "" remote=192.168.88.113 remote-log-format=default remote-port=9514 remote-protocol=udp src-address=0.0.0.0 syslog-facility=daemon syslog-severity=auto syslog-time-format=bsd-syslog target=remote)

BSD syslog Format

Note the priority prefix <30> follow by the timestamp in the header.

<30>Mar 16 17:43:09 mt-hap-capsman log action changed by macintosh-intel-mac-os-x/web:admin@10.200.200.16 (/system logging action set "" remote=192.168.88.113 remote-log-format=syslog remote-port=9514 remote-protocol=udp src-address=0.0.0.0 syslog-facility=daemon syslog-severity=auto syslog-time-format=bsd-syslog target=remote)

BSD syslog with ISO8610 timestamp:

<30>2025-03-16T17:48:26.0000+0200 mt-hap-capsman log action changed by macintosh-intel-mac-os-x/web:admin@10.200.200.16 (/system logging action set "" remote=192.168.88.113 remote-log-format=syslog remote-port=9514 remote-protocol=udp src-address=0.0.0.0 syslog-facility=daemon syslog-severity=auto syslog-time-format=iso8601 target=remote)

CEF Format

Note how this appears to be the most verbose and include additional information about the system config:

Mar 16 17:43:38 mt-hap-capsman CEF:0|MikroTik|hAP ac^2|7.18.2 (stable)|10|system,info|Low|dvchost=mt-hap-capsman dvc=192.168.88.2 msg=log action changed by macintosh-intel-mac-os-x/web:admin@10.200.200.16 (/system logging action set "" cef-event-delimiter\="" remote\=192.168.88.113 remote-log-format\=cef remote-port\=9514 remote-protocol\=udp src-address\=0.0.0.0 syslog-facility\=daemon syslog-severity\=auto syslog-time-format\=bsd-syslog target\=remote)

Syslog Server with Grafana Promtail and Loki

Here is a minimal docker-compose.yml for a Grafana Promtail listening on port 5514 for UDP traffic (and labeling the logs by hostname and severity) and pushing them to a Grafana Loki server on port 3100 for storage:

services:
  loki:
    image: grafana/loki:3.6
    ports:
      - 3100:3100

  promtail:
    image: grafana/promtail:3.4.2
    ports:
      - 5514:5514/udp
    volumes:
      - etc-promtail:/etc/promtail
    command: -config.file=/etc/promtail/promtail-config.yml

volumes:
  etc-promtail:

and the promtail-config.yml contents:

server:
  disable: true

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: syslog
    syslog:
      listen_address: 0.0.0.0:5514
      listen_protocol: udp
      syslog_format: rfc3164
      labels:
        job: syslog
    relabel_configs:
      - source_labels: ['__syslog_message_hostname']
        target_label: host
      - source_labels: ['__syslog_message_hostname']
        target_label: instance
      - source_labels: ['__syslog_message_app_name']
        target_label: application
      - source_labels: ['__syslog_message_severity']
        target_label: level

Although Grafana Promtail is being replaced with Grafana Alloy, I found the new configuration format much harder to work with so I’m sticking with Promtail as something well tested and reliable.

Importantly, we’re using Promtail here only for labeling the syslog messages by their hostname, message context and severity which isn’t supported by the loki built-in syslog integration.

Logs in Grafana

You can then add Loki as a data source in Grafana and display the logs as needed:

Debug Syslog UDP and TCP Traffic

You can use netcat (nc) to capture the messages sent by RouterOS on the remote host:

• nc -k -v -l -p 9514 to capture TCP traffic on port 9514.
• nc -k -v -l -u -p 5514 to capture UDP traffic on port 5514.

where:

• -k keeps the connection alive and listening,
• -v prints verbose information,
• -l makes it listen for incoming connections instead of making one,
• -p for port to listen on.
• -u for UDP traffic (defaults to TCP without the flag).

Or tcpdump to capture both TCP and UDP traffic in a PCAP file for viewing in Wireshark:

tcpdump -i any port 6514 -w dump-tcp.pcap

Disable Podcast Feed Stylesheet

By default the plugin applies an XSL stylesheet to the podcast RSS feeds which make them look like the podcast landing page which might confuse some users. The following filter can be used to disable the stylesheet:

// Disable the podcast RSS XSL stylesheet.
add_filter( 'ssp_enable_rss_stylesheet', '__return_false' );

Remove Permalink Prefix from Podcast Post Type

By default the podcast post type used for episodes (which is linked to the series taxonomy) includes the front prefix of your permalinks. For example, if the permalinks are set to /blog/%postname% then the podcast episode permalinks would be /blog/podcast/%postname% which might not be desirable.

Use the following filter to remove the prefix (by setting the with_front to false) and also adjust permalink slug to something custom:

add_filter( 
	'register_podcast_post_type_args', 
	function ( $args ) {
		$args['rewrite'] = [
			'slug' => 'show', // Change `podcast` to `show` in episode URLs.
			'with_front' => false, // Remove the default prefix.
		];

		// Optional: Disable the post type archive.
		// $args['has_archive'] = false;

		return $args;
	}, 
	100
);

Uncomment the line with has_archive to disable the post type archive (showing all episodes across all registered podcasts) since we already have the dedicated archives for each podcast series.

Adjust the Podcast Series Permalink

As mentioned above, each podcast series is represented by the series taxonomy (which appears as podcasts in the URLs) so the default landing page for the podcast series is /blog/podcasts/podcast-title where /blog is the permalink prefix (if any), podcasts is the label of the series taxonomy and podcast-title is the series term slug.

Most sites use a dedicated page for their podcast landing page such as /podcast so you can adjust the permalink of the specific term ID to point to your custom page instead:

add_filter( 
	'term_link', 
	function ( $url, $term, $tax ) {
		// Redirect the `podcast-series-slug` term to the `podcast` page.
		if ( 'series' === $tax && 'podcast-series-slug' === $term->name ) {
				return get_permalink( get_page_by_path( 'podcast' ) );
		}

		return $url;
	}, 
	10, 
	3 
);

Note that the example above is very fragile as it would break whenever somebody changes either the podcast series slug or the corresponding page slug. It would be better to expose this as a term meta setting that stores the corresponding post ID.

However, most multisite setups are actually private where you trust the content creators. On non-multisite setups this capability is enabled for all users. Here is a filter to disable this limitation for all users with the editor capability, for example:

add_filter( 
	'map_meta_cap', 
	function ( $caps, $cap, $user_id ) {
		if ( 'unfiltered_html' === $cap && user_can( $user_id, 'editor' ) ) {
			return [ 'unfiltered_html' ];
		}

		return $caps;
	}, 
	10, 
	3 
);

It works by “enabling” the requested capability $cap by including it in the requested capabilities $caps for the requested action. You can change editor to any other capability. Consider if you should still honour the DISALLOW_UNFILTERED_HTML constant which should prevent all unfiltered HTML.

Note that any content edits by users without this capability will simply remove the restricted HTML so you should ensure that everyone who can edit the respective content has the necessary capability.

First, define the limit_req_zone at the http {} level and conditionally enable it only for POST requests to the desired request URIs by setting the limit request zone input to $binary_remote_addr while keeping it undefined for all the un-mapped requests:

map "$request_method:$uri" $wp_post_limit_key {
	POST:/wp-login.php $binary_remote_addr;
	POST:/xmlrpc.php $binary_remote_addr;
}

limit_req_zone $wp_post_limit_key zone=wp_post_limit_zone:10m rate=5r/m;

where:

• $wp_post_limit_key is our custom variable name that is either unset by default or equal to $binary_remote_addr when the current request should be rate-limited.
• wp_post_limit_zone is our custom zone name that must be referenced in limit_req of each server {} block.
• rate=5r/m sets the allowed request rate from the same IP to one request per 12 seconds (60/5). Importantly, as mentioned by Igor in the comments, this is the allowed interval between requests instead of total amount of allowed requests per interval.

And then add it to the PHP location in each of your server {} blocks:

location ~ \.php$ {
	try_files $uri =404;
        limit_req zone=wp_post_limit_zone;
	// ...
}

You can define multiple limit_req_zone configurations for different request mapping logic and apply them all to the same PHP location block.

Adjust the HTTP Response Code

By default Nginx responds with HTTP 503 Service Unavailable status code to all throttled requests. Use the limit_req_status directive to change it to 429 Too Many Requests in either http {} or server {} block:

limit_req_status 429; 

I wasn’t able to find a tool to resize and center all open windows to a specific size for screen recording, so I came up with this AppleScript:

set windowWidth to 1024
set windowHeight to 768

tell application "Finder"
	set {0, 0, screenWidth, screenHeight} to bounds of window of desktop
end tell

tell application "System Events"
	set position of windows of (application processes whose visible is true) to {(screenWidth - windowWidth) / 2, (screenHeight - windowHeight) / 2}
	set size of windows of (application processes whose visible is true) to {windowWidth, windowHeight}
end tell

which you can save as an “Application” via Automator (built-in macOS app):

Save it to your desktop or any other convenient location. Double-click the app to run it.

Approve the permissions requests for Finder and System Events. In addition, open the “Settings” app and enable the newly created app under the “Accessibility” section:

Contrary to the manufacturer specification on the web, this pump actually does support USB-C PD3.0 and QC3.0 power output and charging up to 30W. The included paper manual correctly states the supported USB-C voltage and power levels.

Opening the pump is really easy with just six phillips screws at the back. Inside, everything is neatly laid out and with wires of the appropriate gauge and latching connectors for the pump and battery connections, along with some adhesive to keep them secure during transportation.

Pump and Compressor

There are two motors inside — one for a simple fan and another one for driving a piston pump for the high-pressure stage (above 0.8 psi). Interestingly, the fan mode uses 8A at 11V compared to just 4A in the high-pressure mode as shown in this video (be aware of the loud audio):

Battery

It features a pack of six 18650 Li-ion batteries in 3S2P configuration (3 in series, 2 in parallel) with the combined capacity of 57.72Wh (5200mAh at nominal voltage of 11.1V).

USB-C Output

Turns out it actually does support USB-C PD 3.0 charging and output up to 30W at 20V in addition to Quick Charge 3.0 (QC3) with up to 12V and 3A (36W) output thanks to the INJOINIC IP2366 power management chip.

Charging

Charging over USB-C supports PD3.0 30W input while the included charger GQ20PD02-ZG can only deliver QC3.0 20W at 12V/1.67A. It would take either 2 or 3 hours respectively to fully charge the battery.

Charging Error EE3

Having played with the supported USB mode enumeration, I tested the pump performance with an actual 10’4″ (317cm) SUP and was able to bring it to 18 psi twice, including the deflation.

When attempting to charge it with the supplied USB-C charger and cable, I was now suddenly getting a message EE3 on the screen and it wouldn’t charge when left over night. I was able to fix the issue by removing and re-attaching the battery which presumably reset the controller state. Since this is not an easy operation for an average user, I’ve reached out to the manufacturer to confirm alternative solutions for resetting the device.

Photos

I got my wife this Accolmile Antelope 1S electric bicycle with Bafang components from their latest M-series lineup of mid-drive motors and displays which communicate over a CAN bus. It’s a great city bike and the price includes fast shipping from the warehouse in Poland. Their support was also quick to send a replacement wheel for the original that got dented during transport (despite the thoughtful packaging).

CAN over NodeJS

The M500/M600 motors are particularly popular with MTB riders so the communication protocol has been discussed in this forum thread and documented in this GitHub repository. Importantly, the BESST software for managing the configuration and firmware updates is an Electron app with all logic as plain HTML and JS files (and bundled source maps for all minified code), including the CAN frame specification. I’ve started documenting my research in this GitHub repository.

Connecting to CAN Bus

The display connector at the wheel is the most convenient place to tap into the CAN bus. I purchased two HIGO 5-pin connectors B5-F and S5-F from ETShop in Germany for around €7 each (AliExpress / Amazon) and soldered the CAN high (green), CAN low (white) and ground (black) wires from each for a connection to (a copy of) the CANable Pro 1.0 CAN-to-USB adapter (AliExpress / Amazon). Be sure to test the wiring with a multimeter because one of the wires carries the full battery voltage!

Technically any CAN-to-USB adapter will work (as long as it supports 250kbit transfer rate) and the choice depends more on the software you want to use for interacting with the bus. The CANable adapter runs the slcan firmware which implements the Lawicel SLCAN protocol (a basic ASCII serial) which is supported by various libraries, including SocketCAN.

Update Controller Configuration Manually

I was able to test the setup by increasing the assisted maximum speed to 60km/h from the original 25km/h by sending a CAN message composed of the following components:

• 0x05 for the message source (0x01 — torque sensor, 0x02 — controller, 0x03 — display or HMI, 0x04 — battery, 0x05 — BESST),
• 0x02 for the message target (controller),
• 0x00 for a WRITE operation (0x01 for READ),

which are transformed into a frame ID prefix for the 0x3203 code and subcode for “speed limit, wheel diameter and circumference” registry through this transformer function:

buildHexStringCommand = (source, target, opt, anfn, nfn) => {
    const cmdPrefix = hexAllocToBinaryStr(source.toString(16), 5) + hexAllocToBinaryStr(target.toString(16), 5) + hexAllocToBinaryStr(opt.toString(16), 3);
    let cmdPrefixHex = parseInt(cmdPrefix, 2).toString(16);
    if (cmdPrefixHex.length % 2 !== 0) {
        cmdPrefixHex = '0' + cmdPrefixHex;
    }
    let cmdHexString = cmdPrefixHex + anfn + nfn;
    return hexReverse(cmdHexString);
};

which returns:

05 10 32 03

as the frame ID along with the payload:

70 17 C0 2B B6 08 

where (with little-endian byte order):

• 0x1770 is 6000 or 60km/h × 100,
• 0x2BC0 is 700 or 700c wheel diameter (29-inch), and
• 0x08B6 is 2230 or 2230mm wheel circumference.

Use Bafang CANable Pro Software

There is now the Bafang CANable Pro open-source software that allows you to configure all parameters using a desktop app (see related forum thread). Importantly, this requires CANable to be running the candlelight firmware since it uses the GS_USB protocol for talking directly to the USB device without the Serial/UART translation layer.

Makita doesn’t make an official USB-C PD (power delivery) adaptor (they only have ADP05 with two 5V/2A ports) so I found this UDCB094 on AliExpress (affiliate link) with PD65W output and with variants for 18V Makita, DeWalt, Milwaukee and Bosch power tool batteries. It appears to very well built — using 16AWG wires for the DC connection and implements true PD65W standard via the CSU3AF10 charge controller.

Teardown and Internal Photos

The PCB is labeled “YR-PD65W”.

Where to Get it?

Buy it from this store on AliExpress (affiliate link).

The best way to learn about the project is to explore the forum, join the Discord server and the Reddit community, follow #meshtastic on Twitter, Instagram and on your ActivityPub network of choice, and find recent videos on YouTube.

There are various community efforts to build local networks already:

• Meshtastic Ukraine with around 850 active nodes in the 433 MHz range.
• Austin Mesh in Texas, USA with weekly Friday check-ins (also available globally through the MQTT gateway).
• Iffy Books events and resources (including this incredible zine about Meshtastic).

Network Map

Here is a map of all active nodes connected to networks that relay messages to the official MQTT endpoint. This map is created by a forum user and shared in this thread.

How to Build a Network

Following the learnings from the solar-powered Raspberry Pi security camera project, I want to build solar-powered repeat nodes (with REPEATER role) to place in high enough places to enable coverage for everyone in the area. Since repeat nodes are invisible to the network and can’t send health or sensor data, another node with SENSOR role would be connected to the same battery and would broadcast the health of the repeater node along with temperature and humidity at very long intervals for maximum power savings.

I’ve decided to use Heltec WiFi Lora 32 (v3) ($20, schematic diagram, from AliExpress / Amazon) for the repeater nodes as they use ESP32-S3FN8 for the main controller and SX1262 LoRa chip with an IPEX1.0 antenna connector. This type of connector is really practical for bringing the antenna outside of the enclosure as the larger SMA connector cables are usually harder to bend and require more space in the case.

It also features a TP4054 charge controller and a voltage divider connected to an ADC pin for monitoring the battery voltage which is useful for telemetry. I’ve yet to figure out if it has any over discharge protection.

It is reported that RAK4631 WisBlock Core (AliExpress / Amazon) with the nRF52840 microcontroller and the same SX1262 LoRa radio uses significantly less power compared to ESP32 devices so it is probably a better choice for pure repeater nodes. However, I wanted something that is more universal with a screen and a case for this prototyping phase.

Power Requirements

There is a great thread on the forum with several posts linking to the following resources that outline the effective power requirements:

• Meshtastic ESP32 airtime and current draws (Google Sheets)
• NRF52840DK+SX1262 Meshtastic airtime/current draws (Google Sheets)
• Meshtastic Power Consumption Tests (Google Sheets)
• How To Calculate Solar Panel and Battery Size (Google Sheets)

The general consensus appears to be that ESP32 powered devices without any bluetooth, screen or GPS attachments need 0.1W on average. I was also able to confirm this in real-life testing at the 10% air-time (maximum allowed in EU).

Solar Power

The size of the battery and the solar panel power should be matched to ensure that a typical period of sunshine can charge the battery. Consider the following parameters:

• Total battery capacity.
• Maximum charging current supported by the cells.
• Duration of a typical charging session (hours of peak solar panel output).

For example, a typical 18650 cell with a capacity of 2500mAh or 9Wh (at 3.6V nominal voltage) recommends a maximum charging current of only 1A for cycle use which multiplied by the maximum charging voltage 4.2V gives us just 4.2W of maximum charging power. So there is no reason to pick a 40Wp solar panel if only 4W of that can be used by the battery.

The maximum charging power of 4.2W also means that it requires at least 2.1 hours to fully recharge the battery. Accounting for the charging losses it would probably increase to 2.5h.

As a rough guide you can pick a 10Wp solar panel for every 10Wh of battery capacity which requires 3h of full sunshine for a complete recharge.

Typical Charge Controllers

• CN3791 (datasheet PDF) is a true MPPT charge controller with an input voltage of up to 28V and a charge current of 4A (at 4.2V). Batteries discharged below 66% are trickled charged with 17% of the maximum charge current.
• CN3163 (datasheet PDF) is often called an MPPT controller but in reality it is only capable of reducing the charge current to maintain the minimum solar input of 4.4V (up to 6V). This controller can also adjust the charge rate based on the temperature to improve the battery life.
• TP4056 and its clones like CL4056 are generic Li-Ion battery cell chargers that don’t have any special functionality related to the solar input.

From the CN3163 datasheet:

If the output capability of input power supply is less than the charging current set by the resistor at ISET pin, then the on-chip adaptive cell will begin to function to adjust the charging current based on the output capability of input power supply. In this case, the charging current may be less than the value set by the resistor at ISET pin, but it is maximized to the output capability of input power supply on the condition that the input voltage at VIN pin is no less than 4.4V, which is the minimum operating voltage of CN3163.

3.3V Voltage Regulators

Microcontrollers require stable 3.3V input power so every Meshtastic device has a voltage regulator that creates this voltage either from the USB power or the battery. It is important that these devices are efficient and have a low voltage difference at which they can still do the conversion.

For example, the Heltec Lora 32 v3 uses CE6260 with a drop-out voltage of 0.120V at 100mA load which means that it will stop converting to 3.3V as soon as the battery voltage drops below 3.42V which leaves some of the battery capacity unusable. Importantly, the voltage difference increases with load so at 200mA (when transmitting a Lora packet) the drop-out voltage would increase to 0.25V requiring a battery voltage of 3.55V.

Battery Protection

• Most 18650 size batteries don’t have any undervoltage protection.

Solar Test Node

For the initial prototype I found this 4W (D4W) solar panel (AliExpress) with an integrated case for six 18650 battery cells. Using only three cells provides plenty of room for additional electronics like the LoRa board.

In general it is best to oversize the photovoltaic panels significantly to ensure that required charging voltage is reached even when there is low solar radiation (such as during winter).

And here is a close-up of the circuitry:

Battery Undervoltage Protection

The board appears to use XySemi XB5352A (datasheet PDF) battery management chip U5 (the SOT-23-5 component to the right of the “on” switch) which handles over-voltage (4.30V for VCU with 4.10V recovery VCL), over-discharge (2.40V VDL with 3.0V recovery VDL), over-current (3.2A IOV1), and over-temperature protection. However, this chip is placed on the solar input so there is no under-voltage or over-discharge protection on the battery side. This makes this solar panel unusable without additional battery under-voltage protection.

Configuring the Solar Powered Repeater

And here is the case fitted with Heltec Lora 32 v3 with INA219 connected to pins 41 and 42 (confirmed this with the Arduino Core library and the usage in the Meshtastic firmware) for measuring the battery voltage and current over time and reported over Power Telemetry. Note that simply attaching the device to the board will make the firmware use the INA219 bus voltage reading also for Device Telemetry (which is not documented).

Power Measurements

The test setup shown in the photo above was configured as a router node with a single 18650 cell (6.6Wh capacity verified with Liitokala Lii-M4S [AliExpress / Amazon]) at 5% air utilization rate (one telemetry message per minute). It ran for 6 days which amounts to an average power consumption of 0.046W (12mA@3.7V) at 5% utilization rate. Importantly, this node was also powering the INA219 sensor which was doing the power measurements every minute.

• Has only USB type B connection for management.
• Is recognized by macOS and QNAP operating systems as UPS when connected over USB.
• Relies on PowerMaster+ management software for configuration.
• Has four IEC C13 output sockets.
• Uses two 6V/7Ah batteries which gives it a theoretical maximum capacity of 84Wh.
• Has audible transformer hissing when not loaded but is completely fan-less.

Power Consumption

The unit draws an additional 15W when powering a 30W NAS (and connected to the mains) which explains why it gets pretty warm (still comfortable to touch). This is a pretty significant overhead for DC-based systems like routers and mini PC servers.

The specification mentions 95% efficiency under full load when connected to the mains and 78% efficiency when powered from the battery (also under full load) with a 0.60 power factor. The official full-load (300W) backup time is 0.8 minutes or 10.3 minutes for the half-load (150W).

After almost exactly a year of this kind of usage, the batteries were completely depleted and wouldn’t last even a few seconds during a blackout — dropping to 10V as soon as the mains power supply was removed.

For a home server hosting mostly Docker containers I’ve always wanted a computer with proper and multiple disk drives for data redundancy instead of SD cards used by most single-board computers. With the shortage of Raspberry Pi supply over the past years there has been an increased availability of mini PCs with all kinds of power-efficient Intel processors and extensive IO and storage options. Blogs such as CNX Software, Linux Gizmos and Liliputing are amazing for research and deals which is how I discovered Beelink and their mini PCs.

In late 2022 I purchased Beelink U59 Pro with an Intel N5105 processor, 16GB RAM, 500GB M.2 drive and two network ports for around EUR 230 (including shipping). Here is a great review of the device.

Hardware and Upgrades

Overall, the build quality is great with nice and quiet cooling design and convenient placement for the extra SSD drive. It uses a 12V power supply so it can be easily attached to a battery-powered UPS.

For data redundancy I added a 1TB WD Blue SA510 2.5” SATA III drive (Amazon) and used LVM to distribute the filesystem logical volume across the two physical volumes as RAID1.

Below are my notes on getting the device up and running.

Power Supply and Consumption

It is powered by a 12V 3A power supply with a 5.5×2.5mm DC jack. Note the diameter of the inner pin which is larger than the typical 2.1mm and won’t fit most of the low-power 12V power supplies or the POE adapters/splitters.

The power consumption ranges from 17W during the boot process to 5W when idling with ethernet connected and WiFi enabled but disconnected, using the default Ubuntu Server 22 LTS. It gets down to 3W after running powertop --auto-tune which applies the following optimizations:

BIOS Version and Errors

The device comes with Windows 11 installed and activated. However, I wanted to install the Ubuntu server and that would never get pass one of the installation stages due to some memory errors. The device came with BIOS version JTKT001 X64 (build 05/05/2022 15:03:35) and produced the following errors during the boot (shown here with Debian install for testing):

I reached out to Beelink support and after providing the serial number for the hardware revision identification they sent a new version of the firmware JTKT001_20230217_U59_sata.bin along with the tooling to update it from a flash boot. This new version seems to have resolved the issue and I’ve been able to install Ubuntu Server 22.04.2 LTS without any problems.

It is unfortunate that this is not provided on their website and everyone needs to contact their support directly (apparently due to the potential of bricking the device with the wrong firmware).

Enable Wake-Up after Power Loss

This device can automatically restart after a power loss but that isn’t enabled by default. The option for “State After G3” is hidden under the “Chipset” tab and the “PCH-IO Configuration” section in the BIOS settings and needs to be set to “S0 State” (one of the ACPI Sleep States).

This is an important feature for a homelab server!

Usage

This server is running in parallel to a dedicated QNAP TS-435XeU NAS and hosts critical Docker containers for home automation to reduce the impact of NAS firmware upgrades and restarts while still backing up volume data to the NAS.

Beelink Intel Mini S Comparison

Recommended: Mini S13 with N150 and 16GB RAM (AliExpress / Amazon). For NAS application consider Beelink ME Mini NAS (AliExpress / Amazon) with 16GB RAM, 64GB eMMC, dual 2.5Gbps and 6x M2 NVMe SSD slots (24TB max. capacity).

For the SSD storage you can estimate ~$50 per TB (up to 8TB).

Note:

• All Mini S models contain one additional M2 NVMe or SATA SSD slot.
• Amazon often has significant discounts for Beelink products.

It is based on the Tuya TYZS4-IPEX module for the Zigbee connectivity and Realtek RTL8196E controller for the USB and ethernet functionality similar to the Zemismart ZMHK-01 hub I reviewed earlier and the Lidl Silvercrest Zigbee hub.

Considering the shared components, it should be possible to get root access to the device by connecting directly to that UART pins on the PCB (see below) but the bootloader on this device RealTek(RTL8196E) at 2022.01.10-18:12+0800 v3.4T-pre2 doesn’t support the ESC key sequence for entering the boot options as described by this open issue.

The pins at the bottom-left of the PCB (J1) are:

• Pin 1 (square): 3.3V
• Pin 2: GND
• Pin 3: RTL8196E U0_TX (B0)
• Pin 4: RTL8196E U0_RX (A7)
• Pin 5: Tuya TYZS4-IPEX SWDIO
• Pin 6: Tuya TYZS4-IPEX SWCLK

Connecting just the GND, TX and RX pins I was able to read the boot logs:

Booting...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
@ chip__no chip__id mfr___id dev___id cap___id size_sft dev_size chipSize
@ 0000000h 0c84018h 00000c8h 0000040h 0000018h 0000000h 0000018h 1000000h
@ blk_size blk__cnt sec_size sec__cnt pageSize page_cnt chip_clk chipName
@ 0010000h 0000100h 0001000h 0001000h 0000100h 0000010h 000004eh GD25Q128
@ 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
DDR1:32MB
 
---RealTek(RTL8196E)at 2022.01.10-18:12+0800 v3.4T-pre2 [16bit](400MHz)
P0phymode=01, embedded phy
check_image_header  return_addr:05010000 bank_offset:00000000
no sys signature at 00010000!
P0phymode=01, embedded phy
---Ethernet init Okay!
tuya:start receive production test frame ...
Jump to image start=0x80c00000...
decompressing kernel:
Uncompressing Linux... done, booting the kernel.
done decompressing kernel.
start address: 0x80003780
Linux version 3.10.90 (root@WorkPC) (gcc version 4.6.4 (Realtek RSDK-4.6.4 Build 2080) ) #1 Mon Jan 10 18:14:44 CST 2022
CPU revision is: 0000cd01
Determined physical RAM map:
 memory: 02000000 @ 00000000 (usable)
Zone ranges:
  Normal   [mem 0x00000000-0x01ffffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x01ffffff]
icache: 16kB/16B, dcache: 8kB/16B, scache: 0kB/0B
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line:  console=ttyS0,38400 root=/dev/mtdblock2 
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 27344k/32768k available (2763k kernel code, 5424k reserved, 562k data, 192k init, 0k highmem)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:128
console [ttyS0] enabled
Calibrating delay loop... 398.13 BogoMIPS (lpj=1990656)
pid_max: default: 4096 minimum: 301
Mount-cache hash table entries: 512
reg e0=0
reg e1=0
reg e2=0
reg e3=0
reg e4=0
reg e5=0
reg e6=0
reg e7=0
reg f0=0
reg f1=0
reg f2=0
reg f3=0
reg f4=0
reg f5=0
reg f6=0
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 53
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x18002000 (irq = 9) is a 16550A
serial8250: ttyS1 at MMIO 0x18002100 (irq = 13) is a 16550A
Realtek GPIO Driver for Flash Reload Default
tuya_gpio_init ok, scan expire time:50
SPI INIT
 ------------------------- Force into Single IO Mode ------------------------ 
|No chipID  Sft chipSize blkSize secSize pageSize sdCk opCk      chipName    |
| 0 c84018h  0h 1000000h  10000h  10000h     100h   84    0          GD25Q128|
 ---------------------------------------------------------------------------- 
SPI flash(GD25Q128) was found at CS0, size 0x1000000
boot+cfg offset=0x0 size=0x20000 erasesize=0x10000
linux offset=0x20000 size=0x1e0000 erasesize=0x10000
rootfs offset=0x200000 size=0x200000 erasesize=0x10000
tuya-label offset=0x400000 size=0x20000 erasesize=0x10000
jffs2-fs offset=0x420000 size=0xbe0000 erasesize=0x10000
5 rtkxxpart partitions found on MTD device flash_bank_1
Creating 5 MTD partitions on "flash_bank_1":
0x000000000000-0x000000020000 : "boot+cfg"
0x000000020000-0x000000200000 : "linux"
0x000000200000-0x000000400000 : "rootfs"
0x000000400000-0x000000420000 : "tuya-label"
0x000000420000-0x000001000000 : "jffs2-fs"
PPP generic driver version 2.4.2
nf_conntrack version 0.5.0 (427 buckets, 1708 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
l2tp_core: L2TP core driver, V2.0
8021q: 802.1Q VLAN Support v1.8
Realtek FastPath:v1.03
Probing RTL819X NIC-kenel stack size order[1]...
eth0 added. vid=9 Member port 0x10f...
eth1 added. vid=8 Member port 0x10...
[peth0] added, mapping to [eth1]...
VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
Freeing unused kernel memory: 192K (80340000 - 80370000)
init started: BusyBox v1.13.4 (2022-01-10 18:11:37 CST)
Set power startcmd read
b8000038: 2794A104  0000000F    00000042  00000018    '��        B    
cmd write
Write memory 0xb8000038 dat 0x1794a104: 0x1794a104
Set power end
udhcpc (v1.13.4) started
Sending discover...
Please press Enter to activate this console. Tuya Gateway Application Normal Srart /tuya/tuya_start.sh UserAppRunDir:
set defult run_dir:/tuya
TY_ENV_APP_RUN_DIR=/tuya
get user cfg file error, load defult cfg file
load platform configure file:/tuya/def.cfg
start.conf is exist
udhcpc (v1.13.4) started
Normal mode.
current run dir:/tuya/tuya_user1
grep: /var/resolv.conf: No such file or directory
tuya_start_children.sh:UserAppRunDir:/tuya JsonFile Path:/tuya/def.cfg [engineer_mode: ]
Sending discover...
killall: app_detect.sh: no process killed
killall: tyZ3Gw: no process killed
killall: log_detect.sh: no process killed
killall: process_monitor.sh: no process killed
killall: tyZ3Gw: no process killed
Sending discover...
cat: can't open '/tuya/eng_mode_upg': No such file or directory
cat: can't open '/tmp/eng_mode': No such file or directory
no eng file
Sending discover...
nameserver 114.114.114.114
nlRecvFromAppSock sg_netlinkKeyPid:239
nlRecvFromAppSock port link sg_netlinkPid:239
umw send to error.: Socket operation on non-socket
Jan  1 00:00:38 mDNSResponder: mDNSResponder (Engineering Build) (Jul 27 2021 20:15:30) starting
Jan  1 00:00:38 mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
Jan  1 00:00:38 mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
Jan  1 00:00:38 mDNSResponder: WARNING: mdnsd continuing as root because user "nobody" does not exist
Sending discover...

Components

Here are the components for this particular unit (inspected manually or extracted from the available documentation). Note that different production runs might be using different components.

Air Filters

Nilan Greencycle filter (G4, ISO Coarse > 75%).

Supply and Extract Air Motors

D190mm Not confirmed, yet.

Pre-Heating Element (Polar)

RDT TW3 1500W 240V resistive heater coil in the back of the top-left incoming air chamber.

Counter-flow Air Heat Exchanger

Polyethylene terephthalate (PET) counterflow heat exchanger. Potentially Holtop 3D (specification PDF).

Bypass Damper

Belimo CM230-F rotary actuator (orange device in the middle of the photo) controls the bypass damper — the cover for the cross-flow heat exchanger (the aluminium plate covering the green cross-flow heat exchanger in the top-left) and the square opening (to the right of the actuator) in the middle of photo connecting the incoming and outgoing air chambers.

• Belimo CM230-F datasheet PDF
• Belimo CM230-F installation instructions PDF

Air-Source Heat Pump

Danfoss SC15GHH reciprocating compressor pumps the heat from the exhaust air (bottom left) to either the hot water tank or the incoming air. It is a high back pressure (HBP) compressor with a high condenser temperature of 55C to ensure it can heat up the domestic water using the R134a refrigerant.

It’s heat output ranges from 345W at -15C evaporator (is that the outgoing air after the counter-flow heat exchanger?) temperature (COP 1.26) to 1731W at 15C evaporator temperature (COP 3.02) at EN12900/CECOMAF rating conditions:

which looks like this on a chart:

Prices online range from EUR 150 to 900.

• SC15GHH specification PDF
• SC15GHH connections PDF
• SC15GHH service guide PDF

CO2 Sensor (Optional)

Korea Digital SenseCube KCD-AN300 (RS-15-spec) (sold by Nilan) with dual-wavelength NDIR sensor with 4-20mA / 0-10V analog or RS485 / PWM output.

• KCD-AN300 specification PDF
• Available for purchase in EU for EUR 94.

The legend states that any amount of insulation added after R-10,20,30,40… (pick your number but be aware of the units) is a waste of money or unnecessary, or simply doesn’t make sense. I’ll explain why that is not the case.

Note: I originally wrote this as a comment to this blog post and decide to share it here with additional details and context.

Why R-values and U-values Get Confusing

Materials transfer heat at a rate that is proportional to the thickness and the temperature difference between both sides of the material. It is expressed as W/(mK) and a typical (and conservative) value for a blown-in cellulose, wood fibre or mineral wool is 0.04W/(mK).

Dividing this number by the width of the material we derive the rate of heat transfer per area of the material which is the U-value or W/(m²K). The inverse of that is the resistance to the heat conductivity or the R-value or m²K/W.

Important: we’re referring R-value in SI units (also known as RSI) which need to be multiplied by 5.68 to arrive at the values typically used in the U.S.

It appears as if each additional layer of insulation does less to reduce the rate of heat transfer (U-value) while the R-value increases linearly. This is the source of confusion.

Turns out that the amount of insulation added relative to the total amount of insulation is actually the same as the change in the rate of heat transfer or the U-value:

This is similar to how a 50% drop in stock market requires an 100% increase afterwards to get to the original value. The reference point is what matters and creates the perceived difference.

Doubling the width of insulation at every step also halves the U-value but normally the increments are constant so the rate of change appears to slow down.

How Much Insulation is Enough?

After adding enough insulation for basic things like thermal comfort and avoiding condensation risk, it boils down to the cost of energy and its sustainability over the lifetime of the building.

The passive house limit of 15kWh/m2 of energy per year or 10W/m2 of heating/cooling load are great guidelines based on the maximum amount of heat that can be transported with the ventilation air. It is also low enough to require paying attention to thermal bridges and air tightness. Importantly, that amount of energy is easily available from photovoltaics during the summer and can be cheaply extracted from the ground via heat pumps during the winter.

It can be assumed that all of the added heat is equal to the heat lost to the room. This value might vary based on the set temperature and the hysteresis limits used by the device but over a period of a few days it should be possible to determine a reliable average (taking into account the weekly anti-legionella functionality).

Using TuYa TS011F socket with Home Assistant I was able to determine that our 80 liter Gorenje GBU hot water heater looses about 1.3 kWh per day to the room. At average total of 7kWh per day that makes it 18% of energy lost to the room.

Some of the manufacturers actually supply this value in the specification sheet and it is usually around 1kWh per day depending on the volume.

These are two devices (AliExpress) with identical PM2.5/PM10 sensors (boxes with the metal cover), temperature and humidity sensors (top center) which are connected to an STC 8G1K08 microcontroller which prepares the data for the Tuya controllers with either WiFi or Zigbee radio (bottom left). The 6in1 version has an additional VOC sensor (bottom right with the metal mesh) which provides VOC and derived or virtual formaldehyde and CO2 values.

The PM2.5 sensor is a primitive dust sensor with a pair of infrared (IR) source and receiver.

They cost around $25 for the 4in1 version and $30 for the 6in1. I bought them here on AliExpress.

Home Assistant Compatability

The Zigbee version is known as TS0601 Smart Air House Keeper by Zigbee2MQTT (TZE200_dwcarsat) and is supported by their Home Assistant integration as well as the ZHA integration (except for this bug). It is also supported by the Zemismart gateway in the Smart Life app but it does not show up in the Apple Home app.

The WiFi version is supported only by the Tuya cloud integration in Home Assistant and the Smart Life app which detects the device via Bluetooth and then lets you configure the WiFi settings.

What is 10W per square meter?

It signifies the incredibly low heating or cooling power that is needed to keep a passive house comfortable. It signifies how little heat is lost through the building envelope and that is happens really slowly. For example, a 100m² house requires just 1000W or 1kW during the coldest winter nights or the hottest summer days to keep the indoor temperature steady.

It is easy to see how boiling water for tea, cooking food and running other household appliances could generate enough heat that is eventually absorbed by the building to keep the additional heating need even lower. That’s why it’s called “passive” house because it requires so little addition energy to what is already generated by the people just living in it.

Ventilation with Heating and Cooling

Ventilation is the only active process in a passive house as it needs to happen in a way that doesn’t transport any heat out of the house. The magic numbers for this is 30m³ of fresh air per person per hour at a 90% heat recovery efficiency.

What if we used this air to transport heat around the house — add heat during the winter and remove it during the summer? Would it be possible to transport those 10Wh of heat per square meter every hour?

Energy in Air

The heat capacity of air is around 1000 joules or 0.28Wh per kg per degree and its density is around 1.2kg per m³ which means that 1m³ of air is able to transport 0.28Wh/kg × 1.2kg = 0.33Wh of energy per each degree of air temperature change. Compare that to the same volumetric amount of water which has 4 times the heat capacity, 830 times the density and is able to carry 1151Wh energy per degree difference.

A four person household needs 4 × 30m³= 120m³ of fresh air per hour which can transport 120 × 0.33Wh = 40Wh of heat per hour per degree change. So in order to add or remove 1000Wh of heat by transporting 120m³ of air every hour we need a 1000Wh ÷ 40Wh = 25C degree hotter or colder air compared to the room temperature. Doubling the amount of air to 240m³ would decrease that to a 12.5C degree difference.

This proves that in theory it is possible the heat or cool the whole house just by using the air that is already used for ventilation. Not only that — we can use a heat pump to extract even more heat from the air leaving the home.

Heating Air and Water

The ideal way to do this is by placing a heat pump on the exhaust side of the ventilation after the cross-flow heat exchanger to extract even more energy from the outgoing air — like a traditional air-source heat pump but with the evaporator placed inside the exhaust line of the ventilation unit and the condenser in the supply line (in the heating mode). It would also recover all the energy left over by the cross-flow heat exchanger!

There are several products (filter by “Compact heat pump unit”) on the market that do this:

• Nilan Compact P (in component database)
• Stiebel Eltron LWZ 8 CS Premium (in component database)
• Systemair Genius (in component database)
• Genvex Combi 185 BP (in component database)

Some of them have additional routes for the incoming air so that it can be used only for heating water and doesn’t need to be moved through the house when the ventilation needs are low.

They all look pretty much like this:

and they all work like this:

As you can imaging, the same system can also be used in hot climates to both cool the incoming ventilation air and heat up the water just by reversing a few valves.

Some of these units have support for ground-source heat pump additions which can further increase and optimize the available heating and cooling loads at amazing efficiencies.

Interestingly, the Nilan Compact P datasheet has the follow graph:

which confirms that a heat pump is able to extract 2200W of heat from 220m³ of exhaust air every hour. The ventilation loss shown just below the heat output is confusing because my understanding is that the heat pump is placed after the cross-flow heat exchanger so it shouldn’t impact the heat recovery efficiency.

These units cost somewhere in the range of $12,000 to $25,000 and they reduce the utility room down to this one device which still needs to be hidden behind a well insulated walls due to noise, but the savings on piping and installation work should easily justify the cost.

Note: this device is very similar to NEO NAS-ZW05B0!

Getting Root Access

Turns out it is very similar to the first generation of the Lidl Silvercrest Smart Gateway which allows extracting the root user password over the UART connection exposed on the back of the PCB. The screws are hidden behind the rubber ring on the bottom:

And the UART pins TX and RX are clearly marked on the back of the PCB. Note that you must use 3.3V for power and logic when connecting to the device.

After extracting the password from the flash memory you’re able to connect to it over SSH running on port 2333:

$ ssh root@gateway.local -p 2333

where gateway.local is the mDNS address of the device on your network. Alternatively, use the IP address of the device to connect.

The device runs Linux with BusyBox v1.13.4 (2021-08-26 11:01:27 CST) and it uses a bunch of bash scripts to configure and launch the software. Most of the runtime logic is handled by the following process:

./tyZ3Gw /tuya/tuya_user2 /tuya/def.cfg

where tyZ3Gw (sounds like short for “Tuya Zigbee3 Gateway”) is the binary in the /tuya/tuya_user2 working directory using /tuya/def.cfg for config:

{
	"user_cfg_file":"/tuya/config/user.cfg",
	"platform":"RTL8196E",
	"product_key":"keyYOURUNIQUEKEY",
	"mode_id":"RTL8196E_TY01",
	"storage_dir":"./",
	"log_dir":"/tuya/log_dir/",
	"tmp_dir":"/tmp/",
	"bin_dir":"/tuya/",
	"backup_dir":"/tuya/",
	"net_led":"LED0",
	"status_led":"LED1",
	"reset_key":"KEY0",
	"wan_interface":"eth1",
	"wifi_interface":"wifi0",
	"serial_port":"/dev/ttyS1",
	"is_cts":true,
	"is_sync_systime":true,
	"is_hardward":true
}

Note that there is no WiFi network interface on this device although it is mentioned in the config.

Zigbee Communication

The zigbee_agent binary talks to the NXP JN5189 Zigbee module over UART at /dev/ttyS2. There is a custom UART to TCP bridge software developed by Paul Banks that can be used to expose the Zigbee radio to the Home Assistant ZHA integration over TCP. Note that this disables the Tuya and HomeKit integrations since they are no longer able to talk to the same UART device that is now used by the bridge.

Compatible Devices

I’ve successfully tested the following devices with the hub and they become available in the Home app:

• Tuya ZigBee 3.0 Switch Modules (both 1 and 2 channel) with Tuya 2T3L radio.
• GIRIER Tuya ZigBee 3.0 Smart Light Switch Module with Tuya ZTU radio.
• Sonoff SNZB-03 PIR motion sensor.

The following devices are recognized by the Smart Life app but they don’t show up in the Home app:

• Tuya TS0601 Smart Air Box House Keeper 6in1 air quality monitor with ZT3L module.

I used this Modbus registry information to create this device template for Home Assistant where the meter is attached to the Protoss PE11 RS485 to TCP gateway (AliExpress) available on IP 123.123.123.123 which must be adjusted for your setup or switched to a serial config:

modbus:
  - name: Protoss PE11
    type: tcp
    host: 123.123.123.123
    port: 502
    timeout: 0.5
    sensors:

      - name: DDS238-2 ZN-S Total Energy
        device_class: energy
        state_class: total
        unit_of_measurement: kWh
        address: 0
        count: 2
        data_type: uint32
        scale: 0.01
        precision: 2

      - name: DDS238-2 ZN-S Export Energy
        device_class: energy
        state_class: total_increasing
        unit_of_measurement: kWh
        address: 8
        count: 2
        data_type: uint32
        scale: 0.01
        precision: 2
    
      - name: DDS238-2 ZN-S Import Energy
        device_class: energy
        state_class: total_increasing
        unit_of_measurement: kWh
        address: 10
        count: 2
        data_type: uint32
        scale: 0.01
        precision: 2

      - name: DDS238-2 ZN-S Voltage
        device_class: voltage
        unit_of_measurement: V
        address: 12
        data_type: uint16
        scale: 0.1
        precision: 1

      - name: DDS238-2 ZN-S Current
        device_class: current
        unit_of_measurement: A
        address: 13
        data_type: uint16
        scale: 0.01
        precision: 2

      - name: DDS238-2 ZN-S Power
        device_class: power
        data_type: int16
        unit_of_measurement: W
        address: 14
        
      - name: DDS238-2 ZN-S Reactive Power
        device_class: apparent_power
        data_type: uint16
        unit_of_measurement: VAr
        address: 15
        
      - name: DDS238-2 ZN-S Power Factor
        device_class: power_factor
        unit_of_measurement: '%'
        data_type: uint16
        address: 16
        scale: 0.1
        precision: 1

      - name: DDS238-2 ZN-S Frequency
        device_class: frequency
        unit_of_measurement: Hz
        data_type: uint16
        address: 17
        scale: 0.01
        precision: 2

Modbus to TCP Alternatives

The Waveshare RS485 to ETH with PoE (AliExpress) is another great and tested alternative. Note that is has versions with and without the PoE support so be sure to get the right one.

Getting Access

Turns out you can put a file named hostname (without any file extension) in the root of the SD card of the device and it will be executed as a bash script during the boot process. The following contents will set the password for the user root to password and set the WITH_TELNET environment variable to y which enables the telnetd service for remote access:

#!/bin/sh
echo "root:password" | chpasswd
export WITH_TELNET="y"

After inserting the SD card and restarting the camera you should be able to connect to it using telnet:

telnet camera-hub-g2h.local

which opens the telnet prompt:

Trying 123.123.123.123...
Connected to camera-hub-g2h.local.
Escape character is '^]'.

Camera-Hub-G2H login: root
Password:

and you now have full root access to the filesystem!

Setup Aqara Gateway

The AqaraGateway project is a set of custom binaries and python scripts that enable access to all the connected Zigbee devices over MQTT while keeping the Aqara app and the HomeKit integration working as before.

It does it in the following way:

1. You replace the mosquitto MQTT broker binary on the device with a custom one (which appears to be closed source?) which exposes the MQTT service on a public port on your local network and removes the authentication for the MQTT service.
2. You install the Aqara Gateway Home Assistant integration via HACS (Home Assistant Community Store) which then talks to the device over telnet to validate the mosquitto binary, to fetch the available Zigbee devices and to establish an MQTT subscription with the broker on the device.
3. The Aqara Gateway in your Home Assistant maps the MQTT messages to different devices supported by the gateway such as binary sensors and general sensors similar to Zigbee2MQTT.

Initially the gateway integration wasn’t recognizing my camera but this was resolved in one of the recent updates.

Support for new Aqara Zigbee devices requires updates to the AqaraGateway library and it appears that new issues are being opened on GitHub and they are also addressed.

Conclusions

Aqara hubs that support Aqara Gateway software are the only option on the market with local, no-cloud and open source API which supports HomeKit and Home Assistant integration at the same time. Another alternative is the Zemismart Zigbee Gateway which adds HomeKit support for many of the Tuya Zigbee devices, and can be rooted too.

However, the Zemismart gateway looses the HomeKit support if you replace the Tuya integration with the a ZHA serial gateway supported by Home Assistant because it takes over the UART connection with /dev/ttyS2 which is used by the Tuya zigbee_agent to talk to the NXP JN5189 Zigbee module.

As part of an experiment to add domestic water heating capabilities to conventional mini-split ACs, I purchased an air-source heat pump Gree GWH09YD-S6DBA2A which has an inverter controlled compressor and an electronic expansion valve that allows it to work efficiently even down to -30℃ (-22℉).

• Model: GWH09YD-S6DBA2A (outdoor), S6DBA1A (indoor)
• Product code: CB466000100/CB466000102
• Cooling capacity: 2.7kW
• Heating capacity: 3.5kW
• Refrigerant: R32
• Remote model: YAG1FB3

Service Manual

Most of the technical information in this post has been retrieved from the official service manual:

Remote IR Receiver Module

Attached to the back of the inner block cover is a display module combined with an IR receiver. I was wondering if the IR receiver logic could be handled there and forwarded to the main PCB via something like UART. Turns out the LCD elements and the IR receiver diode run down to the main PCB so there is nothing to hijack.

IR Remote Protocol

I used an infrared photodiode attached directly to pins GND and D3 (which is pulled high) of Wemos D1 mini and the IRrecvDumpV3.ino sketch bundled with v2.8.1 of the IRremoteESP8266 library to decoded the messages.

Here are the infrared bit sequences captured by the Saleae logic analyser:

We can clearly see two sets of messages that are repeated twice. Each message has two parts and the first one starts with a longer sync header.

Initially it complained about the packets being too large to fit in the allocated buffer:

WARNING: IR code is too big for buffer (>= 1024). This result shouldn't be trusted until this is resolved. Edit & increase `kCaptureBufferSize`.

That is because of the kTimeout constant which is set to 50 by default and is 10ms above the actual period of 40ms between the groups of messages that we see in the logic analyser output above. By setting the value to 30:

const uint8_t kTimeout = 30;

it started decoding the packets as expected:

Protocol  : GREE
Code      : 0x0C084070000000E0 (64 Bits)
Mesg Desc.: Model: 1 (YAW1F), Power: On, Mode: 4 (Heat), Temp: 24C, Fan: 0 (Auto), Turbo: Off, Econo: Off, IFeel: Off, WiFi: Off, XFan: Off, Light: Off, Sleep: Off, Swing(V) Mode: Manual, Swing(V): 0 (Last), Swing(H): 0 (Off), Timer: Off, Display Temp: 0 (Off)
uint16_t rawData[139] = {9004, 4474,  664, 540,  664, 540,  666, 1642,  664, 1644,  664, 542,  664, 540,  664, 542,  664, 542,  664, 542,  664, 542,  664, 542,  664, 1642,  664, 542,  664, 540,  666, 540,  664, 540,  664, 542,  664, 542,  664, 542,  664, 540,  664, 540,  664, 542,  664, 1642,  664, 542,  664, 540,  666, 540,  666, 540,  664, 540,  666, 1642,  664, 1642,  664, 1642,  664, 540,  664, 542,  664, 1642,  664, 540,  664, 19974,  664, 542,  664, 542,  664, 542,  664, 542,  664, 542,  664, 542,  662, 542,  662, 542,  664, 542,  664, 542,  664, 542,  664, 542,  662, 544,  662, 544,  662, 544,  662, 542,  662, 544,  662, 542,  662, 542,  662, 544,  662, 544,  662, 542,  664, 544,  662, 542,  662, 544,  662, 542,  662, 542,  664, 542,  662, 544,  662, 1644,  662, 1644,  662, 1644,  662};  // GREE
uint8_t state[8] = {0x0C, 0x08, 0x40, 0x70, 0x00, 0x00, 0x00, 0xE0};

In the decoded bit timing sequence above we see a 9004us header mark followed by a 4474us space and then the actual message bits where the bit mark is 664us, logical 0 space is 542us, logical 1 space is 1642us and with 19974us between the two packets of the message.

Enabling the I-feel mode (where the remote sends the indoor temperature to the indoor unit) does append another packet to the end which isn’t parsed correctly, though:

Protocol  : UNKNOWN
Code      : 0x5EF985F1 (18 Bits)
uint16_t rawData[35] = {6008, 2986,  658, 546,  658, 548,  658, 548,  658, 1648,  658, 1648,  658, 546,  658, 548,  658, 548,  658, 1650,  658, 546,  658, 1648,  658, 546,  658, 548,  658, 1648,  658, 548,  658, 1648,  658};

It appears that this packet is supported by the arduino-heatpumpir library. According to the GreeYACHeatpumpIR::send() method we’re expecting a header followed by two data bytes (using the following logic) and one closing GREE_YAC_BIT_MARK:

• 6008, 2986 are the two header marks,
• 658,546 | 658,548 | 658,548 | 658,1648 | 658,1648 | 658,546 | 658,548 | 658,548 maps to 0x00011000 in binary which is 24 in decimal (the temperature measured by the remote).
• 658,1650 | 658,546 | 658,1648 | 658,546 | 658,548 | 658,1648 | 658,548 | 658,1648 maps to 0b10100101 or 0xA5 in hex as expected.
• 658 is the closing GREE_YAC_BIT_MARK.

Wi-Fi Module

There is a built-in Wi-Fi module which uses a protocol that has been reverse-engineered and enables full control over the local network once the unit has been added to the Wi-Fi network using the GREE+ app for iOS and Android. There is even a fully functional HomeAssistant integration.

The COM-MANUAL label and the four wires going to the module from the PCB indicate that this is possibly an UART-to-WIFI bridge. However, attaching the digital logic analyser probes to the dark-brown, light-brown and GND pins produced a lot of noise without clear indication of the data being transfered.

Wi-Fi Module Firmware

Initially the unit was reporting firmware version v1.00 and only in April 2023 it offered an update to v3.76 via the official Gree+ app which completed successfully.

In July 2023 it started showing an available update to v3.77 but I haven’t been able to apply it due to a network timeout after requesting the update.

There is a GitHub repository collecting all the firmware files which can be obtained from Gree servers in the same way the mobile app does it. The app uses the firmware version reported by the hid parameter such as 362001065736+U-QCOM4004CV3.76.bin for my unit where the first part 362001065736 is the firmwareCode that is used to check for a new version by making a GET request to:

http://grih.gree.com/wifiModule/Lastversion?firmwareCode=362001065736

where grih.gree.com can be any of the local servers such as eu.grih.gree.com, for example. It returns a JSON blob:

{
    "CreateDate": "2023-06-15 08:27:08",
    "commProtVer": "V1.2.1",
    "desc": "1、devLogin包中增加hid、ModelType、bc字段；\r\n2、连接调度服时优先使用1812端口（1812端口与5000端口轮换使用）；\r\n3、配网成功后不响应Wi-Fi开关。",
    "forcedUpgrade": 1,
    "frcUpgdType": 0,
    "r": 200,
    "url": "http://grih.gree.com/wifiModule/image/10528/145680",
    "ver": "3.77"
}

or for from the EU server:

{
    "CreateDate": "2023-07-14 02:29:37",
    "commProtVer": "V1.2.1",
    "desc": "In this version, we have fixed some known issues.",
    "forcedUpgrade": 0,
    "r": 200,
    "url": "http://eu.grih.gree.com/wifiModule/image/10141/145680",
    "ver": "3.77"
}

Notice how the firmware URLs are different! However, the contents of both files is identical as confirmed by checksums reported by the server (the FileMd5 response HTTP header):

$ curl -I http://grih.gree.com/wifiModule/image/10528/145680
HTTP/1.1 200 OK
Server: nginx/1.26.1
Date: Sun, 03 Nov 2024 12:08:45 GMT
Content-Type: application/octet-stream
Content-Length: 145680
Connection: keep-alive
Content-Disposition: attachment; filename="ota_sdkshell-1335624479074045096.bin"
Content-Range: bytes 0-145679/145680
FileMd5: f5ac9d07b5499dac210d550710f7ef2a
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache
Set-Cookie: HttpOnly
Set-Cookie: Secure

and:

$ curl -I http://eu.grih.gree.com/wifiModule/image/10141/145680
HTTP/1.1 200 OK
Date: Sun, 03 Nov 2024 12:09:19 GMT
Content-Type: application/octet-stream
Content-Length: 145680
Connection: keep-alive
Server: nginx
Content-Disposition: attachment; filename="U-QCOM4004CV3.77.bin-9979849298584095054.bin"
Content-Range: bytes 0-145679/145680
FileMd5: f5ac9d07b5499dac210d550710f7ef2a
supcc: 3324d648008ce504a8a519571dc2aa8e4816e5ae92c53100a3dd9052e9b9165c
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache
Set-Cookie: HttpOnly
Set-Cookie: Secure

and tested locally:

$ md5sum 3.77-eu.bin
f5ac9d07b5499dac210d550710f7ef2a  3.77-eu.bin

$ md5sum 3.77.bin
f5ac9d07b5499dac210d550710f7ef2a  3.77.bin

Having access to these firmware files allows us to do all kinds of interesting things such find diffs between versions and extract string references using GNU binutils. Here are all the strings as text files for each version:

• 3.74 strings
• 3.76 strings
• 3.77 strings
• 3.78 (test version) strings

The most valuable find appears to be the QCOM4004 reference which points to only a few pages on the web, including this documentation for Alibaba Cloud platform and SDK.

It is interesting to see that the firmware codes don’t increase with each version — for example, the same code 362001065736 is used for versions 3.76, 3.77 and the test 3.78. It is also not clear why the difference between 3.74 and 3.77 is so tiny:

It is almost as if 3.77 rolls back 3.76 to 3.74.

Wi-Fi Firmware Update

The update process is initiated by the mobile app which connects to the unit via a jump server that helps with traversing the layers of NAT.

First, it fetches the hid attribute of the current firmware via an encrypted pack request:

{"cols":["Pow","Mod","TemUn","SetTem","TemRec","WdSpd","Tur","Quiet","SwUpDn","SwingLfRig","Air","Blo","Health","SvSt","Lig","StHt","SwhSlp","SlpMod","LigSen","UvcControl","Dmod","Dwet","ModelType","HeatCoolType","AllErr","AppTimer","AIEnSaveDis","hid"],"mac":"UNIT_MAC_ID","t":"status"}

to which the unit responds with encoded:

{"t":"dat","mac":"UNIT_MAC_ID","r":200,"cols":["Pow","Mod","TemUn","SetTem","TemRec","WdSpd","Tur","Quiet","SwUpDn","SwingLfRig","Air","Blo","Health","SvSt","Lig","StHt","SwhSlp","SlpMod","LigSen","Dmod","Dwet","ModelType","HeatCoolType","AllErr","AppTimer","hid"],"dat":[0,4,0,19,0,5,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,32858,0,0,0,"362001065736+U-QCOM4004CV3.76.bin"]}

after which the app does another pack request:

{"cols":["TemsSenOut","TemSen","DwatSen","FaultDisplay","AntiDirectBlow","hid","ElcEn","Slp1L1","Slp1H1","Slp1L2","Slp1H2","Slp1L3","Slp1H3","Slp1L4","Slp1H4","Slp1L5","Slp1H5","Slp1L6","Slp1H6","Slp1L7","Slp1H7","Slp1L8","Slp1H8"],"mac":"UNIT_MAC_ID","t":"status"}

to which the unit responds with:

{"t":"dat","mac":"502cc685f806","r":200,"cols":["TemSen","DwatSen","hid","Slp1L1","Slp1H1","Slp1L2","Slp1H2","Slp1L3","Slp1H3","Slp1L4","Slp1H4","Slp1L5","Slp1H5","Slp1L6","Slp1H6","Slp1L7","Slp1H7","Slp1L8","Slp1H8"],"dat":[51,0,"362001065736+U-QCOM4004CV3.76.bin",160,0,160,0,160,0,160,0,160,0,160,0,160,0,160,0]}

and then finally the app uses the data from the update sever mentioned above to send another encrypted pack payload:

{"t":"upgrade","url":"http://eu.grih.gree.com/wifiModule/image/10141/145680","mac":"UNIT_MAC_ID"}

to which the unit responds with pack that is encrypted with the hard-coded a3K8Bx%2r8Y7#xDh key:

{"t":"ret","r":200,"mac":"502cc685f806"}

Afterwards the app appears to wait for the unit to update itself (for a hardcoded period of time) and to eventually respond with an updated hid value matching the new firmware. However, in my case it never happens even if I send an upgrade request with a different firmware URL.

BMS and COM Manual Connections

There are two additional wire connections that are coming out of the PCB that are left not connected:

• BMS which is potentially a Modbus or CAN connections for Building Management Systems.
• COM-MANUAL which is designated as “Wired Controller (optional)” in the service manual.

There is a lot of potential for gaining full read-write access to the device through these ports but I haven’t gotten to that yet.

Wired Controller XK76

Some of the Gree models support wired controllers or thermostats in addition to the RF remotes. This indoor unit has two unpopulated connectors labeled BMS and (forgot the other one) in addition to the WIFI cable that is connected to the WIFI module.

The BMS connector is attached to the wired controller and it appears to be using some kind of serial protocol (potentially Modbus over RS485 similar to their commercial units) to communicate with the remote controller.

Unfortunately, it isn’t very clear which wired controllers support which indoor units especially because the model numbers don’t appear to be shared between units sold in EU and US, for example. Your best option is to review the service manual for the heat pump and determine the controller model by the picture. I decided to get what appeared to be the most recent version of the wired controllers XK76 and just hoped it would work with my device. And luckily it does!

Important: Make sure to turn off the heat pump completely before connecting the controller or it will return an error code E6 and fail to communicate with the device. I almost thought it just doesn’t work and put it on sale…

And here is the photo of the PCB which appears to have just a single microcontroller and three physical connection ports with matching drivers and a bunch of passives to drive the screen:

And here is a photo of the main controller which appears to be NXP LPC3100 series ARM9:

Outdoor and Indoor Unit Communication

There is no official documentation for the communication protocol used between the indoor and outdoor units. Below are my findings based on reverse-engineering and the insight shared by other enthusiasts after publishing this post.

System Design

All of the heat pump control logic is handled by the outdoor unit while the indoor unit only requests heating or cooling and sends the temperature readings of the indoor heat exchanger as input for the outdoor control board.

The communication between the outdoor and indoor units happens via a DC signal referenced to the AC power ground.

Communication Protocol

I was able to attach an oscilloscope and record the following communication between the outdoor and indoor units. See this thread on Reddit for what others think.

It is using a 0-60V serial signal centered around 30V — the outdoor control board keeps the signal at 30V and the indoor unit pulls it low to 0V to send the data. For replies the outdoor unit pulls the signal high to 60V.

The logic analyser was able to decode the serial signal when set to LSB byte order, 1200 baud rate, 8 data bits, 1 stop bit and even parity.

Based on the functionality of the multifunctional inverter testers mentioned below, it should contain the following data:

• Operation mode (heating, cooling)
• Internal fan speed
• Set temperature
• Bus voltage (AC supply)
• Bus current
• Compressor frequency
• Expansion valve opening
• Module temperature (?)
• Inner ring temperature (?)
• Inner tube temperature (?)
• Outer ring temperature (?)
• Outer tube temperature (?)
• Exhaust temperature
• Cold inlet temperature (?)

The first byte indicates the type of the message (0x31 and 0x32 in the examples above) followed by the actual data bytes closed out by an 8-bit modulo 256 checksum byte. Here are the messages I’ve been able to decode:

Message 0x31 Source

Message 0x31 Reply

Message 0x32 Source

Message 0x32 Reply

There are several other message types that I haven’t yet captured.

Portable and Multifunctional Tester for Inverter A/C

There appear to be several inverter tester tools which support the single wire communication used by multiple brands. The GT2D3AAa model is often referenced as the “new” version of the older model GZJ10D009 but I haven’t been able to confirm that. Importantly, GZJ10D009 is specifically branded by Gree:

And here is the “new” version:

Drain Pan Heater in Cold Climates

The outside unit contains a resistive heater for the drain pan which is turned on and draws constant 100W when the outside temperature falls below 0C (32F) even when the unit is not running or defrosting anything (there might be a setting that controls this but I haven’t been able to find it).

This leads to 2.4kWh of additional energy consumption per day which is unfortunate. Note that the heater is only for the drain pan and not the compressor so there is no reason it should be on for more than the defrost cycle and some time after it.

The compressor compartment and piping are really well insulated:

Notice how the 4WAY valve 220V switch is almost right next to the HEAT connection for the resistive heater so it should be possible to connect a timer relay which keeps the heater running only for 10 or 30 minutes after the defrost cycle.

Forums and Links

• Heat pump builder community on Facebook (in Polish) where people convert air-source mini-split heat pump to heat water for heating.

The last stable release of the library was in late 2019 and the project appears to have been abandoned by the original maintainers as the pull requests are left unmerged and issues unresolved. Having worked on large open source projects I know that this can happen as the priorities change for the original contributors. It would be great if new contributors could be added to the project to keep it going.

Here are my notes on the state of things as I attempt to use the MySensors protocol for wired (!) nodes over the RS485 physical layer to create switches and sensor nodes for my home automation system:

General Notes

• Some controllers don’t have support for many of the internal message types which are used for node registration I_REGISTRATION_REQUEST, finding node parent IDs I_FIND_PARENT, assigning node IDs I_ID_REQUEST, etc. This prevents nodes that expect those features from working with gateways that don’t support these features. For example, here are the message types supported by the Node-RED integration or the supported messages types by the pymysensors library that is also used by the Home Assistant integration.

General Issues

• The version 3 of Arduino core for ESP8266 isn’t compatible with how MySensors tries to inject itself into the setup() and loop() calls, as reported here. There is a pull request to fix this.

RS485 Transport Layer Issues

• The RS485 transport layer doesn’t support using Arduino SoftwareSerial for communicating to the RS485 transceivers. Issue reported here and potentially fixed by my pull request here. This is probably because originally SoftwareSerial wasn’t part of the Arduino core and the project had to pull in optimised versions of similar libraries for Atmel microcontrollers.
• The node ID discovery/assignment is broken over the RS485 transport layer. There is a pull request to fix this.

Alternatives to MySensors

MySensors serial implementation is great because it allows nodes to talk to the network while most of the other protocols require that the communication is initiated by the controller which isn’t very suitable for scenarios such as switching lights and other real-time events.

Here are some alternative protocols for building “multi-master” bus networks using RS485:

• PJON ThroughSerial defines the communication but doesn’t define the message types for standard automation events so you need to define your own layer for this.
• UARTBus which is influenced by KNX but appears to be relatively new.

Do you know of any other protocols that would support this?