content imprive

smarthome/homematic-mqtt/index.njk

@@ -29,11 +29,39 @@ sensor state changes to MQTT.</p>
 <li>Grafana reads from InfluxDB for the temperature/humidity dashboards.</li>
 </ol>
 
+<h2>The Home Assistant automations</h2>
+<p>Each room has its own automation in Home Assistant that listens for
+state changes on the corresponding HomematicIP thermostat entity. When
+the temperature or humidity changes, the automation publishes the new
+values to MQTT topics like <code>homematic/livingroom/temperature</code>
+and <code>homematic/livingroom/humidity</code>. The automations are
+simple YAML configurations, not custom code, which makes them easy to
+maintain and debug.</p>
+
+<h2>The InfluxDB writer</h2>
+<p>A small .NET background service runs as a Docker container and
+subscribes to all <code>homematic/+/+</code> MQTT topics. When a
+message arrives, it parses the room name and measurement type from the
+topic, converts the value to a float, and writes it into InfluxDB with
+appropriate tags. The service handles connection drops and reconnection
+automatically, and logs all write operations for debugging.</p>
+
+<h2>Dashboard integration</h2>
+<p>Grafana queries InfluxDB using Flux to display real-time temperature
+and humidity charts for each room. The dashboards show current values,
+24-hour trends, and historical averages. This data is also used in the
+home dashboard to display room temperatures alongside other sensor data
+like air quality and power consumption.</p>
+
 <h2>Why this is worth documenting</h2>
 <ul>
 <li>No extra Docker container or unmaintained library dependency.</li>
 <li>Cloud-API changes are absorbed by Home Assistant's own maintainers, not by custom code.</li>
 <li>The MQTT bridge is just configuration (automations), not a service that needs its own uptime monitoring.</li>
+<li>The entire chain is observable: MQTT topics can be monitored with any MQTT client, InfluxDB has its own explorer, and Grafana dashboards show the data flow end-to-end.</li>
 </ul>
 
+<h2>Lessons learned</h2>
+<p>The original approach of running a dedicated exporter was more "architecturally pure" but fragile in practice. When the Python library stopped working, the entire sensor pipeline broke. The Home Assistant approach is more robust because it leverages a well-maintained integration and uses MQTT as a simple, well-understood transport layer. The lesson: for home automation, prefer integrations that are actively maintained over custom code that needs constant attention.</p>
+
 </div>

smarthome/tasmota-energy/index.njk

@@ -10,7 +10,9 @@ layout: base.njk
 
 <p>Power monitoring across the flat runs on a mix of Tasmota-flashed smart
 plugs, tracking accumulated kWh per device and feeding daily usage
-figures into the home dashboard.</p>
+figures into the home dashboard. The setup uses 8 Tasmota-enabled devices
+covering kitchen appliances, office equipment, entertainment systems,
+and LED matrix displays.</p>
 
 <h2>What's metered</h2>
 <table>
@@ -35,11 +37,30 @@ well-documented community process. It occasionally fails on the first
 attempt due to a transient Wi-Fi handshake issue — retrying resolves it
 without any special handling.</p>
 
+<h2>How the data flows</h2>
+<p>Each Tasmota plug publishes its power readings to MQTT via the
+ Mosquitto broker running on the Docker host. A small subscription
+service picks up the per-device topics and writes the values into
+InfluxDB 2.x, tagged by device name, room, and measurement type
+(power, energy, voltage). The home dashboard then queries InfluxDB
+via Flux to display real-time and historical usage charts.</p>
+
 <h2>What this data is used for</h2>
 <ul>
 <li>Spotting appliances with unexpectedly high standby draw.</li>
 <li>Sanity-checking that "turned off" devices are actually drawing near-zero power.</li>
 <li>Feeding the home dashboard's live power figures alongside the climate sensors.</li>
+<li>Tracking long-term energy trends to identify efficiency improvements.</li>
+<li>Alerting when a device draws significantly more than its baseline (e.g., a failing appliance).</li>
 </ul>
 
+<h2>Why Tasmota over alternatives</h2>
+<p>Tasmota was chosen over alternatives like ESPHome or Tuya firmware for
+several reasons. The local-only control means no cloud dependency — the
+plugs work even if the internet is down. The MQTT integration is mature
+and well-documented. The energy monitoring sensors are accurate enough
+for home use (typically within 5% of a dedicated energy meter). And the
+firmware supports a wide range of hardware, making it easy to find
+compatible plugs at reasonable prices.</p>
+
 </div>