My washing machine had technically told me it was finished. The notification landed, my phone buried it under two messages and a calendar reminder, and the wet clothes sat there for another hour. That is the small, slightly ridiculous problem this build fixes. A Divoom Pixoo-64 can turn the few smart-home events that genuinely matter into something you notice from across the room.
One boundary first: this is not a native-MQTT feature guide. MQTT is the inbox, not the display driver, and Pixoo-64 is not a native MQTT endpoint. Node-RED decides whether an event deserves the screen, and Node-RED turns that message into an HTTP request for the Pixoo-64. Think of Node-RED as the translator and the display as the bright little sign on the door. That extra bridge is the whole trick—and the reason you can make it much smarter than “show every notification.”
The video gives you a useful feel for the Pixoo-64 as a smart-home endpoint. Our route is a little different: instead of building a full dashboard, we are going to make a narrow alert pipeline that stays quiet until something worth seeing happens.
The Three-Part Bridge: Inbox, Translator, Pixel Sign
The temptation is to start dragging nodes onto a canvas immediately. Hold that thought for one minute. If each part has one clear job, the flow remains understandable six months from now. If every part tries to do everything, you get the kind of automation that works beautifully until the first router reboot.
| Layer | Its one job | What it should not do |
|---|---|---|
| MQTT broker | Receive events from sensors, Home Assistant or other publishers | Know anything about pixels, fonts or screen layout |
| Node-RED | Filter, format, prioritize and rate-limit each alert | Forward every sensor update without judgment |
| Pixoo-64 | Show one glanceable state on its 64×64 LED canvas | Act as a native MQTT endpoint or replace a full dashboard |
This separation also keeps the new build from stepping on a good setup you may already have. If your real goal is rotating Home Assistant pages, entity cards and HACS configuration, start with our Pixoo-64 Home Assistant dashboard guide. Stay here if your goal is simpler and sharper: “when this event happens, put this message on the physical screen.”
Build the Smallest Useful Node-RED Flow
Start with one topic and one alert. Mine would be home/laundry/state, because it has an obvious moment when the screen becomes useful. The minimum flow looks like this:
MQTT in
→ JSON
→ Switch (only DONE)
→ RBE (ignore repeats)
→ Function (build alert)
→ Delay (rate limit)
→ HTTP Request (Pixoo control layer)
→ Debug / CatchThe MQTT-in node subscribes to the topic. JSON turns a string payload into an object. Switch throws away the states you do not care about. RBE—“report by exception”—allows a value through only when it changes. Then the Function node creates one small, predictable message for the display:
msg.alert = {
title: "LAUNDRY",
value: "DONE",
color: "#55E6A5",
priority: 2,
ttl: 120
};
msg.method = "POST";
msg.headers = { "Content-Type": "application/json" };
msg.url = "http://PIXOO_IP/post";
msg.payload = {
Command: "Draw/SendHttpText",
TextId: 1,
x: 0,
y: 24,
dir: 0,
font: 2,
TextWidth: 64,
speed: 20,
TextString: msg.alert.title + " " + msg.alert.value,
color: msg.alert.color,
align: 1
};
return msg;In the HTTP Request node, use the method and URL already carried on the message and return a parsed JSON object. A successful Pixoo request normally returns an error_code, but there is an important display-mode wrinkle: scrolling text is an overlay and may not appear over every existing clock or gallery view. For a dependable alert canvas, prepare a background frame first or let a Pixoo helper library handle the buffer-and-push sequence. The code above is the clean bridge shape; treat it as the last-mile payload, not a promise that every firmware and current channel behaves identically.
Do a boring brightness test before drawing anything
Send {"Command":"Channel/SetBrightness","Brightness":50} to http://PIXOO_IP/post. If the brightness changes, Node-RED can reach the device and your JSON is arriving. If it does not, fix the IP, VLAN or firewall first. Debugging fonts while the network path is broken is an excellent way to lose an evening.
If Node-RED messages still feel slippery, the official Node-RED concepts page is the link I would send a friend before adding more Function code. It explains the message object and shared broker configuration without burying you in a giant course.
Three Alerts That Deserve 4,096 Pixels
A 64×64 screen gets better when you ask less of it. A full dashboard tries to be a tiny tablet. A good ambient alert gives you one noun, one state and maybe one color. These three patterns cover most of what I would actually want on a desk or kitchen wall.
1. Door Left Open: High Priority, State-Based
Subscribe to a contact-sensor topic and display DOOR OPEN only after the door has stayed open for, say, two minutes. Set priority to 3, use a red or amber background, and keep it visible until the state returns to closed. RBE matters here: the screen should change when the state changes, not every time the sensor repeats “open.”
2. Laundry Done: Medium Priority, One-Time Event
This is a moment, not an ongoing state. Show LAUNDRY DONE for two minutes, then restore the previous display. Do not retain this alert on the broker unless your flow also records that it has been handled. Otherwise Node-RED can restart tomorrow and proudly announce yesterday’s laundry.
3. Rain Soon: Low Priority, Expiring Information
Weather changes are useful but not urgent. Publish something like RAIN 20 MIN, give it priority 1 and a TTL that matches the forecast window. If a door alert arrives, rain yields. If the forecast expires before the display becomes free, Node-RED drops it instead of showing stale advice.
Home Assistant can be one of your publishers, but it does not have to own the display. Its official MQTT page is especially useful when you are deciding between state topics, one-time publishes and retained messages. The practical rule is simple: retain the current truth, not an old event.
Keep the Display From Becoming a Tiny Notification Firehose
The first version of an automation usually proves that something can happen. The second version decides whether you still want it happening next week. Four small controls make the difference.
- Dedupe with RBE. If temperature remains 22°C, the screen does not need another 22°C. Let changed values through; drop repeats.
- Add a rate limit. Put a Delay node before the HTTP request and limit updates to a pace the display can comfortably handle. A one-second sensor should not turn the Pixoo into a network metronome.
- Use priority and TTL together. Priority decides who goes first; TTL decides whether a waiting message is still worth showing.
- Give failure somewhere to go. Connect Catch and Status nodes. Retry a failed HTTP call once, record the error, then fall back to the phone notification you already trust. Infinite retries are not resilience; they are a loop with confidence.
Keep the Node-RED host and Pixoo-64 on network segments that can reach each other, reserve the display’s IP address in your router, and never expose its local HTTP endpoint directly to the public internet. If you isolate IoT devices on a VLAN, allow only the specific Node-RED-to-Pixoo path you need.
When you want richer icons, a prepared background or a simulator before touching the real screen, this Pixoo library is the useful next rabbit hole. Its drawing helpers also make the key operational lesson obvious: build the frame, then push it at a sensible pace.
Who This Build Is For—and Who Should Skip It
This setup is for the person who already has a broker or a Node-RED canvas and enjoys turning a useful idea into a maintained little system. The Pixoo-64 gives that system a much more visible personality than another dashboard tab: 4,096 LEDs, enough room for a word, a number and a tiny icon, with the option to keep it on a desk or move it onto a wall.
Skip it if you want a one-tap, officially supported MQTT appliance. Skip it if your alert needs paragraphs, camera images or historical charts. And skip it if reserving an IP address and checking a failed flow sounds like unpaid homework. A phone or wall tablet will be less charming, but it will also ask less of you.
If the tinkering is part of the fun, our Pixoo-64 API beginner guide goes deeper into the raw control path, and Divoom keeps the official product manuals in one place. Those are better next stops than stuffing another 80 lines into a flow you do not yet need.
Divoom Pixoo-64Ⅱ
A 64×64 Wi-Fi pixel canvas for the desk or wall. It becomes a smart-home alert surface when you are happy to provide the Node-RED and local-control bridge.
View Pixoo-64Not ready to automate it yet? The pixel display collection is the calmer way to compare formats before committing to a developer project.
Frequently Asked Questions
Does Pixoo-64 support MQTT natively?
This guide does not treat Pixoo-64 as a native MQTT endpoint. An MQTT broker receives the event, Node-RED subscribes and filters it, then Node-RED sends the final command through a Pixoo local HTTP control path or a compatible helper library.
Can Home Assistant publish the alerts?
Yes. Home Assistant can publish a short JSON payload to an MQTT topic, and Node-RED can subscribe to it. Home Assistant is optional, though; any sensor, script or service that publishes to your broker can start the same flow.
What happens if Pixoo-64 is offline?
The HTTP request should fail into a Catch or Status path. Retry once if that suits the alert, then use a fallback such as a phone notification. Add a TTL so the flow does not show an expired message when the display returns.
Should every alert use a GIF?
No. Short text, a simple icon and one background color are faster to understand and kinder to the update path. Save animation for the rare alert that genuinely benefits from motion, and rate limit every push.
Make One Alert Earn Its Place on the Screen
Start with the event you missed last week—not the twenty events your system can technically publish. Give it a clear topic, one priority, one expiry time and one fallback. Run that single alert for seven days. If you still glance at the Pixoo-64 after the novelty wears off, it has earned the second alert. That is how a pixel display becomes part of the room instead of another dashboard you stop seeing.
