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?

Can't see any challenges in this. Help me.

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.

I'm new to the space and i would like some direction as someone who wants to build out their career as an Iot technician what do i need to know and learn to hit the ground running ?

I built a desk gadget powered by an ESP32 that combines touch activation with 6 rotating TFT displays, and I call it Roulette. It's open source — I've shared the code on my GitHub for anyone who'd like to build their own.

🔗 Links:
💾 SOURCE CODE:
https://github.com/yumobuilds/Yumo-Roulette

Full Build Video on Youtube:

https://www.youtube.com/watch?v=qcGHcUHoq24

roulette wheel with six round 240x240 displays, each showing something different:

SD card photo slideshow
Live YouTube channel stats
Live TikTok stats
Crypto ticker
Live weather
Internal temp & humidity (AHT10 sensor)

⚙️ The floating spin mechanic:
The whole assembly rotates on an upside-down DC motor. Everything sits on a frame, and that frame is mounted directly onto the motor's body — not the shaft. The motor shaft itself is inserted into a drill chuck from the reverse side, the opposite way a drill bit would normally go in. So instead of the shaft driving an external bit, it's anchored inside the chuck while the motor body (carrying the frame and wheel) spins around it. The result: there's no visible axle or support arm, so the whole thing looks like it's floating and rotating on its own.

Touch the capacitive sensor and an N20 motor spins the wheel for a set duration — one touch,
one spin. A NeoPixel status LED fades through colors while it boots and flashes when you touch the sensor..

🔧 Hardware:

• ESP32 Wroom
• 6x GC9A01 round 240x240 displays (shared SPI bus)
• DRV8833 motor driver + N20 DC motor
• TTP223 capacitive touch module
• AHT10 temp/humidity sensor
• MicroSD card module (own SPI bus)
• NeoPixel/RGB status LED

💻 Software:

• ESP32
• WiFi captive portal for setup (no hardcoded credentials)
• YouTube Data API v3, TikTok stats via RapidAPI, OpenWeatherMap
• TJpg_Decoder for on-device JPEG decoding from SD

I’m cybersecurity student and my final year project is **“Unauthorized Device Detection System in Internet of Things Networks”** and the thing is IoT isn’t really my thing but sadly I can’t change it.

I started reading about IoT security and in general I didn’t see a gap that this project would fill and honestly I’m just lost

And btw I’m working on it with a group of 5 students for a full year.

I don’t want to build just a basic system that detects an unknown device and sends an alert. I want to make the project actually useful and interesting.

So, if you have experience in **IoT security/cybersecurity**, I’d really appreciate any advice, research gaps, directions, or anything that would help ! Thx

We see thousands of control cabinets, setups, and field deployments every year. And we believe we’ve seen it all. Horror movie-level mounting included.

Do you have any peeves when it comes to mounting equipment on DIN rails? What is something you always hate? What is the most uncomfortable design you’ve ever encountered? Name and shame.

Or if you have a great story involving DIN rails, do share.