(HIKVISION's slogan. Me likey)

I've been running my truenas server at home for a couple of years now. Initially, I used it for media streaming and peer-to-peer file sharing :). Later on, I learned about this app - Frigate NVR, and learned that I can easily connect my Google-Coral TPU to it, streaming video to models like YOLO, enjoying local high-level AI detections without choking my server's CPU. Like many NVR's Frigate tags and creates clips of captured interesting things; it runs inference both on video and audio streamed from the camera (So I could be alerted if there's a crying baby, or get a fire-alarm detection). Although applications that come with off-the-shelf cameras can do the same (usually for the price of some online storage), the privacy of running it locally is a relief.

A few months back, I bought an IP camera and started tinkering with Frigate.
Quickly learning that it is really powerful open-source software!

Having just 1 IP camera doesn't suffice. Wanted more coverage, I got this old IP camera - HIKVISION DS-2CD1021 from a friend.
These cameras's designed to work with a DVR, which creates a local network, with a fixed IP.
Connecting it to my network did nothing since the camera is configured to have a static IP.
I can configure it to DHCP through the camera's login page, but first I needed to access it...

Step 1 - Reading HIKVISION DS-2CD1021 specs

Frigate can be configured to work with many streaming protocols.
This camera supports many:

TCP/IP, ICMP, HTTP, HTTPS, FTP, DHCP, DNS, DDNS, RTP, RTSP, RTCP,  
NTP, UPnP, SMTP, SNMP, IGMP, QoS, IPv6, Bonjour, IPv4, UDP, SSL/TLS  

I will use the RSTP.

According to the specs, the default IP address is 192.168.1.64. I need to create a static IP network with subnet 192.168.1.1. Luckily, I have an Omada controller running on my TrueNAS server, which made this procedure rather easy:

Also, I need to set my PC to have a static IP network connection:

Now, I should just enter 192.168.1.64 in the browser and get a login screen of the camera.
Sadly, and expectedly, it didn't work., well, this camera is used and was connected to a DVR before, so my guess is that the default IP changed.

In their user guide, there's a Windows-only program called SADP that automatically detects the connected camera's IP address.

Switching to a Windows machine.: The SADP software surprisingly worked, figured out that the camera's IP is - 192.168.254.3:

Once I've configured a static IP wired-network connection, I've managed to access http://192.168.254.3/doc/page/login.asp yey! Yet it was password-protected (and the obvious admin admin didn't work).

After some reading online:

1. I need to use the SADP; select the problematic camera from the list, press the forget password, and export a code.
2. Then send this code to the local HIKVISION vendor's tech support (In my case tech@hviil.co.il).
3. They will return a generated XML file containing the temporary password.
4. Using the SADP tool - I need to import this XML and insert a new password.
5. I've successfully reset the password! Now we can start tinkering with it :)

One last thing before integrating with Frigate - have a sanity test, and stream video-feed to VLC.

Using this URL rtsp://admin:anIPCamera1!@192.168.0.143:554/Streaming/Channels/101, and voila!:

This camera will come in handy.
It has two streaming channels.
It supports up to 1080p, enough for object detection.
It can be powered with PoE, which is generally a good thing
Most importantly, adding it to should be straightforward, just expand my Frigate camera's config JSON file with this:

cameras:  
  hikvision_ds_2cd1021:
    ffmpeg:
      inputs:
        - path: rtsp://admin:anIPCamera1!@192.168.0.143:554/Streaming/Channels/101
          roles:
            - detect
        - path: rtsp://admin:anIPCamera1!@192.168.0.143:554/Streaming/Channels/102            
          roles:        
            - record # Changed to record for this camera, assuming it's the higher res for 510a
            - audio # Add this if you want to enable audio detection later   
    audio:
      enabled: True # <- enable audio events for the upstairs camera         
      listen:
      - bark
      - fire_alarm
      - scream
      - speech
      - yell
    detect:
      width: 1280
      height: 720
      fps: 10
    objects:
      track:
        - person
        # - car
        - dog
    snapshots:
      enabled: true
      timestamp: true
      bounding_box: true
    record:
      enabled: true
      retain:
        days: 7
        mode: motion

Yup - plug and play :)

In the image below, Frigate's UI, with 2 cameras. The left one is this HIKVISION

Final thoughts

I must confess, HIKVISION's security is tight.
Also, I was sceptical they would help me with this old 2018 IP camera that a friend gave me.
Playing with Frigate is fun. But it's a fraction of what I plan:

Every frigate detection can be published over MQTT... (food for thought)

Cheers, Gal

As a vintage IOT enthusiast I used to flash my own ESPs with code I patched together in the Arduino IDE. My sketch would include WiFi and MQTT credentials along with a few "if then" instructions. I'd attach the ESP to a relay and configure things in Node Red running on a Raspi.

This was well and good at the dawn of IOT, but as commercial companies entered the field, things got more complicated.

Attempting to draw customers into their ecosystems, companies developed apps and protocols to work with only their devices. The result was that if you bought devices from several companies, not only would you need a specific app, but one company's devices wouldn't talk to another. Many of us ended up with entire panels of IOT apps just to control a few switches and lights around the house. To make matters worse, we'd end up using nefarious Chinese web servers that nobody really trusted.

The answer was to use Home Assistant or Node Red, but in each case, you needed an interface to make everything communicate.

Sonoff

Sonoff was among the first to produce useful commerical IOT devices. Using an ESP8266, their smarts were cheap, reasonable quality, and easily available. Eventually they developed Ewelink, their cloud system to take control.

As they were among the first, and because the ESPs had started in the hobbyist realm, developers were quick to create Open Source firmware to enhance control of Sonoff devices. Hence Tasmota was born.

Tasmota

Tasmota, originally developed by Dutch Developer, Theo Arends, in January 2016, was designed to replace the factory firmware on Sonoff's ESP8266 devices. It was local, would allow simple menu-based configuration, and remove dependency on Sonoff's cloud-based services.

By logging into the web page broadcast by the ESP, the user can set Wifi credentials, MQTT, sensor pins, and a host of other parameters. It runs on anything from the basic ESP8266 01 to the ESP32. It is OTA (Over The Air) and after nearly a decade of development, it is extremely stable and reliable.

Many Sonoff devices can happily run Tasmota firmware, and when they do, control is much more extensive, absent reliance on external Chinese servers.

Flashing Tasmota to Sonoff Smart Plug

These instructions relate to the Sonoff S26R2TPH Smart Plug.

Opening it up, look around the ESP chip to find the four pins V, RX, TX, and GND.

On my particular board, I don't have the ESP8266, but the ESP8285 - a very similar chip but with 2MB of SPI flash built in. Tasmota can be flashed to the 8285 in exactly the same way as the 8266.

Solder wires onto the four pads. I suggest Dupont wires as the other end will need to go to your FTDI USB To TTL Serial Adapter.

The ESP is exclusively 3.3v so don't use a 5v dongle. (I've used 5v on ESP Development Boards, but this is not a Dev Board and won't be 5v-tolerant.)

Make sure to connect the TX pad to the RX pin and the RX pad to the TX pin. Of course, V and GND go to the 3.3v pin and GND.

Web-based Tasmota Binaries and Installer

Fortunately, to flash the firmware, we no longer need to use Arduino IDE. It can be done directly from a web page. Personally, I use a Raspberry Pi for flashing because I find linux reliable, and the RasPi Chromium browser is devoid of bloatware and complications.

From this link, download the binaries that are best suited to your needs. As I am using a simple on-off switch, tasmota-lite.bin is sufficient and ensures that I won't run out of memory as I'm flashing.

Use this link to access the Tasmota flashing tool.

First, upload your factory.bin, then click Connect. Select your USB port.

GPIO 0 to GND

Instructions say that GPIO 0 needs to be grounded, so I spent half an hour trying to find a microscopic breakout pad for GPIO 0. After several failures, I realized that my smart switch had a button - could it be this simple?

So, I powered up the ESP with the button pressed, then released it. To my amazement, it worked.

Configuring WiFi

At the end of the flashing process one of two things will happen. Either the flasher will ask if you want to set up WiFi, or it won't. If it doesn't, restart your ESP and search for a Tasmota SSID on your WiFi. It will automatically open a form for you to input your WiFi credentials. Once this is done, you should be able to access your Tasmota smart plug at its IP address on your local network.

Recently, I got a new board at work, with a new sensor (STM's latest).
I've been tasked to write a driver for it to expose its needed capabilities to our application running on Zephyr.

A decent task, not too shabby.

When bringing up a board, one must first ensure that all pins and lines are connected according to the data sheet. One way to do it is with a small program that toggles all the CPU pins, and a fluke - measuring the expected pin gets turned on (in my case: changed from ~0 to 1.8v ).

Next, implement a minimal program that reads the HWO_AM_I register of the sensor.
This register contains the sensor ID, ensuring we are communicating with the expected sensor. The ISM330BX is embedded in the new board with a SPI communication layout. So, this minimal program we'll need to support SPI communications.

The dataset provides the HWO_AM_I address; reading it is straightforward.

If I succeed, it means I have correctly configured the SPI, i.e: * Bit order is as expected (LSB/MSB) * Communication frequency is acceptable * The MISO/MOSI wires are connected correctly.

This also confirms that I'm communicating with the correct sensor, and we can proceed with writing the driver. yey!

But if things are not working, here's why I used an Oscilloscope :(

[Wires are a mess; suggestions for better organizing the wires are welcome.]

I already know things are configured as expected:

• I've checked the wires - V.
• I've checked the register address - V.

Yet when reading the HWO_AM_I register over SPI, I get either 0x00. Connecting an Oscilloscope will help "sniff" the SPI wires and understand the bits that flow over the MISO and MOSI wires.
I use PicoScope 4000 Series (borrowed it from work, they cost too much to have one of my own).

Getting 0x00

0x00 means there's no feedback from the sensor:

1. Either it doesn't get any power.
2. Or is there an issue with the probe wires?
3. Or (if using Zephyr RTOS like me) the DTS (A devicetree is a hierarchical data structure primarily used to describe hardware) is not configured correctly.

Investigating:

I've set up trigger events on the PicoScope to watch the ChipSelect (CS).
Usually, when communicating over SPI, when CS falls to ~0 it means 'start SPI communication'.

In the image below, the CS line (black) didn't fall to ~0 as the others did:

Knowing the wires are connected correctly on the hardware side, I overlooked the firmware side - finding out the DTS wasn't configured correctly:

&spi0 {
    status = "okay";
    compatible = "nordic,nrf-spim";
    cs-gpios = <&gpio0 07 GPIO_ACTIVE_LOW>; <-------- Actually, the CS is connected to gpio1 07
    pinctrl-0 = <&spi0_default>;
    bme280@0 {
        compatible = "bosch,bme280";
        reg = <0>;
        spi-max-frequency = <1000000>; /* conservatively set to 1MHz */
    };
};

Another iteration - fixing the DTS, building, flashing, and voila!
You can see the CS line (black) falls to ~0 along other lines:

Yet, the result of the WHO_AM_I is still 0x00 (also in the image above - the communication is not presented as SPI's digital waves, but rather messi). It means the MISO and MOSI wires are not behaving as expected!

From the DTS snippet above, the MOSI/MISO and clock are defined here - pinctrl-0 = <&spi0_default>;.
Looking at the spi0_default definition:

    spi0_default: spi0_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 27)>, <--- Actually I need <0 31>
                <NRF_PSEL(SPIM_MOSI, 0, 26)>, <--- Actually I need <0 30>
                <NRF_PSEL(SPIM_MISO, 0, 29)>; <--- Actually I need <1 08>
        };
    };

Another iteration - fixing the DTS, building, flashing, and voila (hopefully)!
In the image below, we can see the SPI communication!

Zooming in, looking at this image from left to right:

1. MOSI (master-out-slave-in) command "read register WHO_AM_I register (from the data sheet address 0xD0)
2. MISI (Master-in-slave-out) response from the MISO line: value 0xEF - not the expected response value :(

Replacing the MISO wire on my setup did the trick! Now it is visible - MISO responds with the expected value 0x58:

The red line is the clock, so we can see where there are 8 ticks (which means 8 bits, 1 byte)
The yellow line is the MISO wire; when it is low, it is 0, and 1 when high.
So, from left to right, we get:

01011000b = 58h

The expected response when reading the WHO_AM_I register yey!

We are communicating over SPI with our new sensor, Hazzah!

Now the real project can begin!

Thoughts

Using an Oscilloscope is something super helpful; it helps debug digital communication.
And makes board-bring-up shorter

Cheers Gal.

If you've decided to make the Tip the Balance Bathroom Scale, you won't find instructions here! (If you insist on making it, you can find the code here.) This post, on the other hand, will tell you how to make a working bathroom scale.

List of recommended components

• ESP8266 microcontroller - I recommend the wemos D1 mini - about $2
• Four generic 50 kg load sensors with HX711 Module - about $3 for the entire set.
• 16 x 2 LCD screen with I2C adapter. $2
• A base of wood or equivalent, about a 30cm (1 ft) square.
• Access to a 3d printer.

Putting it all together

The hardest part of the build is constructing an assembly that allows the load sensor free movement under the base of the scale. To do this I used this frame produced by ThomDietrich.

To that I added my own parts that are available on onshape at this link, and this one.

When placed together, they form a solid foundation that allows pressure to be placed evenly over the load sensors.

Wiring

Load Sensors

Each of the four load sensors has three wires, usually black, red and white. Black and red are usually 5v and GND - and should be connected in a loop to the 5v and GND pins on the wemos D1 mini. The white wire of each of the sensor is connected to one of the pins of the HX711. (For more details, see Sparkfun instructions here.)

The HX711 connects to the Arduino with only four pins. Naturally, 5v and GND go where you expect, and in my code below you'll see that the Data Pin (OUT) connects to wemos pin 0, and the Clock Pin (CLK) to pin 2. (See this pinout.)

The LCD Screen

The screen has four wires emerging from the I2C adapter on the back. 5v and GND go to the usual places. SCL goes to GPIO5 on the wemos, and SDA connects to GPIO4. (See pinout below.)

The Wemos Code

I need to alert you to three things:

• This is the code that will allow you to weigh yourself. The device works as a regular bathroom scale.
• I have never formally studied coding. I generally pluck bits of code from other projects and fiddle with it until it does what I want it to do. Thus, the code below, is probably appalling. If anyone wants to volunteer to tidy it up, I'll be the first to accept.
• The code defines the ESP32, yet it works on the wemos D1 mini. It's not a mistake.

#include "HX711.h" // library to read load sensors
#include <LiquidCrystal_I2C.h> // Library for LCD screen
LiquidCrystal_I2C lcd(0x27, 16, 2);

#define calibration_factor 23000.0
#define LOADCELL_DOUT_PIN  0
#define LOADCELL_SCK_PIN   2

HX711 scale;

// Code to set up web page on ESP
#ifdef ESP32
#include <Arduino.h>
  #include <WiFi.h>
  #include <AsyncTCP.h>
#else
  #include <ESP8266WiFi.h>
  #include <ESPAsyncTCP.h>
#endif
#include <ESPAsyncWebServer.h>

AsyncWebServer server(80);

const char* ssid = "your_ssid";  
const char* password = "your_password";

const char* PARAM_INPUT_1 = "input1";

String inputMessage;  // Inputs from the web page  
String inputParam;

//Web page that asks for input
const char index_html[] PROGMEM = R"rawliteral(  
<!DOCTYPE HTML><html><head>  
  <title>ESP Input Form</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  </head><body>
  <form action="/get">
    Desired Weight in Kg: <input type="text" name="input1">
    <input type="submit" value="Submit">
  </form><br>
</body></html>)rawliteral";

void notFound(AsyncWebServerRequest *request) {  
  request->send(404, "text/plain", "Not found");
}

void setup() {  
  Serial.begin(9600);
  lcd.init();
  lcd.backlight();

// Load cell stuff
  scale.begin(LOADCELL_DOUT_PIN, LOADCELL_SCK_PIN);
  scale.set_scale(calibration_factor);
  scale.tare();

  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  if (WiFi.waitForConnectResult() != WL_CONNECTED) {
    Serial.println("WiFi Failed!");
    return;
  }
  Serial.println();
  Serial.print("IP Address: ");
  Serial.println(WiFi.localIP());

  server.on("/", HTTP_GET, [](AsyncWebServerRequest *request){
    request->send_P(200, "text/html", index_html);
  });

  server.on("/get", HTTP_GET, [] (AsyncWebServerRequest *request) {
    // Remove the String declarations here

    if (request->hasParam(PARAM_INPUT_1)) {
      inputMessage = request->getParam(PARAM_INPUT_1)->value();
      inputParam = PARAM_INPUT_1;
    }
    else {
      inputMessage = "No message sent";
      inputParam = "none";
    }
    Serial.println(inputMessage);
    request->send(200, "text/html", "HTTP GET request sent to your ESP on input field (" 
                                     + inputParam + ") with value: " + inputMessage +
                                     "<br><a href=\"/\">Return to Home Page</a>");
  });

  server.onNotFound(notFound);
  server.begin();
}

void loop() {  
  Serial.print(scale.get_units(), 1);

  Serial.print(inputParam + inputMessage + " kg"); // change to lb for pounds
  lcd.print(scale.get_units(), 0);
  lcd.clear();
  lcd.setCursor(6, 0);
  lcd.print(inputMessage + " kg"); // change to lb for pounds
  delay(2000);

}

Yes, you read the title right. No more arduous diets or cutting out snacks. No more exhausting exercises, or battling with feeble willpower. This amazing new device will take pounds (or kilos) off your weight at the literal blink of an eye.

How many times have you stepped gingerly onto your bathroom scales, dreading to peer down at the ascending numbers between your feet? Let’s be honest, how often have you dodged the scales altogether, eager to get out of the house before weight-depression pulls you down?

Dietary Experts

We all know about diets offered by “experts” that promise weight loss with minimum effort. Some work, some don’t, but to keep your weight down, they mostly rely on willpower to permanently change your lifestyle. These so-called "experts" ultimately want you to eat less junk food, exercise, and follow their strict regime of deprivation.

Come on, who really wants that?

Amateur Hobbyist

At last, an amateur hobbyist working alone in his garage has created the perfect solution for instant weight loss, and without the drudgery of starvation diets and exhausting workouts! It’s a cutting-edge device that’s about to revolutionize the entire weight-loss industry.

Introducing the Tip the Balance Bathroom Scales. Instead of letting the scales lie about your weight, with a simple app on your phone, YOU get to tell the scales precisely what you want to weigh!

Yes, at last, internet-connected programmable bathroom scales using advanced AI technology that lets you decide your weight. Leave your house with a spring in your step, lively and refreshed, vitalized for the day ahead. No more dragging yourself to work, worrying what people think, or what your doctor says about your blood-sugar levels. A simple app and scales puts you in charge. You can weigh anything from 50 pounds to 200 - whatever you want!

How it works

Operation couldn't be simpler. Step on the scales then launch the app or your phone. Punch in your desired weight - and voila... your new weight will instantly appear on the scale's screen!

Amazing Features

• Easily adjustable for Pounds or Kgs.
• The Tip the Balance Bathroom Scale App can be accessed by any device on your home network.
• Works with any browser on any phone, tablet, or computer.
• With the right networking skills, you can broadcast your weight to the internet so that the whole world can watch you weigh in!
• Can easily be used as a kitchen scale - but the inventor takes no responsibility for outcomes.

Incredibly Inexpensive

The Tip the Balance Bathroom Scales can be made for less than $10. Yes, less than $10, and you have instant relief from weight worries for the rest of your life.

Open Source Blueprints

Not only is this amazing device now available, but its inventor has shared the entire blueprints. Now anyone with a bit of DIY knowledge, some soldering skills, a plank of wood, and a few dollars, can make their own Tip the Balance Bathroom Scales in a single afternoon.

For detailed instructions click here.

How many hours in your life have you spent troubleshooting a project?

Knowing your I2C from your SPI

You've spent ages connecting a bolognese of wires on your breadboard, making sure to distinguish your MISO from your MOSI, your SDA from your SCK, your DIN from your SDA, and your VCC from GND. You've already flashed your sketch to your ESP or pasted your python to your Pi.

Eagerly, you want to see your little display show the temperature of your sensor, or the stepper motor turn its gear.

You attach your power and....

Nothing.

You check your code and pinouts.

Power up again...

Nothing.

You check again.

Still nothing.

A loose connection obviously. Right? A faulty Dupont wire?

So you change the wires one at a time, laboriously disconnecting your spaghetti, making sure to place each new wire into precisely the right breadboard hole. As you do so, it disconnects from the other end, then you laboriously do the same with your device's pins.

How many times have you discovered that it was, in fact, a faulty wire? I know I have. Dozens of times. I must have spent scores of hours fault-finding, only to find that some stupid wire was invisibly disconnected from its little pin.

The Pianist within us all

You check your Duponts with your multimeter, right? You grip the pin against the probe, then fidget with your unfree hand to find the other pin, and press it to the other probe. Which works fine if it's a male to male. But what do you do with the females? The probe won't go in the hole, so you need to find the little metal tab at the side. Of course, you need to do it at both ends simultaneously - requiring the dexterity of a concert pianist.

It's just all one big mess

The Tool you Need

Wouldn't it be wonderful if we had an easy way to check our Dupont wires for faults before we put then on the breadboard?

Surely such a tool exists, right?

Where else to look but Aliexpress - that has tools for problems that don't even exist.

Nada.

Nope, no Dupont wire tester.

DIY

How hard can it be? Well, suffice to say, finding the parts in my bins of bits took longer than it took to build the tool.

And what a tool it is!

A buzzer, a breadboard, an LED and some headers. That's it. Designed to cater for male, female, transgender, and other types of politically incorrect Dupont wires. This thing checks my wires - visually and audibly - in an instant, and I'm sure it's going to save me decades of troubleshooting.

I won't insult you with a circuit diagram.

If anyone comments about my missing LED resistor, I'll just ignore you; I have a million of them lying around and a split-second three volts isn't about to fry its little crown.

LoRa is relatively new in IoT. (Actually, not that new, but it's taking time to percolate into the ecosphere.)

For those that don't know, LoRa stands for "Long Range."

We all know the problem of putting a great little sensor at the foot of our garden, then finding our WiFi is too weak. We've spent hours soldering the sensor to an ESP, installing a voltage regulator and resistors, writing the code, and incorporating everything into HA - only to find the WiFi just doesn't reach far enough.

And if we want the same sensor in the neighbour's garden 15 houses down the road, catching the data is just a pipe dream.

Long Range Data Transmission

This is where LoRa steps in. Not only does it transmit and receive over hundreds (even thousands) of meters, it's low power, and easily runs on a battery. You could read your temperature sensor from the other end of your farm, and if you have several LoRa boards, they can mesh together, extending their coverage further.

There are a few commercial dev boards available, starting around $20. If you're an Arduino jockey like me, you'll need two, to get them talking.

RFM98

I hesitated to fork out for two more dev boards that would gather dust, waiting for my next inspiration. So I bought the cheapest LoRa board I could find - the $5 RFM98.

When my tiny parcel arrived from China, I looked at the boards with trepidation; they were far too small for a breadboard, and soldered wires would be a spaghetti nightmare.

So I threw them in a box with my ESPs and forgot all about them.

ESP8266-12

Until last week, when I had a brainstorm. I had just desoldered an old ESP8266-12 from a broken device, when I noticed the board it was on.

I remembered the RFM98s and wondered if they would fit.

When I placed them on a spare board, I discovered they fit pefectly.

Of course, the pin numbers are wrong, and I had to remove the resistors, but the size and number of pins was identical.

Within half an hour I had two RFM98s soldered to boards, and hooked up to two Arduinos using dronebotworkshop's excellent guide. Everything was up and running in no time.

200 Meters with Ease

These little boards are about 2cm sq. and I was excited to test their coverage. At night, I put the receiver on my balcony with its tiny white LED. I marched off to the end of the street, about 200 meters distant, and repeatedly pressed the transmitter button. Amazed I was to see the LED instantly turn on and off.

My next attempt will involve a friend with a phone who can report from a much further distance.

I haven't thought of a project yet, but the potential is huge and as I discovered, you never know when old stuff will come in handy.

A few months before Christmas, social media channels start filling with instructions about LEDs for home decoration. Popular software is WLED, a program that describes itself as:

A fast and feature-rich implementation of an ESP8266/ESP32 webserver to control NeoPixel (WS2812B, WS2811, SK6812) LEDs or also SPI based chipsets like the WS2801 and APA102!

In layman's terms, WLED is a wonderful piece of open source software that allows users to remotely control and pre-progam amazing displays of LEDS of any length. It does this through a web interface that's accessible to any browser on the same network - and can be implemented with components costing almost no money at all.

The Hardware

Most descriptions of hardware needed will be:

• an ESP32 or ESP8266 onto which the WLED code is flashed
• appropriate LEDs
• a power source.

If you're just running a short strip, power is not really a problem, but if you're extending to many hundreds (or thousands) of LEDS, wiring can be challenging. Voltage injection may be required somewhere along your strips, your project may draw heavy currents, and you always have to be wary of the 3.3v logic limitation of your ESP - compared to higher voltages of your LEDs.

To circumvent the complexity, a few companies offer pre-constructed controllers. Just add power to one side, LEDs to the other, and off you go. A popular one is the QuinLED LED Controller that comes in several varieties to run anything from a single strip, to a multichannel sound & light extravaganza. I started my own odyssey with the QuinLED-Dig-Uno when I got fed up with wires trailing all over my workbench.

Flashing WLED

You can buy controllers with WLED pre-flashed, but if you have ESPs lying around, you may want to go DIY. Today, it couldn't be easier - no longer do you need the Arduino IDE. Through a browser you can flash straight to your ESP in less than a minute..

This is where it gets interesting

If you're like me, you'll have some ESP8266s lying around the house, left over from the days before commercial companies entered the IoT arena. My board of choice is usually the Wemos D1 Mini because it's small, dirt cheap, and contains everything you need to get the job done. But before the dawn of the Wemos D1 and its ilk, I'd been using the ESP8266 01, that 8-legged temperamental little monster that's impossible to power, and offers a measly two GPIOs.

Chinese Treasure

Then I came across this on AliExpress; a $1 device that purports to control WS2812 addressable LEDS straight from a ESP8266 01. Could it actually work?

I ordered a couple for $2 and waited on the Slow Boat from China.

While waiting, I got started on flashing WLED onto the ESP, using this very-convenient $2 programming board.

At the time, I wasn't aware that older (blue) ESP 01s have 512kB flash memory, and newer ones (black) have 1MB. I just plugged in what came to hand, and set the flasher running.

To cut a long story short, I couldn't get the 512kB to flash. Or rather, it flashed, but it wouldn't broadcast a WiFi access point.

This is the procedure that finally worked for me:

First I found a 1MB ESP in my old component box.

• I used WLED0.14.1ESP01.bin with the ESP in programming mode.
• Once flashed, get out of programing mode and searched for the ESP's WiFI access point.
• Once connected, a window will open to input WiFi credentials.
• I checked Force 802.11g because it's an old ESP 01, but don't know if it's necessary
• The ESP should restart with WLED on your network.

When the little boards arrived from Aliexpress, I checked their input voltage. Could I feed the board 5v without frying the ESP's 3.3v logic? Would the 5v board input drive the LEDs?

With both affirmed, I connected everything up and sat back in amazement. Here I was controlling a 120-LED strip of WS2812s on an ESP8266 01 through WLED. Excluding the strip, the components cost about $3!

Making it Portable

My next step was to see if it would work with a regular LiPo battery. As most readers know, their maximum voltage is generally 4.2v, a bit short of the needed 5v.

Here, I used one of the most useful boards I've come across. This TP4056 boost board not only controls the charge and discharge of your LiPos through a convenient micro USB, but also boosts output up to a purported 27 volts.

I harvested an 18330 battery out an e-cigarette and stuck the rechargeable battery, booster, and ESP inside a small project box. I now have a fully-portable WLED-controlled 120-LED strip that cost pennies to construct.

Many readers of this blog will know that it's possible to make an oscilloscope/logic analyzer from the Raspberry Pi Pico.

Called Scoppy, full details are on github.

When I made a Scoppy with two resistors and a small breadboard a few weeks ago, I went looking for a case to put it in. Coming up empty-handed, I enquired on Reddit if anyone had an stl file to 3d print a suitable stand/case.

I received just a single response - from a Redditor who simply said, "I'll design one for you."

Precision

Over the next couple of weeks we sent messages to one another, and eventually, he/she sent me an stl to try on my printer. I'm not so great at measuring dimensions, but somehow he/she got it all spot-on first time around. When I say it was "spot-on" I mean the USB socket sat exactly in the middle of the case's hole. It was unbelievable for a first attempt so I enquired how he/she had done it with such precision. The response was:

"I found an image online of a pico sitting on a breadboard so i tried to pixel-count it with the dimensions I had off the micro-usb port."

Seriously... a pixel count?

Humiliation

My favorite Redditor then went on to amuse me when he/she apologized for taking so long. (2 weeks!)

"I had exams," he/she said.

Assuming I was dealing with a student of Industrial Design I enquired, "what are you studying?"

"I'm still at school," came the humiliating reply.

Bananas

Anyway, once I'd printed the case, I ordered a few banana sockets from Aliexpress and when they arrived, I put it all together with an old Nexus 6P I had lying around the house.

If you're interested in the stand/case, he/she posted the files on the Prusa 3d Printer Site.

From the Prusa site, I now know I've had the pleasure of working with DerKipo @DerKipo_693686 - who, it would seem, is in Germany.

Thank you DerKipo. And good luck with your exams!

This post is more of a Public Service Announcement that a real "how to" explanation.

A couple of weeks ago I acquired a WeAct 2.13 inch epaper screen from Aliexpress. The price of such screens is falling continually, so they are now within easy reach of almost any maker.

When it arrived, I set about making a weather station. A search of the internet revealed this excellent piece of coding that not only displays the weather on the screen, but questions openweathermap.org for regular updates. It also plucks the correct time from an NTP Server, then draws a beautiful rendering on the screen.

I won't go into a lot of detail as G6EJD's Github is self-explanatory and comprehensive.

However, when I got my arduino code to compile for the Wemos D1 32 mini microcontroller I intended to use, all I could get was the border around the screen. Nothing else showed up at all.

After several hours of research, I finally found the problem.

If you are using the WeAct 2.13 B&W screen, you need to change this:

GxEPD2_BW<GxEPD2_213_B73, GxEPD2_213_B73::HEIGHT> display(GxEPD2_213_B73(/*CS=D8*/ EPD_CS, /*DC=D3*/ EPD_DC, /*RST=D4*/ EPD_RST, /*BUSY=D2*/ EPD_BUSY));  

to this:

GxEPD2_BW<GxEPD2_213_B74, GxEPD2_213_B74::HEIGHT> display(GxEPD2_213_B74(/*CS=D8*/ EPD_CS, /*DC=D3*/ EPD_DC, /*RST=D4*/ EPD_RST, /*BUSY=D2*/ EPD_BUSY));  

You need to change the screen to GxEPD2213B73 to GxEPD2213B74.

Once you've done that, the rest should work.

I usually start my posts by warning readers that I'm an amateur with no background in coding or electronics. I write these blogs because while I'm figuring out how to do things, I'm working at ground level and my descriptions are generally simple enough for others like myself to follow. There are few complicated tech terms - just idiot-proof directions. That said, this post assumes a working knowledge of Raspberry Pi and Node Red.

This particular project was one of the most challenging I've encountered. I slogged for days trying to figure out why is wasn't working. Hopefully this post will save others some trouble.

Home Automation with Node Red

My entire home automation is controlled by Node Red running on a RasPi. I tried Home Assistant a long time ago, but I found it much more complicated than NR. Dragging wires around is much easier for me than deciphering yaml scrips.

My Node Red incorporates MQTT.

RF, IR and WiFi

Node Red communicates with devices all over the house. Until now, everything was either RF, IR or WiFi. The WiFi devices I built myself with ESP8266s, and Raspberry Pis. A connected Broadlink hub does most of the IR and RF work. Searching whatimade.today will turn up dozens of examples.

Motion Sensor (PIR)

One of the devices I've always wanted for my arsenal is a motion (PIR) sensor. I've built several of them, but always faced the same problems. First, I could never make them stable - the WiFi signal somehow interfered and gave me repeated false positives. I tried all sorts of shielding, but nothing worked - I just couldn't trust the output.

The second thing was power. Both the ESP and the PIR sensor need constant voltage - and no small amount of current. Even 18650s couldn't be relied on for long.

So, all my PIR attempts were eventually abandoned.

IKEA

I began my Home Automation odyssey around 2016, a couple of years before commercial gadgets flooded the market. I started by flashing ESP8266s and connecting them to relays. It was about two years later that Sonoff entered the field - then all the rest piled on.

IKEA joined the fray (at least in my part of the world) around 2019. By then, my house was automated with WiFi, RF and IR. IKEA used Zigbee, which wasn't on my radar.

Good Quality, Low Cost

During a recent saunter around IKEA I came across their smart bulbs and switches and realized they're well priced and pretty good quality. Maybe there was place for them in my home automation after all? The Motion Sensor intrigued me most - it operates on a couple of CR2032s and claims to work for months.

I put one into my basket along with a dimmable smart bulb. My intention was to get it all working with Node Red without an IKEA hub. (At the time I wasn't even aware that I could pair the bulb to the sensor directly, without the need for anything in between.)

Connecting to Node Red

Zigbee needs its own controller and I'm pleased to say they can be acquired from Aliexpress for a few dollars. The CC2531 can be purchased without firmware, but this requires you to flash it yourself. As I was unfamiliar with the whole process, I bought one already flashed with "SONOFF Zigbee for Zigbee2mqtt."
When I bought it, I had no idea how it would work. Indeed, with it being a "Sonoff" I didn't know if it would work at all with an IKEA device. (To be honest, I still don't know. I tried to find out if there's a difference between regular CC2532 zigbee2mqtt firmware and that of Sonoff, but I never found the answer. If anyone knows, maybe you can leave a comment).

My CC2531 device arrived and then I set about understanding how to make it work.

Setting up the CC2531

The first thing you need to do is get your RasPi communicating with the dongle. It's a USB device but Raspberry Pi OS doesn't know what to do with it without the necessary firmware.

Most of the instructions you'll need can be found at zigbee2mqtt.io. It's a terrific place for information, but for those lacking experience, you'll need to read it carefully.

Here's an example. If you hit the "Getting Started" page, it takes you to this page:

I immediately started typing commands... until, half way down the page I noticed the sentence, "It's assumed, that you've a recent version of Docker and Docker-Compose is installed."

Of course I didn't, so all my typing and running commands had already filled up my pi with redundant crap that I didn't know how to get rid of!

After a bit more clicking around the site, I found the Linux instructions page.

I followed the instructions to the letter and the dongle was quickly installed.

zigbee2mqtt.io

Next step is to install zigbee2mqtt in Node Red. This is also pretty simple. Go to Manage Palette and install this:
node-red-contrib-zigbee2mqtt


Once that's done, you need to get the zigbee2mqtt bridge node to recognize your zigbee devices. For me, this meant putting my IKEA bulb and Motion Sensor into pairing mode and waiting for my dongle to find them. At zigbee2mqtt.io there's a detailed page with instructions for all the devices that are known to pair with it.

Once your devices are in pairing mode tell your bridge to search.

For me, that too, went without a hitch. Within five minutes my bulb and sensor were neatly registered.

So far, so good, I hear you say. What's so complicated about that? Everything went smoothly until now.

Yes, it did. But it's from this point on that I got tied in knots for six solid days.

My Bulb worked fine; with simple commands from an Input Node, I could switch it on and set its brightness without a problem.

But the Motion Sensor was another story altogether. Although it was recognized by the Bridge, it detected nothing. Zilch. I jumped up and down in front of it for hours, waving my arms, and it paid no attention. I brought Significant Other to join me, but our combined bulk did nothing to attract its attention. At first I thought it was faulty, but along the way I paired it directly with the bulb - and it worked perfectly.

To be honest, I wasn't sure how to get zigbee2mqtt to talk to mqtt. Yes, it's written in technical gobbledegook everywhere, but no matter what I did, it didn't work, so I assumed it was my ignorance. I spent days searching forums (fora?), quizzing Google, and trying to understand what I didn't understand.

No videos on youtube covered my very specific problem with the Motion Sensor and I couldn't find a blog post anywhere that dealt with the issue. (Which is one of the reasons I'm writing this.)

I even posted on a Node Red Facebook group. Of the two answers I got, one recommended I migrate to Home Assistant, and the other that "you don't need a hub with IKEA devices" - which kind of missed the point.

It literally took me days and days, looking everywhere and trying everything and I was getting really, really frustrated. This page confirmed that I was doing everything right, but for the life of me, no matter what I did, I could not get the Motion Sensor to activate. It simply ignored all movement. It was supposed to be, simple, but nothing worked.

Each day I'd arrive with another idea. Each day, I tried something else. I even set everything up on another experimental RasPi, away from my daily Node Red.

Still nothing.

Day Six and Eureka!

The attentive reader will have noticed, that at the top of this post, I wrote "I had no idea how it would work. Indeed, with it being a "Sonoff" I didn't know if it would work at all with an IKEA device."

It had been niggling at me for days. Was it possible that the Dongle Firmware is the problem? Even if the Sonoff firmware IS compatible with IKEA, (which I still don't know) I did buy the thing for pennies from Aliexpress so I couldn't really expect top quality.

I had nothing to lose. If the thing only worked with the bulb, it wasn't much use for all my other automation ideas.

But, how could I update the Dongle? I don't have the necessary CC Debugger and I didn't want to wait weeks for it to arrive from Aliexpress - let alone fork out for something I'd only use once.

Then I discovered this page. that showed me how I could do it with a RasPi.

The biggest problem was the microscopic connector on the CC2532. I have quite a collection of JST connectors, but nothing as tiny as this guy.

Fortunately, I'm quite a whiz at micro-soldering and this was an appropriate challenge.

Following the wiring diagram very closely, I soldered one end of a JST cable onto the designated pins of the dongle connector.

It's not a very neat job, but I only need it to run once.

Into the other side of the cable, I plugged Dupont wires. This made it easy to plug the appropriate wires into the RasPi pins. (Note, when I did the flashing, the dongle was NOT plugged into the Pi USB. Instead it gets its power from the 3.3v pin of the RasPi.)

It's imperative to get the wiring right, so in my case, I had to pay very close attention to the fact the Dupont wires were a different colour from the JST wires. With a continuity meter I also checked that the wires were connected ONLY to the correct pins on the dongle. (The pins are so small, it's easy to bridge between them). I also had to make sure I was looking at my RasPi pins the right way up.

The only problem I had was that WiringPi was not in my RasPi and I had to get it from somewhere. If you run the script as it appears on the page, it won't work because WiringPi has been abandoned by its creator. However, following instructions on this page will get you what you need.

I'm no longer invisible

When I plugged my re-flashed dongle back into my Pi, nothing worked. Even the bulb wouldn't light. Then I realized that I'd wiped everything clean, so I did the pairing business again and reconfigured the Node Red Bridge. Immediately, without a moment's delay, my motion sensor spotted me! Within two minutes, I had it ringing a bell, then turning on my irrigation. At last it's working and I'm a very satisfied blogger.

Hi there! my name is Elad and I recently joined the crew here on Whatimade.today. I'm happy to be here and I hope you'll enjoy reading :)

I am an early riser and usually have no problem waking up in the morning. Yet sometimes, especially during long periods of not enough sleep, I find the everyday smartphone alarm clock isn't doing the trick... I just don't hear it. Another thing I noticed is that once I get off the bed and take a few steps - I'm good to go - its just getting to those few steps that may require... some special measures 🤔

I have a Garmin hand watch that's on me all the time, even when I sleep. MAYBE I could do something with it? I found the Connect IQ SDK and at first glance considered developing an application for my watch, only to later find out the specific model I'm using is not supported.
I went through a few other design alternatives, and eventually decided to create a hybrid of few of them: I will use my Garmin as a sensor, and build a "waking up mechanism" around it. I named the project " Walk Up! " and it took me a few evenings/nights to complete.

In this post I will briefly go through the moving parts of the project, and talk about the main features of each. This will not be a full code review, but an abstract overview. For the Full code, please refer to the Git repository.

The Alarm-clock side:

The Physical unit to actually play the the alarm consists of the following:

• ESP32
• Amplifier module (pam8403)
• 40mm loudspeaker.
• 0.96" OLED

This Unit is merely an alarm clock that can be turned on and off over MQTT. All the logic is implemented in the Python3 code that runs on the RPi.

To control the amplifier module and play sound I used XTronical's XT_DAC_Audio library. The library is generally great to use, but a bit hard to set up. I got it to work using an old version of the ESP32 board manager (V1.0.5) on the Arduino IDE. I could not get it to work properly on my usual PlatformIO over Visual Studio Code settings. A few hours of writing code without code-completion and proper syntax highlighting, and a few of tweaking the WAV file with Audacity and I had the speaker roaring my childhood's theme song (comment if you recognize it :D).

This was an interesting experience since I never tinkered with audio before. It was rather thought provoking too: two semesters ago I took a course in signal processing. One of the main themes in the course was the sampling error vs the quantization error tradeoff, the meaning and origin of the two and the mathematical means of minimizing them. Those ideas, Despite being fundamental (and rather simple, maybe) left a strong impression on me. When dealing with audio relying on MCUs and 8Bit mechanisms, adding to that the limited memory in the ESP, and those two mathematical objects hit you right in the face. In a good way though.

For the MQTT aspect of the code I used the popular PubSubClient library.

The OLED shows some messages, indicating the current state of the system.

The Raspberry Pi's side:

The Pi has a double role here really. First, it runs (constantly) the scheduling daemon that allows me to set new alarms anytime I wish, using my phone or laptop over my home network. Second, when the previously set alarm time comes, it runs the program that turns the ESP32-based alarm clock on, and then continuously polls Garmin's server to check whether the set number of steps is reached, turning the alarm off when it is. Let's dive deeper.

Alarm scheduling daemon:

The daemon is implemented in Python3 and mainly uses the time package, and the paho.MQTT module that is an MQTT driver for python. The Daemon "listens" for alarm requests (Over a dedicated MQTT Topic), and upon receiving a new alarm request, It invokes a Built-in scheduling mechanism in Linux to actually set the alarm-routine. I chose to use the already existing Linux's "at" utility (a less popular sibling of the Cron utility) as the actual scheduling mechanism. The main benefit is, well... that it's there already,and works well. Furthermore, it is reboot proof(thus power outage proof), and with it I can trigger any other program I wish, in any set time. The at utility is invoked from within the python code. I created a cron job for the daemon program, thus the Raspberry Pi invokes it right after booting.

Alarm-routine:

This is the program that actually triggers the alarm. As previously mentioned, it is invoked at the destined time and sends an "alarm_on" message to the ESP32 unit. After turning the alarm on, it continuously polls Garmin's servers using a dedicated API wrapper. This wrapper works flawlessly, and is worth checking if you have any Garmin device. It is simple and intuitive to use.
When the desired number of steps is reached-The routine sends "alarm_off", and exits.

Some images:

A video:

Final thoughts:

This one was fun. It was relatively quick to make and I gained some new skills and knowledge working on it. It is sub-optimal in some ways, mainly since I decided to utilize already-existing tools, at the expense of a simpler, minimalist architecture and fewer moving parts. Some future improvements I may add are on device alarm setting, alarm canceling ability, improved audio and maybe other "wake-up" goals: Rope jumping, Heart rate levels etc. All in all, I'm happy with the way it came out, and it definitely works- and that's what it's all about for me.

Thanks for reading.

Elad

As I've mentioned so many times in my blog posts, I've never studied electronics or engineering. Consequently, I come at my projects entirely as an amateur - which means that when I finally figure out how to do something, I'm able to guide others like myself through the technical complexities, explaining step-by-step how to get things working.

For about a year I've been a keen follower of Volos Projects on Youtube. His work is outstanding and he makes really attractive gadgets. More than once I've found myself ordering parts simply so that I could build one of his projects.

This happened last month when I came across his GC9A01 240x240 display video. It just looked so good, I immediately ordered one from Aliexpress.

When I was ordering it, I was aware that I didn't have an ESP32, but I assumed that my trusty old ESP8266 Dev Boards would suffice.

Lesson One: Beware of my first mistake

The screen arrived in a surprisingly short time, and I set about scouring Google for instructions.

First, I thought I'd get the screen up and running with an Arduino Uno - just to see that it works. I connected everything up, and only after I'd failed repeatedly did I realize that my version of the GC9A01 is not 5v tolerant. Of course, in my amateur stupidity, I believed that connecting the VCC pin on the screen to 3.3v on the Arduino was sufficient. It was only afterwards that I realized that the Arduino Digital Pins are 5v - and I could have ruined the screen before I even got started.

ESP8266

Worried now that I'd damaged the GC9A01, I was desperate to see any image at all. As I knew that the ESP8266 is 3.3v, I searched for a script to get it working. I tried various libraries and Youtube videos, but still I couldn't get an image. I was convinced I'd destroyed it with over-voltage.

Raspberry Pi Pico

In a last-ditch effort, I pulled out a Raspberry Pi Pico and after some searching, I found concise instructions on the PCBWay website. After connecting all my wires, I finally got the GC9A01 working with the excellent Arduino TFT-eSPI library. At this stage, all I could do was view the library's examples (of which there are many), but at least I confirmed that the screen hadn't been damaged.

ESP32

But I was still determined to make Volos's watch, and the only way I could do that would be to acquire an ESP32.

So I waited for China Post to bring it. I ordered a cheapie, assuming they're all basically the same. It arrived about two weeks later.

In preparation, I plugged the ESP32 into my Mac and fired up Arduino, intent on flashing blink.

Of course, the serial port was nowhere to be seen. Nothing. I tried various permutations of pushing the ESP's buttons, both while it was powered and during power-up. Nothing at all. Dead as a doorpost.

So then I Googled it.

Serial Chip

Turns out the cheap versions of the latest ESP32's come with a different serial programming chip. So, first I looked at the specs on the Alixexpress page. It authoritatively informed me that the chip is a CH9102X. So, off I went in search of a the Mac driver for the CH9102X. A quick search revealed this post. Now, if you look carefully, you'll notice something that I didn't - which gave me another hour of confusion and frustration.

While the question asked in stackexchange refers to the CH9102X, the link that's given is for a driver for the CH34XSER chip. I didn't notice, and simply downloaded the CH34XSER driver. I then went through the extremely nerve-wracking procedure of installing it into my Mac while ignoring progressively-hysterical security warnings as I went along.

As instructed, I restarted my Mac, entered Arduino, and plugged in my ESP32.

It was there! I could see it!

I loaded up the blink example, changed my board to ESP32, and hit upload. It compiled the code and went into upload, and .... ERROR!

I tried again....

ERROR!

I couldn't figure it out and being the amateur that I am, assumed it was still a driver problem. I tried all sorts of things and nothing worked.

Fortunately, with the driver, comes a small instruction manual. Even more fortunately - unlike the site itself - the manual is in English. It contains a wee bit of troubleshooting so I diligently followed the instructions.

To see if my driver was installed properly, within Mac Terminal:

cd /dev ls tty.wch*

If the result is something like tty.wchusbserial21311 the driver is properly installed.

I did this, and yes, my driver was properly installed.

I tried again - but still it Errored on the upload. At this stage, I still hadn't noticed that the driver I'd installed wasn't the driver mentioned on the Aliexpress specs page.

After some more fiddling, I suddenly noticed - I'd installed the wrong driver. I went looking for the CH9102X driver - but I kept coming back to the CH34XSER page.

Aha, I thought, why not look at the chip itself!

I took a closeup with my phone and expanded the photo on my screen. The chip was clearly a CH340G!

Lesson Two - don't rely on Aliexpress specs

So, in the end, I HAD installed the correct driver - and the specs on Aliexpress were wrong. Hence, my second Public Service Announcement: if Ali's specs say it's a CH9102X chip, check to see if it is, in fact, a CH3400.

So why wouldn't the damned thing upload?

I spent another couple of hours trying it on another computer, pressing buttons, searching Google, and scratching my head. I even tried another cable.

It's the cable again, Idiot!

I learned a long time ago that we should always use the shortest cable possible. Most of mine are 15cm.

So, I tried another cable - but it still didn't work. I was about to give up for the night when I had a brainstorm.

I looked down at my Mac. For convenience purposes, I have a USB extension cable permanently attached. It's so much easier to plug and unplug that way, rather than reaching to the back of my Mac Mini. Aware that long USB cables sap power, I connected my 15cm cable to the ESP32 and plugged it directly into the Mac.

Blink uploaded in a blink and my little LED starting flashing!

This had never happened before with an ESP8266 or a RasPi Pico. There wasn't enough power getting to the ESP32 to flash it.

Getting to Volos

Now that I was successfully flashing my ESP, it was time to get back to the Volos watch. I opened up VolosProject's video and went looking for the wiring diagram. First I searched at his GitHub page but it only contained the code. So then I just looked at his amazing video. It was pretty clear where each wire should go, so I wired mine the same.

With my new-found skills of ESP32 flashing, I downloaded his excellent code, stuck it in the Arduino IDE, and hit UPLOAD. The sketch flashed in an instant.

Nothing. Blank screen. Not a cheep.

Yet another wild goose chase

So now I thought it was my wiring. My first assumption was that my ESP wasn't configured the same as the one in the video. I looked closely and noticed that his RX2 and TX2 pins are labeled D16 and D17 on my board. Everything else looked fine, but this particular observation sent me on a pointless quest for the pinout of my precise ESP32 board. I must have looked at hundreds of them, but I couldn't find my exact board. Fortunately, more than one photo indicated that D16 and D17 can be RX2 and TX2 - so I was making progress, but still nothing would work.

By this time, I was just jumping around from point to point on his video, looking for something I'd missed. On one such jump, at minute 4:12, he mentions his previous video that explains how to set up the display.

So back I go to his previous video and there at the bottom of his description is the pin setup!

It's so hard when you've never been trained...

So there I had it, the MISO pin, the MOSI pin, the SCLK pin - everything you could want. Except that my screen was labeled:

So which pin was MOSI? Which was MISO, and SCLK - is that the same as SCL?

More Googling. More searching. What's the difference between MISO and MOSI and how do they relate to SCL and SDA? Around in circles I went, getting more and more confused.

Come on, Dear Reader, you've got to admire my perseverance. I've been at this for hours and I refuse to give up.

Nearly there

I must have spent about two hours on MISO and MOSI, SPI and I2C and about every other electronics acronym in the book. I was still searching for my wiring problem, and getting nowhere at all.

What's the equivalent of RTFM for video? WTFV?

In the end, I did what I should have done at the outset: watch the F..ing video! In it, Mr. Volos tells his viewers specifically what to do. This includes, among other things, going into the TFT.eSPI library and adjusting the Setup200_GC9A01.h file.

Obedient as I am, I opened the file and saw this pinout defined:

Always looking to do it the hard way, I then tried to figure out with pins to change. Which of them is MISO? - it's not mentioned there at all. It does say, "In some display driver board, (sic) it might be written as "SDA" and so on." - but to the amateur this doesn't help me very much.

In the end, and in despair, I just decided to comment out all existing pins, and simply copy the new ones exactly as Mr. Volos had written them. I was skeptical because I couldn't see how the LED back-light could be the MISO pin.

I watched through to the end of the video then powered up the ESP32.

I couldn't believe my eyes. After several hours of struggling, a very unstable Volos Watch appeared on the screen. It has lines all over it, but at least I was one step closer.

Power, I thought. The RTC - which requires 5v - is draining power from the screen. I turned it all off and looked for the VIN pin on the ESP. I then attached it to the RTC's VCC. I powered up again, and finally I had a perfect picture!

Setting the time

Of course, that wasn't the end of it. The time showed 3:49 and it was 11pm. It was also about seven months ahead of me and it certainly wasn't Wednesday!

My Volos Watch was showing the time it got from the RTC, so I needed to set the latter's time. I'd had experience before of the DS3231 Real Time Clock (RTC). In the past I'd found some obscure library to do this, but as usual, it wasn't simple; it required manually setting the time and date, and predicting what time it would be when the sketch had finished uploading! I knew there must be an easier way.

Fortunately, I found it in Adafruit's RTC Library. All I needed to do was load up the DS3231 example and the library read my system time, then set it precisely on the RTC.

Staples are your friend

I love the way Volos presents his projects. It's always so neat, compact and tidy. I wanted to emulate this as best I could, so I utilized one of my favourite wiring techniques. As you'll see from the photo, by using regular staples, you can cut down wiring considerably and it makes for a very neat package.

Who is going to create a 3d printable case?

Now I have a beautiful, compact watch attached to a mini breadboard, but obviously it needs a case. I tried to make something in Tinkercad but like everything else I design, it was just circles and squares and looked like a 7 year-old's creation. Anyone ready to design something wonderful?

Most of us use a phone app to see the temperature outside - which is fine if you don't mind receiving a reading from a sensor located at a meteorological station somewhere nearby.

And when we finally do set up our own IoT sensors, to see them, we need to open an app, or log onto a webpage.

No device needed

But what if you want to know the temperate outside your own house without opening a device? You want your outside temperature to be displayed permanently inside your house so that it's visible whenever you want, and anywhere you want to see it. (Even in multiple rooms...)

This post explains how to do it. A temp sensor outside sends its reading to a screen inside the house. It's all done with inexpensive components and a few wires and connections. If you already have a Raspberry Pi, you're already nearly there.

Components

• Two Wemos D1 minis - about $2 each.
• One SSD1306 0.96 inch screen - about $2.
• DS18B20 waterproof temp sensor - $1.
• 4.7k resistor
• Raspberry Pi running Node Red and MQTT (Any model RasPi will do, but if you're running a full Home Automation System, better a Pi 3+ or 4).
• Power supply for both Wemos chips. (I use an 18650 battery and solar panel for the outside sensor. More about that below.)

The Principle

Every half an hour, (or other user-defined period) the outside Wemos D1 wakes from deepsleep, reads the temperature from the DS18B20, then transmits the data to the Raspberry Pi using the MQTT Publish protocol.

The RasPi MQTT server receives the data, then sends it to the MQTT Subscribed devices - in this case the other Wemos D1 mini(s). The latter then displays the temperature on the SSD1306 screen.

As it costs only about $3 for the Wemos/Screen setup, any number of these devices can be placed around your house and they'll all update simultaneously.

Setting up the RasPi

I won't explain here how to install Node Red and MQTT onto a RasPi. Rui Santos over at Random Nerd Tutorials does it much better than me..

Two things I'd emphasize:

• Understand the concepts of Subscribing and Publishing in MQTT as we'll be using them when programming our Wemos D1 minis.
• In the MQTT server, if you give yourself a username and password you'll need to use them in your Wemos sketch. You place them under "Security" in the MQTT node in Node Red.

Setting up the Wemos D1 mini with the DS18B20 temp sensor

The DS18B20 is a really simple sensor to work with. When you buy it, make sure you get the waterproof version as the indoor version won't last long exposed to the elements. Connect the sensor to the Wemos as follows:
(This is a NodeMCU, but it's the same principle as the Wemos. Connect the 4.7k resistor as a pull-up for the sensor pin. Make sure you use the correct pin numbers in your own script below.)

Setting up the Wemos D1 mini with the SSD1306 screen

In my setup, I have the SSD1306 connected the the Wemos 3.3v output. Check before connecting. Wiring diagram courtesy of Bits and Bobs

The Outside Sensor Script

This script wakes up from deepsleep every 30 minutes, reads the DS18B20, connects to Wifi, and Publishes the MQTT data to a topic on the Raspberry Pi Node Red/MQTT server.

You need to write your WiFi credentials in the script, as well as your username and password for your MQTT server, and the topic you've chosen.

// Michael Diamond and Allan Shwartz

#include <OneWire.h>            // to connect to the OneWire temp. sensor
#include <DallasTemperature.h>  // temperature sensor driver
#include <ESP8266WiFi.h>        // for WiFi Client class
#include <PubSubClient.h>       // for MQTT PubSubClient class

// Update these with values suitable for your network.

const char *ssid = "Your_WiFi_Name_Here";       // your WiFi name goes here  
const char *password = "Your_WiFi_Password_Here";    // your WiFi password goes here  
const char *mqtt_server = "192.168.x.x"; // IP address of the MQTT server/Raspberry PI  
// Declaration of (instantiation of) a WiFiClient called espClient
WiFiClient espClient;

// Declaration of (instantiation of) a PubSubClient called client
PubSubClient client(espClient);

// GPIO where the DS18B20 temperature sensor is connected to
const int oneWireBus = 2;

// Setup a OneWire instance to communicate with any OneWire devices
OneWire oneWire(oneWireBus);

// Pass our OneWire reference to Dallas Temperature sensor
DallasTemperature sensors(&oneWire);

// constants needed for millisecond timing
const unsigned long SECOND = 1000;  
const unsigned long MINUTE = (60 * SECOND);  
// Push data at this interval
const unsigned long deepSleep_ms = 30 * MINUTE;


//----------------------------------------------------------------------
//  setup() function
//
//  ... setup the Serial class, the Wifi, and the Publish-Subscribe Client
//----------------------------------------------------------------------
void setup()  
{
    // start the Serial Monitor
    Serial.begin(115200);
    // setup the temperature probe
    pinMode(2, OUTPUT);
    // setup the networking functions
    setup_wifi();
    client.setServer(mqtt_server, 1883);
    // Start the DS18B20 temperature sensor
    sensors.begin();
}


// ----------------------------------------------------------------------
//  setup_wifi() function
//
//  ... connect this ESP node to the House WiFi network
//      we only call this once at "setup-time"
//----------------------------------------------------------------------
void setup_wifi() {

    delay(10);
    // We start by connecting to a WiFi network
    Serial.println();
    Serial.print("Connecting to ");
    Serial.println(ssid);

    WiFi.mode(WIFI_STA);
    WiFi.begin(ssid, password);

    while (WiFi.status() != WL_CONNECTED)
    {
        delay(500);
        Serial.print(".");
    }

    randomSeed(micros());

    // networking is successfully up
    Serial.println("");
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(WiFi.localIP());
}


//----------------------------------------------------------------------
//  reconnect() function
//
//  ... The connection to the MQTT server must constantly be checked
//      if it is down, reconnect
//----------------------------------------------------------------------
void reconnect()  
{
    // Loop until we're reconnected
    while (!client.connected())
    {
        Serial.print("Attempting MQTT connection...");
        // Give each ESP its own client name. If they are all the same, it'll repeatedly connect.
        String clientId = "RemoteTempSensor";

        // Attempt to connect
        if (client.connect("Your_topic", "your_MQTT_user", "you_MQTT_PW"))
        {
            Serial.println("connected");
            // Once connected, publish an announcement...
            //     client.publish("Your_topic", tempString, "ºC");
        }
        else
        {
            // if our connection attempt fails, print some debugging to the Arduino console
            Serial.print("failed, rc=");
            Serial.print(client.state());
            Serial.println(" try again in 5 seconds");
            // Wait 5 seconds before retrying
            delay(5 * SECOND);
        }
    }
}


//----------------------------------------------------------------------
//  loop() function
//
//  ... actually the most important function here.
//----------------------------------------------------------------------
void loop()  
{
    // we must be vigilant in keeping our MQTT connection up
    if (!client.connected())
    {
        reconnect();
    }

    // call the loop function of the Publish-Subscribe client
    client.loop();

    // now read the temperatures
    sensors.requestTemperatures();
    float temperatureC = sensors.getTempCByIndex(0);

    // display on the Arduio console ... just as a debugging tool
    Serial.print(temperatureC);
    Serial.println("ºC");

    // we need to convert this into a text string to transmit
    char text[8];
    dtostrf(temperatureC, 1, 1, text);

    // publish this text to our MQTT server
    client.publish("Your_topic", text, "ºC");
    delay(SECOND);   // to insure the packet gets out

    // now go into a power-saving deep sleep for 30 minutes
    ESP.deepSleep(deepSleep_ms);
}

The Inside Sensor Script

This script is Subscribed to the topic of the outside sensor on the Node Red/MQTT server. When the outside sensor Publishes, the server on the Pi sends the data to this (and all other Subscribed devices on this topic). Once the data is received, the sketch displays the result to the attached SSD1306 screen.

Here too you need to write your WiFi credentials in the script, as well as your username and password for your MQTT server, and the topic you've chosen.

// Michael Diamond and Allan Shwartz

#include <Wire.h>             // to connect to I2C screen
#include <Adafruit_GFX.h>     // for screen graphics
#include <Adafruit_SSD1306.h> // for Adafruit_SSD2306 class
#include <ESP8266WiFi.h>      // for WiFiClient class
#include <PubSubClient.h>     // for MQTT PubSubClient class
#define SCREEN_WIDTH 128      // OLED display width, in pixels
#define SCREEN_HEIGHT 64      // OLED display height, in pixels

// Declaration for an SSD1306 display connected to I2C (SDA, SCL pins)
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, -1);

// Update these with values suitable for your network.

const char *ssid = "Your_WiFi_Name_Here";       // your WiFi name goes here  
const char *password = "Your_WiFi_Password_Here";    // your WiFi password goes here  
const char *mqtt_server = "192.168.x.x"; // IP address of the MQTT server/Raspberry PI

// Declaration of (instantiation of) a WiFiClient called espClient
WiFiClient espClient;

// Declaration of (instantiation of) a PubSubClient called client
PubSubClient client(espClient);

// constants needed for millisecond timing
const unsigned long SECOND = 1000;  
const unsigned long MINUTE = (60 * SECOND);

//----------------------------------------------------------------------
//  setup() function
//
//  ... setup the Serial class, the Wifi, and the Publish-Subscribe Client
//----------------------------------------------------------------------
void setup()  
{
    // start the Serial Monitor
    Serial.begin(115200);
    // setup the networking functions
    setup_wifi();
    client.setServer(mqtt_server, 1883);
    // set the callback function ... to be called when we get a message
    client.setCallback(callback);
}


//----------------------------------------------------------------------
//  setup_wifi() function
//
//  ... connect this ESP node to the House WiFi network
//      we only call this once at "setup-time"
//----------------------------------------------------------------------
void setup_wifi()  
{
    delay(10);
    // We start by connecting to a WiFi network
    Serial.println();
    Serial.print("Connecting to ");
    Serial.println(ssid);

    WiFi.mode(WIFI_STA);
    WiFi.begin(ssid, password);

    // continue to try to connect to the WiFi, showing connection attempts
    while (WiFi.status() != WL_CONNECTED)
    {
        delay(500);
        Serial.print(".");
    }

    // networking is successfully up
    Serial.println("");
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(WiFi.localIP());
}


//----------------------------------------------------------------------
//  callback() function
//
//  ... we have received a message from the MQTT server
//      display it.  repaint the SSD1306 screen
//----------------------------------------------------------------------
void callback(String topic, byte *payload, unsigned int length)  
{

    Serial.print("Message arrived on topic: ");
    Serial.print(topic);
    Serial.print(". Message: ");

    // the payload is a "byte-stream".  Convert this to a printable String object
    String message;
    for (int i = 0; i < length; i++)
    {
        message += (char)payload[i];
    }
    Serial.println(message); // debug print on our Arduino console

    // We have our RemoteTemp MQTT message, we want to display

    if (topic == "Your_topic")
    {

        // restart the SSD1306 screen with a call to .begin()
        if (!display.begin(SSD1306_SWITCHCAPVCC, 0x3C))
        {   // Address 0x3D for 128x64
            Serial.println(F("SSD1306 allocation failed"));
            for (;;)
                ; // infinite loop on failure
        }

        // repaint the SSD1306 OLED screen using various Adafruit_SSD1306 functions
        delay(50000); // delay 50 seconds (otherwise is blinks too much)
        display.clearDisplay();
        display.setTextColor(WHITE);
        display.setTextSize(1);
        display.setCursor(2, 0);
        display.println("Temperature Celcius");
        display.setTextSize(4);
        display.setCursor(10, 20);
        // Display static text
        display.println(message); // This is the content to display
        display.display();
    }
}


//----------------------------------------------------------------------
//  reconnect() function
//
//  ... The connection to the MQTT server must constantly be checked
//      if it is down, reconnect
//----------------------------------------------------------------------
void reconnect()  
{

    // Loop until we're reconnected
    while (!client.connected())
    {
        Serial.print("Attempting MQTT connection...");
        // Give each ESP its own client name. If they are all the same, it'll repeatedly connect.
        String clientId = "Your_topic";

        // Attempt to connect
        if (client.connect("TopicName", "Your_MQTT_User", "Your_MQTT_Password"))
        {
            Serial.println("connected");
            client.subscribe("Your_topic");
        }
        else
        {
            // if our connection attempt fails, print some debugging to the Arduino console
            Serial.print("failed, rc=");
            Serial.print(client.state());
            Serial.println(" try again in 5 seconds");
            // Wait 5 seconds before retrying
            delay(5 * SECOND);
        }
    }
}


//----------------------------------------------------------------------
//  loop() function
//
//  ... actually the most important function here.
//----------------------------------------------------------------------
void loop()  
{
    unsigned long loopTime_ms = millis();

    // we must be vigilant in keeping our MQTT connection up
    if (!client.connected())
    {
        reconnect();
    }

    // call the loop function of the Publish-Subscribe client
    client.loop();

    // we want to do this "loop" function once a minute
    while ((unsigned long)(millis() - loopTime_ms) < (1 * SECOND))
        ;   // wait for the minute to be over
}

I 3d-printed a neat little box for the screen. You can download the stl files here.

Triggering other things

As I'm sure most readers are aware, with the outside sensor connecting to Node Red, it's very simple to use the incoming data to trigger anything else in your network. For example, if it gets too hot, the AC will come on. If it gets too cold, the heater will come on.

Powering the Outside Wemos with Solar Panel

Due to its relatively high current drain during WiFi activation, the ESP8266 is notoriously difficult to power remotely. I got around this relatively easily.

First, by bridging pins RST and D0 on the Wemos, the board can enter full deepsleep. This means there is negligible power consumption between each wakeup.

Second, I've used an inexpensive 18650 board that powers the Wemos through the USB output - and also controls battery charge and discharge.

Third, I used a small solar panel from Aliexpress that outputs 5v from its USB. This plugs into the 18650 board above. My system has run for nearly two years without a problem.

All Around the House

I placed little screens all around the house making it easy for me to keep track of the outside temperature without fiddling with my phone. I find myself looking at it regularly. I also added a flow to Node Red that records the incoming data in a text file. Another flow displays a graph of the last 48 hours.

One of the first commercial home automation devices I bought was a hot water boiler switch from Switcher. Like most remote devices, it came with its own app. At the time - about 5-6 years ago - it was nigh-on impossible to hack into the protocol to connect to it in any other way.

For years, as my house became smarter and smarter, the boiler remained a conundrum. Our blinds would lower if the sun got bright, and our AC automatically kept us cool. Lights would turn off at bed time, and garden sprinklers would work only on dry days.

But the boiler was stuck to rigid rules, completely unconnected to climatic conditions. I prayed that one day I could make it turn on when clouds obscured our solar panels, or when the temperature fell below a set threshold.

Today, after much sweat, trial and effort, that changed. Today, for the first time, my Node Red commanded my Switcher to turn on, then turn off - and I danced around the hallway with glee.

This is how I did it

A couple of notes first:

• I run my Node Red on a Raspberry Pi 3+ - which makes things a little easier for this tutorial. I'm sure it can be done on other platforms but that's beyond my current scope.
• My Switcher is Version 2 (35DA), running Firmware version 72.36. The library I used has only been tested on Switcher Version 3 (and now V2!) - so there's hope if you have a different version.
• Make sure you're running your Node Red and Switcher on the same Wifi network. I don't know if it works between the 5gHz and 2.4 bands, but mine is all running on 2.4.

Getting Switcher's Identity

This part uses the Python script written by Aviad Golan (@AviadGolan) and Shai rod (@NightRang3r) on this github. On their page, they have a really long description, most of it irrelevant if you don't use Home Assistant. All you really need to do is copy switcher.py to your Raspberry Pi, then move to the directory you copied it to.

Once there, run the following command:

sudo python switcher.py discover

This should give you a screen that looks something like this:

From this screen, note down the Device ID and the IP address for later.

Using Nodejs Library

Now that you have the Device ID and IP address, we move over to johnathanvidu's github here.

Step 1:

On the Raspberry Pi running your Node Red, go to the Node Red directory. This is usually acquired by

cd .node-red/

Once there, type:

npm install switcher-js

You may need "sudo" to run this.

This will install the necessary nodejs library in the appropriate place in your Node Red setup.

Step 2:

We're about to change the "settings" file of Node Red. As this is crucial to its operation, you might want to make a backup before you do anything.

While still inside the .node-red directory, type

cp settings.js settings.bkup

Then edit the "settings" file with this:

sudo nano settings.js

Inside the settings file, look for the line functionGlobalContext. (It's a long way down).

Directly below functionGlobalContext type:

switcher: require('switcher-js').Switcher

Once this is done, it should look like this:

Syntax is hugely important so make sure all your commas and cases are right. Close and save.

Step 3:

Now we're going to set up Node Red, but before we do so, I suggest rebooting your pi so that the above changes are implemented.

We're about to use a Function Node. The nodejs code for importing is at the foot of this page.

In Node Red, open a new Function Node and use this code for turning on:

const Switcher = global.get('switcher');  
//complete with your data
var switcher = new Switcher('yourDeviceID', 'yourIP','0000','00000000', console);

switcher.on('state', (state) => { // state is the new switcher state 

});
switcher.on('error', (error) => {  
    msg.payload = error;
    console.log(error)
});

switcher.turn_on();

return msg;  

and this one for turning off

const Switcher = global.get('switcher');  
//complete with your data
var switcher = new Switcher('yourDeviceID', 'yourIP','0000','00000000', console);

switcher.on('state', (state) => { // state is the new switcher state 

});
switcher.on('error', (error) => {  
    msg.payload = error;
    console.log(error)
});

switcher.turn_off();

return msg;  

Use a regular Inject Node to activate.

Error Message

Your Switcher should now be working with Node Red. For reasons I don't understand, I still get this error message on a debug node:

"Error: status report failed. error: bind EADDRINUSE 0.0.0.0:20002"

Google says it's an authorization problem, but with everything working as it should, I just ignore it.

Connecting to Weather

My Node Red follows the weather for my location. Now that I can control my boiler, my weekend project will be to set it up to turn on the water heater only when inclement weather dictates.

Good luck!

Update - 2 weeks later

Not only is my hot water boiler now weather-dependent, but the nodes worked so well that I connected my drip irrigation too. (Irrigation isn't connected to Switcher, but once I'd worked out how to make the boiler weather-dependent, it was very simple to apply the same nodes.) Now the irrigation won't come on if it has rained in the last six hours.

Update - 4 weeks later

We had a power outage and suddenly Switcher stopped working in Node Red. After a bit of fiddling, I realized that its IP address must have changed. I used "switcher.py discover" again, and found it had moved. This time I noted down the device's MAC address, and gave it a static IP address in my router. Once I updated the flow, it came back to life.

Nodejs for importing:

[{"id":"59c46b3.2b3fb94","type":"function","z":"67d04cec.e90134","name":"Turn on","func":"const Switcher = global.get('switcher');\n//complete with your data\nvar switcher = new Switcher('yourDeviceID', 'yourIP','0000','00000000', console);\n\nswitcher.on('state', (state) => { // state is the new switcher state \n \n});\nswitcher.on('error', (error) => {\n msg.payload = error;\n console.log(error)\n});\n\nswitcher.turn_on();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":940,"y":180,"wires":[[]]},{"id":"7a008aa2.8411a4","type":"inject","z":"67d04cec.e90134","name":"Turn on Switcher","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"00 07 * * *","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":730,"y":180,"wires":[["59c46b3.2b3fb94"]]},{"id":"acd82843.d6b578","type":"function","z":"67d04cec.e90134","name":"Turn off","func":"const Switcher = global.get('switcher');\n//complete with your data\nvar switcher = new Switcher('yourDeviceID', 'yourIP','0000','00000000', console);\n\nswitcher.on('state', (state) => { // state is the new switcher state \n \n});\nswitcher.on('error', (error) => {\n msg.payload = error;\n console.log(error)\n});\n\nswitcher.turn_off();\n\nreturn msg;\n","outputs":1,"noerr":0,"initialize":"","finalize":"","x":940,"y":240,"wires":[[]]},{"id":"1732c821.3bb2d8","type":"inject","z":"67d04cec.e90134","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"30 07 * * *","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":750,"y":240,"wires":[["acd82843.d6b578"]]}]