Just Nommy - Blog

Deep cleaning of secrets in Gitlab

2026-03-17T00:00:00+00:00

So, we accidentally git commit -a -m "I don't know how to use git"</code>. Or we just missed the fact that after a frantic debugging session, the new commit contain credentials for some particularly important service that shouldn't be there. We're all humans, after all. So now we're going to figure out how to minimize the damage.

Scenario One: Nothing seems wrong yet</h1>
We noticed in time that something went wrong and haven't done git push</code> yet.

Give yourself a gold star for paying attention, edit the file, do git commit --amend</code>, and enjoy peaceful life.

But that's only if the slip-up happened in the very last commit.</p>
If mistake happened several commits ago and we still haven't done git push</code>, there are two more or less good options.</p>

git reset --soft <commit_sha></code>, edit the file, and create a clean commit again.</li>
git rebase -i <commit_sha></code> and enjoy the thrilling process of an interactive rebase.</li>
</ul>
Also there is an alternative route using fixups, but you would need to have them in your workflow pipeline from the beginning.</p>
Scenario Two: Why am I an idiot?</h1>
We didn't notice in time that something went wrong and did git push</code> anyway.</p>
First of all — any credentials that made it into the public must be revoked as quickly as possible</strong>.</p>
Secondly — get ready to get beaten. Maybe even with legs.

To make the beating less intense, do everything from the first case, and then git push --force-with-lease</code>.</p>

Usually, this is where most of the "What to do if I pushed creds to git?" guides end, and where the actual content that I want to share begins.

Highly knowledgeable people know that Git has a reflog, and a rewritten commit still stays on the disk, available for recovery. 

And people who make Gitlab know this too, which is why Gitlab periodically runs housekeeping tasks that clean these dangling commits.</p>
To avoid waiting for the janitor to sweep up after you, you can clear the trash in Settings > General > Advanced > Prune unreachable objects</code>.

However, there are cases where this button, despite its dangerous red color, doesn't wipe the dangling commit.

You can check this by trying to open the commit with a direct link. Something like gitlab.example.com/group/project/-/commit/46a9d30f7a7d86adf34299367b0be7ffd0700eb60b079f3cad246c57409bd471</code></p>
Does it show 404? Everything is fine (relatively). But sometimes it shows the old code, and here they are, our creds in plain text again.</p>
Scenario Three: Oh God, why?</h1>
Here we should take a detour and talk about things that aren't in Git, but are in Gitlab. CI/CD and Merge Requests.

Somehow we can see the list of commits, diffs, and all of that in the MR.

And it doesn't go anywhere. Even when the branch is deleted, the MR is closed, and everyone has already forgotten about it.</p>
It's especially "pleasant" to find out when a repository has existed for several years and someone once left an API key in a separate branch, in one of the very first MRs.

Bonus points if repository was inherited and the account access was lost five years ago, and SOC 2 audit is right around the corner.</p>
And this is exactly the scenario we're going to talk about now. Specifically in the context of self-hosted Gitlab, because no one is giving us root on the cloud.</p>
Also, a small disclaimer: this applies to Gitlab 18.6.2, and I'm not the only one annoyed by the keep-around mechanism, so everything might change in the future.</p>
Cleaning up the main history</h2>
MAKE A BACKUP!!!</strong>

Just like this in caps with three exclamation marks. Losing important data while rewriting history is a very real possibility, and you'd better have a recovery point.</p>
Next, we need to run a scanner of our choice and record the full hashes of the commits that contained the creds.

Just because it's convenient, and running a scanner each time we did something is not a particularly fast process.</p>
And after that, you can run BFG</a>, git-filter-repo</a>, or some other tool to purge unwanted strings from the history. It doesn't really matter which one.</p>
Then git push --force --all</code>, and all of this from the tool's manual.</p>
Finding entities</h2>
Before starting to clean the remote repository, we should track down where these commits are used at all, to not accidentally break the Gitlab UI.</p>
So we do gitlab-rails console</code> and start remembering Ruby.</p>
commit_sha = "</span><target_commit_hash></span>"
</span>
</span># List of pipeline IDs
</span>Ci</span>::</span>Pipeline</span>.where(</span>sha:</span> commit_sha).map(&</span>:id</span>)
</span>
</span># List of MRs
</span>MergeRequestDiffCommit</span>.where(</span>sha:</span> commit_sha).map(&</span>:merge_request_diff</span>).map(&</span>:id</span>).uniq
</span></code></pre>
Not very pretty but easy to debug.</p>
I'm not sure if these things must be deleted, but just to be safe. Who knows where Gitlab can break later.

You can do this through the console, but at this stage, paranoia usually reaches the level "it's better to do this in UI".</p>
Finding the repository</h2>
Before opening the console, you need to go to the UI and find the Project ID. It's in Settings > General > Naming, descriptions, topics > Project ID</code>.</p>
Then return to the console and do:</p>
Project</span>.find(</span>PROJECT_ID</span>).repository.disk_path
</span></code></pre>
This will give us a relative path like @hashed/5d/0d/5d0db47fcc1b04bcf18b2f6d7d2f8d9c40589f3bf329b55baf7084cb553e8da8.git</code>.

It's relative to the storage path, so if you're on NixOS, it's /var/gitlab/state/repositories/</code> by default. For other setups — check the blueprint.</p>
Glue it together and let's go:</p>
cd</span> /var/gitlab/state/repositories/@hashed/5d/0d/5d0db47fcc1b04bcf18b2f6d7d2f8d9c40589f3bf329b55baf7084cb553e8da8.git
</span>
</span># Branches with the commit
</span>git</span> branch</span> --contains </span><commit_sha>
</span>
</span># Tags with the commit
</span>git</span> tag</span> --contains </span><commit_sha>
</span>
</span># Refs with the commit
</span>git</span> for-each-ref</span> --contains </span><commit_sha>
</span></code></pre>
The search in branches and tags must return an empty result. If it's not empty, you missed something and it's time to go back to step one.</p>
But the list of refs from the last command are the very things that prevent Gitlab from properly cleaning up commits. It looks something like this:</p>
d6cb0ea8746201dfb0a9303563bd52e31555541a25fc9e1dbfda8f757a9c92bb    commit  refs/keep-around/d6cb0ea8746201dfb0a9303563bd52e31555541a25fc9e1dbfda8f757a9c92bb
</span>4ef7ba090eb92e6a95f727b73cf2f1979ba83ee6bb63a4dc902790793b9274c6    commit  refs/keep-around/4ef7ba090eb92e6a95f727b73cf2f1979ba83ee6bb63a4dc902790793b9274c6
</span>fd3fa98ec1d67c155f2e9900023460bd4c41f6b87b2344188a4a1b1b51ee6fbf    commit  refs/keep-arount/fd3fa98ec1d67c155f2e9900023460bd4c41f6b87b2344188a4a1b1b51ee6fbf
</span>d602c43e76a1e51e77b9aa441f5250d14b05ce55b213214aa287610b22b8df5a    commit  refs/merge-requests/512/merge
</span>ae2e6f410385c1e78c2be5bb839299b14db296a9048ddb04a5605e035e023816    commit  refs/merge-requests/712/merge
</span></code></pre>
It's logical to assume that refs/merge-requests</code> relate to merge requests, but refs/keep-around</code> is a slightly different story. As far as I understand (and I didn't understand very well), Gitlab creates these refs for CI tasks, but apparently not only for that. Therefore, cleaning them up might break something besides the CI, which we (in theory) cleaned up in the previous step.</p>
So, at your own risk:</p>
git</span> update-ref</span> -d </span><ref_name>
</span></code></pre>
And finally:</p>
git</span> reflog expire</span> --expire</span>=now</span> --all
</span>git</span> gc</span> --aggressive --prune</span>=now
</span></code></pre>
Scenario Four: Hans, get the flammenwerfer!</h1>
git@sweetiebelle in /var/gitlab/state/repositories/52/66/5266a2866c3d458909112a2a85958e690e5b5b10ac3ef8e97b50f195ff145d74.git λ git for-each-ref --contains b682940 | wc -l
</span>6251
</span></code></pre>
FUCK!!!</strong></p>
I'll just create a new one.</p>

Testing "exotic" p2p VPN 2025-09-27T00:00:00+00:00 How did the moose begin</h1> My standard "everyday" solution when it comes to connecting computers into a single network is Wireguard. Wireguard is good, supports p2p, and generally has no downsides. The downsides come from having part of my home infrastructure located in territory controlled by a country that has blocked Wireguard by signatures. This is, of course, utterly disgusting, and what's even more disgusting is that these blocks have long since stopped following any kind of legislation. The result is an incomprehensible black box that can do anything, behave however it wants, and nobody knows how this shaitan-machine even works anymore. So it's time for penetration. Why not obfuscation?</h1> Actually, there are several projects that allow obfuscating Wireguard traffic and punching through firewalls. udp2raw</a>, wstunnel</a> and others handle this excellently. And Amnezia VPN</a> has made their own fork of Wireguard, specifically for breaking through government censorship. But the main problem with obfuscation is the reduction of effective packet MTU. Because we wrap one packet in another packet, and this overhead takes up space. And that's not good. What I want from a VPN</h1> p2p mesh network Wireguard is good, of course, but routing all traffic through one server has consequences. The consequences usually include launching a Mars rover to switch the VPN to another server in case of IP blocking or just because the server started feeling unwell. And routing traffic halfway around the planet just to get access to a machine that's within arm's reach — that's just wrong. </li> Open source and selfhosted In matters like this, relying on a third-party provider is either dangerous or useless. Tailscale, for example, is famous for its geographical blocks, so relying on it is pointless. And since Tailscale doesn't do this on a whim (I hope), there's no guarantee that other services won't do the same. </li> Ideologically correct VPN This point exists here specifically for Headscale and ZeroTier. Creating a crippled open-source product to advertise a commercial one is a vicious practice and I personally don't approve this. </li> Not Wireguard For obvious reasons. Signature-based blocking. </li> Packaged in nixpkgs This one's even more obvious. I'm not going to package a VPN into nix myself. </li> </ul> Test subjects</h1> EasyTier</h2> GitHub</a>, Official site</a> This is probably the simplest way to create a p2p network. So simple that there isn't even a module in nixpkgs to run it. For security, there's only a password in --network-secret</code>, which is used for traffic encryption. To work, it immediately opens TCP, UDP, WG, WS, WSS and whatever Lucifer's IT department cooked up. If one gets blocked, it'll break through via another. Essentially all nodes in the network are identical and you can specify multiple peers for initial connection establishment. You can use either public ones, which can be viewed here</a>, or specify one of your own nodes. It doesn't require any additional configuration. By the way, it has clients for Android, Windows and Mac OS, so it's a good time to dig out those old games you didn't finish in childhood and organize LAN party with friends who aren't very tech-savvy. The main disadvantage is that you can't bind IP addresses to specific machines. And yes, this is a project from China, which might not appeal to some for ideological reasons, but personally I hope it was created by enthusiasts specifically for breaking through the Great Firewall of China. Configuration example</summary> { networking.firewall = { allowedTCPPorts = [ 11010 11011 11012 ]; allowedUDPPorts = [ 11010 11011 11012 ]; }; environment.systemPackages = [ pkgs.easytier ]; systemd.services."easytier" = { enable = true; script = "easytier-core -d --network-name sumeragi --network-secret changeme -p tcp://public.easytier.cn:11010 --dev-name et0 --multi-thread"; serviceConfig = { Restart = "always"; RestartMaxDelaySec = "1m"; RestartSec = "100ms"; RestartSteps = 9; User = "root"; }; wantedBy = [ "multi-user.target" ]; after = [ "network.target" ]; path = with pkgs; [ easytier iproute2 bash ]; }; } </code></pre> </details> Nebula</h2> GitHub</a>, Official site</a> This is a more pompous commercial solution from the creators of Slack. It has elliptic curve encryption, suggests using its own PKI and looks generally reliable. Though the prospect of manually distributing certificates to machines doesn't thrill me. For its operation it requires "lighthouses" that will connect all other nodes. Inside, everything works on Noise Protocol</a>. On the outside it exposes only a single UDP port. Among the nice features there's a firewall and zoning, to build slightly more complex networks than "everyone with everyone." And also Nebula's interface is absolutely shit. Instead of a normal CLI, you need to configure an internal sshd and connect via SSH to localhost. Maybe it's more secure, but it's utterly disgusting. ConfigurationExample</summary> let isLighthouse = if (config.networking.hostName == "lighthouse") then true else false; in { services.nebula.networks.sumeragi = { enable = true; ca = "/etc/nebula/ca.crt"; cert = "/etc/nebula/node.crt"; key = "/etc/nebula/node.key"; isLighthouse = isLighthouse; lighthouses = if (isLighthouse) then [] else [ "10.1.0.1" ]; listen = { host = "0.0.0.0"; port = 4242; }; staticHostMap = { "10.1.0.1" = [ "266.266.266.266:4242" ]; }; settings = if (isLighthouse) then { sshd = { enabled = true; listen = "127.0.0.1:2222"; host_key = "/etc/nebula/id_ed25519"; authorized_users = [ { user = "nommy"; keys = [ "ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" ]; } ]; }; } else { }; firewall = { outbound = [ { port = "any"; proto = "any"; host = "any"; } ]; inbound = [ { port = "any"; proto = "any"; host = "any"; } ]; }; }; networking.firewall.allowedUDPPorts = [ 4242 ]; } </code></pre> </details> Tinc</h2> GitHub</a>, Official site</a> When I found this, my first thought was "The fuck is this?" The project is over 10 years old and is still in an unstable state. The current version is 1.1pre18</code>, released way back in 2021. The last commit to the 1.1</code> branch was over a year ago. It's packaged in Nix as Lucy knows what. How is this even a thing? But actually, Tinc can surprise you quite a bit. Under the hood it uses its own protocol over UDP, elliptic curves and a ton of black magic (which, by the way, is properly documented) that makes it all work. Of course, it still needs a node for initial connection bootstrapping, but there's no special setup required — any node can do it, and afterwards it's all direct node-to-node communication. It has a relatively normal CLI, can show a graph of the entire network, has other tasty features, but really lacks some kind of TUI, or at least ASCII art for rendering that graph. Example of not very good configuration</summary> For obvious reasons, the configuration was assembled in a dendrofecal manner, I strongly advise not copying it as-is, but rewriting it yourself. Yes, interface and route configuration is done through tinc-up</code> and tinc-down</code>. This is the intended way</a> let hostName = config.networking.hostName; in { networking.firewall.allowedTCPPorts = [ 655 ]; networking.firewall.allowedUDPPorts = [ 655 ]; services.tinc = { networks = { sumeragi = { name = hostName; ed25519PrivateKeyFile = "/etc/tinc/sumeragi/ed25519_key.priv"; interfaceType = "tun"; debugLevel = 3; hostSettings = { lighthouse = { settings.Ed25519PublicKey = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; subnets = [ { address = "10.2.0.1/32"; } ]; addresses = [ { address = "266.266.266.266"; port = 655; } ]; }; laptop = { settings.Ed25519PublicKey = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; subnets = [ { address = "10.2.0.2/32"; } ]; }; rpi = { settings.Ed25519PublicKey = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; subnets = [ { address = "10.2.0.3/32"; } ]; }; }; }; }; }; environment.etc = { "tinc/sumeragi/tinc-up".source = pkgs.writeScript "tinc-up-sumeragi" '' #!${pkgs.stdenv.shell} ${pkgs.nettools}/bin/ifconfig $INTERFACE ${(builtins.elemAt config.services.tinc.networks.sumeragi.hostSettings."${hostName}".subnets 0).address} netmask 255.255.255.0 /run/current-system/sw/bin/ip r add 10.2.0.0/24 dev tinc.sumeragi ''; "tinc/sumeragi/tinc-down".source = pkgs.writeScript "tinc-down-sumeragi" '' #!${pkgs.stdenv.shell} ${pkgs.nettools}/bin/ifconfig $INTERFACE down /run/current-system/sw/bin/ip r del 10.2.0.0/24 dev tinc.sumeragi ''; }; } </code></pre> </details> Methodology of measurment</h1> This is actually a huge topic and you could write a whole book about it, but the most important thing is — IPerf lies. Different versions of IPerf show different numbers, use different measurement methodologies by default, have many tuning options that affect results, and sometimes their readings differ significantly from reality. So along with two versions of IPerf, it's worth adding some real-world network usage cases. Internet speeds in both directions are roughly the same for all nodes, so I'll take numbers from the first direction that comes up, since the difference will be within the margin of error. Infrastructure</h2> For realistic measurements I'll use three machines: Home laptop (Laptop) in Spain</li> Intermediate server with public IP (Lighthouse) in Finland</li> Raspberry Pi (RPi) behind the Russian firewall</li> </ul> The mesh network coordinators are hosted on Lighthouse, while speed is measured between Laptop and RPi. Ping</h2> ping -c 300 10.1.0.3</code> We send ICMP packets, wait for the response to arrive, measure the time it took to get the response. Here we can check latency, jittering and the number of lost packets. Latency is the average ping response time. Jittering is how much the response time "wanders" relative to the average. Measured in ms. The number of lost packets is self-explanatory. For more or less stable results, 300 packets should be enough. /dev/zero through SSH</h2> ssh 10.1.0.3 'dd if=/dev/zero bs=128M count=3 2>/dev/null' | dd of=/dev/null status=progress</code> We read three times 128 MB of zeros through SSH, then look at the reading speed. Generally not a bad way to determine data transfer speed inside an SSH tunnel. The main reason for using this test is that through some solutions SSH works so hellishly slow that more than a second can pass between pressing a key and the character appearing on screen, which is completely unacceptable. And sometimes it doesn't work at all. Wget</h2> wget 10.1.0.3:5201/testfile</code> As a test file — the same 384 MB of zeros from /dev/null. As a server I use simple-http-server</a>, setting the number of threads equal to the number of CPU cores (8). Of course, with compression disabled, otherwise megabytes of zeros risk turning into kilobytes of headers. iperf2 and iperf3</h1> Yes, they show orange prices in Africa. Hell knows how to tune this. So we just run them with standard configuration and then normalize the results from megabits to megabytes. Reference values</h2> Measuring exact values for speed, ping and all this stuff that we could use as a baseline is somewhat impossible, since both machines are behind NAT. But since the infrastructure includes a Lighthouse with a public IP, we can run a few tests and fantasize about some results. </th> ICMP packet loss</th> ICMP Latency</th> ICMP Jittering</th> /dev/zero through SSH</th> Wget</th> iperf2</th> iperf3</th></tr></thead> Laptop -> Lighthouse</td> 0%</td> 71.879 ms</td> 1.422 ms</td> 25.5 MB/s</td> 23.3 MB/s</td> 18 MB/s</td> 24.375 MB/s</td></tr> RPi -> Lighthouse</td> 0%</td> 51.872 ms</td> 1.011 ms</td> 9.0 MB/s</td> Timeout</td> 9.963 MB/s</td> 11.112 MB/s</td></tr> </tbody></table> Now we can start fantasizing. Speed between nodes is limited by the slowest link, so we use the minimum values as our reference. Latencies can simply be added together. But what to do with jittering isn't entirely clear. Supposedly you can't add such values, I don't want to recalculate every packet manually, so I'll just take the maximum value. And it's time for the final results. Results</h1> All speeds are normalized in bytes. To convert to bits, multiply by 8. </th> ICMP packet loss</th> ICMP Latency</th> ICMP Jittering</th> /dev/zero through SSH</th> Wget</th> iperf2</th> iperf3</th></tr></thead> Reference</td> 0%</td> 123.751 ms</td> 1.422 ms</td> 9.0 MB/s</td> Timeout</td> 9.963 MB/s</td> 11.112 MB/s</td></tr> Wireguard + udp2raw</td> 49.6%</td> 108.806 ms</td> 3.724 ms</td> Timeout</td> Timeout</td> 3.175 KB/s</td> 0.00 B/s</td></tr> EasyTier</td> 0%</td> 153.163 ms</td> 36.290 ms</td> 2.7 MB/s</td> 8.09 MB/s</td> 6.15 KB/s</td> 0.00 B/s</td></tr> Nebula</td> 0%</td> 122.173 ms</td> 15.054 ms</td> 2.7 MB/s</td> 3.40 MB/s</td> 5.975 KB/s</td> 0.00 B/s</td></tr> Tinc</td> 2.3%</td> 115.065 ms</td> 3.393 ms</td> 14.7 MB/s</td> 5.16 MB/s</td> 6.488 MB/s</td> 4.175 MB/s</td></tr> </tbody></table> Egyptian power of those iperfs... Tinc, as I already said, is very capable of surprising. EasyTier can be forgiven for such overheads, it's ad-hoc after all and generally "be thankful there's any connection at all." But Nebula frankly disappointed me. Here I really want to crack a joke about the Slack client on Electron, but... I expected better, seriously. So if you want to get something like this — Tinc is the best choice performance-wise. I'll keep all of them at once for myself. I don't like launching Mars rovers unnecessarily. That's all, folks. And it all started when mom asked me to fix the robot vacuum... Connecting Tasmota to Home Assistant and other weird noname devices 2025-03-12T00:00:00+00:00 What problem do we have?</h1> One day, a very naughty person decided that wiring the whole house (including the electric stove) on a single 2.5mm² cable was a very good idea. Fire safety regulations and automatic fuses didn't agree with this fact. So turning on the boiler and the oven at the same time causes a complete power outage in a single apartment, which frustrates me a lot. And going to unplug the boiler every time when I want to cook something is definitely not the thing that I want to do. And because of this we are going to make a smart home so that I can control the boiler at least from my smartphone. Las Planchas</h1> A quick search on Amazon gave me SONOFF Zigbee Bridge 3.0 Gateway Hub, ,Soporte de Protocolo Dual,WiFi, Compatible con Dispositivos Zigbee Pro, Alexa & Google</code>, also known as SONOFF ZBBridge-P</code> only for 35€. A quick googling revealed that there's some kind of opensource firmware for it. “I should buy it”, I thought. At the same time to the cart went ZigBee Enchufe Inteligente Alexa 16A, 3680W Smart Plug con Monitor de Energía, Enchufe Temporizador con Control Remoto, Control por Voz y Funciones de Temporización, apoyo Alexa & Google Home</code> (4 pieces for 45€), which later turned out to be Tuya TS011F</code>. And also for the change was thrown in Garza Smart - Bombilla LED Zigbee Estándar A60, 11W (equivale a 75W de incandescencia), E27, Requiere Puente/Bridge, RGB + CCT, Intensidad regulable, Programable, Control por voz y app, Alexa/Google</code>, which for some reason pretended to be Tuya TZ3210</code>. What exactly this TZ3210</code> means, I have not been able to establish. Various sources say that it is either a switch, a humidity and temperature sensor, or as I can guess an RGB lightbulb. Curing the bridge from the cloud</h1> Since it's mauvais to dump all smart home data to some obscure cloud, the first thing to do is to put a new firmware to the bridge. I followed this very detailed instruction How to flash Tasmota on Sonoff ZB Bridge Pro</a>. The only thing that caused some confusion is the GPIO00</code> pin. It should be pulled up to GND</code> during the startup to put this la plancha into UART mode. I had some difficult time trying to understand what went wrong, so you can track the successfulness of this operation with elegant screen /dev/ttyACM0 115200</code> and then look at the startup logs. I won't describe the complete flashing process, as it's perfectly described in the link above, but... Fig. 1. How to suddenly get a heart attack </figcaption> </figure> Fortunately, this bug was fixed a long time ago and someone just didn't update their Flipper's firmware for a long time. Setting up secured MQTT</h1> Despite the fact that ESP32 already has Wireguard implementation, Tasmota still doesn't support it, so I have to put MQTT server outside and configure SSL on it, so that random vanderers don't have fun with my sockets. And with a slight nixos-rebuild switch ...</code>, we will put Mosquitto on an external server with a static IP users.users.mosquitto.extraGroups = [ "nginx" ]; services.mosquitto = { enable = true; listeners = [ { address = "123.456.789.123"; port = 1883; users = { tasmota = { acl = [ "readwrite tasmota/#" ]; password = "changeme"; }; }; settings = { "allow_anonymous" = false; "require_certificate" = false; "cafile" = "/var/lib/acme/mqtt.example.com/fullchain.pem"; "certfile" = "/var/lib/acme/mqtt.example.com/cert.pem"; "keyfile" = "/var/lib/acme/mqtt.example.com/key.pem"; "tls_version" = "tlsv1.2"; }; } { address = "10.20.0.1"; port = 1883; users = { hass = { acl = [ "readwrite #" ]; password = "changeme"; }; }; } ]; }; </code></pre> The mosquitto</code> user was sent to the nginx</code> group just to be able to use Let's Encrypt certificates. I'm also using a system with two listeners. One is SSL protected, restricted to the core and looks outside, and the second one is in the internal VPN network, allowing to connect other clients, but about this later Also worth noting are the lines “require_certificate” = false;</code> and “tls_version” = “tlsv1.2</code>. First line disables TLS authorization, leaving the password one, and the second enables traffic encryption. Without the first one Tasmota cannot connect to MQTT, and without the second one Mosquitto will ignore all configured certificates and will work in unencrypted mode. On the Home Assistant side I have configured a bridge that will take all messages from the external MQTT and put them into the main MQTT. Just because I already had MQTT configured for local stuff and didn't want to touch it. services.mosquitto = { enable = true; listeners = [ ... ]; bridges = { "external2internal" = { addresses = [ { address = "10.20.0.1"; port = 1883; } ]; topics = [ "tasmota/# in" "tasmota/cmnd/# out" ]; settings = { remote_username = "hass"; remote_password = "changeme"; }; }; }; }; </code></pre> With this topics setup, I don't pull anything extra inside, and only direct commands for Tasmota can go outside. But of course this can be skipped if there is only one MQTT. AND DON'T FORGET TO OPEN THE PORT ON YOUR FIREWALL! Connecting the bridge to the secured MQTT</h1> It's already obvious and self-explanatory here, except for a couple things. Be sure to click the MQTT TLS</code> checkbox so that it will be able to connect to our secure Mosquitto. And in the Full Topic</code> field you should add tasmota/</code> in the beginning, so that all messages are neatly piled into one group and we won't write each bridge address into ACL. After pairing devices with the bridge (Just press the Zigbee Permit Join</code> button and turn on las planchas), it is not unreasonable to check if everything is working properly and the messages from the devices are getting to MQTT. Subscribe to tasmota/#</code> and wait for something to be appeared there. If nothing appeared for a long time, go back to the beginning and think about what can went wrong. Repeat until you are completely satisfied. Exploring the devices</h1> Fig. 2. SONOFF ZB Bridge-P </figcaption> </figure> This is where the hell and Wisconsin begins. The thing is that Tasmota can't do auto discovery. To be more precise, it can, but only for Tasmota running end devices and through their own plugin. And since we have a bridge, two facts follow from this: We don't need a plugin, raw MQTT is more than enough.</li> No one will help us.</li> </ol> But first we should arm ourselves with the console on the bridge itself and see what we have there. Fig. 3. Green and scary </figcaption> </figure> We go to Tools > Console</code> in the bridge web interface and start poking everything around with a stick. The full list of commands can be found here: Tasmota Commands</a>, but now we are only interested in the Zigbee</a> part. To be more precise, the commands ZbInfo</code>, ZbName</code> and ZbSend</code>. ZbInfo</h3> By typing ZbInfo</code> into the terminal, you can get (mostly) all information about the connected devices. The result is usually a mess like this 20:03:18.524 MQT: tasmota/tele/tasmota_6A65EC/7E20/SENSOR = {"ZbInfo":{"0x7E20":{"Device":"0x7E20","Name":"main_light_0","IEEEAddr":"0xA4C138E23EE90340","ModelId":"TS0505B","Manufacturer":"_TZ3210_4sku4dkz","Endpoints":[1,242],"Config":["O01","~01.1","L01"],"Power":1,"Dimmer":254,"Hue":0,"Sat":0,"X":24218,"Y":15601,"CT":499,"ColorMode":1,"RGB":"FFFFFF","RGBb":"FFFFFF","Reachable":true,"LastSeen":4,"LastSeenEpoch":1741806194,"LinkQuality":91}}} 20:03:18.536 MQT: tasmota/tele/tasmota_6A65EC/CD47/SENSOR = {"ZbInfo":{"0xCD47":{"Device":"0xCD47","Name":"aquarium_light","IEEEAddr":"0xA4C1382214F48A12","Endpoints":[1],"Config":["P01","O01"],"RMSVoltage":226,"ActivePower":10,"Power":1,"Reachable":true,"LastSeen":6,"LastSeenEpoch":1741806192,"LinkQuality":185}}} 20:03:18.548 MQT: tasmota/tele/tasmota_6A65EC/9AD4/SENSOR = {"ZbInfo":{"0x9AD4":{"Device":"0x9AD4","Name":"boiler_switch","IEEEAddr":"0xA4C13877C8106300","ModelId":"TS011F","Manufacturer":"_TZ3000_cehuw1lw","Endpoints":[1],"Config":["P01","O01"],"RMSVoltage":226,"ActivePower":0,"Power":0,"Reachable":true,"LastSeen":73,"LastSeenEpoch":1741806125,"LinkQuality":98}}} 20:03:18.563 MQT: tasmota/tele/tasmota_6A65EC/3B30/SENSOR = {"ZbInfo":{"0x3B30":{"Device":"0x3B30","Name":"main_light_1","IEEEAddr":"0xA4C1381A825F2ADE","ModelId":"TS0505B","Manufacturer":"_TZ3210_4sku4dkz","Endpoints":[1,242],"Config":["~01.1","O01","L01"],"Power":0,"Dimmer":254,"Hue":0,"Sat":254,"X":38449,"Y":21476,"CT":283,"ColorMode":2,"RGB":"FF0000","RGBb":"FF0000","Reachable":true,"LastSeen":136,"LastSeenEpoch":1741806062,"LinkQuality":163}}} 20:03:18.578 MQT: tasmota/tele/tasmota_6A65EC/898A/SENSOR = {"ZbInfo":{"0x898A":{"Device":"0x898A","Name":"studio_light","IEEEAddr":"0xA4C1389F99E433CE","ModelId":"TS0505B","Manufacturer":"_TZ3210_4sku4dkz","Endpoints":[1,242],"Config":["O01","~01.1","L01"],"Power":0,"Dimmer":42,"Hue":0,"Sat":254,"X":13578,"Y":14165,"CT":283,"ColorMode":2,"RGB":"FF0000","RGBb":"2A0000","Reachable":true,"LastSeen":150,"LastSeenEpoch":1741806048,"LinkQuality":65}}} </code></pre> If you sit and read carefully, you can find: Device</code> - Short device address (0xAAAA). Usually used to refer to the device.</li> ModelId</code> and Manufacturer</code> - The actual description of the model. If you look at the beginning of the article, you can see that cheap Chinese Tuya can be found under various pathos brands, but this is the place where the truth is revealed.</li> Dimmer</code>, Hue</code>, Sat</code>, X</code>, Y</code> and all other hardware-specific parameters that this device will send to MQTT.</li> </ul> The last ones will be especially useful for us, but we will talk about it later. ZbName</h3> Now it's about time to give all devices readable names so that we don't get confused later. ZbName short_address,name</code> will help us with this. The name, that we will give tp the device will pop up in every event and we can do something using it, but the main goal is just not to get confused with different addresses. ZbSend</h3> And now we can actively poke the device with the stick, because ZbSend</code> allows us to send different messages and see how the device reacts. We can, for example, put a stick in the smart socket. ZbSend { “device”: “0x9AD4”, “send”: { “power”: “ON“ }}</code> will turn the smart socket on, and ZbSend {”device": ‘0x9AD4’, ‘send’: { “Power”: “OFF” }}</code> will turn it off, correspondingly. How we know, that we need to send message { “Power”: “ON” }</code>? It's the most interesting question. And the answer to it would be "just guessed", but that's not actually true. Let's take a closer look at the JSON from the output of the ZbInfo 0x9AD4</code> command { "ZbInfo": { "0x9AD4": { "Device": "0x9AD4", "Name": "boiler_switch", "IEEEAddr": "0xA4C13877C8106300", "ModelId": "TS011F", "Manufacturer": "_TZ3000_cehuw1lw", "Endpoints": [ 1 ], "Config": [ "P01", "O01" ], "RMSVoltage": 226, "ActivePower": 0, "Power": 0, "Reachable": true, "LastSeen": 73, "LastSeenEpoch": 1741806125, "LinkQuality": 98 } } } </code></pre> Among other things, here we can see the Power</code> field with the value 0</code>, i.e. “Off”. And the trick with more readable ON</code> and OFF</code> I just found up in the Internets. And if you look at the JSON from the lightbulb, there's more interesting stuff here. { "ZbInfo": { "0x7E20": { "Device": "0x7E20", "Name": "main_light_0", "IEEEAddr": "0xA4C138E23EE90340", "ModelId": "TS0505B", "Manufacturer": "_TZ3210_4sku4dkz", "Endpoints": [ 1, 242 ], "Config": [ "O01", "~01.1", "L01" ], "Power": 1, "Dimmer": 254, "Hue": 0, "Sat": 0, "X": 24218, "Y": 15601, "CT": 499, "ColorMode": 1, "RGB": "FFFFFF", "RGBb": "FFFFFF", "Reachable": true, "LastSeen": 4, "LastSeenEpoch": 1741806194, "LinkQuality": 91 } } } </code></pre> In addition to Power</code> we also have Dimmer</code>, Hue</code>, Sat</code>, X</code>, Y</code>, CT</code>, ColorMode</code>, RGB</code> and RGBb</code>. Spoiler: not all of these can be changed in the same way, but we have a general direction for digging for the API. One more thing to mention (Backlog)</h3> Ah, yes. There's one more thing to mention. Even though we can do ZbSend { “device”: “0x7E20”, “send”: { “hue”: “128” }}</code>, We can't do ZbSend { “device”: “0x7E20”, “send”: { “hue”: “128”, “sat”: “254” }}</code> because we can change only one parameter per request. As a quick workaround for the problem, you can use Backlog</a>, the built-in language... In short, you can just pass several commands in a row to this device, and then they will be executed sequentially. And as a result, our command will look something like this: Backlog ZbSend { “device”: “0x7E20”, “send”: { “Hue”: “128” }}; ZbSend { “device”: “0x7E20”, “send”: { “sat”: “254” }} </code></pre> Good for quick hacks, but in practice it turns out that sending two commands is not the fastest process and instead you can sometimes find “undocumented” commands. In case of this lightbulb there is a command Color</code> which allows to set X</code> and Y</code> values at the same time, but about this again a little later. Home Assistant</h1> Fig. 4. Home Assistant </figcaption> </figure> Remember when I said that Tasmota doesn't know how to do auto discovery? Well, here it is. We're gonna write the configs. By hands. And may Nix and its ability to write functions for autogenerating YAML help us. MQTT Topics</h2> Essentially we only need two topics: tasmota/tele/tasmota_${gw_addr}/SENSOR</code> to read telemetry and tasmota/cmnd/tasmota_${gw_addr}/ZbSend</code> to send commands. Perhaps a third tasmota/cmnd/tasmota_${gw_addr}/Backlog</code> for executing Backlog commands. Yes, any of the commands from the list</a> can be called via MQTT by sending it to the appropriate topic, where the last part is the name of the command. We will send JSON's and parse them too. So let's get to practice. Switches and sensors</h3> Fig. 5. Switches with sensors </figcaption> </figure> Let's remember out JSON from the socket { "ZbInfo": { "0x9AD4": { "Device": "0x9AD4", "Name": "boiler_switch", "IEEEAddr": "0xA4C13877C8106300", "ModelId": "TS011F", "Manufacturer": "_TZ3000_cehuw1lw", "Endpoints": [ 1 ], "Config": [ "P01", "O01" ], "RMSVoltage": 226, "ActivePower": 0, "Power": 0, "Reachable": true, "LastSeen": 73, "LastSeenEpoch": 1741806125, "LinkQuality": 98 } } } </code></pre> In addition to Power</code>, which controls turning the socket on and off, we also have RMSVoltage</code> (measures the amount of volts) and ActivePower</code> (measures the amount of ampers). So let's go to writing the config: mqtt = { switch = [ { unique_id = "boiler_outlet_switch"; name = "Boiler Outlet Switch"; state_topic = "tasmota/tele/tasmota_6A65EC/SENSOR"; value_template = "{{ value_json.ZbReceived['0x9AD4'].Power }}"; command_topic = "tasmota/cmnd/tasmota_6A65EC/ZbSend"; payload_on = ''{"device":"0x9AD4","send":{"Power": "ON"}}''; payload_off = ''{"device":"0x9AD4","send":{"Power": "OFF"}}''; retain = true; device_class = "outlet"; device = { name = "Boiler Outlet"; model = "TS011F"; manufacturer = "Tuya"; identifiers = [ "0x9AD4" ]; }; } ]; }; </code></pre> A full explanation of each parameter can be found in the corresponding documentation</a>, so I'll run through the important stuff: state_topic</code> and command_topic</code> are those topics for reading the state and sending commands. Usually right after receiving a command a device will throw a message with the changed state, which allows you not to rely on the “optimistic” strategy of Home Assistant and, albeit with a slight delay, but to know the actual state of the hardware. value_template</code> - a template for pulling a parameter value from JSON. Since JSON's are generated by the getway itself, you can copy the template from the example and only change the last part. Yes, I copied that from someone else too. payload_on</code> and payload_off</code> - everything is clear here too, but later we will learn how to template them. Of course, it will be unpleasant to write such a mess for each socket, so let's wrap everything in a function: ts011f_switch = id: name: short_addr: gw_addr: { unique_id = id; name = "${name} Switch"; state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; value_template = "{{ value_json.ZbReceived['${short_addr'].Power }}"; command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; payload_on = ''{"device":"${short_addr}","send":{"Power": "ON"}}''; payload_off = ''{"device":"${short_addr}","send":{"Power": "OFF"}}''; retain = true; device_class = "outlet"; device = { name = name; model = "TS011F"; manufacturer = "Tuya"; identifiers = [ short_addr ]; }; }; </code></pre> Wait, we also have sensors. So, we are writing functions for them too: ts011f_sensors = id: name: short_addr: gw_addr: [ { unique_id = "${id}_power"; name = "${name} Power"; state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; value_template = "{{ value_json.ZbReceived['${short_addr}'].ActivePower }}"; unit_of_measurement = "W"; device = { identifiers = [ "${short_addr}" ]; }; } { unique_id = "${id}_voltage"; name = "${name} Voltage"; state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; value_template = "{{ value_json.ZbReceived['${short_addr}'].RMSVoltage }}"; unit_of_measurement = "V"; device = { identifiers = [ "${short_addr}" ]; }; } ]; </code></pre> As a result, our config immediately starts to look nicer and we can add as many outlets as we have (and I have four of them): mqtt = { switch = [ (ts011f_switch "boiler_switch" "Boiler" "0x9AD4" "6A65EC") ]; sensor = (ts011f_sensors "boiler" "Boiler" "0x9AD4" "6A65EC") }; </code></pre> Lightbulbs</h2> Fig. 6. Lightbulb </figcaption> </figure> Now for the hard part. Lightbulbs. Lightbulbs are completely cursed devices. They look simple enough, but that simplicity is deceptive and lures the unfortunate people to the cliffs of insanity. Cliffs of insanity</h3> Let's take another look at JSON { "ZbInfo": { "0x7E20": { "Device": "0x7E20", "Name": "main_light_0", "IEEEAddr": "0xA4C138E23EE90340", "ModelId": "TS0505B", "Manufacturer": "_TZ3210_4sku4dkz", "Endpoints": [ 1, 242 ], "Config": [ "O01", "~01.1", "L01" ], "Power": 1, "Dimmer": 254, "Hue": 0, "Sat": 0, "X": 24218, "Y": 15601, "CT": 499, "ColorMode": 1, "RGB": "FFFFFF", "RGBb": "FFFFFF", "Reachable": true, "LastSeen": 4, "LastSeenEpoch": 1741806194, "LinkQuality": 91 } } } </code></pre> This particular bulb can change power, temperature and color. In fact, it doesn't do this simultaneously, but rather switches between modes, that we can see in ColorMode</code> parameter. However, we need this information only for research and debugging. The first mode is a bright glow at full power with variable temperature. The parameters Dimmer</code> and CT</code> (Color Temperature) are responsible for this, correspondingly. The second and third modes are RGB modes. They differ only in the way of color selection: Hue\Sat or X\Y. It is logical to assume that we want to change the parameters Hue</code> and Sat</code> or X</code> and Y</code>, but here comes a question that is not the most obvious from the first time. What exactly are the values that this parameters can take? On the one hand, we can rely on common sense. Hue is a circle, so the range of values should be 0...360. And the XY coordinate system uses range 0.0 to 1.0. But life is always more unpredictable than the theory. And we are dealing with a lightbulb that is both a switch and a humidity sensor. So the only adequate way to know the real range of values is to poke them with a stick and see what happens. For example, Dimmer</code> has a value range of 0...254. But when we try to set it to 255, the bulb returns null from the telemetry topic, which is very strange, because it is obviously an 8-bit variable. My attempts to find the values of Hue</code> and Sat</code> did not lead to anything constructive, but X</code> and Y</code> simply refused to accept the command when I tried to put into them a value not in the range of 0..65279. Why not 0..65535, as someone suggested on the Internets, thinking that this is a 16-bit variable? Well, that's... Because! Just don't ask. Compiling everything into Home Assistant</h3> As a result, we have gathered all the knowledge, gained during the process of poking things with a stick, and now we are ready to write the function. tz3210_lamp = id: name: short_addr: gw_addr: { unique_id = id; name = name; command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; payload_on = ''{"device": "${short_addr}", "send": {"Power": "ON"}}''; payload_off = ''{"device": "${short_addr}", "send": {"Power": "OFF"}}''; brightness_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; brightness_command_template = ''{"device": "${short_addr}", "send": { "Dimmer": "{{ value - 1 }}" }}''; brightness_state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; brightness_value_template = "{{ value_json.ZbReceived['${short_addr}'].Dimmer }}"; xy_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; xy_command_template = ''{"Device": "${short_addr}", "send":{ "Color": "{{ x * 65279 }},{{ y * 65279 }}"}}''; xy_state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; xy_value_template = "{{ value_json.ZbReceived['${short_addr}'].X / 65279 }},{{ value_json.ZbReceived['${short_addr}'].Y / 65279 }}"; color_temp_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; color_temp_command_template = ''{"device": "${short_addr}", "send": { "CT": "{{ value - 1 }}" }}''; color_temp_state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; color_temp_value_template = "{{ value_json.ZbReceived['${short_addr}'].CT }}"; device = { name = "RGB Lamp"; model = "TZ3210"; manufacturer = "Tuya"; identifiers = [ short_addr ]; }; } </code></pre> This function is just a beautiful collection of hacks to make the things somehow work. Let's go in order According to Home Assistant, Dimmer</code> should take values 0...255, but as we already know, the maximum value there is 254, so just subtract one. Anyway you can't set a power in HA interface lower than 3%. Same thing for CT</code>. According to the same default Home Assistant settings, X</code> and Y</code> take values from 0 to 1.0, so the conversion back and forth is done simply by multiplication\division by the maximum possible value. Besides, Color</code> function is used here in xy_command_template</code>, which allows to pass X</code> and Y</code> values in one command, which was accidentally found in the discussion about some other device I don't remember where. If this function wasn't there, the config would look something like this: xy_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/Backlog"; xy_command_template = ''ZbSend {"Device": "${short_addr}", "send":{ "X": "{{ x * 65279 }}"}}; ZbSend {"Device": "${short_addr}", "send":{ "Y": "{{ y * 65279 }}"}}''; </code></pre> This is the end</h1> And on that note, my adventures are finally over. The lights are lighting, the boiler is boiling and even the aquarium light has its own remote control. I really didn't like the smart home, the process was just too stupid for production use. And the fucked up overpricings upset me even more. I'd better go to AliExpress to buy other hardware, at least there they can clearly write the model and manufacturer. Fig. 7. Bisexual lighting </figcaption> </figure>

Just Nommy - Blog

Deep cleaning of secrets in Gitlab

Testing "exotic" p2p VPN

Connecting Tasmota to Home Assistant and other weird noname devices

MQTT Topics</h2> Essentially we only need two topics: tasmota/tele/tasmota_${gw_addr}/SENSOR</code> to read telemetry and tasmota/cmnd/tasmota_${gw_addr}/ZbSend</code> to send commands. Perhaps a third tasmota/cmnd/tasmota_${gw_addr}/Backlog</code> for executing Backlog commands.</p>