2 of 3 devices work perfectly, firmware incompatibility?

[tedcarstensen]

I’m new to homebridge and have been blown away at how smooth the system is, your plugin included! After adding three Wi-Fi LED strips to the magichome app I installed your plugin and restarted homebridge. 2 of the 3 controllers were found and added with no issue, but I can’t get the third to connect at all. The only difference I can identify is the one not showing up is running what appears to be a newer firmware (v6 vs v4)

Here’s my configuration:

{ "pruning": { "pruneMissingCachedAccessories": false, "restartsBeforeMissingAccessoriesPruned": 3, "pruneAllAccessoriesNextRestart": false }, "whiteEffects": { "simultaniousDevicesColorWhite": true, "colorWhiteThreshold": 10, "colorWhiteThresholdSimultaniousDevices": 50, "colorOffThresholdSimultaniousDevices": 5 }, "deviceManagement": { "blacklistOrWhitelist": "blacklist", "blacklistedUniqueIDs": [ "" ] }, "platform": "homebridge-magichome-dynamic-platform" }

And here are screenshots of the devices showing as connected and controllable in magichome, active on my network, but being missed in the discovery process on homebridge restart. I’ve manually reset and re-paired the problem controller several times, can’t seem to get homebridge to see it!

Is it possible to manually add in config since I know the MAC and IP?

[Zacknetic]

Hi, thank you for bringing this to my attention. Thank you for showing me all of that information, it helped confirm that there are, unfortunately, no quick solutions.

I have devices with versions 3-9 with the exception of 4 and 6 so I am delighted version 4 is working properly. My plugin does not offer a "manual" device addition feature as there are already many plugins that do so. Additionally, even if the plugin had that ability, the protocol wouldn't be mapped out properly for each version to work. It's not completely out of the question but adding that sort of feature would not be a quick as I'd want it to be robust enough to work 90% of the time (or in your case at least more than 66.66% of the time :P).

I'll start with low hanging fruit. Fair warning, these are all longshots:

1. Have you restarted homebridge a few times? Sometimes the discovery program doesn't pick things up on the first try. Don't worry, your devices will persist cross-restart. Restart 3 or 4 more times.
2. Install gordalina magic-home cli and scan with magic-home scan [--json] [--timeout 500] a few times. Does it discover your missing controller?
3. You've mentioned that you reconnected the light to WiFi a few times, are both your lights and the device hosting homebridge connected to the same WiFi UUID? A few notes about this. Magichome controllers cannot connect to 5GHz WiFi frequency bands, only 2.4GHz. Many routers combine these two bands as a single broadcasted ID and have devices default to 5GHz if they have that capability else falling back to 2.4GHz if they do not. Make sure your device hosting homebridge is on the 2.4 GHz band. You can ensure this by going in your router's settings and individually naming your 2.4GHz band something like "Router_Name-24". The Magichome app has some nasty tricks like coaxing the device list from your router to find controllers, a feature my plugin does not implement for privacy reasons (and laziness). So sometimes the app finds devices my plugin can't find.

If I think of any more ez-pz's I'll let you know. If these solutions don't work we'll move on to reverse engineering your v6 controller's elusive UDP broadcast protocol. Good luck.

[tedcarstensen]

Thank you for responding so quickly 💪

I can see why adding manual config is unnecessary complexity. I hoped that nudging the plugin in the right network direction would help, but hearing there are so many different versions with completely different control schemes I realize that was a naive suggestion.

To answer your questions:

1. Yes, I restarted homebridge multiple times after each factory reset of the v6 controller. Nothing I tried then made the device show in homebridge.

2. I installed the CLI and before messing with the network settings, the scan only returned the two v4 devices.

3. I use two distinct SSIDs broadcast by two APs. Each SSID is limited to either 2.4 or 5, but they are otherwise a single network using the same address space etc. The Magichome devices are all connected to the 2.4 network. My homebridge setup is running on a Mac Mini that's connected to the network via ethernet, and usually has wifi turned off.

To test, I connected the Mini to the 2.4 network (but did not remove the hard-line) and ran magic-home scan --json --timeout 500 a few times. The first time only the two v4 controllers showed up, and the second time only the v6 controller showed. On the third scan (and every scan since), only the two v4 controllers were found.

Second scan result:

USER:~ USER$ magic-home scan --json --timeout 500 [ { "host": "192.168.1.141", "id": "2CF432A025D1", "model": "AK001-ZJ210" } ]

Seeing that it was found once, I crossed my fingers and restarted homebridge. The v6 device was immediately found and added to homebridge and my home app alongside the two v4 devices.

I was able to control all three devices from inside Home, including changing colors and brightness.

Hoping that the 'connection' had been made, I turned off wifi (I would prefer that this machine is hard-lined only) and tested again, but the v6 device connection was lost.

Here are a few errors from the process:

After turning wifi off without restarting homebridge:

(node:33568) UnhandledPromiseRejectionWarning: Error: connect EHOSTDOWN 192.168.1.141:5577 - Local (192.168.1.104:57280) at internalConnect (net.js:923:16) at defaultTriggerAsyncIdScope (internal/async_hooks.js:351:12) at net.js:1011:9 at processTicksAndRejections (internal/process/task_queues.js:79:11) (node:33568) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

After then restarting homebridge:

[homebridge-magichome-dynamic-platform] Warning! Continuing to register cached accessory 'LED - Back Yard' despite not being seen for 1 restarts. Model: 'AK001-ZJ210' Unique ID: '2CF432A025D1' IP-Address: '192.168.1.141' Version 6 Version Modifier: 51

Attempting to use the homebridge and Home app UIs to turn the light on even though the device was not seen:

[homebridge-magichome-dynamic-platform] getState() error: Error: connect EHOSTDOWN 192.168.1.141:5577 - Local (192.168.1.104:58256) at internalConnect (net.js:923:16) at defaultTriggerAsyncIdScope (internal/async_hooks.js:351:12) at net.js:1011:9 at processTicksAndRejections (internal/process/task_queues.js:79:11) { errno: 'EHOSTDOWN', code: 'EHOSTDOWN', syscall: 'connect', address: '192.168.1.141', port: 5577 }

Turning wifi back on and fully deactivating the ethernet interface did not resolve the disconnection issue, even after restarting homebridge. It seems that once the connection is lost, it's completely toast and you have to start over. I set the plugin to prune missing devices and fell back to just the two v4 controllers in homebridge.

Starting the process over, I've been unable to see the v6 device via CLI scan again - it has only ever showed once.

Here is what I've found: if I try to add the v6 controller while the lights are off, it cannot be found by homebridge. If I turn the lights on using the magichome app, the homebridge plugin sees the controller on restart and adds it successfully. Once added I have full control in homebridge and the home app.

The second time adding the v6 device it had a different default name: RGBWW Non-Simultanious, whereas the first time it showed as Simple RGB just like the two v4 devices.

So this is progress! Thank you for the wifi suggestion, I would not have thought of this since the v4 controllers worked without the homebridge server needing to be on wifi.

My question now, assuming the current connection holds, is: is it possible that I could eventually control the v6 from my wired Mac Mini with wifi turned off? Is this possibly a network issue on my end, or is this something that's baked into the control scheme?

Thanks again for your work on this plugin, I can't imagine being forced to use the awful magichome app for control.

[Zacknetic]

Ah yes, the infamous EHOSTDOWN bug. That occurs due to parts of the transmit code that allows the plugin to understand TCP responses from certain rgbww controllers. The issue is most likely not with your network but your thorough troubleshooting process has given me some insight on the bug.

The reason you're getting the second error is because my plugin is auto assigning the wrong transmit protocol to it when it receives no data after the first TCP handshake. Unfortunately model number alone is not sufficient to determine a controllers type as identical model numbers (transmitted over the UDP broadcast reply) can have different capabilities and thus different transmit protocols. When you try to control the device, a 9 byte message is sent instead of an 8 byte message. Why does it fail to connect over a bridged connection for only the V6, I have no clue. Some genius probably implemented some untested code in the V6 firmware that goofed everything up.

If you want to stay with my plugin, try this:

1. remove all the devices with pruning
2. repeat your v6 discovery processes again but this time, when you turn off WiFi on your Mac, don't restart the router. Or if you absolutely have to, be sure to assign a static IP to the v6 controller. In fact, that's probably a good practice anyways. The devices are persistent and I've written logic to fix IP discrepancies, but only if they show up when scanned.

When you restarted your router, that probably changed the IP of the v6 device, but without being able to scan for it anymore my plugin was unable to resolve that IP discrepancy and sent a message to your smart toaster or something.

If that doesn't work, I still do not know how to fix bug without breaking other things. However, @tom-23 has a magichome plugin, albeit less robust but better named (hi Tom), that seems to solve that issue for all the other controllers. My suggestion is to do the following.

1. Remove the config for my plugin "homebridge magichome dynamic platform" and ensure the tiles no longer show up in homekit. Be sure to restart homebridge.
2. Install homebridge-magichome-led and add the necessary config to your config.json.
3. Follow your steps to get the v6 to appear.
4. Disconnect your WiFi.

This should tide you over until I get time to fix this bug.

Alternatively, I'd suggest investing in a Raspberry Pi 3b or 3b+ (not the 4. over-expensive). I'm not promising it would solve your issue so don't buy it solely for this bug. But they're great devices to play around with. They can be left on 24/7 at a much lower power cost. And they have GPIO pins which let you do all sorts of DIY IOT nonsense. But please take my suggestion lightly and make sure it works for you.

The magichome app is awful and it just keeps getting worse. It recently added an ambient movie lighting feature using the phone's camera. But with ZERO explanation on its use. My 32 magichome devices fill the entirety of the little menu so I guess it's not meant for that many. I guess they didn't expect people to buy so much of their crap. Not that I'd want to use their app anyways.

Let me know how those steps go.

[tedcarstensen]

Thanks for the quick response again.

After further testing with your plugin, the v6 did not respond reliably to color and brightness commands, and certain selections in the color wheel turned the lights off completely. I'm guessing this is the byte size of the messages being sent, as you described. Several of the devices (v6 always, but also v4s) were not seen over multiple restarts, but continued to respond to Home commands, really strange. Also strange, the device previously registered correctly as v6 in Homebridge last showed as v5 🙃

Just to clarify - I never restarted the router when switching the network interface the Mini uses to connect to the network. Not sure if that changes your troubleshooting suggestions. Re: Raspberry Pi, I use the Mini for other things like Plex so it's already on 24/7, I'd prefer to keep Homebridge running there. I may eventually want to use PiHole in which case maybe it can do double duty.

Each time I re-added the problem v6 controller in the MagicHome app it was given the same IP it had been before. Just in case though I've set all 6 controllers (I discovered three more controllers, all showing firmware v2, installed elsewhere in our new rental home) to use static IP addresses.

I've removed your plugin and switched to homebridge-magichome-led as you suggested, which allows me to manually register each controller. Once all devices were registered, I turned wifi off on the Mini and have been able to maintain control of the controllers for the most part.

The v6 is still problematic in that it sometimes must be turned on in MagicHome before it can be controlled again in Homebridge or Home. After first turning off the wifi, all of the devices reported as offline, but after coaxing them a bit they now reliably show correctly.

I've starred and watched your repo and can hopefully return to it at some point - I do appreciate that it's a verified plugin. If there's any additional troubleshooting or testing I can do to help provide broader firmware/device support, I'm happy to help. I now have devices with firmware V2, V4, and V6.

[Zacknetic]

Much appreciated. Could you tell me, what kind of controller is the V4 and V6. How many pins does it have, including ground? Just RGB?

[tedcarstensen]

I snapped some photos of the V6 and one of the V4s, both have 4 pins (RGB and what I assume is the ground) as well as what appears to be an IR receiver (I do not have access to remotes if they ever existed).

V4:

V6:

Generally seeing lots of 'no response' messages in Home for both V4s and the V6 until I refresh a few times or jump into the Magichome app, while the V2s work flawlessly with this other plugin. Also still having more pronounced connection issues with the V6 in Homebridge, possibly due to using the incorrect model number? Here's what that looks like (I know this isn't your plugin, but maybe it will help if/when you expand model/firmware support) Error: connect ETIMEDOUT 192.168.1.141:5577

[Zacknetic]

Hi, @tedcarstensen. I've updated the plugin with some better version detection.

Please update in config ui x > plugins > homebridge-magichome-dynamic-platform > update

(!Important!) Next purge all magic-home accessories by going to config ui x > plugins > homebridge-magichome-dynamic-platform > settings > checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge at least twice > un-checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge

Let me know how this goes? Should improve things for your v4.

[tedcarstensen]

Thanks @Zacknetic and sorry it took a few weeks to respond here. I've switched back to your plugin and am experiencing great reliability with the V4s and especially the V2s compared to the other plugin. Thank you!

At this point it seems that the V6 is a lost cause and I'm better off buying another controller to swap in? I'll look at Amazon now, hopefully I don't end up with another V6!

[Zacknetic]

I HIGHLY suggest you buy one of the MagicHome controllers which can control at least 1 white channel RGBW or even two white channels RGBWW. The LED strips aren't too expensive for these and it allows for some beautiful mixed color and white blends.

If you'd like amazon / aliexpress suggestions please let me know.

I'm sorry to hear that about the v6. Sometimes these things are just out of my control.