Continuing with the Kiosk project

It is fairly interesting that just as with other "things" that I have equipped my house with, this Kiosk and other IoT gadgetry proved to be of relevance not just for my geek person, but for my family as well. For example my wife likes to keep track of the vacuum cleaner progress. Having its map and progress show up automatically when it starts cleaning, proved to be quite useful in this sense:

Attempting to repair a Vorwerk TM31 Bimby / Thermomix

At the beginning, when in my house we decided to purchase this kitchen food processor/blender almost 10 years ago, I considered it to be somewhat of an overpriced consumer asset in spite of the multiple features that it enclosed. Still I went with the hype and gave some credit to how much it could make life easier, in particular when it came to cooking meals and otherwise more complicated recipes.

Configuring Home Assistant to run off of a USB drive in a incompatible Raspberry Pi

 A problem with the earlier generations of Raspberry Pi's, especially the Pi 1 and the Pi 2 up to version 1.1, is that these cannot be configured to boot from an external USB storage device.

This is a particular relevant limitation for a number of reasons, including the fact that relying on an SD card for most of the storage needs is a solution that may have limited endurance.

The later versions of the Raspberry Pi (RPi 2 v1.2 and upwards), already offer some form of allowing external USB media to boot the operating system. 

Improving an RPI 2 based Home Assistant server for reliability and performance

For some time I have been using the same Raspberry Pi 2 v1.1 as the infrastructure for my Hass.io instance. It proved to perform quite reliably over the approximately 18 months I have been using it 24x7. From that time during approximately 1 year I used the same SanDisk Ultra XC I 64 GB MicroSD card:

Just for precaution I have later switched to a similar card, a SanDisk Ultra HC I 32 GB, and moved my Hass.io installation onto it:

Building a hardware watchdog timer for a kiosk or other system that needs to run 24x7 - version 2.0

My previous post covered a first version of a watchdog timer that I used in the past for another project. 

You may check it here.

As I mentioned there, I suspected that a somewhat different design would be necessary, because the target device could not have either GPIO pins available for allowing a keep-alive signal to be sent to the watchdog timer, or even if it had, it would be unlikely that the underlying linux OS on the Android system could not have the necessary drivers or support for changing the output of such pins.

Building a hardware watchdog timer for a kiosk or other system that needs to run 24x7

It was proven by Alan Turing back in 1936 that the halting problem applies for computing in general, and our contemporary computing machines are no exception.

Would predicting the crashing of an algorithm or program be a possible function, and we would be able to know the edge cases that cause an application to fail or enter a loop, without having to explore the actual scenarios to find these edge cases. To put it simply we would only have to ask the algorithm in which conditions it would enter a loop or end unexpectedly, and by not providing these inputs we would with absolute certainty not enter these scenarios.

Building a kiosk for Home Assistant from scrap parts - Part 2

With a project of this type, the hardware preparation is just the tip of the iceberg. It was thoroughly explained in the last post, despite one last change still being pending. What lacks is basically the addition of a resistive touch panel to the front of the screen, in order not to depend on the mouse as a pointer/input device. The panel is still somewhere between China and my location..

The first aspect that I found important to cover, now that I had this Android based kiosk up and running, was the ability to remote control it and launch arbitrary applications and services on startup.

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.

Attempting to reverse engineer a home automation oriented smart-meter - Part 1

In my quest to make my house smarter, but still looking forward to keep having control over it, I have been doing some additions which I plan to further document here, in the short term.

In the meantime I thought it would be more relevant to share my findings in regard to a device a bit more "exhotic" than the Sonoff boxes we are all used to. This device is a sort of a miniature smartmeter that fits in a DIN rail next to the circuit breakers.

Just like the Sonoff modules, it also pairs with your WLAN, and connects to a cloud service. Instead of the eWeLink cloud to which Sonoff devices connect to, in this case it connects to another relatively popular cloud service called Tuya.

Waking up devices in Hass.io (Home Assistant)

This is a quick post on a challenge I had to overcome while integrating my SmartTV (an LG TV 55UJ620V) with Hass.io.

I wanted Hass.io to be able to turn on the TV (as such allowing automations to be built on top of it, or for example turning it on through a voice command via Google Assistant). As such I first resorted to using the Home Assistant Wake on LAN built in integration (https://www.home-assistant.io/integrations/wake_on_lan/). It kind of worked, but was not very reliable (perhaps 2 out of 5 times it would work).

I knew that by definition, the way that (Wake-up On LAN) WOL is implemented is inherently unreliable: essentially the target (dormant) device is expecting a frame with a specific pattern of bytes. If it receives that frame, it wakes up the host, otherwise nothing happens. The device will normally scan for that pattern of bytes in the frame regardless of the type of transport level protocol it may be on top of. In the case of WiFi in particular, there is the probability (high or low, depending on the network conditions) of that single frame not reaching the destination. This probability increases with the more hops we have in between.

With this Hass.io implementation I was requiring the magic packet to be sent from a host (the Raspberry Pi where I keep Hass.io running) that is in a separate router vlan, from where the TV is (these are connected via Ethernet and WiFi respectively):

Building a kick-ass home automation by reflashing the Sonoff devices with Tasmota and getting it all working with hass.io

For some time I have been gradually bringing more devices to my house, which are either designed or having features allowing these to be integrated to a home automation system.

In spite of all the concerns that can arise from bringing smart/connected devices to the place where you expect personal privacy to exist, the convenience of having these ends up speaking louder overall..

It all started with having a set of unrelated devices in the house, each featuring connectivity and some cloud-based features provided by the vendor. This is the case for the Xiaomi Rockrobo vacuum cleaner, the Sonoff switches, the multimedia devices such as the TV set (an LG smartTV), and also the Google Chromecast and Assistant devices.

Consumer grade WiFi gear - when fixing the root cause is not at reach

Some time ago, I had to improve the performance and coverage of my home network, so as to be able to use the several devices around the house flawlessly, regardless of the location. Some of these devices have a certain demand for consistent bandwidth, as is the case of the SmartTV for watching IPTV and Netflix, and others such as the smartphones and tablets.

As always I tend to be frugal with spending money in hardware, trying to go with what performs well and is just about enough for the job.

This led me to aim for WiFi gear that would both be somewhat popular and low cost, while at the same time having some hope of being hackable and reflashed to OpenWRT in the future. This was the reasoning when I decided to buy a couple of TP-LINK TL-WR841N routers (with v9 hardware at the time).

At first I set these up and played with the stock firmware, configuring one to play the roles of  NAT, DHCP, DNS, firewall and so on, and the other to act solely as a WDS repeater, allowing WiFi coverage to be extended to the rest of the house.

The hurdles of fixing a puncture in a Xiaomi M365 scooter

I can say that I am pretty seasoned at fixing bicycle tires. It dates back to my childhood, where numerous times I had to fix the punctures by patching the inner tubes. I still remember the patching kits featuring an assortment of patches of different sizes and shapes, sanding paper, and the rubber cement.

Never had much trouble in separating the tire from the rim, and putting it back together, after having fixed the puncture. The same applies for fixing the tires of more recent MTBs, where upon following the usual technique no major obstacle arises in accomplishing these tasks.

But now, just after a bit over 100 Km into using my Xiaomi M365 scooter, I found a rattling noise in the front tire while riding it. Went on to take a look, and found a thumb tack, fully buried in the tire. As I started removing it, I could hear the air escaping. Decided to leave it there just so that I could ride the scooter back home.

EDF Propelled Hovercraft project - first outdoor test

Following the post regarding the construction of this project, here is finally the first real test:

Performance and handling are very good, as expected.

The most inneficient (and probably the coolest) EV in the world - the electric hovercraft!

This project may well model what an electric hovercraft could feel like to drive. At least from a noise perspective, trust me, it is a pretty solid preview in spite of its small scale!