IoT on BlocNotes

Reverse engineer Cubii elliptic bike BLE protocol

Wed, 13 Sep 2023 00:00:00 +0000

Introduction

I recently bought a Cubii under desk elliptical bike, I have two use cases for it:

Physiotherapy after a foot surgery
Help me to warm-up in my cold home office in the winter

Added bonus, doing light exercise. I definitely not find it as enjoyable as using a full size machine, or doing “real” sports, but this is just my preference and I am stuck at home with crutches anyway 😅

So my second hand model is a Cubii pro: no screen to display statistics, but with Bluetooth connectivity, which means that I had to install yet another proprietary app. I doubt usefulness of collecting those data but as it is BLE communications I wondered if it would be easy to reverse engineer the protocol by spying on the frames…
It appeared to be even easier to look into the Android application to find everything I need to dump the data into InfluxDB, and a fun weekend project.

Decompiling the Android application

I never decompiled any Android application but I knew that it was not hard, especially as Java is interpreted and not a compiled language. A quick search pointed me to Jadx, which did all the magic to extract the code from the Android APK to human readable Java files. Then it took only few minutes to get to the interesting code:

Calories conversion

From the class CubiiBleManager:

calories = this.this$0.getCalories(this.$revolutions, (latestCubiiNoLive == null || (cubiiResistance = latestCubiiNoLive.getCubiiResistance()) == null) ? 1 : cubiiResistance.intValue());
distance = this.this$0.getDistance(this.$revolutions);

public final double getCalories(int i, int i2) {
    // Oliv': i=revolutions, i2=resistance selector
    double d = 0.717d;
    switch (i2) {
        case 2:
            d = 0.733d;
            break;
        case 3:
            d = 0.767d;
            break;
        case 4:
            d = 0.833d;
            break;
        case 5:
            d = 0.9d;
            break;
        case 6:
            d = 1.033d;
            break;
        case 7:
            d = 1.267d;
            break;
        case 8:
            d = 1.483d;
            break;
    }
    return i * 0.03d * d;
}

public final double getDistance(int i) {
    // Oliv': i=revolutions
    return i * 1.93E-4d;
}

BLE UUID

From BLEConstants:

Name	UUID	BLE defined
RPM	00001731-2927-efef-cdab-eba0fe583711	No
Battery	00001732-2927-efef-cdab-eba0fe583711	No
Break position	00001733-2927-efef-cdab-eba0fe583711	No
Revolutions	00001734-2927-efef-cdab-eba0fe583711	No
Device info	0000180a-0000-1000-8000-00805f9b34fb	Yes
Software version	00002a28-0000-1000-8000-00805f9b34fb	Yes
Hardware version	00002a27-0000-1000-8000-00805f9b34fb	Yes
Cubii BLE service	00001730-2927-efef-cdab-eba0fe583711	No
Cubii motorized BLE service	6e400001-b5a3-f393-e0a9-e50e9ecadc24	No
Cubii + BLE service	6e400001-b5a3-f393-e0a9-e50e24dcca9e	No
Cubii+ OTA BLe service	0000fe59-0000-1000-8000-00805f9b34fb	Yes

Read BLE value from broadcast

From broadcastUpdate() in file BLEService:

GetIntValue() documentation, constant list here:

Type	Value
Float	52
Sfloat	50
Sint16	34
Sint32	36
Sint8	33
Uint16	18
Uint32	20
Uint8	17

Integer revolutions = bluetoothGattCharacteristic.getIntValue(18, 0);
Integer rpm = bluetoothGattCharacteristic.getIntValue((bluetoothGattCharacteristic.getProperties() & 1) == 0 ? 17 : 18, 0);
Integer battery = bluetoothGattCharacteristic.getIntValue((bluetoothGattCharacteristic.getProperties() & 1) == 0 ? 17 : 18, 0);
// Hardware revision
byte[] value = bluetoothGattCharacteristic.getValue();
// Software revision
byte[] value2 = bluetoothGattCharacteristic.getValue();

Read value from BLE service

From file BLEService:

    private final void readRPM() {
        BluetoothGatt bluetoothGatt = this.mBluetoothGatt;
        BluetoothGattService service = bluetoothGatt == null ? null : bluetoothGatt.getService(UUID.fromString(BLEConstants.CUBII_BLE_SERVICE));
        if (service == null) {
            Logger.INSTANCE.d(this.TAG, "Cubii service not found!");
            return;
        }
        BluetoothGattCharacteristic characteristic = service.getCharacteristic(BLEConstants.Companion.getRPM());
        if (characteristic == null) {
            Logger.INSTANCE.d(this.TAG, "Battery level not found!");
        } else {
            readCharacteristic(characteristic);
        }
    }

Easter egg

There is a small copy/paste typo in BLEService. If the RPM BLE service cannot be found the warning is about the battery :-)

    BluetoothGattCharacteristic characteristic = service.getCharacteristic(BLEConstants.Companion.getRPM());
    if (characteristic == null) {
        Logger.INSTANCE.d(this.TAG, "Battery level not found!");
    } else {
        readCharacteristic(characteristic);
    }

BLE connection mode

Cubii is using connected BLE mode, then either notify you with new data or accumulate them between two consecutive read operations.

Reading data and sending them to InfluxDB

Thanks to Python, the libraries Bleak (BLE) and InfluxDB it was fairly easy:

Connect to the device
Subscribe to notifications
Accumulate/average data for 15 seconds
Write them to InfluxDB
In case of disconnection, restart in 1.

Cubii is sending the data every 3 seconds but I am sending them only every 15 seconds to avoid extra disk space. It could easily be down sampled inside InfluxDB thanks to tasks but yeah, it was not really required in the beginning for the small amount of data, and all the actions are done in the Python code, easier to manager for such small project

Dashboard

As expected I have no real use of the data but it was fun, so I draw the data in Grafana:

Grafana dashboard with the collected data

Code

The Python script is hosted on Gitlab.

Tools

jadx: Decompile and transform Dex to Java
Apktool: Decompile/recompile APK
BLE assigned numbers

Reverse engineer a wireless temperature sensor - Rika pellet stove

Sun, 04 Dec 2022 00:00:00 +0000

I own a Rika Filo pellet stove, which I like, but it is on the expensive side of the market and the Wi-Fi module to remote control it was a no-go. This article describes the way I reverse-engineered the radio protocol.
As it is my sole heating system and winter is coming, I wanted a non invasive approach to avoid breaking anything, so I hooked up a logic analyzer to record the commands sent by the micro-controller to the radio chip, which helped me to learn the RF parameters + actual payload.

1. Hardware

The wireless temperature sensor is really simple:

Battery holder - with polarity inversion protection :-)
ATmega48 micro-controller
TI CC1101 radio transceiver
Temperature sensor in a SOT-23 package?

Fortunately, the ATmega is using a programming port called “ISP”, which shares the SPI port, and there is a nice 0.1" 2x3 header footprint on the PCB. I soldered the pin headers and easily used them to connect a logic analyzer, in order to spy the commands sent by the ATmega. The only missing signal was the chip select, which I found on a pull-up resistor between the batteries.

2. Understanding the SPI commands

I initially used LogicAnalyzer by El Dr. Gusman: a nice project based on Raspberry Pi Pico RP2040, which I recommend. Then I lent it to a friend so I finished with my work’s Saleae device.
As Dr. Gusman’s logic analyzer can export to Sigrok I wanted to use the integrated CC1101 decoder to figure out the commands sent by the device. It did not work, I tried to debug it, figured out that the bug was already fixed, compiled the latest Sigrok then… the decoder was not able to decode my frames for a reason I did not understood. I gave up and wrote a quick and dirty parser which, in the end, would have been a faster solution :).

Fill TX buffer and send data

3. Radio parameters

Decoding the SPI commands gave the following parameters:

Modulation: FSK
Manchester encoding: No
Forward Error Correction (FEC): No
Carrier frequency: 868.317 MHz
Frequency deviation: 19042 Hz
IF frequency: 304.687 kHz
Bandwidth: 203.125 kHz
Datarate: 115051 bauds
Sync mode: 30/32 bits
Preamble length: 32 bits
Sync word: 0x4904
Whitening: Yes (Seed: 0x01FF)
FSK header: implicit/fixed length, ie address and size are not added by the chip
CRC: Yes (16 bits. polynomial: XX, init: XXX)
Transmitted packet length: 5 bytes
Bit shift between preamble and sync word (not in SPI recording, I discovered it later…)

Despite the Sigrok CC1101 protocol analyzer issue, it was not that hard. I had everything I needed to simulate the Rika temperature sensor, so I took a Semtech LR1110 eval board I had laying on my desk, set the right parameters and the payload, flashed the eval board and… it did not work :(

4. Radio analysis

I doubled check each parameter, they where correct. What could be the issue then? Time to look at the FSK signal itself: I used an SDR stick with the wonderful Universal Radio Hacker software to record the transmitted payload and try to understand the issue.

4.1 Preamble

Small detail, the preamble was shifted by one because the TI chip is transmitting 0xAA, but the Semtech chip is transmitting 0x55. Fortunately, the LR1110 allows to select the number of bits of sync word to transmit, so I can added the missing ‘0’ bit before my sync word and set its length to 33 instead of 32.

4.2 What the…Whitening?

Now the difficult part: the preamble and the sync word are the same between both records, but not the payload and the CRC. It has to be a whitening issue! Both chips are using a PN9 algorithm, and I set in the Semtech chip the same init than TI is using: 0x01FF. What next? It took me a while to understand that the CC1101 starts the whitening on the most significant bit of each byte, while LR1110 starts the whitening on the least significant bit!

Whitening: Also called scrambling, is to avoid long series of the same bit. Alternate bits helps the receiver to avoid desynchronization as TX and RX clock do not perfectly match.

4.3 Wrapping-up

Knowing this I was able to implement the whitening in software, and this time, it worked! The pellet stove was receiving my packets :-)

Note: I also had to implement the CRC16 as the whitening is applied to it:

FSK payload, from Semtech SX126x datasheet

5 Payload analysis

5.1 Header

The payload is surprising, in FSK we explicit header can often see preamble | syncword | payload length | address | payload |. In our case, the DIP switch on the board allows to change the second byte, which corresponds to the address but the first byte is always 0x11, so it might actually be a custom Rika header…

=> header is one byte, 0x11

5.2 Address

The second byte is an address directly correlated to the first three DIP switches, 1 is the LSB, and 3 is the MSB:

| Switch #3 | Switch #2 | Switch #1 | Address value |
+ --------- + --------- + --------- + ------------- +
|    Off    |    Off    |    Off    |      0x00     |
|    ...    |    ...    |    ...    |       ...     |
|    On     |    On     |    Off    |      0x06     |
|    On     |    On     |    On     |      0x07     |

Note on switch #4: as written in the documentation it is selecting power output of 1 dBm (Off) or 10 dBm (On).

5.3 Battery

The last byte was more difficult to figure out and I must admit that I decided to not bother with it until I found Hublol’s github project when writing this article, who already did some reverse engineering. Even if the radio parameters are not fully described on Github he found that this byte was the battery. I do not plan to use it, but for the completeness of the reverse engineering I hooked my lab power supply and recorded the value transmitted when I swiped the voltage from 1.8 V to 3 V:

Graph - Sent value = f(supply voltage)

| Supply voltage (V) | Value sent | Trendline |
+ ------------------ + ---------- + --------- +
|         3.0        |     215    |    213    |
|         2.8        |     193    |    193    |
|         2.6        |     172    |    172    |
|         2.5        |     159    |    162    |
|         2.3        |     143    |    142    |
|         2.1        |     118    |    122    |
|         1.8        |      97    |     62    |

=> The function encoded_value = voltage_V * 100.02 - 87.556

5.4 Temperature

I eventually figured out that the temperature is encoded in the first two bytes, it is weird as I was not able to find a “usual” way to encode the temperature… I then swiped the values with steps of 256 and read the temperature displayed by the stove: the conversion is not linear!
As we usually heat around 19°C, I did a linear trendline between 15 and 22°C where I want the highest precision: the room never reached more than 22°C thanks to the stove, and the temperature accuracy below 15°C is not important as the stove need to heat at full power

Graph - temperature = f(sent value)

| Value | Displayed        |           Hublol         |         Trendline        |
|  Hex  | temperature (°C) | temperature (°C) | delta | temperature (°C) | delta |
+ ----- + ---------------- + ---------------- + ----- + ---------------- + ----- +
| 4080  |       2.0        |        -0.80     |  2.8  |         2.4      | -0.4  |
| 4500  |      10.2        |         8.20     |  2.0  |        10.2      |    0  |
| 4600  |      11.9        |        10.20     |  1.7  |        11.9      |    0  |
| 4700  |      13.7        |        12.20     |  1.5  |        13.7      |    0  |
| 4800  |      15.4        |        14.20     |  1.2  |        15.4      | -0.1  |
| 4900  |      17.2        |        16.20     |  1.0  |        17.2      |    0  |
| 4A00  |      18.8        |        18.20     |  0.6  |        18.9      | -0.1  |
| 4B00  |      20.5        |        20.20     |  0.3  |        20.7      | -0.1  |
| 4C00  |      22.4        |        22.20     |  0.2  |        22.4      |    0  |
| 4D00  |      24.0        |        24.20     | -0.2  |        24.1      | -0.1  |
| 4E00  |      25.6        |        26.20     | -0.6  |        25.9      | -0.3  |
| 4EAD  |      26.8        |        27.55     | -0.8  |        27.0      | -0.2  |

=> The function is encoded_value = temperature_celsius * 0.0068 - 109.91.

6. Code

The library to create the payload, as well as the whitening and CRC, is on available on Gitlab.

7. Conclusion

I am now able to replace Rika’s temperature sensor, so I will be able to create a “smart thermostat” and remotely control my stove to rise the temperature when I am returning from vacation, or prevent its start when the sun will heat the house in the next hour or so. Next step is to create a dedicated board to be able to control the remote from LoRaWAN.

I tested it against Rika pellet stove Filo and Sumo, but I am surprised that the temperature encoding differs so much from Hublol’s findings; he might have a more recent stove where they changed the electronics, I will ask him…

LoRaWAN on RAK3172 thanks to ST CubeMX, with VS Code

Thu, 06 Jan 2022 00:00:00 +0000

Kongduino kindly sent me a WisDuo RAK3272s few weeks ago, it is a a breakout board for RAK nice module (RAK3172) around the STM32WL5 system on chip from ST. Let’s see how to use STM32 CubeMX to generate the initialization files and the LoRaWAN stack, then setup Visual Studio code debugger.

1. STM32 CubeMX

Download STM32 CubeMX from ST website, install it as instructed.
Open it then create a new project thanks to ACCESS TO MCU SELECTOR. In the Part Number searchbox look for STM32WLE5CC then select STM32WLE5CCUx and Start Project. CubeMX will now create empty project with only the RF and oscillator pins initialized plus some core peripherals, we have to select the features we want:

1.1 Pinout & configuration tab

Analog -> ADC

Check Vrefint Channel, it will be used by the demo application.

Timers -> RTC

Check Activate Clock Source and Activate calendar. Add the following values in configuration section, tab User constants:

RTC_PREDIV_A: ((1<<(15-RTC_N_PREDIV_S))-1)
RTC_N_PREDIV_S: 10
RTC_PREDIV_S: ((1<<RTC_N_PREDIV_S)-1)

In Parameters Settings tab:

Bin mode: Free running binary mode
Asynchronous predivider value: RTC_PREDIV_A

Connectivity -> SUBGHZ

Check Activated to use the LoRa IP.

Connectivity -> USART2

To send traces (printf) from the STM32 to the computer.

Select Mode to Asynchronous
In Configuration section, tab DMA Settings:
1. Click on Add
2. In DMA request select USART2 TX
3. In Channel select DMA 1 channel 5
4. In Direction select Memory to peripheral
5. In Priority select Low
Tab GPIO Settings should already have:
- PA2 as USART2_TX
- PA3 as USART2_RX

Middleware -> LoRaWAN

Check enabled to add the LoRaWAN stack to the project then in the configuration section, tab LoRaWAN Middleware:

lorawan_conf: select your region
Tx Rfo Config: CONF RFO HP

In tab LoraWAN Application:

Application: End Node skeleton
LoRa App->Active region: Select your region

In tab Platform Settings:

Name	IPs or Components	Found Solutions
ADC	ADC: Vrefint channel	ADC
USART	USART: Asynchronous	USART2
RTC	RTC: RTC Enabled	RTC

Note: If you do not know which EUI/Key to use follow the chapter TTN OTAA Device Registration in RAK’s quickstart.

In tab LoRaWAN commissioning:

Check Static Device Eui
Fill LoRaWAN device eui, App/JoinEUI and Application key

System core -> NVIC

Check SUBGHZ Radio Interrupt.

Pin configuration

On the STM32 picture click on:

Pin PB0: select VDDTCXO
Pin PC14: select RCC_OSC32_IN
Pin PC15: select RCC_OSC32_OUT

1.2 Clock Configuration tab

In RTC Clock Mux select LSE input
MSI RC can be pushed to 48000

1.3 Project Manager tab

Set Project name, then in Toolchain/IDE select Makefile.
The project is ready, click on GENERATE CODE in top right corner.

When generated you can open the folder in your favorite editor, I will use VS Code.

2. Configure the C code

Now the program skeleton is generated but it can not be compiled yet, otherwise the compiler with output warnings like:

#warning user to provide its board definitions pins

We have to provide some specifics about the radio pins. Download radio_board_if_c.patch and radio_board_if_h.patch, place them in the root directory of your project then:

patch -u LoRaWAN/Target/radio_board_if.c -i radio_board_if_c.patch
patch -u LoRaWAN/Target/radio_board_if.h -i radio_board_if_h.patch

3. Compile the binary

Download arm-none-eabi toolchain, add it to your path then it is as simple as make -j.

4. Flash the microcontroller

RAK official documentation is using a serial<>USB converter and the integrated STM32 serial bootloader to flash the firmware, but I prefer an ST-Link as I will also be able to debug the code.

4.1 ST-Link pinout and wiring

You can use an ST-Link or any Nucleo header as long as it is broke from the target board or the jumpers ST-LINK are removed. Then the connector SWD/CN4 must be wired to the RAK module, Nucleo’s serial<>USB converter can be used thanks to CN3:

Signal name	Nucleo header	RAK3272s
VDD_ref (optional)	CN4->1	3V3
SWCLK	CN4->2	SWCLK-PA14
GND	CN4->3	GND
SWDIO	CN4->4	SWDIO-PA13
nRST	CN4->5	RST
UART_TX	CN3->1	UART2_TX
UART_RX	CN3->2	UART2_RX
Power Supply (3.3V)	CN1->1	3V3

4.2 Use ST-Link USB mass storage

You can flash the microcontroler by copy/pasting the .bin file in the ST Link folder.

4.3 OpenOCD

Required only if you want to use the debugger. As of december 2021 most OpenOCD releases does not yet include STM32WL support, it has to be compiled from the sources. The steps are easy for Linux:

git clone https://git.code.sf.net/p/openocd/code openocd-code
apt install make libtool pkg-config autoconf automake texinfo libusb-1.0-0 libusb-1.0-0-dev
./bootstrap
./configure --enable-stlink
make
make install

4.5 VS Code

Install the extension Cortex-Debug if you want to use the debugger, then edit the launch.json file, or create it if required, to have

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceRoot}",
            "executable": "./build/${workspaceFolderBasename}.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "configFiles": [
                "interface/stlink.cfg",
                "target/stm32wlx.cfg"
            ],
        }
    ]
}

5. LoRaWAN uplinks

TTN uplinks in the console

If you have any issue the project is available on Gitlab. The project also contains a populated SendTxData() function to actually send uplinks :)

6. Next steps

Now that we are connected to the network the next post should be about optimizing power consumption and enter in stop mode to only consume µAmps when not sending data.

Update iTead Sonoff Zigbee 3.0 USB Dongle Plus

Sun, 12 Dec 2021 00:00:00 +0000

I recently bought a Sonoff Zigbee 3.0 USB Dongle Plus from iTead to use it with Home Assistant.
While it worked out of the box, the update itself was not complicated but you have to find the right tools…

Update the firmware

The nice Python script cc2538-bsl can be used, but the branch feature/ITead_Sonoff_Zigbee-delay needs to be selected until the pull request is merged.

Install cc2538-bsl

git clone https://github.com/JelmerT/cc2538-bsl.git
cd cc2538-bsl
git checkout feature/ITead_Sonoff_Zigbee-delay
python3 -m venv .venv
source .venv/bin/activate
pip install wheel
python setup.py install
pip install intelhex python-magic

Flash the dongle

Download the firmware from Koenkk’s Z-Stack:

Then use the command

python cc2538-bsl.py -e -v -w --bootloader-sonoff-usb ./CC1352P2_CC2652P_launchpad_coordinator_20211207.hex

Which should output:

sonoff
Opening port /dev/ttyUSB0, baud 500000
Reading data from ./CC1352P2_CC2652P_launchpad_coordinator_20211207.hex
Firmware file: Intel Hex
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:25:6C:59:51
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x0000000
Write 104 bytes at 0x00057F980
    Write done                                
Verifying by comparing CRC32 calculations.
    Verified (match: 0x6dca550e)

After that you can use the nice Zigbee Home Automation integration to easily setup the Zigbee dongle.

Automate shutters with an ESP and Home Assistant

Sun, 12 Jul 2020 18:50:41 +0000

I recently did a proof of concept on shutters automation by hacking the remote control: the idea is to wire the ESP in parallel with the remote control buttons.
My remotes are Bubendorff 41677 but it should work with a lot of other remote controls.

Wemos & the remote control

After poking with a multi-meter it appears that two test points are connected to the right signals:

TP103: Up
TP102: Down

The signal is active low: there is a pull-up resistor and it must be grounded to simulate the activation. A 680 Ohm resistor is used in series with each button of the remote to prevent current overshoot and maybe reduce power consumption, so I also used them:

Schematic

You might not see the resistors on the top picture as I only had SMD 0603 on hand; look carefully :)

On the first attempt, I used the great ESPHome project to simulate pressing the pushbuttons. I just created 3 virtual switches as a proof of concept but for correct integration, a cover component can be used.
I split the configuration into two files: one generic and the other only specifying the shutter name (room) and timings.

Per device file, called shutters-office.yaml in this example:

substitutions:
  # Used for HASS identifier
  name: office
  # Used for friendly name
  switch_name: "bureau"
  # Time from fully closed to fully opened
  full_time: "16s"
  # Time from fully closed to slightly opened
  partially_open_time: "5s"
  # Time for the "button pressed" event
  on_time: "150ms"

<<: !include shutters-common.yaml

Then the generic file called shutters-common.yaml:

esphome:
  name: shutters_${name}
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: "MY SSID"
  password: "MY PASSWORD"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Shutter fallback hotspot"
    password: "12345678ABCDEF"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

switch:
  # Define with GPIOs are used
  - platform: gpio
    id: up
    pin:
      number: 12
      inverted: yes
    restore_mode: ALWAYS_OFF
  - platform: gpio
    id: down
    pin:
      number: 14
      inverted: yes
    restore_mode: ALWAYS_OFF

  # Define template simulating the push on the button
  - platform: template
    name: Shutter ${switch_name} open
    turn_on_action:
      - switch.turn_on: up
      - delay: ${on_time}
      - switch.turn_off: up

  - platform: template
    name: Shutter ${switch_name} close
    turn_on_action:
      - switch.turn_on: down
      - delay: ${on_time}
      - switch.turn_off: down

  # Define template for slightly opening the shutter
  - platform: template
    name: Shutter ${switch_name} slightly open
    turn_on_action:
      - switch.turn_on: down
      - delay: ${on_time}
      - switch.turn_off: down
      - delay: ${full_time}
      - switch.turn_on: up
      - delay: ${on_time}
      - switch.turn_off: up
      - delay: ${partially_open_time}
      - switch.turn_on: up
      - delay: ${on_time}
      - switch.turn_off: up

As there is no feedback information on the shutter state the “slightly opened” state is achieved by fully closing the shutter then opening it for a small amount of time.
Once the ESP8266 or ESP32 is flashed the only thing remaining is to add it to Home-Assistant, thanks to Configuration => Integrations => Set up a new integration => Search for ESPHome => enter the ESP IP address. Et voilà, you are good to go and create powerful automations in Home-Assistant.

On the next version, I used a more clever strategy to command shutters from 0 to 100%, and a LoRaWAN board to allow battery-powered operation - to be published soon.

How to monitor pellet stove's tank

Tue, 26 Nov 2019 12:53:50 +0000

I have a great Rika pellet stove, but despite all the embedded electronics, it is unable to warn me just before the pellets tank is empty. As I already have my own low-power wireless devices and home automation tools, I just added a distance sensor and designed some enclosures.

Pellet stove

Sensor selection

IR sensor

Cheap usual Sharp sensor needs to be at least 10 cm away from the pellets. It is a no go for this use case as pellets are close to the lid when the tank is full

Ultrasonic sensors

As common as the Sharp IR sensor, the HC-SR04 was an option but I discarded it for two reasons:

Dust generated by pellets: sensor difficult to clean
Not working well with a power supply of 3.3 Vdc

STMicroelectronics time of flight sensor

So I went with ST VL53L0X: range adapted to my needs, low power, and it is easy to the clean sensor. Regarding dust, I used it for several months without having to clean it but summer was included, so let’s wait a full winter for feedback.

Hardware

I bought a cheap breakout board from eBay and plug the I2C lines into my NoteRF boards

Software

I just added the library from Pololu to my project then translated the data in Node-Red.

// VL53L0X
if ( sensorType == 7 ) {
    msg.topic = `data/sensor/noterf_distance_${sensorName}/state`;

	var distance = msg.payload.split( "|" )[2];
	distance_percent = 100 - distance/590*100;

	msg.payload = {
	    'rssi': rssi,
	    'battery': battery,
	};

	// Filter abnormal values
	if ( ( distance >= 0 ) && ( distance < 8000 ) ) {
	    msg.payload.distance = distance;
	    msg.payload.distance_percent = distance_percent;
	}
}

Home assistant

As for all other connected things in my house it reports to Home Assistant, which allows a nice interface, that I rarely use thanks to the automation: I am notified on my phone (through pushbullet) when tank level or device battery cross a threshold: the purpose of that device is achieved! Anyway, some fancy displays can be setup in a few seconds:

Tank status gauge - color changes according to the value

Tank status in millimeters - useless as percentage is more descriptive

Icons + values - I have view with it for all my devices

Device battery needs calibration :-)

Mechanics

I designed with OnShape two 3D printed boxes for the sensor and the electronics/battery, both are using magnets to stick in place The sensor is on the tank lid, while electronics and batteries are outside, hidden on the back of the stove.

Design files:

Time of flight sensor - Hot glued into 3D printed box

Enclosure for the electronics and the battery

ESP32 / MQTT - BLE beacon tracker powered by microPython

Thu, 19 Oct 2017 13:47:55 +0000

I am currently working with BLE beacons -only iBeacons for now- with Espressif’s esp-idf libraries. The aim is to use the ESP32 as a gateway to published detected beacons to an MQTT broker. It was surprisingly easy and I will write something about that when the code will be more polished.

Anyway, by curiosity and to speed up development, I wanted to try microPython port to ESP32, and I did. Unfortunately, BLE support is not yet reliable enough and a lot of advertisements were lost with 4 to 6 beacons. This post is to keep track of my work and, hopefully, use in the future when microPython port will be more reliable :-)

microPython compilation

While compiling microPython was really straightforward, I had one issue afterward: I was unable to use the MQTT library, neither by calling it mqtt or umqtt, nor by putting it manually in flash. I did not investigate why but I found that adding it to the “frozen” scripts worked.

The code used is from Pycom with Wipy 2.0 as target. I used this commit against this version of esp-idf.

Clone both repositories, update esp-idf’s submodules
Set PATH to xtensa compilation tools. Be careful to use only version 1.22.0-61 for the mentioned Pycom & esp-idf commits.
Set IDF_PATH to esp-idf directory
Change directory to pycom-micropython-sigfox
run
- cd mpy-cross && make clean && make
- cd ../ESP32/frozen
- wget https://raw.githubusercontent.com/micropython/micropython-lib/a09b3ec20a745cfd1bccb7bd9db513bfe36968db/umqtt.simple/umqtt/simple.py
- cd ..
- make BOARD=WIPY TARGET=boot
- make BOARD=WIPY TARGET=app
- make BOARD=WIPY flash

You can now connect to microPython REPL on your ESP32!

##Python BLE tracker Following is a quick and dirty code I used to test it. It does:

Connect to WiFi
Connect to MQTT server
Scan for BLE advertisements
Send one MQTT message by discovered device

from network import Bluetooth, WLAN
from mqtt import MQTTClient
from binascii import hexlify
import machine
import time
import ujson


def hexlifyNone(object):
    return None if object is None else hexlify(object)


def scan():
    devices = {}
    print("***   Starting   ***")
    bt = Bluetooth()
    print("Scan...", end="")
    bt.start_scan(10)
    time.sleep(10)
    print("OK")
    advs = bt.get_advertisements()
    print(advs)

    for adv in advs:
        devices[hexlify(adv.mac)] = {
            "Mac": hexlify(adv.mac),
            "Rssi": adv.rssi,
            "Data": hexlifyNone(adv.data),
            "MfrData": hexlifyNone(
                bt.resolve_adv_data(adv.data, Bluetooth.ADV_MANUFACTURER_DATA)
            ),
            "NameShort": hexlifyNone(
                bt.resolve_adv_data(adv.data, Bluetooth.ADV_NAME_SHORT)
            ),
            "NameComplete": hexlifyNone(
                bt.resolve_adv_data(adv.data, Bluetooth.ADV_NAME_CMPL)
            ),
            "Flag": bt.resolve_adv_data(adv.data, Bluetooth.ADV_FLAG),
            "Appearance": hexlifyNone(
                bt.resolve_adv_data(adv.data, Bluetooth.ADV_APPEARANCE)
            ),
        }
        """
        print( 'MAC: {}\n\tRSSI: {}\n\tData: {}\n\tName: {}\n\tMfrData: {}'.format(
                hexlify( adv.mac ),
                adv.rssi,
                hexlify( adv.data ),
                bt.resolve_adv_data( adv.data, Bluetooth.ADV_NAME_SHORT ),
                hexlify( bt.resolve_adv_data( adv.data, Bluetooth.ADV_MANUFACTURER_DATA ) )
                )
              )
        """
    print("\n***********\nDevices: ", devices)
    for key, data in devices.items():
        print("\n***********\n", data)
        msgJson = ujson.dumps(data)
        client.publish(topic="/test", msg=msgJson)

    print("***   End   ***")


def sub_cb(topic, msg):
    print(msg)


wlan = WLAN(mode=WLAN.STA)
wlan.connect("SSID name", auth=(WLAN.WPA2, "password"), timeout=5000)
while not wlan.isconnected():
    machine.idle()
print("Connected to Wifi\n")

client = MQTTClient(
    "device_id",
    "MQTT broker address",
    user="user if any",
    password="password if any",
    port=1883,
    ssl=True,
)
client.set_callback(sub_cb)
client.connect()
client.subscribe(topic="/test")
client.publish(topic="/test", msg="Started")
scan()

How to make a LoraWAN GPS tracker

Fri, 03 Jun 2016 20:13:37 +0000

What can you do on a rainy evening when you go to your hackerspace?
Take a NoteRF V2 PCB, a GPS, a battery, and you can make a LoRaWAN GPS tracker!

Solder the PCB

Solder paste rig

Hand solder it or for lazy guys like me, order a $5 stencil from OSH Stencil.
Prepare the rig, apply solder paste, and place components.

Hot plate reflow

Time to reflow in a hot plate, then visual and electrical inspection.

Burn bootloader

Pogo pin rig

Use a pogo-pin rig to easily burn the Arduino bootloader into the ATMega, verify it.

Solder GPS and battery

Everything is soldered and connected

Solder the GPS, the battery, flash the code and another time: test it!

Display data

Node-RED map

Thanks to Node-Red and OpenStreetMap, we can easily grab data from the LoRaWAN operator, decode and display it on a map.

Make a nice box

We now have a battery-operated GPS tracker… what about putting everything in a box?

Laser cutted box

As I use upcycled 18650 lithium elements, the battery is by far bigger than the PCB + GPS, so I decided to design two compartments inside the box. Some lasercut after it is all working !!!

Fully assembled LoRaWAN tracker!

Also, it was not planned, the box sound more like a locomotive than a GPS tracker, so back to the laser cutter to make four little circles and… finished product with a fun design!
I even had some time left for a beer :p

NoteRF V2 - LoRaWAN compatible

Tue, 24 May 2016 11:39:37 +0000

The new version of my NoteRF project, its features are:

New radio footprint for RFM69 (FSK/OOK) or RFM95: LoRaWAN !
Mosfet to switch off sensors or control actuators
Edge connector for external antenna
Mounting slot for 3 mm screws
Fits on a breadboard
3.3V regulator

04/05/2016 - GPS tracker

LoRaWAN GPS tracker

First application : a GPS tracker. More info here

02/05/2016 - All components soldered

NoteRF V2.0 board

Everything is soldered and working, can start a real application! One minor design flow: no pull-down for the interrupt line, easy fix :-)

23/05/2016 - PCB + RFM received

NoteRF V2.0 partly soldered

After soldering, even if I have not received all components, the radio is working on LoraWAN network!

LoraShield

Tue, 24 May 2016 08:54:42 +0000

This project is to try LoRaWAN networks, I designed a simple Arduino shield with RFM95w: LoRa modules from HopeRF.

Main characteristics

Level shifter as RFM95 I/O are 3.3V
SMA edge connector
Jumpers to select RFM’s digital IO
Jumper to be able to change slave select
A little prototyping area

It works with LoraWAN :-p

Now working with LoraWAN networks !!! Code and details soon. Works in class A with pre-provisioning or OTAA, and it is compliant to specification LoraWAN v1.0

Finished LoRa shield

It’s alive!

It emits and receives to a LoRaWAN gateway, need further testing.

First tests

PCB received, need to be tested

LoRaShield PCB

Design done

LoRaShield PCB