https://community.element14.com/technologies/internet-of-things/The Internet of Things (#IoT) becomes a popular industry topic and data illustrating perspectives are very impressive: IHS predicts 29.2 billion of connected devices by 2020. Huge opportunity! Let's discuss about technology, market trends and solutionsen-USTelligent Community 12https://community.element14.com/technologies/internet-of-things/f/forum/57151/i-built-micropidash-real-time-web-dashboard-in-under-20-lines-of-micropython-no-cloud-no-frameworkTue, 04 Aug 2026 17:52:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:94854de6-6644-406c-aae4-1db42b05f13eKritishBeen building IoT projects every day for my #100DaysOfIoT challenge and kept running into the same problem — monitoring sensor data from ESP32/Pico 2W in a browser was always a mess. So I built micropidash. real-time web dashboard in under 20 lines of MicroPython. No cloud, no framework. Just shipped v2.0.0 with live sensor graphs — tested with DHT11 on Pico 2W, temp + humidity updating in the browser over WiFi. pip install micropidash github.com/kritishmohapatra/micropidash Would love feedback if you try it!element14 communitymicropythonraspberry pihttps://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237530Fri, 24 Jul 2026 12:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d0a7e6f8-86c1-43ec-91de-42f16d3e983bmichaelkellettThe FP6277 is a boost converter - not a battery charger. You don't need a booster to charge a Lithium Ion battery from USB - just a charger control chip. https://www.adafruit.com/product/259 https://www.amazon.co.uk/Lithium-Battery-Charging-Protection-Functions/dp/B08DQXPNR1/ref=asc_df_B08DQXPNR1 You could then connect the Pico directly to the battery. https://randomnerdtutorials.com/power-raspberry-pi-pico-6-different-ways/#batteries I haven't tried or tested any of the above. I suggest that you do a good bit more web research before spending money. MKhttps://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237529Fri, 24 Jul 2026 11:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d569f81e-89aa-444c-b316-86fe353b57c4GeoForemanHi, Sorry for being a noob. I want to start with the charging unit, I am using FP6277 as charger / booster, I want to connect the 3.7v 4000mA battery to the FP6277 and raspberry pi pico 0 : RP2040, in such a way that it it can charge the battery while connected to usb port and run and boost the voltage as necessary even without connected to USB. It would be helpful if you can send me a schematics so that I would have an idea. I need to see the connection how it is connected also to pico ports. Thanks.https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237528Fri, 24 Jul 2026 11:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a0ebe7c2-23c4-48ac-bb83-0a77643ff39dGeoForemanThanks I will draw it.https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237527Fri, 24 Jul 2026 09:59:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:52adb745-d369-40f2-bffe-dc964990c098dang74Thanks dougwhttps://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237526Fri, 24 Jul 2026 09:58:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0e53e317-cff4-4e11-af1c-5fff82a8e62cdang74Thanks michaelkellett this is what I want to achieve.https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237523Fri, 24 Jul 2026 08:45:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:b88d0e91-d968-4fd1-baf8-3f036a89d04emichaelkellettIf you must have 3.3V you will have a hard choice. To get the most out of a nominal 3.7V Lithium Ion battery you would like to run it down to 3V or even 2.7V. Fully charged it will deliver 4V. For low power stuff you could use an LTC3532 regulator which will do the business: I think this is a quite common approach - and there will be other (and cheaper) chips than the LTC3532 but I've used it and know it works. It is also supported by a good model in LTSpice. The max input voltage for the chip is only 5.5V so don't forget to have some kind of transient clamp on the input. MKhttps://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237519Fri, 24 Jul 2026 07:02:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:fbd70d2e-f7cc-4a19-9364-7bf79eaf52e5dougwSystems that require multiple supply voltages are very common and it is much simpler now to use efficient switching converters to meet these requirements than it used to be. It is very common to generate high voltages with step-up converters.https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/236508Thu, 23 Jul 2026 15:00:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:65816fce-1bf1-4f01-8919-336a330b5c9cdang74In the future I was considering starting a project that will use a chargeable battery. I was thinking of having a SEPIC converter between the battery and my downstream 3.3V devices. The thought process being that it could handle the higher than expected voltages like the 4.2V that you cite and also keep ticking as the battery voltage gets depleted. Do you know if this is a common approach?https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/236506Thu, 23 Jul 2026 13:54:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:76ced377-3ac1-452e-927d-497316f3046ddougwThe battery could have a max voltage higher than its nominal 3.7V , maybe as high as 4.2 V. Pico has a regulator that outputs 3.3V and expects interface signals to be 3.3V compatible. Do you have a specific question about the peripherals you mentioned? Are you looking for a schematic?https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/236501Thu, 23 Jul 2026 13:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d0ff0751-f7fa-4c5d-a511-bba5dc25d743robogaryRecommend you first draw or sketch a schematic and check each component for 3.7v capability. You may need to include 5v circuits as well as 3v circuits. I usually build my own breadboard using convenient connectors for power distribution , usually pcb to screw terminals. Ill include screw terminals for an external fuse and on/off switch.https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problemThu, 23 Jul 2026 03:05:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6eae5dac-c79a-4e21-a08b-07ba3052f3c0GeoForemanHi Everyone, I have a project that needs to connect rp2040, rapsberry pi pico 0 to modules : HW‑357, 3.7v 4000mA battery, usb for charging, now for other sensors Ky-008 ,HC-SR501 , NEO-M8, 3V-5V DC vibration motors ,microSD card breakout board / microSD card Adapter, please include the breadboard..picoraspberry_pi_3https://community.element14.com/technologies/internet-of-things/b/blog/posts/building-a-local-iot-controller-for-a-netflame-stoveWed, 22 Jul 2026 07:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0b9f7cb1-00d3-4e3a-a4d2-12549d596211afernandezHi! I’m writing this post because I’d like to share one of the IoT projects I have recently been working on: a Python application to discover, monitor and control a NetFlame stove directly from the local network. First of all, I want to give some context about this project. Many connected appliances include their own mobile application or web interface, but integrating them with other systems or creating a custom interface is not always easy. In this case, the stove includes a network controller that exposes a local HTTP interface. My objective was to understand how this interface works and build an independent application around it, without modifying the stove firmware or its internal electronics. The result is netFlameIoT , an open-source Python project that automatically finds the stove on the network, communicates with its controller and displays its current state in a graphical desktop interface. The project The project is divided into four main components: A local network scanner A generic HTTP client for stove controllers A high-level NetFlame API A graphical application developed with PySide6 This separation was important because I did not want all the device communication, interface logic and network discovery to be mixed into a single application. Instead, each layer has a specific responsibility and can potentially be reused independently. The complete communication flow is: Scan the configured local network. Find the stove using its MAC address. Create an authenticated HTTP client. Verify that the device responds correctly. Start periodic polling. Convert the raw response into structured data. Send a snapshot of the device state to the graphical interface. Finding the stove on the network One of the first problems was that the stove could receive a different IP address from the router. Using a fixed IP address in the application would therefore work only until the DHCP lease changed. To solve this, I created a small LAN scanner based on nmap . The scanner performs a ping scan over a configurable CIDR range and extracts the IP address, MAC address, hostname and manufacturer information for every detected device. The application then compares the discovered MAC addresses with a reference MAC configured by the user. If the stove is not found, the application waits and repeats the discovery process. By default, a new attempt is performed every five seconds. There is also a fallback mechanism for environments where nmap cannot obtain the MAC address. In that situation, the application tries to establish a real connection with each active IP address and checks whether the device responds like a compatible stove controller. Once the stove has been identified, the discovery process stops and regular device polling begins. Communicating with the controller The stove controller exposes a CGI endpoint that receives HTTP POST requests. Each request contains an operation identifier called idOperacion , together with any additional parameters required by the operation. For example, one operation reads the complete stove status, while other operations change the power state, temperature setpoint, power level or operative mode. I created a generic StoveClient class to handle this communication. The client supports: HTTP Basic authentication HTTP Digest authentication Unauthenticated connections Persistent HTTP sessions Configurable request timeouts Automatic retries after transport errors Operations with additional parameters Parsing of firmware error codes The response returned by the controller is not JSON. Instead, it consists mainly of text lines using a key=value format. The client parses these lines and converts them into a structured response containing the operation identifier, returned parameters, error code and original raw response. This transport layer is intentionally independent from NetFlame-specific operation codes, making it possible to reuse it with other compatible stove controllers. The NetFlame API On top of the generic HTTP client, I implemented a higher-level NetFlame class. This class knows the operation identifiers and parameters expected by the device firmware and provides simpler methods such as: get_data() get_alarms() get_hour() power_on() power_off() increase_temperature() decrease_temperature() increase_power() decrease_power() set_temperature_mode() set_power_mode() The raw values returned by the firmware are also converted into typed Python models and human-readable descriptions. For example, the internal stove state is translated into states such as: Powered off Preheating Starting combustion Running Shutting down Waiting for program loading Alarm state The same approach is used for operative modes and alarm codes. This mapping keeps firmware-specific numbers outside the graphical interface and makes the rest of the application much easier to understand. The API also applies limits before changing certain values. The temperature setpoint is constrained between 12 and 40 °C, while the power setting is constrained between levels 1 and 9. The graphical application The desktop interface was developed using PySide6. I wanted the application to resemble a modern thermostat rather than a conventional configuration utility. The main screen displays: Current room temperature Temperature setpoint Stove state Operative mode Current power level Device alarms Stove date and time Discovered IP address Power control Temperature or power adjustment Mode selection The central thermostat contains two circular indicators. One represents the configured temperature and the other represents the current measured temperature. The application also includes an animated power switch and a row of indicators for power levels 1 to 9. In the current version, this numbered row highlights the active power level. Directly selecting a level from the row is not yet connected to the network worker, so power changes are currently performed using the increase and decrease controls. Keeping the interface responsive Network access must never block the graphical interface. For this reason, all device discovery, HTTP communication and polling are handled by a dedicated Qt worker running in a separate QThread . Two QTimer objects control the worker: A discovery timer that searches for the stove A polling timer that periodically reads its state By default, the stove is polled once per second after the connection has been established. Communication between the worker and the interface is implemented using Qt signals. The worker sends connection events and immutable stove snapshots to the interface. In the opposite direction, the interface emits high-level requests when the user changes the temperature, power state or operative mode. User commands are placed in a thread-safe queue and processed by the worker during the polling cycle. This prevents concurrent HTTP requests and ensures that the UI thread never communicates with the stove directly. Connection recovery Another important part of the project was handling connection failures. The stove may temporarily disappear from the network because of a Wi-Fi interruption, a device restart or a router configuration change. If a polling operation fails, the worker: Reports the disconnection to the interface. Stops the polling timer. Removes the existing client. Clears the stored IP address. Restarts the discovery process. This allows the application to recover automatically when the stove becomes available again, even if it receives a different IP address. Results The final result is a local application capable of discovering and controlling the stove without requiring a fixed IP address. The interface receives a complete device snapshot every polling cycle and updates the temperature, setpoints, state, mode, power and alarm information. Separating the application into independent layers also produced another useful result: the graphical interface is only one possible frontend. The same NetFlame API could later be reused from: A command-line utility A web service A Home Assistant integration An MQTT gateway A mobile application A home automation controller One of the most important lessons from this project was that communicating with an IoT device is only one part of the solution. A reliable application must also handle discovery, authentication, response parsing, device-specific states, reconnection and concurrency. Current limitations The project is currently focused on Debian and Ubuntu systems. The LAN scanner depends on nmap and currently expects it to be available at /usr/bin/nmap . The connection information is also stored in a Python configuration file containing the reference MAC address, network range, username and password. For this reason, the configuration file should not be committed to a public repository or shared with real credentials. The application is intended for use on a trusted local network. The current controller communicates over HTTP, so I would not recommend exposing its interface directly to the Internet. Another current limitation is that the timezone used to display the stove clock is configured for Europe/Madrid. This should become configurable in a future version. The project source code is available here: https://github.com/afernandezLuc/netFlameIoTUbuntupython 3raspberry-piraspberri piraspberrypistoveraspberry_pi_projectshttps://community.element14.com/technologies/internet-of-things/b/blog/posts/sega-genesis-fanatics-can-now-play-their-favorite-games-onlineFri, 17 Jul 2026 18:54:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:151aa5c4-1017-4dc6-b790-2978369a756bCatwellDoragasu’s MegaWifi cartridge placed in a MegaWifi programmer. (Image Credit: doragasu/ Kernel Hacks ) Retrofitting old electronics with new abilities is an obsession I didn’t know I needed. We love playing video games online. But what if we could do that with vintage gaming systems? Now, that’s possible thanks to a project called MegaWifi Addon , created by developer doragasu. This nifty device provides the Sega 16-bit system with online play capability. The Kickstarter video even shows a custom port of Namoc’s Battle City using the MegaWifi Addon. One side of the Mega WIFI Addon connects to the Genesis’ cartridge bus so the 68000 CPU can talk to the hardware. For WIFI, Doragasu integrated an ESP8266 wireless module and a UART chip in the cartridge. The UART bridges the Genesis cartridge interface and the ESP8266 serial interface by converting the console’s cartridge commands into serial data that the ESP8266 understands. The ESP8266 functions like a network co-processor for the console. It doesn’t force the 68000 CPU to implement internet protocols like TCP/IP networking and Wifi communication. Instead, the ESP8266 handles those tasks. The Genesis issues high-level commands while the module does the networking. Additionally, the creator wrote firmware for the WIFI module and a matching library/command-based API for Genesis developers. With the API, the cartridge becomes usable from 68k code and makes software development easier. Developers call pre-built functions that scan Wifi networks, join access points, open TCP or UDP sockets, perform HTTP or HTTPS requests, sync the system clock using SNTP, or transfer data. Those requests are then packed into a command containing a payload length, optional data, and an identifier before the ESP8266 firmware receives those results. Afterward, it processes the request and performs the specified task, such as connecting to a server or making an HTTPS request. It then returns the requested data or an error message. Those results are sent back to the Genesis console. MegaWifi also allows developers to upload ROMs over Wifi rather than using a programming cable or removing the cartridge. In this workflow, the wflash bootloader receives the ROM image and writes it to the cartridge flash memory. This ensures faster development and testing. Along with that, the hardware and API support online gameplay. MegaWifi-enabled titles can exchange player state through the cartridge. That data is then sent to a remote peer over the network to support online gameplay. This MegaWifi Addon concept isn’t just for the Sega Genesis/Mega Drive. It can be adapted for other retro systems. Consoles that communicate with a cartridge or other expansion device could use this technique to add online play. By pairing legacy hardware with a modern Wifi microcontroller over the appropriate bus or interface, developers can add internet connectivity and online features without redesigning the console. For example, wifi Game Boy cartridges shows that this idea isn’t just for Sega hardware. Have a story tip? Message me here at element14.modsretrofitwirelesssega genesisconnectivityinterenetsegacommunication