inki - low power wireless epaper device

Project Logs

Collapse

Updated pcb and reflow soldering
caspar • 11/01/2025 at 22:58 • 0 comments

Since the pcb in the meantime contains quite a number of smd parts, soldering by hand became increasingly tedious. So, I changed the placement of the components so that most of the smd's are on the bottom. And took the opportunity to build a poor man's reflow oven using the approach from here: https://github.com/apollo-ng/picoReflow, something I always wanted to try.

Below you see the results, works nicely with an used oven and a bit of tinkering. And, now I can reflow solder also smaller components and those that cannot be soldered by hand - I have a few ideas for what I can use that for in the future.

Before reflow soldering

After reflow soldering
Home automation display - inki-homematic
caspar • 10/17/2025 at 20:34 • 0 comments
As another example for using inki, I implemented an application for use with the homematic home automation system.

Home automation systems collect a wealth of real-time data from sensors and devices throughout your home. While you can always check this information through web interfaces or mobile apps, there’s something uniquely convenient about having key information automatically displayed on a dedicated “electronic dashboard” that you can glance at during your daily routine. Above you see inki displaying live data from our Homematic system - temperatures from HmIP-STE2-PCB sensors, heating control status from HmIP-WTH-1, and power monitoring from HmIP-PSM-2 devices.
https://makertube.net/w/bWefBKAkkHVg7govr5T3QV

Inki-homematic directly connects to your Homematic CCU via XML-RPC, retrieving and displaying live sensor data and device status information. It integrates seamlessly with existing Homematic installations to provide wireless ePaper visualization of your home automation data. In general any homematic device parameter can be read out by configuring inki via the webinterface, see the examples below.

You can easily configure inki-homematic through the web interface, such as from your smartphone. Here’s what the configuration screens look like:

Setup Process:
1. Connect to the inki setup WiFi network
2. Access the web interface at http://192.168.4.1
3. Configure your home WiFi credentials
4. Enter your Homematic CCU IP address and port
5. Add device IDs and value types from your Homematic system
6. Set display labels and update intervals
More info at https://c0de111.github.io/inki/homematic/
New webpage with applications
caspar • 09/30/2025 at 18:03 • 0 comments

A lot more information can now be found at: https://c0de111.github.io/inki/
Webinterface for configuration and firmware updates
caspar • 08/17/2025 at 13:39 • 0 comments

The main point of the inki devices it that you can hang them on the wall, no cables needed, and information is automatically retrieved and displayed on the epaper. However, you also might want to change the settings from time to time, when using desk sharing such as seatsurfing, for instance, you might want to change the room or the logo, when using homeautomation such as ccu-historian maybe you want to query a different parameter. Or simply set the realtime clock. It would be nice to be able to change settings and also upgrade the device in place without the need of a dedicated development setup, and without the need to move the device at all.
For this I implemented a wifi access point mode with lw ip: inki can be started in this mode, it will show the display with the access information (see below) and stay on for 15 minutes. You can now simply connect to inki with your cell phone, tablet or pc to the corresponding access point "inki-setup" and go to 192.168.4.1 in your local network. This will bring you to the setup page:
A short walk through the pages:
Set the wifi credentials for the client mode. This will be needed in the usual client mode.
Settings for seatsurfing, this information can be copied and pasted from your seatsurfing webinterface, it is using the service account (thanks to Heiner from seatsurfing https://github.com/seatsurfing/ for adding it!).
Configuration of the device itself (not all shown): refresh times, timeouts, adc conversion factor, etc.
Upload your own logo, will be written into the pico's flash and show up instead of the small octopus.

Device status page.
Firmware update: Choose the new firmware and upload. The file will be written to the pico's flash, crc checked, and, if valid, and more recent than the current firmware, the device will boot from this version after the next power cycle. This is using a small custom bootloader https://github.com/c0de111/pico_bootloader I wrote. No additional hardware needed, only your cell phone / tablet / laptop / pc.
Set inki's realtime clock using the time of your device. This will use the current date of your device (cell phone / tablet / pc) and set inki's clock to that time.
The webinterface thus gives access to the relevant aspects that are organized in the pico's flash as follows:
RP2040 Flash Memory Map (2 MB = 0x200000)
┌──────────────┬──────────────────────┬────────────┬──────────────────────────────────────┐
│ Address │ Region │ Size │ Description │
├──────────────┼──────────────────────┼────────────┼──────────────────────────────────────┤
│ 0x000000 │ Bootloader │ 64 KB │ Custom bootloader │
│ 0x010000 │ Firmware Slot 0 │ 940 KB │ FIRMWARE_FLASH_SIZE = 0xEB800 │
│ 0x0FB800 │ Firmware Slot 1 │ 940 KB │ FIRMWARE_FLASH_SIZE = 0xEB800 │
│ 0x1E7000 │ Config & Reserved │ 100 KB │ Configuration, logos, OTA buffers │
│ 0x200000 │ Flash End │ │ End of 2 MB QSPI flash │
└──────────────┴──────────────────────┴────────────┴──────────────────────────────────────┘

Firmware slots start at XIP_BASE + offset:
- Slot 0: 0x10000000 + 0x010000 = 0x10010000
- Slot 1: 0x10000000 + 0x0FB800 = 0x100FB800

Notes:
- Bootloader includes 256-byte...
Read more »
inki as display for home automation
caspar • 08/14/2025 at 18:20 • 0 comments

inki can be used to display interesting accessible via wifi, as for instance from home automation systems. In this example I implemented a query for ccu-historian (https://github.com/mdzio/ccu-historian) that is based on the "homematic" system. In the image below the large / 7.5" version of inki displays the temperature of the last 24 hours in our garden. Yes, it was a very hot day!

The operation principle, the hardware and most of the firmware are the same as in the desktop sharing application: inki wakes up at user defined intervals, and in this case queries the raspberry pi running ccu-historian. Thanks to the very well documented API of ccu-historian (https://github.com/mdzio/ccu-historian/wiki#autor-und-lizenz) the data is readily available in the form of a JSON container that is interpreted by the pico. At each wake-up interval the data is updated and plotted - in the example above you simply get a plot of the temperature of the last 24 hours. The possibilities extend to all the data logged in the years it is running at our home, and not only the temperature.

This was another example how to use the device - maybe you have ideas for more?
Idea, prototype zero and power consumption
caspar • 08/09/2025 at 11:55 • 0 comments

The main point of the inki devices it that you can hang them on the wall, no cables needed, and the (room) information is automatically retrieved and displayed on the epaper. For this, I want the circuit to run on conventional batteries as long as possible. However, the raspberry pico W board will consume a current in the mA range in its sleep mode, which effectively gives only a few days operating time. However, I would like to have operating time of years.

But, the board only needs to be active and online at certain times for a short duration when polling the server. For my application, typically about 15 seconds are needed, the online time is only about 3 seconds. More on this later (or on https://github.com/c0de111/inki). So let's build a circuit that is exploiting this!

To implement this application cycle and address the power consumption issue, I use a realtime clock DS3231 in combination with a simple p-mosfet Q1, see schematic. The basic ideas is as follows:

In the default state of the circuit, Q1 is in the off-state and the pico does not get any supply voltage. Two events can switch Q1 on via its gate and thus power the pico: An alarm from the RTC DS3231 via its INT pin, or a manual trigger via pushbutton #0. If this happens, the pico will start, and as a first action in its program pull down the gate from Q2, so that power is maintained even if the push button is released by the user. The pico will then execute its programme and always finish the programme with setting the next alarm in the DS3231, and, subsequently, finally cutting itself off power by switching Q1 off. Never forget to set the alarm, or you will never wake up again! This leaves the pico completely unpowered and the circuit back to the default state. In the default state, the circuits draws a few µA only, compared to several mA in the usual sleep modes of the pico. During the wake cycle, the current drawn is approximately 50 mA for about 15 seconds. The epaper is controlled via SPI, the DS3231 via I2C.

To test this approach I put together a prototype zero, see image at the start. Not exactly beautiful, and tedious to do, but it is good enough for testing and it has all the components (this is with the 7.5" epaper on the backside, not visible). The circuit did what I expected it to (after some mistakes, of course) - but how should I measure an expected current in the off-state in the range of µA? I do not really have a sufficiently sensitive current meter at home, and even if I had, not sure I would trust it ;).

Instead, to estimate the off-state current, I used the following approach: I now have a circuit that is powered on by the real time clock at programmable times and connecting to a server. The pico has an onboard analog-to-digital converter. So, I measure the battery voltage at each wake/refresh cycle, and log it on the server. Each refresh cycle will consume a certain amount of energy, while in the off-state the energy consumption is always present and constant. If I now change the refresh time, I can estimate the off-state current from the scaling, and compare to expectations. The figures below show two examples with a refresh time of two minutes, and 30 minutes, respectively. Note the different timescales of the plot (15 days vs. 198 days)! And, of course, I did not wait for 200 days ;) - this was just running along on its own.

In both cases, inki reaches about 10.000 refreshs, which means battery lifetime is not limited by power consumption in the off-state for these refresh times. Also, this agrees with expectations, see https://github.com/c0de111/inki for details. I use three simple & cheap supermarket AA alkaline batteries. The decay of the voltage seems to follow typical behavior (https://de.wikipedia.org/wiki/Alkali-Mangan-Zelle, chemistry going on!). Overall this means that lifetimes in the range of years are realistic, and also the circuit and firmware...
Read more »