Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts

Sunday, November 29, 2020

HelloTwo

Overview

Kickstarter promo image, ©Hello
In 2014 a startup called Hello launched their first product on kickstarter the "Sense". This little orb of intricate injection moulded plastic was easily the most fully featured sleep tracking device available to consumers. The business model was solely based around sales with no ongoing service fees. This made the business very unsustainable. After attracting quite a lot of success and breaking into mainstream retail sales Hello folded in 2017

Unfortunately, this left the hardware unsupported with no servers to process it's data. The Hello company did initially offer some support for the idea of open sourcing support for their devices but this never got off the ground. Fast forward to 2020 and it has become obvious no one is going to get the original hardware working again. It simply wouldn't make sense in the days of $4 WiFi enabled MCUs to put the effort into reverse engineering the software stack on the Sense. What does make sense is scavenging some of the amazing industrial design and sensors and building a new data logging solution.

The original Sense offers 6 environmental sensors: illumination, humidity, temperature (HTU21D-F), sound, dust (Sharp GP2Y10), and motion, via a bluetooth dongle. I'm only interested in air quality so my work only involves those sensors.

Hardware

Before tearing my device to pieces, I had a look around the internet and stumbled onto Lyndsay Williams' Blog. Lyndsay did a great teardown and inspection of the Sense back in 2015 and his images were a great help to me.

Power board pictured later
To summarize, the Sense is built with 4 PCBs. From bottom up: power conditioning, LEDs, processor, and finally sensor board.

Between the LED board and the processor sits the Sharp GP2Y10 dust sensor.

To avoid self heating, the HTU21D-F is mounted at the bottom of the device near the input air vents. The intent here seems that any heat generated in the device will create an updraft. Any resulting airflow would contribute to keeping the temperature and humidity values reasonably true. Reviewing the layout of the sensors shows that for this project only the power conditioning board is needed. All the others can be removed. This leaves plenty of space to fit a NodeMCU board inside the Sense.

In order to power the replacement MCU and talk to the HTU21D-F, there needs to be several connections to the power conditioning board. Originally, these were made with a flex PCB ribbon cable. Not having access to an appropriate header, the obvious solution was to take inspiration from the insanity that is the Wii Modding community and break out the magnet wire.

Using a multimeter in continuity mode, I probed around the power board and found pads which carried the I2C signals from the HTU21D-F and the USB power signals. The same process could be carried out to interface with other sensors in the device, but as previously mentioned I was only interested in air quality. After soldering magnet wire to each of the pads, I applied a couple of dabs of enamel nail polish to relieve the wires and avoid having to do any later rework.


Wiring to the Sharp GP2Y10 was somewhat simpler. Again the connection is made with a ribbon cable. However, in the case of the Sharp sensor this is a regular wire cable. The MCU end of this cable can be snipped off and soldered to. The Sharp GP2Y10 is a really frustrating device. It's apparently calibrated at factory but relies on two external components (a resistor and capacitor) to control the sensing and readout. This means that the sensor can never be more calibrated than the tolerance of the external components. It would have been extremely easy for Sharp to have integrated these and calibrated the system as a whole. With the magnet wire mess already well underway from interfacing the temperature sensor, I decided to simply float the support components for the Sharp sensor.


With all the sensors wired up, I powered up the board by the USB port on the NodeMCU and tested out my interface code. It turned out that several of the digital pins broken out the NodeMCU have odd reservations and the trigger pin for the Sharp sensor had to be moved. 

After this was complete the sensors worked as expected. The only issue was the really intense LED on the NodeMCU. 

The Sense was designed to include a ring of LEDs and as such, the whole thing lights up blue. That wasn't desirable so the LED was quickly desoldered. After carefully reassembling the device, the hardware work was complete. (I did not bring the USB data lines from the power board up to the NodeMCU so the device must be opened to update the firmware via USB).


Software

For collecting and monitoring the data I looked into a lot of solutions. For this project I wanted long term data storage, low cost, and MQTT as the data transfer mechanism. Adafruit and Particle offer hosted services which meet two of these conditions, but fail to provide the full package. Turning to DIY solutions ELK(Elasticsearch, Logstash, and Kibana) was my first thought. However, while searching around on GitHub I found similar datalogging project by Nilhcem. He uses MQTT, InfluxDB, and Grafana. This is a much better stack and thanks to Nilhcem, you can stand up his logging solution from a Docker Compose file in about 5 minutes. A couple of simple Grafana graph configurations later, and you should have a dashboard like this.

If you have a Hello Sense sitting around and want to replicate what I built, you can pull the Arduino code from my GitHub here: https://github.com/Bostwickenator/HelloTwo.


Troubleshooting

  • Pin reservations on the NodeMCU. GPIO 9 and 10 are special and you need to be careful using them http://smarpl.com/content/esp8266-esp-201-module-freeing-gpio9-and-gpio10
  • Timing for the Sharp GP2Y10 is very dependant on capacitor value. I suggest graphing the sensor response and picking the highest point of the curve for your individual circuit instead of relaying on the 280 microseconds specified in the datasheet.
  • Docker for windows does not boot on startup. solution on StackOverflow
  • Accidentally using 3 instead of D3 for a pin operation on the NodeMCU will compile and will hard reset your device each time it is executed.
  • Self heating. The NodeMCU produces a surprising amount of heat. With the device in full powered up state the temperature reported was 3 degrees centigrade higher than the true value. To combat this I put the WiFi module into forced power down this reduced the temperature offset to 1 degree which I compensated for in software.
  • The Sharp GP2Y10 response values are incredibly noisy. The values bounce around with a standard deviation of at least 3 bits in the 10 bit ADC on the ESP8266. To get around this, I had to collect a lot of samples and apply a Gaussian filter 
  • The Sparkfun library for the HTU21D-F crashes the ESP8266.The Adafruit library works perfectly.

Thursday, November 5, 2015

IoHeating Part 1


Recently I had a few days off from work and decided to solve one of the problems that had been bothering me throughout winter. Namely a cheap heater which had a temperature dial that was:
  1. Completely unlabeled
  2. Driven by a large loud low accuracy thermostat.
Instead of solving these problems by getting a new heater or off the shelf controller I decided to make things a little more interesting. That meant it was parts shopping time. 

If you are switching mains power you have two options relays and triacs. Triacs are a sextuple layer silicon switch similar to the better known transistor but compatible with alternating current. They are great because you can switch them many millions of time with no wear and because they are completely silent in operation. Relays are simply electronically operated physical switches. A triac would clearly be optimal here. A quick Google later and it turns out that the majority of parts for the hobbyist market are based around relays. I wanted to utilize one of these readily available parts because:
  1. When I have time off work I'm trying to be as lazy as possible
  2. Relays and triacs often need a drive transistor which I would have to solder on veroboard (eww)
  3. Isolation.
In New Zealand we use 240V AC in every country the AC transmission voltage is dangerous, here especially so. Isolating the low voltage electronics especially the controller (more on that soon) is important for safety and longevity. Fortunately electrocuting kids is very bad press so most of the hobbyist relay boards include a drive transistor AND an optoisolator. If you haven't come across these before I'm about to make your day.

Optoisolators are essentially a transistor where the gate is not electrically connected but optically connected. So on on side of the package you have an LED and on the other a transistor with a gate that is excited by photons not those dirty old electrons. This whole thing is packaged up in a nice black box that puts the input side far enough away from the output side that everything is electrically isolated and safe enough to lick (do not lick). We are actually using the same power supply for driving the relay and the controller so this doesn't actually make us all that much safer but it is still good to isolate our delicate IO lines from nasty physical things like relay coils.

Something like this.
So we have a switch that we can control. Now we need to know when to turn the heater on and off. The clunky old thermostat relied on a bimetallic strip to sense the temperature of the room. This sensor if you want to call it that is large and has an inherent hysteresis. We can do better. How precise does our temperature need to be half a degree you say? Perfect we'll use the DS18B20. This is one of the first digital parts I ever utilized. They are a robust, decently accurate, and voltage compensated sensor. Even better you only need a single IO line to talk to them due to the exceedingly well named "1-wire protocol". 

Finally time for the controller! Particle (previously known as Spark) are a group who have developed a seriously amazing little bit of kit. The Photon dev board. To boil it down. ARM microcontroller, WIFI 802.11n, Cloud API and development platform, ludicrously simple code and integrations, $20. Go and buy one right now.

So with our shopping list complete let's build our thing. Just so you know a couple of additional components will probably come in handy, those are.
  1. A heater with some space in it
  2. A power supply for your controller
  3. A high temperature insulation. Don't use heat shrink this is a heater. Instead use Sugru

With that the beautiful build is revealed! From top to bottom we have. A USB power supply from a hapless phone and behind it the Photon board. Below that we have the original heater switches and the thermostat. At the bottom you'll see the relay board and the actual heating elements. The relay board has been tapped into the AC power such that it can break the circuit to the heater whilst leaving the Photon board powered (clever huh). It is also wired in such a way that all the heater's original safeties are in place. The original thermostat (turned up to full), a thermal fuse (in between two of the elements you might spot it) and a thermal cut off at the other end of the element which isn't pictured. Also not seen the the DS18B20 as that is carefully located outside the case as to make it less susceptible to heat soak from the heater chassis. There are more pictures of the build here.




The genius of the Photon dev board is just how easy it is to step integrations between real world items like our heater and the world of data. For this project I used the build.particle.io development platform and whipped up a simple firmware that knows how to turn the heater on and off, how to measure the temperature from our temperature sensor.

There were a couple of small complications discovered whilst writing the code.
  1. I didn't read the datasheet for the DS18B20 temperature sensor quite well enough you need to use a pull up resistor to get the 1-wire communication working with the Photon. No issue that five minutes with a soldering iron can't fix.
  2. Our relay board likes to turn on but doesn't like to turn off. To deal with this one we can get away with setting the IO line to INPUT_PULLDOWN this soaks up any stray electrical potential and makes sure the relay optoisolator and thus the relay returns to the off state.
Want to have a look at how simple this was to implement or even spare yourself that effort and copy it for your project? Go right ahead and read this gist of heater code. Just remember that you'll have to use the library include system in Particle Build to add the libraries listed at the top of the source.



At this point we have a heater that can turn on and off at the whim of anything that can use a REST protocol. While using a web browser to turn a heater on and off is pretty cool that isn't going to cut the mustard in this connected world. What we need is apps! lots of apps. Well maybe just one. Next post I will tell you about the application below.