Wiznet makers


Published October 13, 2022 © MIT license (MIT)

0 Projects

0 Resellers

1 Contests

Sabre Wall Light

Sabre Wall Light. An animated light blade that turns on via PIR detection or switch. Colour and animation are set through IoT.

COMPONENTS Hardware components

WIZnet - WizFi360-EVB-Pico

x 1

x 1

1M 144Led Strip

sparkfun - Level Shifter Board

x 1

Software Apps and online services

mqtt - MQTT

x 1

coreMQTT, coreMQTT-Agent from FreeRTOS

WIZnet - WIZnet WizFi360-EVB-Pico-C

x 1

Uses WizFi360 EVB Pico stack, CMSIS_5, CMSIS_DRIVER, FreeRTOS


I’m a self-confessed star wars fan and in this project, I want to build some wall IoT-controlled wall lights that look a bit like Light Sabers. They have an animated turn on and off of the blade. The project uses the new WIZnet WizFi360-EVB-Pico, a RP2040 board with the same pinout as a Raspberry PI Pico.


The concept is for a connected set of wall lights for my hall. Each unit can have a configured blade colour and animation sequence for the turn-on and off sequence. No sound is included. A local push switch will turn the blade on or off. It will also activate via a PIR when I walk into the hall. 

The lights will connect to my network via Wifi and a local MQTT hub, though a public one like Flespi would also work well. The MQTT message is used for the configuration of the colour and animation sequence. It also allows one light to inform the others that it has activated. This allows all of the light units within the hall to turn on together.

The light units are also smart as they know the time of day, using SNTP protocol. At night they are able to move to a different mode, where the light doesn’t turn on it peers. It also animates with a difference sequence. So I can set the lights to be dim and fairly still for a night light effect for any visits to the toilet over night.



The project uses a good set of standard components.

  • WizFi360-EVB-Pico: RP2040 board with Wifi adapter for connectivity and control
  • 144, 1M WS2812B: The LED used to illuminate and animate the blade
  • Logic Level Shifter: Used to drive 5V signal to WS2812B
  • 1000uF Capacitor: Smooth out supply for the WS2812B strip
  • 330Ω Resistor: Signal connection to the WS2812B strip
  • 4x 75Ω (or 91Ω) Resistors for onboard LEDs
  • SPST Non-latching Switch: For turn on or off the blade
  • AM312: Small PIR sensor module
  • 100nF Cap: Power smoothing for the AM312 to prevent false detects
  • 100uF Cap: Power smoothing for the AM312 to prevent false detects
  • 5Amp Fuse and Holder: Main power fuse
  • 100℃ Thermal Fuse: Main power thermal fuse
  • RGB 5mm LED - To use as signal LED
  • Red 1.8mm LED - to use as a pulse LED against the device
  • 6V >5Amp Power Suppl
  • 1m White Acrylic 20mm Tube: The blade cover tube. White so it is diffusing the light
  • 3D Printed Parts: Handle and pommel are 3D printed


The project uses a 5Volt supply and I have used 6Amp switched DC power supply. The WS2812B LED was drawing up to 5Amps at full on. I’ve therefore placed a 5Amp fuse into the circuit and protected from the build-up of heat by using a thermal fuse.

The WS2812B is connected with a 1000uF capacitor to protect the Pico from a brown out when the blade quickly changes power draw. To run 144 WS2812B LEDs in a chain reliably needs a 5V signal. A logic level shifter is used to provide this signal from the RP2040 to the WS2812B. This was a quick, easy and reliable way of generating the 5-volt signal.

The SPST control switch is simple connecting in pull up mode to a RP240 GPIO Pad. The AM312 is also connected into a GPIO Pad as a 3.3v signal device. Capacitors are used to filter the power to the AM312 as these devices are very sensitive and generate false positive signals. 

A 5mm RGB Led is used as a status LED changing colour as the device connects and messages the MQTT broker. A small pulse led is also used on board to let me know the device has not crashed.


The Software Stack

The project uses the WizFi360 drivers from the CMSIS-Driver project and therefore a large set of CMSIS libraries. MQTT is provided using FreeRTOS libraries. Adaption of this to a digital twin framework is done through my own twinThing framework.

  • CMSIS_5 - CMSIS Framework
  • CMSIS-FreeRTOS - CMSIS port of FreeRTOS
  • CMSIS-Driver - WizFi360 Driver
  • IoT_Socket - Socket framework
  • coreMQTT - FreeRTOS MQTT library
  • coreMQTT-Agent - FreeRTOS MQTT Agent library, using FreeRTOS tasks
  • twinThingWizFi360 - Digital Twin library
  • json-make - JSON creation used for the payload of all MQTT messages
  • tiny-json - JSON parser used for the payload parsing of all MQTT messages
  • PicoLED - Used to drive the WS2812B LED via PIO

MQTT Space

The saber wall light conforms to a standard set of control that I use for digital twin management of my IoT devices.  

First of all the device will respond to ping requests to “TNG/<<deviceId>>/TPC/PING” and will respond on the topic “TNG/<<deviceId>>/TPC/PONG”. All devices can also be pinged via the group “ALL”, “GRP/ALL/TPC/PING” and again the device will respond on it’s local PONG channel.

The device retains it’s configuration in a state which is published to it’s digital twin. This is maintained through the topics “TNG/<<device>>/STATE/GET” and “TNG/<<device>>/STATE/SET”. With updates to the state being published on “TNG/<<device>>/STATE/UPD”.
To notify it’s peers or turn on and off events the wall light will publish to the topic “GRP/saber/TPC/on” and “GRP/saber/TPC/off”.


Preserving State

I need to be able to retain the configuration around power loss or reset. I could save this to flash memory. I have chosen to instead hold the data within a digital twin service on the network, and reload the configuration each time the unit reconnects to the network.

The digital twin also gives me the ability to configure all of the saber group devices in one go, rather than load the configuration of each device separately. This is because my twin system understands the concepts of groups and queries across groups. 

The Twin Manager sits on the MQTT network like any other devices. It is actually just python running within a docker service. It also talks to a MySQL database to store the twin state. The database is shared with my MQTT Broker, which is EMQX. The Twin Manager can read the authorisation table to infer groups.

The Saber manager also is a device connected to the Broker, again Python within a docker service. It has an additional browser interface for the configuration. This uses the twin manager to configure all saber devices as a group.


Additional Functions:

The saber also uses the RP2040 realtime clock which is set from NTP. This allows the lamp to be dimmed for nighttime illumination.



A really fun project to build using the WizFi260-EVB-Pico, and a stunning looking result.

  • SaberWIZFi360

    GitHub Repo

  • Schematic

  • Video Guide to Project


0 Projects

0 Resellers

1 Contests

Comments Write