WIZnet

Motion is not presence. That is the problem every smart home user eventually meets. The room is still occupied. Someone is reading, working, watching a movie, or lying in bed. But the motion sensor sees nothing. So the light turns off. The HVAC changes mode. The automation feels “smart” right up until it annoys the person in the room. That is why mmWave presence sensors are interesting. Sensy One E1 Pro Multi Sense is a PoE / Wi-Fi mmWave presence sensor designed for Home Assistant. The useful part is not just “another sensor.” It combines presence detection, position/movement data, light/UV sensing, optional CO₂ or air-quality add-ons, ESPHome/Home Assistant integration, and fixed-installation connectivity. From a WIZnet perspective, the interesting signal is the wired path: an always-on presence sensor is exactly the kind of device where PoE / Ethernet makes sense. Less dependence on Wi-Fi congestion. One cable for power and network. Better fit for ceiling or wall-mounted sensors. More stable local automation. The bigger lesson: Smart homes do not get better by adding more triggers. They get better when the system understands the room correctly. What automation has annoyed you most because it detected motion, but not real presence? #HomeAssistant #ESPHome #SmartHome #PoE #Ethernet

Ping is not observability. A device can be reachable and still be a black box. For embedded Ethernet devices, that becomes a real operations problem: Can you read its status? Can you expose OIDs? Can it send traps? Can your NMS tell “online” from “healthy”? That is why we released the WIZnet PICO SNMP-C SDK for ioNIC / W55RP20. It brings SNMP agent support to WIZnet TOE-based Pico platforms, including W55RP20-EVB-Pico. Supported features include: SNMPv1 / v2c / v3. SNMPv3 USM authentication and privacy. GET / GET-NEXT / SET. Traps. MIB-II system group. Custom OID callbacks. Compile-time feature selection. The point is not just “SNMP on a microcontroller.” The point is making small Ethernet devices manageable by real network tools. For gateways, converters, sensors, and industrial nodes: reachable is not enough. Manageable is better. What status do you wish every embedded Ethernet device exposed by default? #SNMP #NetworkManagement #EmbeddedSystems #Ethernet #IndustrialIoT

Your drone is online. You still can’t reach it. That is one of the less obvious problems in BVLOS telemetry. Radio range is only one layer. If the airborne side sits behind CGNAT on LTE, 5G, or satellite internet, the ground station may not be able to open a connection back to the drone. That changes the architecture. This engineering diary looks at that problem through a Pixhawk MAVLink telemetry concept using WIZ-IP20 as a UART-to-Ethernet bridge. The useful part is not “just add a bridge.” It is the trade-off: TCP client mode can help with the “who opens first?” problem. UDP may still be better for latency-sensitive telemetry — if NAT traversal is solved elsewhere. And before any network design matters: Pixhawk telemetry power can be 5V. WIZ-IP20 expects 3.3V VCC. Not a flight-test report. A useful research note. In BVLOS telemetry, what usually hurts first: radio range, NAT traversal, latency, or payload space? #BVLOS #MAVLink #DroneTech #EmbeddedSystems #Ethernet

The drone can send data out. That does not mean you can reach it back. That is one of the more interesting problems in long-range drone connectivity. When a Pixhawk sends MAVLink over LTE, 5G, or Starlink, the radio link is only part of the story. The harder issue is often network structure: the airborne side usually sits behind CGNAT, which means the ground side cannot simply open a connection back to the drone like it would on a private network. That is why this WIZnet Makers write-up caught our attention. It looks at WIZ-IP20 not as a generic Serial-to-Ethernet part, but as a practical bridge between a Pixhawk UART telemetry port and an IP backhaul for BVLOS-style multi-link concepts. What makes the idea interesting: - Pixhawk outputs MAVLink over UART - WIZ-IP20 bridges that serial telemetry into Ethernet - LTE / 5G / Starlink carries the link onward - TCP client mode can help solve the “who opens first?” problem behind CGNAT - UDP remains attractive when low latency matters more than retransmission The really good part is that the article does not stop at “just use TCP.” It actually engages with the trade-off: TCP helps with session establishment, but real-time control traffic may prefer a lower-latency path without head-of-line blocking. It also calls out a very practical integration detail: Pixhawk telemetry power is 5V, but WIZ-IP20 expects 3.3V VCC, so power design matters before anything flies. That is the kind of engineering note we like: not hype, just a real system constraint that changes the design. The bigger takeaway: In drone networking, the challenge is not only wireless range. It is how UART telemetry, IP networking, NAT, latency, and power constraints all meet in one small airframe. Which constraint usually becomes the real bottleneck first in your drone system: latency, NAT traversal, power, or payload space?

The RJ45 is not just a connector anymore. That is the idea behind WIZ-IP20. Normally, adding Ethernet to a serial device means adding more than a port: RJ45. Magnetics. Ethernet controller. TCP/IP handling. MAC address. Serial-to-Ethernet firmware. Configuration tools. That is a lot of design work just to make a UART/SPI device visible on the network. WIZ-IP20 takes a smaller path: put the Serial-to-Ethernet subsystem inside a MAG-JACK form factor. It looks like an RJ45 port. But it is built around WIZnet’s W55RP20 MCU and provides a compact path from serial to Ethernet. For hardware teams, that means less board area and fewer Ethernet-side design decisions. For firmware teams, it means less networking code before a product can speak TCP, UDP, MQTT, MQTTS, or Modbus. And because it comes with a unique MAC address, provisioning becomes one less thing to build from scratch. The point is not just “add Ethernet.” The point is: Ethernet integration can start at the connector. Where would this save the most time in your design? PCB layout? Firmware? MAC provisioning? Field configuration? #EmbeddedSystems #HardwareDesign #Ethernet #SerialToEthernet #IoT

The machine still works. The dashboard can’t see it. That is the quiet problem behind many industrial upgrades. RS-232 and RS-485 devices can run reliably for years: meters, controllers, panels, sensors, legacy machines. But the new system expects Ethernet. Remote configuration. Modbus over TCP. A way to monitor and update without opening the cabinet. So teams face a wasteful choice: replace a working device, rewrite firmware, or bridge the old interface into the new network. That is where WIZ-IP32 fits. It is a compact dual Serial-to-Ethernet module in a MAG-JACK form factor, built on WIZnet’s W55MH32 MCU. What matters in practice: - two serial ports for RS232 / RS485 - 10/100 Ethernet - serial speed up to 1.152 Mbps - TCP server/client and UDP modes - Modbus RTU/ASCII to Modbus TCP/UDP - web, ConfigTool, and AT command setup - local and remote firmware upgrade The point is not “serial is old.” The point is: working industrial devices should not become isolated just because the rest of the system moved to Ethernet. What is one serial device you would rather bridge than replace? #IndustrialAutomation #Modbus #Ethernet #EmbeddedSystems #RS485

An alarm is useless if it never leaves the cabinet. That is the real problem behind field alert systems. The machine can detect the fault. The sensor can report the value. The PLC can raise the condition. But someone still needs to receive the alert. This ESP32-SMS-SRV project is interesting because it separates the two jobs: W5500 Ethernet handles the control side: web dashboard, HTTP API, MQTT, NTP, OTA, remote configuration. The GSM modem handles the alert side: SMS messages, incoming call events, caller ID logs. That split matters. You do not want the firmware to freeze the dashboard while a modem is slowly sending an SMS. You do not want MQTT reconnects to block modem events. You do not want an installed field box that can send alerts but cannot be maintained. So the lesson is bigger than “ESP32 sends SMS.” A reliable alarm gateway needs two paths: one for operations, one for the message that must get out. Where do alerts usually fail first in real systems: detection, network path, notification, or maintenance access? #IndustrialIoT #ESP32 #W5500 #MQTT #FieldReliability Espressif Systems

A small autonomous vehicle can fail before the autonomy even starts. Not because the path planning is wrong. Because the control board mixes jobs that should stay separate. Motor PWM. Relay switching. RS-485 sensors. Vehicle status. Remote telemetry. Debug commands. They do not all belong in the same timing layer. That’s why this STM32 + W5500 vehicle control-board project is worth studying. The STM32 Nucleo F446RE handles the local vehicle I/O: PWM outputs, relays, RS-485, digital I/O, and status indication. The W5500 gives the board a wired Ethernet path for supervision: telemetry, remote commands, diagnostics, and test integration. That distinction matters. Ethernet is not there to “drive the motors.” It is there so the system can report, debug, and coordinate without stealing focus from local control. Small board. Very real systems lesson: Keep time-sensitive control local. Put telemetry and diagnostics on a predictable wired link. What is one signal in a vehicle or robot that you would never put behind an unreliable connection? #Robotics #EmbeddedSystems #STM32 #Ethernet #AutonomousVehicles

Not every Pico project should be wireless. Sometimes the upgrade is a cable. Raspberry Pi just featured WIZnet’s W6300-EVB-Pico2 in its Maker Monday roundup of RP2350-based boards. And the reason it stood out is simple: Some projects need predictable networking more than convenient networking. Low-power web servers. Network monitoring. IoT data logging. Industrial devices. Those are not always “just add Wi-Fi” problems. W6300-EVB-Pico2 brings wired 10/100 Ethernet to the RP2350 world, with a hardwired TCP/IP stack and IPv4/IPv6 support. The lesson is bigger than one board: Wireless is great for access. Wired still wins when reliability, speed, and repeatability matter. Where do you still choose Ethernet over Wi-Fi? https://lnkd.in/gics3sJD #RaspberryPi #RP2350 #EmbeddedSystems #Ethernet #IoT Raspberry Pi Raspberry Pi Foundation

Serial devices are not dead. They’re just stranded. A lot of equipment still does its job perfectly over UART. The problem starts when everything around it expects Ethernet, MQTT, Modbus, remote updates, or a dashboard. That’s where teams often face a bad trade-off: rewrite firmware, replace a working controller, or add a messy gateway next to it. WIZ-IP20 takes a different path. It is a compact Serial-to-Ethernet module in a MAG-JACK form factor, built on WIZnet’s W55RP20 MCU. What it gives you: - UART to Ethernet - 10/100 Mbps Ethernet - up to 921.6 kbps serial speed - TCP server/client and UDP modes - MQTT/MQTTS and Modbus support - OTA firmware update - web, tool, and command-based configuration The lesson is simple: Don’t rip out a working device just to give it a network path. Make the bridge smaller. Make the setup easier. Make the old interface useful again. Where do you still see reliable serial devices trapped offline? #EmbeddedSystems #IndustrialIoT #Ethernet #Modbus #IoT