[APP][Pro] Magic Home LED

John_Kevin · January 12, 2026, 6:04pm

Hi Martin, some of my addressable strips will not change color, either via the device color picker, nor via the set hue card in a flow. My diagnostics code is a84bf61e-f167-481d-9bca-e20e07dc44c4
The device is MHA Kit Counter AK001-ZJ2149 (192.168.1.198) in room Snug2. I also get time-out messages for many of my strips, but I have just upgraded my WiFi network.

martijnpoppen · January 13, 2026, 7:19am

Hey @John_Kevin
Did it work before ? Or is it a new controller?
Did you add it as addressable ?

John_Kevin · January 13, 2026, 2:38pm

Apologies Martin, I have worked out what was wrong. The LED strips identified as model AK001-ZJ2149 when they were included, and since there was no ZJ2149 in the dropdown list, I selected ‘other’ on some strips and left the model blank on others, but I realise now I should have chosen ZJ2148 as they seem to work correctly with that model number if using flow-cards (but still not color changing in the GUI) but that is not a problem.

martijnpoppen · January 13, 2026, 5:46pm

@John_Kevin glad it works.!

John_Kevin · March 30, 2026, 7:47pm

Hi @martijn,

I’m still having problems with my addressable strips. Unfortunately I can’t change the strips as they are now built into my cabinets, but I have replaced the drivers with newer ones with no improvement. The latest SPI controller are very close to working but have a repeatable issue.

Setup:

Controller: generic WiFi LED SPI Controller (12–24V, ≤2048 pixels)
Strip: WS2811 (WORLDSEM WS2811 20220608), 24V RGB (grouped)
Magic Home app works perfectly (colour/brightness/on-off always reliable)

Homey:

Setting model to AK001-ZJ2148

On/Off
Brightness
Colour (initially)
After app restart → works
After some time → colour stops working, but on/off + brightness still work
Restarting app restores colour temporarily

Setting model to AK001-ZJ2146

GUI shows color and white wheel controls but nothing works

Repro:

ZJ2148 → restart app → colour works → wait/use → colour stops → restart → works again

Conclusion:

ZJ2148 looks like the correct protocol, but colour handling breaks over time. Control from Magic Home app stays 100% stable while Homey control is broken.

Question:

Does this controller need a slightly different profile (e.g. generic WS2811 24V), or could there be a bug in ZJ2148 colour handling over time?

Happy to test

Photos of my controller and strip are attached.

martijnpoppen · March 31, 2026, 11:34am

@John_Kevin that really sounds like a connection issue. can you send a diagnostic report when this occurs again?

John_Kevin · March 31, 2026, 1:28pm

a0ba047b-3f86-49c8-9847-a7831367f762

Setting a colour using a flow card failed for pixel strips fails, but works for non-pixel strips. Also control by Magic Home app works at all times, suggesting connection is ok?

John_Kevin · March 31, 2026, 2:10pm

Also, there is a flowchart for non-pixel RGB strip driver AK001-ZJ2145 which is set a temperature, but this does nothing in my case.

John_Kevin · August 19, 2026, 8:02pm

Possible addressable recovery-path defect

Hi Martin,

As you know, I have experienced intermittent control problems for some time. The Magic Home app and Alexa can control the brightness and colour of the same addressable LED strips that your Homey app could not control during these tests.

I tested all 16 Homey devices with the same sequence:

On → 100% red → 75% blue → 50% green → 25% cyan → 0%

All 8 non-addressable AK001-ZJ2145 devices succeeded. Only 3 of 8 addressable devices succeeded; the other 5 accepted On but ignored every colour and brightness command. Success and failure occurred with both AK001-ZJ2148 and AK001-ZJ2149, so this does not appear to be model-specific.

The failed Flows reported no errors. Homey initially showed the requested state, but subsequent polling restored the unchanged physical colour and brightness. It could therefore read the controllers, but its commands had not been applied.

The public drivers/main-device.js may explain this. Initialisation correctly uses ControlAddressable, but onSettings(), ping recovery and rediscovery appear to replace it with ordinary Control. Both classes share the power command but use different colour protocols—closely matching On working while addressable colour and brightness fail. The rediscovery timeout also appears to set runningDiscovery = true instead of false.

I realise the public source may differ from Store version 3.6.7. Could you please confirm whether these recovery paths remain in the installed version?

Thanks,
John_Kevin

martijnpoppen · August 19, 2026, 9:38pm

@John_Kevin sorry what is your question exactly? This really seems AI generated and to me it’s not clear what you expect from me in this case

As already mentioned earlier in this thread the addressable support was added based on best effort and it might not work for your specific decide

The library this app uses is outdated and doesn’t seem to get updated anymore. So currently there are no plans to fix the addressable integration as I don’t have the experience and devices to do that

John_Kevin · August 20, 2026, 12:54pm

@martijnpoppen, I apologise if my message was unclear, I will try and make it easier.

I have found errors within the code on your GitHub page from two years ago which would give rise to the same problems that I have been reporting to you over the last 18 months.

Your initialisation depends on the user picking the correct type of strip. However, once the apps connection to an addressable driver is dropped for any reason, your public code shows that your app reconnects to that same addressable driver using the method reserved for a non-addressable device. This would explain why I can control the colour and brightness of my addressable LED strips for a few hours after initialisation, but only ON and OFF work after a few hours/days.

I was asking if your current Homey Store app v3.6.7 still uses the same connection recovery methods as the publicly available GitHub code, because that would explain the problems I am experiencing.

I understand why you may not want to put much effort into addressable strips, but this fix seems easy to implement since the initial pairing works well, it only requires the re-connection to use the same addressable mechanism. I am very willing to help you test any revision you do. I don’t think it will be a complex process and would help many people experiencing the same problems as me.

If you would like more details, then please get back in touch.

martijnpoppen · August 20, 2026, 12:57pm

@John_Kevin yes the version on github is in sync with the app store version.
Feel free to create a PR or point me in the right direction

John_Kevin · August 20, 2026, 7:44pm

Thank you. GitHub currently shows version 3.6.4 with its last commit dated April 2024, while the Homey Store contains version 3.6.7. Could you please push the current 3.6.7 source to GitHub, or confirm that drivers/main-device.js is unchanged? Once the current code is available, I can prepare a precise PR.

martijnpoppen · August 20, 2026, 7:45pm

@John_Kevin done!

John_Kevin · August 22, 2026, 10:31am

@martijnpoppen,

Your source contains two clear errors: addressable devices start with ControlAddressable, but rediscovery recreates them using ordinary Control. Also, the rediscovery timeout sets runningDiscovery to true instead of clearing it.

These errors match the exact behaviour I reported on 30 March with my addressable strips: colour control works after restarting the app but fails after time, while the Magic Home app remains reliable.

I corrected only those errors; the controller library, packets, device models, test Flows, hardware and network remained unchanged. Controlled testing of my patched app against your Store app was conclusive:

Store v3.6.7: All three addressable devices were controllable immediately after restart; one failed after two hours, then all three failed after an overnight soak.
Corrected v3.6.7: The same addressable devices passed immediately, again after three hours, and all three passed after more than 21 hours.

This is controlled evidence that the cause is not my network, addressable LED drivers, strips or device compatibility. Your unsubstantiated alternative explanations have wasted my time with months of unnecessary troubleshooting and equipment replacement.

The tested correction is ready as a small PR. Please treat this as a confirmed app defect and release the fix.

martijnpoppen · August 22, 2026, 10:50am

Ouch…

Will do.

martijnpoppen · August 22, 2026, 10:53am

@John_Kevin Please send the PR.

John_Kevin · August 22, 2026, 11:15am

Thank you. PR #12 has now been submitted:

github.com/martijnpoppen/magic.home.wifi

Fix addressable controller recovery (#12)

master ← EditBear:codex/fix-addressable-recovery

opened 10:58AM - 22 Aug 26 UTC

EditBear

+12 -10

### Summary Preserve the addressable controller implementation whenever a dev…ice connection is created or recreated, and release the discovery guard after its timeout. ### Cause Initialisation selects `ControlAddressable` for devices with the `addressable` capability, but the settings, ping-recovery and rediscovery paths unconditionally replace it with ordinary `Control`. An addressable device can therefore lose its addressable controller implementation after runtime reconstruction. The rediscovery timeout also assigns `runningDiscovery = true`, leaving later discovery attempts blocked instead of releasing the guard. ### Change - Add one controller factory that selects `ControlAddressable` when the device has the `addressable` capability and `Control` otherwise. - Use that factory during initialisation, settings changes, ping recovery and rediscovery. - Set `runningDiscovery` to `false` when the rediscovery timeout expires. ### Verification A local automated recovery-path harness passed **3/3**. It verifies: - correct controller selection for addressable and ordinary devices; - preservation of `ControlAddressable` through initialisation, settings recreation, ping recovery and rediscovery; - release of the discovery guard so a later discovery attempt can run; and - no remaining connection-construction site bypassing the shared factory. `homey app build` also completed successfully against validation level `debug` using the unchanged upstream app identity, manifests and production dependency declarations. A matched live A/B test used two `AK001-ZJ2148` addressable controllers and one `AK001-ZJ2149`, with equivalent paced colour/brightness/final-off diagnostic Flows: - Store v3.6.7 passed all three immediately after the app was re-enabled. One `AK001-ZJ2148` controller then failed after approximately **2 hours 3 minutes**. After the overnight soak, all three failed to apply the addressable sequence. - The modified v3.6.7 build then passed all three on the same physical controllers. That same controller passed again after approximately **3 hours**, and all three passed after approximately **21 hours 27 minutes** of uninterrupted modified-app runtime. The failures and passes were physically observed and checked with delayed Homey read-back. No controller-library, packet, model-mapping, Flow values or pacing, hardware, LAN, repair/re-pair, or controller-reset change was made during the matched comparison. The test build used a separate app ID/name only to keep it isolated from the Store app; its functional source change was the one-file diff in this PR. Forum report and test summary: [Homey Community post 699](https://community.homey.app/t/app-pro-magic-home-led/1750/699) ### Scope Non-addressable devices continue to use ordinary `Control`. This PR does not change controller packets, the controller library, device-model mappings, capabilities, Flow cards, polling intervals, app identity or dependencies.

martijnpoppen · August 22, 2026, 6:13pm

New app update ( TEST: 3.6.8):

Changelog:

NEW:
1: None

FIXES:

1: FIX: addressable controllers lost color and brightness control after a reconnect (thanks @John_Kevin)
2: FIX: rediscovery no longer blocks itself after the first run

If you find any issues, send a diagnostic report

Note: Before sending a report make sure to reproduce the issue so the issue will be visible in the report

Via Homey Mobile app:
More - apps - Magic Home - settings wheel right top - send diagnostic report (put your email in the input field to make it easier)

Via Homey Webapp:
Settings wheel bottom left - Select Magic Home - Click on send diagnostic report

You can install this version by clicking the link above and press install (do not remove the app, only press install)

Don’t want to be part of a test version? Install the live version → Magic Home WiFi LED | Homey

martijnpoppen · August 25, 2026, 10:56am

New app update ( LIVE: 3.6.8):