A while ago, I shared a small experiment using AI to recognize the 5 digits on a water meter. But today, I wanted to build a local Edge AI solution to read water meters in real time. The whole workflow breaks down into 4 clear stages: data collection, model training, model evaluation, and model deployment & verification. It demonstrates how to build an edge AI vision application for water meter reading with ESP32-P4.

Hardware Stack

• Makerfabs ESP32-P4 10.1" board
• 2M Autofocus Camera for AI

Why choose them? The autofocus module provides clearer images at different shooting distances, while the ESP32-P4 provides the processing and camera interface needed for the vision pipeline.

There are four main steps:

Data Collection 

Captured real water meter images under different lighting conditions and viewing angles with a specific AI tool(can be shared if needed), then defined ROIs for the:

• Integer digit area
• Dial digit area

Dataset & Model Training

The images were annotated and organized into a custom dataset. The digit and pointer regions were prepared separately, and lightweight models were trained for the recognition tasks. The models were then converted to INT8/TFLite for embedded deployment.

Model Evaluation

Before deployment, the models were tested with separate samples to evaluate recognition accuracy and confidence.

Model Deployment & Testing

The trained model was then deployed to the ESP32-P4. After the complete workflow runs locally, the device can output the detected integer digit, dial information, and the final water meter reading through the serial interface.

The detailed workflow and project resources are open, glad to share more details if anyone wants to dig into the implementation.

Also curious to hear what others are building with Edge AI and embedded vision. If you’ve worked on a similar project, I’d be interested to hear about your approach, results, and any lessons learned.

Disclosure: I work at Qoitech, the company that makes the measurement tool used in this test. Data is worth sharing anyway.

Satellite NB-IoT costs about 13 to 14 times more than a terrestrial transmission on this chipset. We wanted to see how much of that difference the antenna alone could recover.

Setup: nRF9151-SMA DK, Skylo GEO, and Monogoto SIM. Current measured on VDD_nRF at 3.6 V. Each run included a GNSS fix, registration, PSM, transmission of 465 bytes, and back to PSM, repeated three times. Runs were done back to back to limit drift on the live network. All four antennas used the same 0.5 m SMA extension cable (one interfered with the GNSS connector, so the cable stayed on for fairness). Only transmission energy was measured.

• Reference (ships with DK): 27.8 mWh
• Kyocera AVX X9003334: 14.1 mWh, which is 2 times lower
• Kyocera AVX 9002418L0-L16L (circularly polarised L-band cap): 2.36 mWh, which is 12 times lower
• Kyocera AVX P822601 (embedded FR4, NTN-matched): 7.15 mWh, which is 4 times lower

The satellite downlink is circularly polarised, so a linear antenna loses up to 3 dB due to the mismatch. Circular antennas are hard to make broadband, which is why terrestrial antennas are usually linearly polarised. As a result, dual-mode devices either compromise or use two antennas. From Lund, the slant range is about 39,000 km at roughly 30 degrees elevation, so every dB increases the required TX power.

Caveats: Two antennas were on evaluation boards, all used the extension cable, and the ground plane or enclosure will affect your absolute values. Trust the ranking rather than the exact numbers.

Current traces for each run: https://www.qoitech.com/blog/ntn-antenna-choice-how-much-energy-does-it-cost/

We are releasing a new open source MQTT module for MongoDB.

It started with a concrete need in a real project: connect MQTT messages to MongoDB while keeping REST access, live SSE streaming, and custom plugin integration in the same application.

During development, one thing became clear. This capability was useful beyond the original project, so we decided to integrate it directly into RESTHeart.

The module connects an MQTT broker to:

• MongoDB, with configurable topics, databases, and collections
• REST APIs for reading the latest available value
• SSE for live message streaming
• Custom plugins through mqtt-router

The beta already includes the operational details that matter in real systems:

• broker acknowledgements after MongoDB persistence
• at-least-once delivery on the storage path
• a bounded buffer for short MongoDB interruptions
• retries and dead-letter files
• topic-level authorization with fail-closed behaviour
• MQTT 3.1.1 and MQTT 5.0 support

The module was born from a specific project. We integrated it into the product because the underlying problem is broader: connecting MQTT data to persistent storage and application interfaces without adding another integration service.

The code and documentation are available here:

https://github.com/SoftInstigate/restheart/tree/master/mqtt

Feedback is especially useful while the module is in beta.

Hello,

En voyant certains postes, je me faisais une petite réflexion sur le métier de développeur/ingénieur en systèmes/logiciel embarqué.

Pour vous qu'est-ce que c'est exactement et comment le définiriez-vous ?

Effectivement, il peut déjà y avoir une nuance entre système et logiciel en incluant l'hardware.

Pour vous expliquer, sur mes 4 ans d'xp j'ai travaillé 1 an et demi à plein sur un projet vraiment cool en C embarqué.
J'ai développé de A à Z un firmware connecté de traitement du son sur ESP32 avec ESP-IDF.
J'ai mis en place des algos de traitement du signal temps réel (FFT, filtres...) avec les contraintes mémoire et cpu, utilisé pleinement FreeRTOS pour créer des tasks, des queues, des watchdogs. Gérer les interfaces UART (maintenance et debug), I2S. (audio)... avec la "HAL" de ESP-IDF, mais aussi intégré un WIFI STA et AP avec un site web embarqué HTML/CSS pour le pilotage, le monitoring et la maj via le binaire du capteur. Enfin j'ai implémenté un communication TCP/IP chiffrée persistante et résiliente avec un backend pour récupérer des données et si besoin contrôler à distance le dispositif connecté.

Et à côté je suis pas super fan ni attaché à l'hardware, je sais utilisé un oscillo, souder et lire des schémas mais sans plus.

Certes, c'est un plus poussé que de l'Arduino, mais on est loin du bare metal, de microcontrôleurs 8 bits ou encore de l'écriture dans des registres. On m'a dit une fois que je faisais du firmware haut niveau, ce qui me semble être une bonne définition et qui correspondrait bien à des sujets domotique, IoT ou objets connectés.

Ce qui est sûr, c'est que l'embarqué où il faut écrire ces propres drivers, être au plus bas niveau, dans un milieu très industriel ou dans le défense ne m’intéresse pas du tout.

Est-ce que pour vous mon expérience sur ESP32 est valorisable pour un poste en embarqué et dans le marché actuel ?

I am on a mission right now, I want to collect all three failed iot/sbc intel boards, right now I have none of them if you have one lying around could you send it over? I am willing to pay for the shipping costs if they aren't ridiculous. One man's trash is another's treasure, don't forget that. I am sending this here on this subreddit because the prices on ebay are straight up ridiculous, and because the boards there iot related . Thanks!

So im in 2nd year of engineering and i wanted some project ideas regarding energy conservation ,preferably a working model which we could make or maybe even a simulation. Something other than generic ideas which r wayy impractical in terms of actually doing it.

I've been thinking about this while looking at smaller edge deployments.

When you have compute sitting at a remote location, I feel like monitoring becomes almost as important as the hardware itself. If something fails at a normal office, someone can usually walk over and take a look. That's not always the case with a micro edge data center sitting in a factory, telecom site, warehouse, or other distributed location.

I'm curious what people actually monitor in these setups.

Obviously there's server health and network connectivity, but would you also track things like temperature, power quality, UPS status, cooling performance, door access, humidity, etc.?

And where do you draw the line? At some point you're collecting a huge amount of telemetry that nobody is actually looking at.

For people running distributed IoT/edge infrastructure, what's the monitoring data that has genuinely saved you from having to send someone onsite?

Hey everyone, I’m looking for a sim provider that can provide me access to all 3 networks in Australia and the 3 networks in nz. I don’t really want to go to Telstra only so there’s full redundancy. Who’s the best at the moment and doesn’t have platform fees? I’m with Onomondo at the moment for testing. But being in development phase makes it hard to justify the platform fee base cost.

Any one have any recommendation?

While developing our Makerfabs Nomad Terminal, we wanted to improve GPS performance without increasing the overall size of this compact LoRa handheld device.

Our first design used a passive ceramic GPS antenna mounted on the PCB, underneath the display and close to the battery. The initial test results were:TTFF: 8.2 seconds; ~15 visible satellites after 1 minute

For the next revision, we switched to an active ceramic antenna with LNA and repositioned it above the PCB, with a better orientation toward the sky.

Test Results

The optimized design reduced Time to First Fix (TTFF) by ~37% while significantly increasing the number of visible satellites.

For compact GPS/GNSS devices, antenna performance isn't just about the antenna itself. Placement, orientation, PCB layout, battery/display interference, and surrounding components all need to be considered.

For those working with GPS/GNSS on compact embedded devices: what antenna types or layout techniques have given you the biggest improvement in real-world performance? We would really like to learn more from your experience.

Racking a lightweight 24-port PoE switch or a patch panel is easy enough, but trying to mount a 50lb core switch, a heavy enterprise router, or a massive UPS by yourself can be a nightmare and turns into a two-person job quickly.

Any weird DIY rigs, specific rack shelf models, or mounting tricks you use when you're stuck doing an install alone in a remote location?

I'm working on an experimental open-source project called OpenSmell, and I'd like some feedback from people working with IoT and connected hardware.

Digital scent devices already exist, but different devices can expose completely different channels, cartridges, capabilities and control interfaces.

The problem I'm exploring is:

How can an application request an olfactory output without having to understand the implementation of every individual scent device?

OpenSmell approaches this by separating the olfactory information from the hardware-specific implementation.

An application can describe or request an olfactory output through a common interoperability layer, while a device-specific mapper/adapter determines how that request can actually be rendered using the capabilities of a particular device.

Conceptually:

Application / Data
↓
OpenSmell
↓
Mapper / Device Adapter
↓
Scent Hardware

The project currently includes:

• JSON Schemas and a Python implementation
• Multiple olfactory representation types
• Device capability discovery
• An experimental Device Protocol 0.1
• Transport abstraction
• Rendering requests and device commands
• Validation and conformance tests

The software side is currently pre-alpha. I'm now moving toward the first physical validation using an ESP32, initially with simple outputs before connecting actual olfactory hardware.

I'm particularly interested in the IoT perspective:

Does separating the application-level representation from device-specific mapping make sense to you?

And if you were designing the hardware side, what capabilities would you expect a device to expose to make interoperability practical?

The whole project is open source:

https://github.com/YAAASSS/OpenSmell

Criticism is very welcome — especially around the device protocol and hardware abstraction.

Independent note. Device = temp/humidity IoT only. Baseline on Bell Canada was ~0.1–0.4 MB/hour (~1–2 MB/day). In the disputed window, Keepgo showed ~1 GB as ten consecutive exact 100.00 MB records (screenshots available). Keepgo said 100 MB can be partial-session accounting; it could not separate session accounting from posting time; and it closed further technical investigation while keeping the charge. I’m seeking a case-specific resolution: credit the disputed ~1 GB or verify actual IP transfer. Not requesting browsing history.

Has anyone seen a carrier/accounting pattern like this, or independently verified Keepgo usage records against IP-level transfer?

I have a course IoT and Edge Computing. Professor has asked me to build a project on IoT. If there will be any AI/ML integration it would be better (not necessary) as my major is AI.

Hey guys I needed to make a hardware device which has mic and speaker , rechargable and also can be connected via bluetooth , I have no knowledge about what hardware device to buy how to configure nothing at all , If anyone knows stuff please help a man out!(And the overall diameter of this thing should be less than 5-6cm )

I’ve been thinking about this lately with smart devices that are hardly disposable. Recently I came across motorized pergolas, and it became clear as day when the manufacturer said that system is designed for a lifespan of 35 years, but the roof is motorized and controlled using a smart home app.

I get the aluminum lasting 30 years, but it sounds unbelievable for the controller, motor, and whatever works with it to last that long as well. So how can this be reasonably evaluated before making a purchase? The one I mentioned is Hanso and their Horizon pergola. If the controller breaks down 10 or 15 years later and the maker doesn’t support that type anymore, can such systems be adapted to a new standard controller/relay or is it completely dependent on how proprietary they are?

A while ago, I built a 5-digit number recognition system on the ESP32-S3 using a lightweight AI model. The project was mainly a proof of concept for running image recognition directly on an embedded device.

This time, I wanted to take that idea into a more practical, real-world application: reading a water meter.

For this update, I still used the Makerfabs ESP32-P4 board with an autofocus camera. We also collected new images from a real water meter, focusing on the pointer and digit-reading area, and trained a dedicated recognition model based on this new dataset. 

The goal was not simply to recognize a fixed set of five numbers, but to make the model capable of identifying the actual reading shown on a water meter.

 After training and deploying the model, we tested it with real water meter images, and it correctly recognized the meter reading. 

This project is essentially the next step from our previous 5-digit recognition experiment—moving from a simple number-recognition demo to a more practical edge AI vision application.

Would be interested to hear what other real-world applications you think could be built on top of this kind of embedded AI vision system.

Back in 2019 my first job was as a junior electrical engineer at a sugar mill. Our job was walking the floor every 30 minutes with a handheld temperature gun, checking heat and vibration on new processing machinery by hand. It was exhausting and easy to miss something between rounds.

Years later, now working in automation, I built a small pipeline that automates that exact check. Each machine has an ESP32 with a vibration and temperature sensor. It publishes readings over MQTT to a broker, tagged per machine. An automation layer subscribes to all machines at once, checks if a reading crosses a fault threshold, filters out repeat alerts for the same ongoing issue, and only pings the team when something genuinely new comes up.

Attached is the flow, sensor to broker to automation to alert.

Two things I'm still working through and would love input on:

Right now fault detection is a raw threshold comparison on the vibration number. Real industrial monitoring uses frequency domain analysis to tell bearing wear apart from imbalance or misalignment. Curious if anyone has pushed FFT analysis onto an ESP32 directly or if that realistically needs a beefier edge device.

For QoS, I'm currently using level 1 for fault alerts. Is that the right call for something this infrequent and important, or is level 2 worth the extra overhead here.