Building a kiosk for Home Assistant from scrap parts

It is great to have automation in the house providing increments of comfort such as eliminating manual tasks like cleaning the floor, or to aid in managing the energy consumption by turning off lights and appliances which are not in use, or in the safety side, by providing intrusion detection or monitoring the presence of gas leaks or other hazards, and executing the adequate actions.

Tasmota-based multi-channel air quality sensor station

The sense of smell is an amazing function in vertebrate animals. Even the human nose, which is not particularly notable in comparison with other animals, is fascinating in its sensitivity to trace amounts of a large variety of substances. It has a level of selectivity and capability of distinguishing between different kinds of smells, which is very difficult to match by even the most sophisticated artificial sensors.

Having as the main motivation the enrichment of the IoT gadgetry sitting around in my house (and eventually fill up an entire 192.168.1.1/24 network address range), I found that (after the motion and entrance detection device), an interesting device to invest time on would be something capable of sensing multiple air quality parameters at the same time.

Trying to make the most out of Home Assistant + rooted Xiaomi vacuum cleaner + Valetudo

After some time using HA (Hass.io), and even longer using the Xiaomi Roborock (first generation) vacuum cleaner, I kind of felt a certain discomfort in keeping this robot in a stock setup. Sticking to the original firmware meant having a device that is permanently connected to a chinese cloud service, and without the user awareness it sends many megabytes of data daily to this service. Also it meant that integration and features via a platform such as Home Assistant, are limited.

One feature that I fancied for some time was the ability to define zones, and instuct the robot to go to these predefined zones on demand.

Ghost switching can be a bitch if your switch is your main circuit breaker

On my way to eat my own dog food, I learned the hard way that ghost switching is kind of the default problem most people will stumble upon when setting up their MQTT switch for the first time.This is not a big deal when you are configuring a single light switch or some other not so critical appliance. But when your switch is in series with your main circuit breaker, ghost switching suddenly gains a whole different level of importance.

ZMAi-90 (or SMTONOFF WDS688) DIN rail meter/switch - more details on GPIOs and configuration

As an update to the previous post where I have shared the details on how to "Tasmotize" this device, I am adding more detail on what is the physical assignement of GPIO pins from the ESP8266, to other components in this device.

Given the pins from the ESP8266 microcontroller that are exposed in its breakout board (which in turn is SMD soldered to the main PCB):

Intrusion / motion / door opening detector using a NodeMCU, some sensors, and Tasmota

The Espressif Systems chip manufacturer kind of created a revolution by opening the door to the creation of dirt cheap chips for building IoT devices. Its low cost led to introduction in the market, of many types of home automation devices, such as switches, light dimmers, smart bulbs, HVAC systems and what not.

On par with that, the open source community quickly became an interested party as well, and this led to the introduction of tools for quickly allowing developers to write interesting applications for practically anything based on these chips. It is the case of the Arduino core for the ESP8266 chip -  https://github.com/esp8266/Arduino. This allowed for Arduino IDE accustomed developers, to write their own code, and either replace the original firmware on commercial devices featuring the ESP8266, or use open-source board designs such as NodeMCU and build their own custom devices.

Reverse engineering the ZMAi-90 DIN rail meter/switch and integrating with Hass.io using Tasmota - Part 2

I finished the first post with  a tone of optimism, in spite of not being quite there yet. But this time I'm bringing the complete story, with something which hopefully can be a useful takeaway for most users.

Initial analysis of the MCU communication

After figuring out what kind of communication was going on between the ESP8266 and the Vangotech V9821 chip (the specialized MCU which does all the metering functions - and a bit more which I will go in detail afterwards), I got a bit puzzled with the output and its consistency. I first connected a known AC current source through the shunt mounted in the relay's output rail, and in the middle of a stream of garbage, some values seemed consistent with the current I was putting and  being shown in the device's display.

I still cracked my mind at trying to figure out a pattern (I felt as if I was trying to incarnate John Nash while looking for patterns in seemingly chaotic data), and trying to prove assumptions such as the last byte being a checksum. But nothing fruitful came out of that first iteration.