Starting to think that using #OpenHAB for my "smarthome" for my case is kinda overkill…

I have some sensors (temperature and humidity), some reed switches for windows and possibly I'll add thermostats for heating batteries (because here, even with 0°C outside, the central heating works for all the money and it is impossible to sleep and work without all opened windows). All things are using #ZigBee so my #server uses some ZigBee coordinator dongle and #zigbee2mqtt with some MQTT broker inside. I already able to read all necessary data from sensors by reading the right MQTT topics.

And the OpenHAB just communicates with my MQTT broker and displays some nice widgets on the Web UI. This is cool, because I don't need to think about how to work with MQTT and how to output data — all somehow works "by magic".

But the price is very big. The OpenHAB eats near 600 MB of RAM and swaps a lot (near 1 GB for now). It is a largest memory consuming service in my server, which has only 2 GB of RAM (and a RAM prices already increased here  ). And also it's sandbox takes near 3.5 GB of SSD space.

So, do I really need not to think about how it all works under the hood while wearing out my SSD or get some services OOMed if I disable swap and start e.g. using BorgBackup? Looks like the game is not worth the candle. I can literally pick #EclipseMosquitto #C library, unwrap some memories about how to use CGI and get the same nice page with sensors data and some logic inside. But with a waaaay less memory footprint and with possibility to open this page from #Dillo  

#SelfHosting

Excellent! Another step in my old-server-setup migration plan done. I'm switching from a Conbee II #zigbee stick to a SMLight SLZB-06M ethernet adapter (POE) to manage all of my smart devices. The old stack is #zigbee2mqtt / #EclipseMosquitto on Proxmox, and I'm moving to the same but on my new #k3s cluster.

I'm already impressed with the SMLight and its included management interface. It was quite straightforward to add it to Z2M as well. I've got a whole bunch of new devices to add to it tomorrow (alongside a house full of legacy ones). Wish me luck! 😅

#homelab #selfhosted #smarthome

#CHERI all the way down (or up)!

Or: The worlds most overengineered (but secure!) lightswitch!

The #EclipseMosquitto MQTT server, running as a pure-capability #CheriBSD pure-capability binary on a Morello system, acting as the server component for an IoT system. Pure-capability programs run with hardware-enforced memory safety, with every pointer represented with a CHERI capability so even single-byte out-of-bounds errors will trap. The kernel is also built in this mode.

I accidentally booted with the wrong kernel, so we don't have temporal safety on the server yet.

On the client, we have a #CHERIoT system, where everything has spatial and temporal memory safety. This connects to the CheriBSD server and sends the state of the switches via MQTT and sets the LEDs on the board based on subscriptions to MQTT events. This all happens over TLS 1.2 with ECDSA.

The network stack is compartmentalised. This demo includes 9 isolated compartments as well as several shared libraries, on a board with 256 KiB of (code + data) RAM, including a memory-safe shared heap.