Can anyone suggest some ai tools for iot based project?!.I'm in my 2nd year pursuing btech cse iot, so I need to do course project but as a team. Me and my team decided a project from sih2026 problem statements it is mostly hardware based so for connections , code, and setting up the components i thought of using chatgpt and Claude but I'm getting so irritated with chatgpt, it doesn't have a clarity on components first it gave like use esp32,dc fans, dht sensor, container right after that it again told to add load cell, led, buzzer, solar...it is making me confuse and hard..whereas Claude after asking few questions, it gives comeback tomorrow...basically rn, i need an ai tools which gives me clear explanation and connecting of components with code, and components needed!!

I created this free BLE course that anyone can take. I feel there are too many beginner level courses but not many good intermediate or advanced level courses.

I am focusing on building a small catalog of IOT courses that helps you build a project and I also discuss field issues/bugs that can be helpful in your career.

Please give it a try and you can always email me if you get stuck on amy step. I will be posting more free courses soon.

Let me know if you want a free course on a specific topic. If there is enough demand I can definitely work on that topic.

Hi everyone,

I’m a Mechatronics Engineer with a background in embedded systems and IoT. A few years ago, I used to tutor beginners and adult learners in microcontrollers and basic IoT to make some extra money, and I really enjoyed it.

I currently have some free time and I’m trying to decide my next move:

1. 1-on-1 Online Tutoring / Mentorship (ESP32, MQTT, basic sensors, etc.)
2. Local Workshops in my community/library
3. Pre-recorded Courses (Udemy / YouTube)
4. Skip teaching entirely and focus on building personal portfolio projects for my engineering career.

Is there still demand for 1-on-1 IoT maybe even basic robotics, or is everything covered by free content now? From a career perspective,would you recommend teaching or focusing purely on engineering projects?

Thanks!

everyone has ever used the lorawan LG280 DR206 and, maybe the LoRa DR124?

TLDR: there is a vendor-operated remote-command-execution channel (the cloud "remote debug" feature), a shared static root password in the image, a root-SSH enable switch, and a pre-provisioned outbound SSH key to a Nanoleaf AWS host. That's a meaningful attack surface that all funnels through Nanoleaf's cloud and their key management. If that cloud path or signing key is compromised, so is the device.

I've got enough to give you a solid assessment. I pulled the firmware, confirmed it's not encrypted, unpacked it, and went through the accounts, services, and the vendor daemons. Here's what's actually in your Hexagon (Shapes) firmware.

What the firmware is

- Shapes 12.3.2

- Standard OpenWrt 19.07.4 (ramips/mt76x8, a MediaTek MT76x8 MIPS SoC), uImage kernel (Linux 4.14.195, LZMA) + xz-compressed SquashFS rootfs. Built 2020-09-06.

- The image is signed (signify: "signed by key ---------------------"), and the kernel header labels it a "Local build key" — so these public S3 images are signed with a dev/local key, not a hardened production signing key. The GPL kernel/BusyBox sources aren't published, which the reference notes flag as a likely GPL violation, but that's a licensing issue, not a security one.

So: nothing exotic, just an old OpenWrt build. I unpacked the whole root filesystem and read it.

The things worth your attention

1. Vendor remote command execution over the cloud (the real headline).

/sbin/cloud_daemon connects to Nanoleaf's MQTT broker (-----------.nanoleaf.me, tokens from apollo.nanoleaf.me / iaso.nanoleaf.me) and implements a feature it calls "remote debug." On receiving a message it logs Got an remote debug request. The command is: [...], parses it into arguments, forks, redirects stdin/stdout/stderr through pipes, and runs it (system/execv). In other words: Nanoleaf's cloud can push a shell command to the controller and get the output back. It also has an "upgrade" path that fetches and flashes firmware from a URL the cloud supplies.

This is the capability most people would call a "backdoor." The honest framing: it's a vendor remote-management channel, not a hidden third-party implant. It's gated behind their cloud auth (device tokens), only works while the device is internet-connected and talking to their broker, and is a known pattern for IoT "remote support / OTA." But it is genuinely remote code execution controlled by Nanoleaf (and anyone who compromises that cloud path), and it's not something you can see or disable from the app.

2. A static root password baked into the image.

/etc/shadow has root:XXXXXXXX — a weak MD5-crypt hash, identical in every unit running this firmware (2020-era). I did not and won't try to crack it, but a shared, firmware-embedded root password is a textbook weakness. It only matters if someone can reach a root login surface (see #3).

3. SSH present, off by default, root login allowed when on.

Dropbear is installed. /etc/config/dropbear ships disabled (enable 0) but with RootPasswordAuth on. /sbin/system_manager has a command sequence (COMMAND_SEQUENCE_SSH_ENABLE) that flips it on, starts dropbear, and touches /nanoleaf_config/ssh_enabled. So SSH isn't running out of the box, but there's a built-in switch to turn on root SSH — and #1 is one way a command could reach the device to flip it.

4. A bundled SSH identity + a hardcoded AWS host.

/root/dropbear is an SSH private key, and /root/.ssh/known_hosts pins one host: ------------.us-west-2.compute.amazonaws.com. Combined with the ssh/dbclient binaries present, this means the device is provisioned to make an outbound SSH connection to a Nanoleaf-controlled AWS box (log upload / remote support / possibly a reverse tunnel). Worth knowing, though an outbound connection the device initiates is less exposed than an open inbound port.

1. Telemetry, as expected. Data collector (my-test.nanoleaf.me/datacollector/receive), reliability collector (collector.nanoleaf.me), auto firmware-check on a timer, log upload via curl to firmwareupdate.nanoleaf.me/uploadlogs.

Bottom line

No hidden third-party malware or sketchy foreign callback — it's a stock OpenWrt device. But your instinct wasn't wrong: there is a vendor-operated remote-command-execution channel (the cloud "remote debug" feature), a shared static root password in the image, a root-SSH enable switch, and a pre-provisioned outbound SSH key to a Nanoleaf AWS host. That's a meaningful attack surface that all funnels through Nanoleaf's cloud and their key management. If that cloud path or signing key is compromised, so is the device.

If you want to shrink the exposure without modifying firmware: put the Hexagons on an isolated VLAN/guest network with no inbound access and block their outbound internet (they work fine on LAN-only / local HomeKit — you just lose cloud features and OTA). That neutralizes #1 and #4 in practice.

❯ is there a microphone / ability to record audio or analyze audio or send audio built into the firmware?

Good question — Hexagons do have sound-reactive scenes, so there's likely a mic. Let me check what the firmware actually does with audio.

No ALSA, no /dev/snd or /dev/dsp, no audio libraries, no sound kernel modules. The only audio-adjacent thing is the "Rhythm" subsystem. Let me confirm how it works, since that's where any mic would be.

Clear answer: yes, there's a microphone, but the firmware on the main controller never touches raw audio. Here's the actual architecture I found.

There's no audio stack on the Linux controller at all

The main brain (the OpenWrt/MIPS controller) has nothing to capture or process audio:

- No ALSA, no /dev/snd, no /dev/dsp, no audio codec or FFT libraries.

- No sound kernel modules.

- No raw-audio buffers, no PCM/WAV handling, no sample-rate constants (I grepped for 8000/16000/44100/48000), no .raw/.wav/.pcm file paths anywhere in PixelCC.bin or RhythmCommunicator.bin.

So the Linux side cannot, with the code that's shipped, record or store a sound clip.

The mic lives on a separate dedicated chip (the "Rhythm" module)

The microphone and all audio DSP sit on a separate Silicon Labs Gecko microcontroller — the "Rhythm" subsystem. That's what rhythm.gbl is (a Gecko Bootloader firmware image for that MCU, a different CPU architecture entirely). On Hexagons this is built into the controller; on older panels it was the plug-in Rhythm module.

The Linux controller talks to that chip over a plain UART serial link (rhythm_driver.ko / serial_driver.ko, driven by RhythmCommunicator.bin). What the controller does with it:

- RhythmEngine::enableMicrophone(bool) — the mic is explicitly switched on/off; it's only enabled while a sound-reactive scene is running.

- selectSoundFeatures / getSpecificSoundFeature(SoundFeatureId) / readRhythmMetadata / getAgcPreGainValue — the controller requests and reads back processed "sound features" (beat/energy/frequency-band style summaries). The FFT/beat detection happens on the Gecko chip; Linux only ever sees these abstract numbers, not an audio signal.

What leaves the device

On the LAN API (PixelCC.bin's OpenAPI) the sound-related fields are just state and the live visualizer feed: rhythmConnected, rhythmMode, screenMirrorRhythmMode — on/off, which mode, and the feature stream that drives reactive effects. I found no code path that uploads audio, or even the sound-feature data, to Nanoleaf's cloud. The cloud service publishes command/response and firmware/health messages, not an audio or audio-feature stream.

Newbie here

im thinking of using ESP8266 for my home automation project.

i just need to control 3-4 components fan, lights etc etc.
is it the ok for an entry level?
pls dont roast me lol

hii Hi guys! I hope you’re all doing well.

I’m a BTech sophomore studying CSE, and I’m participating in a national-level hackathon with my team. We’re working on an IoT-based project, and this is my first hackathon as well as my first IoT project.

My main goal right now is to research and design the system architecture, particularly how data collected by hardware components, such as sensors, will be processed by the ESP32 module and sent to our backend in JSON format. I’m also trying to understand which scripts need to be written on the ESP32 and how the communication between the hardware and backend should be implemented.

I’d be really grateful if anyone could share some useful learning resources or tutorials on these topics. If anyone has experience with IoT development and could offer some guidance, that would be amazing!

I apologize if I’ve missed any important details about the project. I’d be happy to provide more information if needed.

Thanks in advance!guys , i hope you all are doing well , i am a btech sophomore , studying cse, so i along with my team is participating in a national level hackathon so we are working on an iot based project this is my first hackathon and first iot based project so my main aim for now is do research and make an architecture that how hardware data like we have used sensors esp32 module etc will be sent to out backened in json format which script will be written in esp etc so i would be thankful if anyone of you can help me with resources to learn or maybe themseleves im sorry if i didnt include some necessary details you need to know about the project, thanks

Hey, I am a first year B.Tech CSE (IoT) student from India. Here in India, IoT is more niche and a lotta people don't even know what IoT is (ngl I didn't know too until I joined this course). Even now, I am not sure I have a good enough understanding of what IoT is. I want to build a good understanding of IoT, get my hands on it , explore & experiment a lott AND build a good student profile. Where do I start? What projects do I do? Any resources?

Hey everyone,

I got tired of monthly subscriptions for simple IoT monitoring, so I built 100% free, open-source cold-chain monitoring platform.

You can deploy your own Django server on PythonAnywhere in about 30 minutes using a one-click Bash script. It handles real-time telemetry, PDF reporting, and live charts. It also has a Windows Desktop App (available in the Microsoft Store) that acts as a firmware generator for ESP32, ESP8266, and Raspberry Pi Pico W.

No monthly fees, no data harvesting, just your hardware and your server.

Links:

• Step-by-Step Guide: youtube video
• GitHub (Server): https://github.com/AdminOceanremote/oceanremote-own-hosting
• GitHub (Desktop App): https://github.com/AdminOceanremote/OceanRemote-WPF
• Microsoft Store: https://apps.microsoft.com/detail/9PGTCMSM3TQS

The guide is fully written with screenshots. Let me know what you think!

Watch the video tutorial: https://www.youtube.com/watch?v=jwu82rBBvZw

I’ve successfully implemented point-to-point wireless image transmission using two custom-designed LR2021 nodes at Makerfabs.

Traditional LoRa sensor applications focus on small data packets; this demo explores the LR2021's capabilities for larger data transfers. 

I used two nodes equipped with Makerfabs-designed LR2021 modules; I've successfully demonstrated point-to-point wireless image transmission. All the transmission information can be shown on the OLED display.

Technical Highlights

• High-speed FLRC: Supports PHY data rates up to 2.6 Mbps.
• FLRP Protocol: Supports high-speed burst transmission, data segmentation, acknowledgments, and retransmissions.
• Flexible Applications: Enables exploration of larger data transfers, including images, firmware updates, and remote monitoring.

Ongoing Research

With basic wireless image transmission working, I’m now evaluating actual transfer throughput, effective communication range, link reliability under interference, and power consumption during high-speed bursts.

I’d love to hear your thoughts and ideas on LR2021. What applications would you explore with it?

hi,
my friend needs some survey submissions for his master degree.
he doesn't have reddit so I'm posting this on his behalf.

please participate 😁

google forms survey

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!

Organizing everything like before 😂

I built a smart alarm and it works great but I want cellular backup. I'd like something cheap but reliable since this would only matter if/when my internet is down. I don't need very much data. I was looking at 1nce since it's supposedly a one time purchase for 10 years but it looks like it's just for businesses? Technically I run a business but it's not really related as this is a personal project. I'm not sure if that matters. Then shipping the sim was gonna cost more than that actual sim/data. That's not bad if it actually does what I want but I didn't want to spend that and then find out it doesn't work for what I want. Any suggestions? Any experience with 1nce?

*edit... Anybody heard of keepgo? It seems simliar to 1nce with no data expiration and different data amounts.

What sensors have you found most reliable in harsh production environments?

I’m looking for sensors for detecting metal parts.

There’s some dust, vibration and occasional oil around the equipment, so reliability and avoiding false signals are more important than getting the cheapest option.

What sensor has worked out best for you? And in your experience, are failures more often caused by the sensor itself or things like mounting, cabling, contamination, vibration, etc.?

Anything else I should watch out for?

Hi all I have recently published something I built and find useful often. I used this base Framework to create my own IOT devices for my house.

I am publishing it in the hope that it gets a little traction as a open source project and we can work together on IoT security, implement matter and Google home and perform research.

Even a couple of code reviews or suggestions on improvements are appreciated. You can find the project on my git hub here : https://github.com/awaine93/espBaseFramework

Not a project, just curious how people actually solve this.

Scenario: remote site, primary link is cellular, but it drops out for days at a time. I don't need a broadband backup. I just need a best-effort path for a heartbeat and the occasional small reading or exception push while the main link is down.

Starlink feels like overkill in cost and power for a few hundred bytes a day, so I keep landing on NTN sat IoT modules as a thin secondary channel.

For anyone who's actually deployed one of these:

- What heartbeat interval did you settle on, and what did it do to your power budget?

- How did real-world delivery rate compare to the spec sheet? Any messages that just silently never arrived?

- Any winter gotchas? Snow on the antenna, battery derating in the cold, that kind of thing.

My uninformed guess is that a 15-minute heartbeat on NTN is totally fine on a modest solar plus battery setup, and that antenna sky view matters way more than the interval. I suspect people who've run one through a real winter will tell me I've got that backwards. What held up for a full year for you?

About me: 3 years as Business Ops & Systems Lead at a 200+ person manufacturing plant, working with operators and maintenance every day. I know where plants lose time and what gets adopted on the floor.

I want to build sensor-based products for factories. Looking for a partner who knows hardware and IoT, has native or native-level English, and is comfortable in front of customers.

DM me.

so at work, we kept running into delayed location updates and sluggish sensor processing in our fleet system. Initially blamed the software... turns out the onboard chip was struggling to keep up.

that got me looking at mediatek’s work in transportation and fleet management. their better connectivity and onboard processing can make a real difference when vehicles need to send reliable data on the move

makes you wonder how many software bugs are actually hardware bottlenecks... anyone here run into something similar with an IoT deployment?