Wiznet makers

JSY Energy Data on ESP32

Mycila JSY App is an Arduino/ESP32 firmware project for Shenzhen Jiansiyan JSY electricity meters. It reads single-phase, two-channel, and three-phase JSY meter data over UART, then exposes the measurements through a local web dashboard, REST endpoints, Shelly-compatible API routes, and a UDP telemetry stream. For WIZnet readers, the relevant point is that the project includes W5500 Ethernet board support for ESP32-S3 targets, so JSY power data can be published over wired Ethernet on boards such as LilyGO T-ETH-Lite ESP32-S3 and Waveshare ESP32-S3 ETH.

The application is written at the ESP32 Arduino networking level with AsyncUDP, AsyncTCP, ESPAsyncWebServer, and MycilaESPConnect. The W5500 appears in selected PlatformIO environments as the Ethernet interface used by the ESP32 network stack. That makes the project useful as an integration example: it shows how a practical energy-monitoring firmware can include W5500-based Ethernet board targets while keeping the same dashboard, API, and UDP telemetry features.

W5500 Board Targets in PlatformIO

The main WIZnet evidence is in platformio.ini. The lilygo_eth_lite_s3 target enables Ethernet support and selects the W5500 PHY type for an ESP32-S3 board with SPI Ethernet wiring:

[env:lilygo_eth_lite_s3]
upload_speed = 115200
board = esp32s3box
build_flags = ${env.build_flags}
  -D ESPCONNECT_ETH_SUPPORT
  -D ETH_PHY_ADDR=1
  -D ETH_PHY_CS=9
  -D ETH_PHY_IRQ=13
  -D ETH_PHY_RST=14
  -D ETH_PHY_SPI_MISO=11
  -D ETH_PHY_SPI_MOSI=12
  -D ETH_PHY_SPI_SCK=10
  -D ETH_PHY_TYPE=ETH_PHY_W5500

The same file also defines a waveshare_esp32s3_eth environment with ETH_PHY_TYPE=ETH_PHY_W5500 and a different SPI pin map. Other Ethernet-capable board targets are present too, including OLIMEX ESP32-PoE, ESP32-GATEWAY, and WT32-ETH01, but the W5500-specific evidence is tied to the two ESP32-S3 targets above.

Dashboard, REST, and Shelly-Compatible APIs

The firmware is built around src/main.cpp. It creates an AsyncWebServer on port 80, starts ESP-DASH at /dashboard, adds ElegantOTA at /update, and exposes WebSerial at /console. For direct integrations, the app registers REST endpoints such as /api/jsy, /api/jsy/reset, /api/jsy/publish, /api/restart, and /api/reset.

The project is especially interesting for home automation because it implements Shelly EM and Shelly 3EM style routes. In the inspected source, routes such as /rpc/Shelly.GetDeviceInfo, /rpc/Shelly.GetStatus, /rpc/EM1.GetStatus, /rpc/EM1Data.GetStatus, /rpc/EM.GetStatus, /rpc/EMData.GetStatus, /emeter/0, and /status are registered in the web server. The firmware maps JSY readings into Shelly-like JSON fields such as voltage, current, active power, apparent power, power factor, frequency, and active energy. That allows platforms already familiar with Shelly energy meters to consume JSY data through a similar HTTP shape.

UDP Telemetry with Message IDs and CRC

For push-style data, the app broadcasts JSY data on UDP port 53964. The callback attached to the JSY library converts the current data into JSON, filters channels or phases based on dashboard publish toggles, serializes the payload as MsgPack, adds a message ID, and appends a CRC32. The sendUDP() function then broadcasts through the active ESPConnect mode: access point, Wi-Fi station, or Ethernet.

The repository also includes examples/Listener/src/main.cpp, a companion listener that receives the UDP packets, validates the message type, checks duplicate message IDs, reassembles multi-packet payloads, verifies CRC32, and deserializes MsgPack back into JSON. This is useful because it documents the expected receiver behavior, not just the sender.

One small documentation caution is worth noting. The README and generated docs describe the UDP message type as 0x02, but the inspected src/main.cpp defines the active value as 0x03, described in the source comment as the newer format with a message ID. The listener example also expects 0x03.

Network Modes for Board Flexibility

In src/main.cpp, ESPConnect reports a current mode such as AP, Wi-Fi station, or Ethernet. The dashboard displays Wi-Fi fields and, when Ethernet support is compiled, Ethernet fields as well. The sendUDP() function uses the active adapter, so the same JSY data path can run on Wi-Fi-only boards or Ethernet-capable boards.

This architecture keeps the application portable across many ESP32 boards. For Wi-Fi-only boards, it can still run as a web energy gateway. For the W5500 ESP32-S3 targets, the same application services can be exposed through wired Ethernet.

Practical Fit for Energy Monitoring

The firmware supports multiple JSY model families and changes the dashboard layout according to the detected meter model. Single-phase meters use one set of cards, two-channel models expose channel swap and Shelly ID remapping controls, and the JSY-MK-333 path exposes phase A, phase B, and phase C data. The per-channel UDP publish switches are persisted with ESP32 preferences, so an installation can choose which channel or phase should be sent to listeners.

The project does not include schematic files, KiCad design files, or a BOM, so hardware wiring should be checked against the selected ESP32 board and the JSY meter documentation. The README provides default serial RX/TX pin mappings for each build target, and the PlatformIO environments provide the strongest evidence for how each firmware image is configured.

FAQ

1.What does this project use the W5500 for?

The W5500 is used as the Ethernet interface for selected ESP32-S3 board targets. In platformio.ini, the lilygo_eth_lite_s3 and waveshare_esp32s3_eth environments define ETH_PHY_TYPE=ETH_PHY_W5500 along with SPI Ethernet pins.

2.What data does the firmware expose?

It exposes JSY meter data such as voltage, current, active power, apparent power, reactive power, frequency, power factor, and energy counters. The data is available through the dashboard, REST endpoints, Shelly-compatible endpoints, and UDP telemetry.

3.Can this be reused on another ESP32 board?

The project is structured for multiple PlatformIO board environments, so porting is mainly a matter of selecting or adding the correct board target, JSY UART pins, and Ethernet settings if needed. W5500 reuse requires the board support and SPI Ethernet pin definitions to match the hardware.