A clarification first: the Pixoo64 app currently does not use mDNS discovery. Auto-discovery uses the Divoom same-LAN cloud endpoint first, then falls back to a local subnet scan from Homey. So if mDNS/Bonjour is blocked or unreliable on your network, that should not be the direct cause here.
That said, direct connection still depends on Homey itself being able to reach the Pixoo64 locally. A curl command from your PC only proves that your PC can reach the Pixoo. If Homey is on another VLAN, guest Wi-Fi, isolated SSID, or behind firewall rules, Homey may still be unable to connect even when curl works from another machine.
I found one issue in the pairing detection logic: some newer Pixoo64 API revisions can answer the test command with a minimal { "error_code": 0 } response instead of the full configuration fields the app expected. That could make manual pairing fail even though the API was actually reachable.
I’ve uploaded test version 0.1.7 with improved pairing detection:
accepts both legacy http://IP:80/post and newer http://IP:9000/divoom_api
accepts minimal successful API responses during detection
lets you enter either a plain IP address or a full local API URL
improves the Divoom cloud discovery request format
If pairing still fails after 0.1.7, please check whether Homey can reach the Pixoo64 from the same network segment. Common blockers are VLAN separation, guest network isolation, client/AP isolation, firewall rules between Homey and IoT devices, or Homey being wired/wireless on a different subnet than the Pixoo.
This version works! Now it discovered it immediately like the stable released version, but unlike it it shows the Divoom as online and ready for play time.
Hi DJP, very glad to find the Divoom Pixoo 64 is supported by your app.
Therefor I ordered one from ibood which has it on sale today for €69,95 which seems a reasonable price for the device. Just a tip for others who might be interested as well.
I just ordered a Pixoo 64 II. I hope that it is supported by the app. I have looked for a long time for a simple display for some stats. Naturally there are always the repurposed e-ink price tags, but this seems like a good start.
@DJP Big thanks for the app. It worked on first try with autodetect. Question: I ordered a Pixoo64 II, but I am a bit confused. The II is not really mentioned on the packaging, maaaaaaybe as a 2 in the serial number… However, the app detected Legacy Revision on the API. I assume that has nothing to do with what version I have of the device, or does it?
I think there are multiple revisions of the hardwares, including “brighter” ones, maybe that’s what the shop you ordrered from calls “II”.
What I know is that there are 2 revision of the internal system, and if yours is detected (and working) as “Legacy” then it’s the “original version” (still, maybe with a better display).
I can’t really tell you more about the different versions, packaging, naming etc. Divoom is a chinese company and it’s hard to keep track sometime due to localization issue, region specific naming, etc. Even the “Legacy” vs “Newer” is just how I’ve decided to call it and I had no idea it existed before getting feedbacks about issues. Divoom still hasn’t updated the API document to adress that newer revision.
@DJP Thanks for the reply. Divoom themselves claim that I have gotten the II, but I have been around the block to many times… That’s why I asked you. I think I’ll communicate some more with them before accepting their explanation. Do you have any recommendation as to how I might access hardware revision data, and what the two versions should list in terms of components? That way I could send them some more detailed questions.
Absolutely no idea, I wouldn’t even consider my identification of “legacy” / “newer” as anything more that a differenciation of API versions. Maybe they have 2 production lines with different setup or whatever. who knows.
What did you expect from this “version II” to be different ? have been able to see anything online about differences…
Some kind of hardware difference that would bring some minor noticable change. Like Homey23/26 perhaps. It could just be that all the specs that matter are the same, but the hardware platform is slightly different . (Perhaps more reliable.)
Anyway, now to play with your app and test out how to make my own designs. Again, thanks for the app.
The app is working great and I have no problem building my own layouts. I might have detected a layout bug in the “Display Text” command, but I want to do some more testing before I bother you with it.
However, I do have a feature request (if it is possible through the API). It would be nice to be able to request which channel the Display is in, so that for instance when I have put it in Clock mode, I can check before an update to a variable triggers a channel switch to Custom.
Maybe I am missing another way of doing it and the feature is unnecessary. Please tell me if that is the case. Thank you.
I am getting unexpected behavior in this flow. The two LaMetric at position (0,36 and 0,45) are not showing all the frames. However, if I Load the Lametric #24800 in place of the Lametric #58195 at position 0,18 everything works fine.
It’s possible you are pushing the frame limite with too many animated gifs with various frame counts.
Try replacing all the “frame 0” with “frame 1” to test without the animations.
As an explaination :
Let’s say you have 2 gifs with 3 and 5 frame, then the Divoom app generate a merged display of 15 frames (5*3) to properly display both.
if you have a 3rd gif with either 3 or 5 frames it’s fine as it fits within the 15 frames loop.
if you have a 4th gif with 4 frames then 15 isn’t good anymore and you need 60 frames to keep the loop going properly for all gifs… and that’s when you start reaching the max of the device.
Gifs can’t work “separately”, they have to be merged.
Would it be possible to add a compositor mode for animated LaMetric icons?
Instead of treating several LaMetric GIF icons as separate animations and merging them using the least common multiple of their frame counts, the app could render the whole 64×64 scene into one fixed master animation timeline.
For example, the app could take all current canvas elements — static text, static images, animated LaMetric icons, and other drawn elements — and pre-render them into one final 64×64 GIF of 12, 16, 32, or 64 frames.
Each animated icon would simply be sampled into the master timeline. So if the final animation has 64 frames and an icon has 8 frames, its frames are repeated across the 64-frame master loop. If an icon has an awkward number of frames, the app could use time-based sampling or normalize it.
This would avoid the current frame explosion problem where several animated icons can produce a very large merged animation because of LCM behavior. It would also make the behavior more predictable and allow a fixed safety limit.
I think this would make dashboards with multiple LaMetric icons much more reliable, because the app would always send one finished 64×64 animation instead of trying to juggle several independent animations.
(It could also be the case that I don’t understand at all the limitations of the Pixoo and Homey, and what I am asking for is impossible. )
I’m note sure I understand the difference with what I’ve tried to explain (and already doing).
In your “12, 16, 32, or 64 frames” examples a 5 frame gif or a 3 frame gif wouldn’t fit, so all gif not fitting the selected frame rate would be cut during there last playback and reboot a the “first frame” of the global loop (the glitchy look every second or more would drive people crazy).
16, 32 and 64 basically support Gif with : 2,4,8,16,32 and 64 frames only
12 would support gifs with 2, 3, 4, 6, 12 frames gifs, but the others wouldn’t support 3, 6 or 12.
None would support 5, 7, 9 etc. properly
“If an icon has an awkward number of frames, the app could use time-based sampling or normalize it.” > That’s a huge amount of work and would look bad with such short loops
And I don’t plan to do a statistical analysis of all the frame count of the gifs in the LaMetric database
First check if with no animation (frame = 1) it works, then only add the animations on the important ones, that’s the only proper solution I have for now (or test with alternatives gifs, the database has a lot of lookalike).
Edit : And by the way, the “Hard limit” (but sometime it’s lower for unknow reason) is 60 frames total
