Made this little brief with a bunch of radio and rfid modules what are some interesting (barely) legal projects I can do? I’m just getting started and want to see the limits and possibilities with hardware integration

I'm the CEO of 0G IoT Solutions (formerly IoTNet Mexico), and we've been operating the Sigfox 0G network in Mexico since 2016. I wanted to share some real operational data because I see a lot of theoretical IoT discussions here but not much from people actually running networks at scale.

Our numbers (as of 2026):

- 500,000+ connected devices (primarily electric meters)

- 8 million messages processed daily

- 1,000+ base stations

- 200+ cities with coverage

- 60% of Mexico's population under coverage

What actually works at massive scale:

1. Ultra-low power is everything. We have devices running on AA batteries for 5+ years. When you have 500K devices, sending a technician to change a battery is a logistics nightmare. Our meters have a 10-year maintenance-free guarantee. This single factor determines whether a project is viable at scale.

2. 12 bytes is enough. When we started, everyone laughed at Sigfox's 12-byte payload limit. "That's nothing!" But here's the thing — a smart meter reading is just a number. A temperature sensor sends a number. A door sensor sends 1 bit. You don't need 4G to transmit "142 kWh".

3. The "host" antenna model beats towers. Instead of renting expensive telecom towers, we put small antennas on people's rooftops. Regular people who maintain them like their own equipment. Our network availability is higher than European Sigfox networks because Doña María calls us if something looks wrong before our monitoring detects it.

4. Multi-technology is the future. After Sigfox's bankruptcy in 2021 and UnaBiz's acquisition, we pivoted to offering Sigfox 0G + LoRaWAN + NB-IoT. Different use cases need different tech:

- 500K meters with 10-year battery? Sigfox 0G

- Private factory network? LoRaWAN

- Need to send a photo? NB-IoT/LTE-M

5. The hidden costs will kill your project. Hardware + connectivity = 15% of your total cost. The other 85% is cloud, integration, maintenance, security updates, and device management. We learned this the hard way. Our TCO analysis shows the traditional approach costs 71% more than an integrated model over 10 years for a 500K meter deployment.

The biggest surprise: Mexico has 46 million electric meters. Only about 1% are connected today. The market hasn't even started. Same for water — Mexico loses 43% of distributed water due to lack of measurement.

What we got wrong:

- Chasing coverage KPIs instead of revenue (2016-2020). We covered 80% of the population before we had enough paying customers.

- Being single-technology (Sigfox only) when clients needed flexibility.

- Underestimating the Sigfox bankruptcy impact — we couldn't enter water utility tenders for 2 years.

Happy to answer questions about operating an IoT network at scale in Latin America, LPWAN technology comparisons, or smart metering deployments.

---

Disclosure: I'm the CEO of 0G IoT Solutions, the Sigfox 0G network operator in Mexico. Sharing this because I think real operational data helps the community more than marketing.

I was planning to go on vacation for 1 week and my biggest worry was how to supply water to my backyard plants. There are lot of plants and in this summer they need water regularly, otherwise many of them would have died.

So I decided to build a watering system which I can control from app or add schedules, so watering can happen automatically.

I used ESP32, designed and vibe coded backend, Android app, firmware & used an open source MQTT server. Also, created box in OpenSCAD and 3d printed it. From the app I can see live status, turn watering on/off anytime, and add/remove schedules.

So I am back after vacation and all plants are doing well. So now system is working well and I am also thinking maybe I can ask gardener to come less frequently, which can save some money also :).

Some gotchas: Water Usage is just place holder and schedule title for evening mentioned "Morning Watering"
This is still in early phase but functional and working prototype!

TL;DR: Three solar powered bus signs, four and a half years, and no way to know what was going on inside one without driving to it with a ladder. I ended up building the platform myself.

In July I posted here about the IoT platform I built. This is the project that forced me to build it.

Three solar powered bus departure signs run at PVTA stops in Western Massachusetts: Haigis Mall at UMass Amherst (stop 73), the Holyoke Public Library (stop 414), and the corner of Mill and Locust in Springfield (stop 1670). I built and still service all three.

The project came to me in a Teams message from my boss Adam on October 21, 2021: "PVTA wants to reverse engineer the hardware for the solar-powered real-time display at Haigis Mall... All are going to stop working this month as the company is no longer supporting them." The old signs ran proprietary firmware on PIC microcontrollers with 3G modems. Replacement parts were already impossible to find and AT&T's 3G shutdown was on the calendar for February 2022. The agency wasn't happy with the quotes for new signs, so Adam said "Justin can do that." I was an hourly employee fresh out of college writing Ruby on Rails for internal transit apps. My major had been ECE and my passion was hardware though, so he figured it was a good fit.

Remote logging and monitoring were on the wishlist from day one. They were just scheduled behind getting the signs to work at all.

The data plan

The first controller was a Pycom GPy running MicroPython, which I figured would be easier to maintain than C. I was so naive back then. It couldn't reliably talk to the displays, so it was out. Next up was a Blues Notecard and Swan, and that's when I ran into the part nobody warns you about with cellular: the data plan. PVTA had asked for ten seconds of latency, and even at 30 second polling each sign needed roughly 1.15GB a month.

My verdict on the Blues kit went to Adam a day after it arrived: "Bad news, there is no way to circumvent Blues' Notehub which currently costs $0.006 everytime a single sign checks for departure time." Blues came back with a $15,000 bulk credit pitch. I ran their numbers and got them wrong by an order of magnitude (I like to teach computers how to do math so I don't have to). Adam caught it: the credits would have lasted 19.29 years across 5 signs, not the 7.7 months I'd already told the CIO. It didn't change my mind though. A contract with a vendor whose platform didn't let me speak directly to my own data sources wasn't going to be part of this project. The kit went back that spring.

So I moved to a Circuit Dojo nRF9160 Feather. That meant writing the firmware in C on Zephyr, but at least we could use our own SIM cards and the network stack was mine to control. AT&T, which PVTA already had a FirstNet contract with, told us the hardware was "not compatible". Verizon wanted $22 per device per month for 1GB, or $60 for 10GB. Hologram, the SIM the board shipped with, worked out to about $82 a month. My recommendation (shockingly) was Verizon. PVTA was wary of another carrier contract, and from June to mid August 2022 development was blocked waiting on a decision. Then AT&T's FirstNet team reversed itself, and the fleet still runs on FirstNet today.

Keeping them alive

The first retrofitted sign went up at Haigis Mall on August 28, 2023. Adam occasionally drives the Route 38 bus through Haigis Mall, so for two months he was my monitoring system. "How's my sign?" "Off again." The following Monday he reported it off again and I asked if he'd tried kicking it.

The real problem was power. The easy answer was a bigger solar panel, but the transit authority's IT architect said that "could potentially be a nightmare". So I went after the load instead. My first LED panels drew about 2.8W each with no LEDs on at all. A few panel redesigns later the quiescent current problem was solved, and by August 2024 the Haigis sign had "been running happily for a few weeks" without a bigger solar panel.

Of course the signs kept finding new ways to die. December 2024, water got into the Holyoke sign and shorted the backlight wires. The drowned battery lied about itself, reading full for four seconds at 4% charge. January 2025 taught me the ugliest failure chain in the fleet. A battery short resets the microcontroller over and over until the modem trips into what Nordic calls Modem Reset Loop Restriction: every attach attempt blocked for 30 minutes. My firmware reset the controller whenever it failed to retrieve or display prediction data, so it never let the restriction clear without someone intervening. A power fault turns into a device that can't get on the network for half an hour at a time and can't tell anyone why.

What actually worked

1. Returning the Blues kit. A vendor whose platform didn't let me speak directly to my data sources wasn't going to be part of this project, even after the math was corrected.

2. Owning the network stack. Writing C on Zephyr was the price, but it bought our own SIM cards, our own carrier, and a network stack I could fix myself.

3. Cutting the load instead of buying more solar.

What I got wrong

1. The Blues math, by an order of magnitude, after I'd already sent it to the CIO.

2. Using a reset as the error handler. Resetting whenever predictions failed to load is what kept the modem stuck in reset loop restriction, and the restriction made every other issue harder to find.

3. A public misdiagnosis. After a car struck the Springfield sign it kept resetting, and I called it a strike damaged control board. With full debug logging on my bench sign I found the real issue: my own firmware cap of 6 routes against a real time API returning 7, because of "trippers", extra buses scheduled on the same route when demand outruns regular service. I drove buses and dispatched for PVTA. I should have known about the trippers. 3 + 4 = 7. 7 > 6. I raised the cap to 8 and retracted my diagnosis the same day. That had been the main cause of the resets for over a year, and I would have found it the first time if I'd had the logs. But the log history was wiped on every watchdog reset and I had nowhere to send them.

4. Treating remote management as a someday feature. I had prototype server software for data collection and OTA updates sitting with nowhere to deploy it, while Adam's bus route was the monitoring system. That's how the route cap bug lived in the field for over a year.

How it ended

What never existed, through four and a half years of water, heat, dead batteries, and purchase orders, was a way to see any of it without driving to the sign with a ladder and a laptop. In May 2026 confirming the Haigis sign was working still meant Adam watching a bus on the tracker and calling the radio operator as it pulled in: "Haigis sign is working."

The monitoring conversation had happened back in November 2024. The transit authority's IT architect wanted to know when a sign went dark, and so did I. I admitted I'd already built prototype server software for data collection and OTA updates, I just had nowhere to deploy it. Both needed a server. Adam said it in so many words later: "Anyway, I don't want to run a middleware server." The off the shelf IoT vendors billed per request, and against devices polling every 30 seconds the price was too high. Same wall as 2022.

So I made my own platform, in Rust, on the Cloudflare edge. The signs run on it now. It's called PidgeIoT and the fleet was its first tenant. The long version, with dates and receipts, is at https://pidgeiot.com/stories/departure-board/ if you want it.

Happy to answer anything in the comments!

Hey guys,

I’ve been heavily focusing on IoT lately. I've built several hands-on projects using the ESP32, and right now, I’m diving deep into the cloud side of things using AWS IoT Core.

However, I recently talked to some mentors at my university, and their feedback honestly hit me hard. They told me that IoT isn't a viable career specialty on its own. According to them, it has largely been overhyped, there are very few jobs that focus purely on it, and companies prefer to just hire standard Computer Science students and teach them the IoT stuff on the job because "it’s easy."

Now I'm stuck doubting my path. I thought building a niche skill set in hardware-to-cloud integration was valuable, but now I don't know what to think.

• Is it true that IoT is mostly just overhyped buzz?

• Are there actually no "pure" IoT jobs out there?

• For those working in the industry, what does the actual job market look like for someone specializing in hardware and cloud pipelines?

Would love to get your honest thoughts and advice on this.

Just thought I’d share one of my most recent installs! This one is designed to count mating sage grouse (a threatened species). Our monitoring area is about 70 miles down a dirt road with zero cell service. This system uses a mountain top backhaul (three jumps about 200 miles total) to get back to our office where we host a server to automate data collection. A cool example (I think) of improving data transmission for a good cause!

In the attached pictures you can see also the controller I used, the temperature and humidity sensor, anemometer and the one with blue enclosure is the water level sensor. all sensors communicate via Modbus RTU (The modbus module is placed under the esp in the image).
( My family have a small greenhouse and I always liked to make automations but most of commercial systems were too expensive and I decided to build it myself. With what I’ve built I can control irrigation system (one 2.2kw pump and two valves for the main water lines) both sides of the greenhouse to open and close using 4 motors, I have integrated some automations using the temp and humidity measurements also the wind speed.
Some of you might recognize the controller which is a KC868-A16, which is ESP based but is very powerful and has a lot of built in features.
Maybe I should mention that I have previous experience with Industrial Automation and Embedded Systems. )

What do you guys think?

I’ve been testing ESP-VISION on ESP32-S3 and built a small edge AI vision project for real-time object detection.

I put together a standalone real-time object detection demo that runs entirely on the device, with no cloud or external processing.

Technical Setup

• Framework: ESP-VISION + MicroPython

• Model: Quantized AI model loaded from an SD card

• Pipeline: Camera feed → on-device AI inference → real-time display with bounding boxes

• Hardware: MaTouch AI ESP32-S3 with integrated camera and TFT display from Makerfabs

Project Result

The prototype successfully runs real-time target detection locally on the ESP32-S3, demonstrating that lightweight computer vision workloads can be handled directly on an MCU.

This kind of compact Edge AI setup could be useful for applications such as smart cameras and visual sensors, object or people detection, smart home devices, etc.

For me, the interesting part isn't just getting object detection to run, but seeing how much AI vision functionality can be moved directly onto a low-cost MCU.

 There is still plenty of room to optimize the model. What would you build with an ESP32-S3 if you could run lightweight computer vision completely offline? Free to share your ideas!

Actualizing an idea I had on building a custom tracking unit.

Hey guys,
I wanted to share the biggest issues I stumbled across during the creation of a complete IoT platform that took like 2 years from start to finish...

Im gonna sum up the most important aspects, Id be happy to help if youre solving any of these now...

Its a complete IoT platform, meaning we developed the hardware, firmware, backend, frontend and server infrastructure as well...

Its multi-domain as hell, expertise from electronics engineering, microcontroller firmware development, cloud infra, backend and frontend development was needed...

And that's just the tech side, not mentioning the business side...

We designed it as a "platform" - meaning - on top of this platform you could build any other layer so that same platform could be re-used for multiple businesses and brands...

We didn't want to get locked-in into a one-off system, so we layered it like this...

The first upgrade on top of this platform was GPS Tracking system for small field businesses like HVAC etc, but thanks to this layering, we could easily offer multiple systems that look different from the clients perspective, yet the backend interfaces were exactly the same, so the devices could be used the same or slightly modified - using the same interface to the backend...

The only thing we would change was the frontend - the app the clients actually use...

I'll probably start with the hardware side...

We did like 7-8 iterations of PCBs until we tweaked all the annoying issues...

Our first mistake was that we started with using Arduino Nano ESP32 as the core microcontroller... we didn't realize back then neither the hardware nor the arduino firmware was NOT suitable for production use.

It's hobby-class, not production grade.

Here's the list of issues we had with Arduino:
- expensive retail pricing for the hardware (Nano ESP32)
- bugs in arduino source code
- the arduino core is built on top of a particular ESP-IDF version - I guess it was v4.4.3 or so - so even if a new ESP-IDF was released, you were locked in to ESP-IDF 4.4.3 if you wanted to use any native ESP-IDF functions
- very quickly we realized that arduino implementation was not sufficent or our cases so we had to use native ESP-IDF functions as well - we ended up having calls to arduino functions + esp-idf functions as well
- the most annoying issue was that the arduino core was built on top of ESP-IDF using THEIR OWN sdkconfig, so we were literally unable to alter the sdkconfig so enable/disable microcontroller functionality
- the hardware board had LED always on - eats power and couldnt be turned off
- because of the sdkconfig if i recall correctly, you couldnt enable secure boot or code encryption - a MUST for production
- so we moved AWAY from arduino hardware to pure ESP32S3-WROOM chip, yet still kept the firmware with arduino core...
- after more issue we rewrote the firmware to use pure ESP-IDF - no arduino at all...

For production-grade devices, avoid hobby-class stacks or you won't be able go to market...

Another issue was the modem with LTE Cat-M connection...

We used SIM7080G to connect to the internet...

Here started another hell on its own...

The sample codes for these modems show a few AT commands, but that's good for playing in a lab only... you cannot use it like that for a remote device that MUST stay connected and reconnect automatically...

...or you'll lose it and will have to go to the field a fetch it...

These SIM modems have nice datasheet with AT commands but... if there's an error, it only says "ERROR", that's all...

It doesn't tell you WHAT went wrong... so you have to guess - we spent MONTHS trial and error until we figured this whole shit out...

There were issues with SSL certificate formats or chains - but the modem doesn't tell you... it just says "ERROR"... so we had to play with it to find out...

Then the modem can work in 3 modes:
- its own stack - the HTTP(S), MQTT(S) AT commands
- PPP tunnel - its dialling a special number to enter the PPP mode - this is what esp_modem package uses...
- using the TCP stack and tunneling all the layers through it

PPP tunnel enables you to use esp's clients for http, mqtt etc... but you now cannot determine connection status using AT commands... in PPP, AT commands are disabled unless you have multiple UART interfaces available on the modem chip... one for traffic, one for AT commands - we had only one...

We used the modem's own stack for a while... but keep this in mind...

The stack lifetime is tied to the modem's firmware...

Unless you make sure you can remotely update the modem's firmware as well, the stack version will stay the same for the lifetime of the device...

Here's the issue...

The stack has its own TLS stack to connect securely to HTTP and MQTT services...

For example, my modem chip had several years old firmware which allowed only TLS v1.0, which was already DEPRECATED and not safe for use over the internet... that's a problem...

Upgrading the chip manually is not straightforware... the Chinese guys will send you an exe firmware update tool and firmware package that should work, yet in my case the whole update tool didn't... so its another issue to even get it upgraded once...

Another way is to use the TCP stack and tunnel everything through it... so you'd use ESP-IDFs networking that would tunnel the traffic through the modem's low-level TCP stack...

and you would be able to use AT commands to determine connection status as well...

Next.

Testing in a car in the field, the modem disconnects arbitrarily, so you must have a complete solution created around to automatically reconnect...

On top, you must use queues to queue messages because you cannot assume you're connected - you might be not...

After connection we flushed the whole queue to the server... worked well...

We used MQTT for bi-directional communication... worked well...

Connecting to the vehicle over CAN bus was a challenge on its own... especially because in personal vehicles, you must REQUEST a data from the CAN bus to get a reply from it...

meaning...

You're device is NOT passive listener... it's active part of the vehicle's CAN bus once connected...

If your ESP32 crashes or hangs, it can - and it will - block the whole CAN bus so that no other node can send any data, because your device is blocking it...

All lights on your dashboard will start to flash - every error imaginable - from ABS failure to whatever... and you must immediately stop and turn off the vehicle... after 15 minutes, the car resets these errors automatically and everything goes to ok...

You can literally kill yourself if this happened during the ride...

We spent MONTHS designing around this so it was super safe and couldnt happen...

Happened to me many times over while debugging on the parking lot sitting in the car with my laptop on for hours though...

We had to update the PCBs again, add mosfet switches to by default, the CAN is disconnected - and make sure the firmware handles these cases so that it does not block your car...

In trucks it is much simpler... there is passive listener only CAN bus so this massive issue is not there...

Next thing was OTA...

Which we implemented from scratch... so the backend requests OTA via MQTT and the device enters its "firmware upgrade" mode and start to download CHUNKS...

It then verifies checksum, flashes that chunk and go to the next one...

If any error happens, it is simply aborted and nothing bad happens...

On ESP32 platform, if you wanna have OTA, you must have TWO code partitions - ota1 and ota2...

Youre current code is running on either one of these and the other one is unused - ready to be flashed with a new firmware version...

So you copy the code there and if everything is successful, you tell the ESP32 to switch to the next partition and reboot...

On reboot, it will use the new partition...

During the process we send progress/event message to the backend so its knows the status...

This part was thougher as well...

Regarding the backend and frontend and the infrastructure...

We designed it so its scalable...

Used Kubernetes so it was easy to scale... picked TimescaleDB for large timestamped event data database...

Also had classic Postgresql for all other data... but for the ingressed device data, we used Timescale...

The backend was running on Laravel 12 so everything was based on that...

And the frontend on React...

Aside from this... we used EMQX MQTT broker in the cluster to have MQTT connection with the devices...

So the backend sent messages through the broker and the broker sent messages to the backend from the devices...

Worked very well...

We esentially saved all the incoming data, showed important stuff in the frontend - the map, the paths, the real time data like speed, cooler temperature, rpm, and business related data...

But we also sent just for us the diagnostic data - the RAM usage, the SD card space, the device uptime, the MQTT queue size, logs...

We were storing these as well - it was like Sentry for our embedded devices...

Then we were able to PLAY BACK these sessions so we saw vehicles on the map, going through the terrain, tunnels etc... and these diagnostic values second by second in the recording...

Invaluable...

We debugged and fixed many bugs like this simply because we were able to spot important DIAGNOSTIC events on the map...

So we also added these icons to the map like MQTT disconnected/connected, internet connected/disconnected, device booted up (signalled crash), etc...

This was very helpful because we saw patterns... like device crashing everytime we went through a particular part of our highway - where there was a 100m no signal zone etc...

It's been a lot to go over... if you're interested in anything particular, feel free to comment...

Enjoy the weekend!

It can be a real issue to get data from the sensors to your machine. Either you have to buy complex and expensive hardware, or do some programming in C++, with Arduino or Raspberry Pi, write libraries and work on hardware and firmware development. Not to mention, how hard it gets when you have to send the information in the opposite direction. What do you think about solutions for data collection where you can just connect the sensors and get the readings?

The things conference wall of frame. A few years ago it was all PCBs and now mostly products.

Built this and so far so good. Had challenges with the GSM module but works perfectly. Goal is to track vehicles and manage loads.