Initial pairing instructions

[rytilahti]

Hi,

as the app did not work for my led strip (AK001-ZJ200 as reported by HF-A11ASSISTHREAD), I decided to dig a bit how to do it without the app and wrote this up just in case someone else wants to do the same, or if someone wants to try to integrate this to the code-base.

I found a link to a spec sheet from https://github.com/vikstrous/zengge-lightcontrol which describes the 48899 port communication to some extent: http://www.hi-flying.com/downloadsfront.do?method=picker&flag=all&id=dc406e44-84ec-4be1-ab11-a4ce403f6d3f&fileId=0f147d14-d0aa-4fc8-b01f-36e43418d19d .

For starters you must connect to the network advertised by the device LEDnetXXXX or similar.
It should also be noted that some commands require passing a \r while others do not.
On successful commands this device yields +ok= (for queries followed by the response).

The wifi mode can be queried and set with the AT+WMODE command, so the first step was to change the controller from AP to STA mode:

echo 'AT+WMODE=STA\r' | nc -u  10.10.123.3 48899

This device required STA all uppercase, a diversion from that spec sheet.

Setting the SSID and the key worked as follows:

echo 'AT+WSSSID=<NETWORK>' | nc -u 10.10.123.3 48899
echo 'AT+WSKEY=WPA2PSK,AES,<PASSWORD>' | nc -u 10.10.123.3 48899

The first two parameters needs to be adjusted accordingly depending on used encryption mode and cipher, this device accepted only all-uppercase variants. Note that adding \r after the password would include that in it, the same is probably true for the name of the network.

After that the device can be rebooted and will hopefully connect to the network:

echo 'AT+Z\r' | nc -u 10.10.123.3 48899

Apparently some sort of software version can be requested by using VER, FVER and/or LVER, on my device only LVER did give a response:

AT+LVER\r
+ok=33_17_20170825_IR

It would be nice to have this integrated into this library & script, but I don't unfortunately have time for it. Hopefully this can be helpful to someone who wants to implement it, and maybe it helps someone who is looking into how to get these paired without the official "magic home" app.

[Chris-Johnston]

I also found that while I could send AT+H (help), not all of the instructions listed worked.

If it helps, here's the activity that the app generated when changing SSID (AT+Z resets it just fine, dunno why they did it three times.) I didn't find AT+Q in the HF-LPB100 manual.

And here is the activity when clicking the "factory reset" button. Oddly, the SSID and password used are from the current connection when the reset is initiated.

Here's the output of AT+H, for reference (this was also contained in the PDF linked above).

   AT+: NoNE command, reply "+ok".
   AT+ASWD: Set/Query WiFi configuration code. 
   AT+E: Echo ON/Off, to turn on/off command line echo function. 
   AT+ENTM: Goto Through MOde.
   AT+NETP: Set/Get the Net Protocol Parameters.
   AT+MSLP: Set/Query deep sleep mode parameters.
   AT+PING: General PING command.
   AT+WMODE: Set/Get the WIFI Operation Mode (AP or STA).
   AT+WSLK: Get Link Status of the Module (Only for STA Mode).
   AT+WSLQ: Get Link Quality of the Module (Only for STA Mode).
   AT+WSCAN: Get The AP site Survey (only for STA Mode).
   AT+TCPLK: Get The state of TCP link.
   AT+TCPTO: Set/Get TCP time out.
   AT+TCPDIS: Connect/Dis-connect the TCP Client link
   AT+RECV: Recv data from WIFI
   AT+SEND: Send data to WIFI
   AT+WEBU: Set/Get the Login Parameters of WEB page.
   AT+WEBVER: Get WEB version.
   AT+WSDNS: Set/Get the DNS Server address.
   AT+WADMN: Set/Get the domain name of WEB page.
   AT+WEBSWITCH: Set/Get the parameters of WEB page.
   AT+PLANG: Set/Get the language of WEB page.
   AT+UPURL: Set/Get the path of remote upgrade.
   AT+UPFILE: Set/Get the file name of config file for remote upgrade.
   AT+UPST: Start the remote upgrade.
   AT+UPWEB: Start the remote upgrade webpages.
   AT+UPCFG: Start the remote upgrade default setting.
   AT+UPAUTO: Start the remote upgrade by config file.
   AT+LOGSW: Enable/Disable upload logs.
   AT+LOGPORT: Set/Get the UDP port for upload logs.
   AT+SOCKB: Set/Get Parameters of socket_b.
   AT+TCPLKB: Get The state of TCP_B link.
   AT+TCPTOB: Set/Get TCP_B time out.
   AT+TCPDISB: Connect/Dis-connect the TCP_B Client link.
   AT+RCVB: Recv data from socket_b
   AT+SNDB: Send data to socket_b
   AT+RELD: Reload the default setting and reboot.
   AT+SLPEN: Put on/off the GPIO7.
   AT+RLDEN: Put on/off the GPIO45.
   AT+Z: Reset the Module.
   AT+MID: Get The Module ID.
   AT+VER: Get application version.

I had actually been trying to figure out how the UDP communications worked myself before I found this repo. I had been working on my own library for controlling these lights independently that was much more hacked together and not nearly as complete.

[NeonDaniel]

EDIT: Looked at this again today with the full manual and it seems to be working as it should (maybe because I sent AT+Z to reset).

It looks like many of these commands no longer work; I have a newer light (MagicLight) that reports model AK001-ZJ200 and version 44_25_20180904 when I send HF-A11ASSISTHREAD\r and AT+LVER\r respectively. No response to any other commands; the commands are received by the bulb according to wireshark, but no response is given and setting WMODE seems to not work. Any ideas where to go from here?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[disgustipated]

I'm getting an +ok= response but nothing after the = any idea what i might be doing wrong?

[Chisight]

This issue comes up early in google searches and contains the excellent @Chris-Johnston wireshark captures that were instrumental in solving this problem on my newer Magic Home LED controller. Please forgive the necroposting but I'm trying to help anyone else with a similar problem on newer controllers.

My Magic Home WiFi LED controller (affiliate link) didn't work quite as above. It has a version identifier AK001-ZJ2145 which is different, so not surprising that it behaves differently. Some of the changes appear to be them actually fixing the well known security problems with these controllers, they're still not safe to put on the public internet though.

I powered mine up with 12VDC and scanned for new SSIDs. Mine came up as LEDnet003325A63A where the MAC address ends with 25A63A. I had used the above instructions and managed to soft-brick it so needed to reset to get back to a working state. These controllers no longer revert to AP mode if they can't connect (it was a security problem) so you have to factory reset if something doesn't work.

To factory reset, timing is important.

1. plug it in and give it a minute to boot up.
2. unplug it for 2 seconds.
3. plug it in for 3 seconds
4. repeat from step 2 four times. (the directions say three, but I have to do four)

The commands below are for Linux, Windows users might have to do things differently.

Connect to LEDnet0033xxxxxx via WiFi with DHCP enabled.
In a root shell, run route -n to get the gateway. Mine was 10.10.123.3.
you can confirm the version is AK001-ZJ2145 with:
echo 'HF-A11ASSISTHREAD' | nc -u -v -w 3 10.10.123.3 48899; echo
Mine returns: 10.10.123.3,B4E84225A63A,AK001-ZJ2145
This will get you more version information, but I don't know what any of it means:
echo 'AT+LVER' | nc -u -v -w 3 10.10.123.3 48899; echo
Mine returns: +ok=33_33_20201024_ZG-BL-IR

To configure it for your WiFi set the credentials variables and run the following:
export IP=10.10.123.3
export SSID=myssid
export PASSWORD=mywifipassword
ping -c3 $IP && ( echo 'HF-A11ASSISTHREAD' | nc -u -v -w 3 $IP 48899; echo; echo -e 'AT+WMODE=STA\r' | nc -u -v -w 3 $IP 48899; echo; echo -e "AT+WSSSID=${SSID}\r" | nc -u -v -w 3 $IP 48899; echo; echo -e "AT+WSKEY=WPA2PSK,AES,${PASSWORD}\r" | nc -u -v -w 3 $IP 48899; echo; echo -e 'AT+Z\r' | nc -u -v -w 3 $IP 48899; echo; echo -e 'AT+Z\r' | nc -u -v -w 3 $IP 48899; echo; echo -e 'AT+Q\r' | nc -u -v -w 3 $IP 48899; echo; echo -e 'AT+Q\r' | nc -u -v -w 3 $IP 48899; echo )

Four of the commands should return +ok, but a few return nothing.
It is supposed to reboot by itself, but mine usually doesn't so I power cycle it.

I used zengge-lightcontrol to verify operation. To install it, use:
go get github.com/vikstrous/zengge-lightcontrol/cmd/zengge-lightcontrol
It's not fully compatible but the "local" commands seem to work.
Get your controller's IP from your DHCP server (firewall) and export IP again.
To use zengge-lightcontrol:
~/go/bin/zengge-lightcontrol local get-state -o $IP:5577

You can also use netcat to set the color:
export COLOR=808080
echo -en "\x31\x${COLOR:0:2}\x${COLOR:2:2}\x${COLOR:4:2}\x00\xf0\x0f\x10" | nc -w 1 $IP 5577 > /dev/null'
You can also use netcat to get the color, but I rarely need to read the color so I didn't bother to decode the results.

I hope this helps someone.

[Arakon]

I've been trying to get one of mine to work.
It returns 10.10.123.3,B4E84255BD1E,AK001-ZJ2148
Unfortunately, after sending any other command, including "AT+H", I receive nothing, the prompt just stalls until I Ctrl-C out of it.
It also seems to disconnect me every time. Only the identification seems to work.
Any ideas?

Edit: Okay, it worked now. However, I still can't get it connected.. apparently the password length for the network is limited to 10 characters, anything longer and the connection fails cause it only sends a partial pass.. awesome.

[icemanch]

I've been trying to get one of mine to work. It returns 10.10.123.3,B4E84255BD1E,AK001-ZJ2148 Unfortunately, after sending any other command, including "AT+H", I receive nothing, the prompt just stalls until I Ctrl-C out of it. It also seems to disconnect me every time. Only the identification seems to work. Any ideas?

Edit: Okay, it worked now. However, I still can't get it connected.. apparently the password length for the network is limited to 10 characters, anything longer and the connection fails cause it only sends a partial pass.. awesome.

What commands are you actually sending?

[Arakon]

I sent the complete script by @Chisight multiple times, and also broke it into single commands. For some reason, this didn't work until the fifth time.
Sadly, the password limit makes it impossible for me to integrate them into my network.

[icemanch]

I sent the complete script by @Chisight multiple times, and also broke it into single commands. For some reason, this didn't work until the fifth time. Sadly, the password limit makes it impossible for me to integrate them into my network.

We're going to work on adding the ability to the flux_led but it's probably a few months out.

Have you tried just using the App to add them to the network and then using flux_led to control them?

[Arakon]

Yes. I initially tried to use the app and then tried this method BECAUSE the app failed to connect it. I tested it out with a different access point and every time the password exceeds 10 characters, the connection fails cause the password sent is not complete.
It seems to be a bug (or really bad planning) in the actual firmware of these chips. I had been hoping it's a bug in the app instead.

[icemanch]

Yes. I initially tried to use the app and then tried this method BECAUSE the app failed to connect it. I tested it out with a different access point and every time the password exceeds 10 characters, the connection fails cause the password sent is not complete. It seems to be a bug (or really bad planning) in the actual firmware of these chips. I had been hoping it's a bug in the app instead.

My pass is 10 characters long. I'll make it 11 and see if I can figure it out.

[Arakon]

I found a sort of workaround.. by attaching a small USB Wifi stick to the Odroid, and setting up the addon "Hassio wifi hotspot", I can provide a seperate network for these strip controllers with a shorter password.

[Arakon]

Well.. or not. After a while of being offline (unplugged), the controller simply forgets all settings and returns to factory settings, it appears. I can reconnect it using the app again, but not access it until I go through the whole "find new device" thing.

[bdraco]

I run a separate wifi SSID for my IOT devices that only operates on 2.4 ghz and is segmented off from the rest of my network for this exact reason. Not sure if your wifi setup supports this.

[Arakon]

That's how it's set up now, with the access point being on the HA device itself. My main router doesn't allow for a second SSID.
I'm thinking that the firmware/chipset of these things is just not entirely bugfree yet.

[bdraco]

#58 has some helpful decoding on setting the sort order

[bdraco]

    async def async_probe_network(self, address: str, timeout: int = 10) -> None:
        """Probe the network settings."""
        await self._async_send_commands_and_reboot(
            [
                self.VERSION_MESSAGE,
                "AT+WSLK\r".encode(),
                "AT+WSSSID\r".encode(),
                "AT+WSKEY\r".encode(),
                "AT+WMODE\r".encode(),
                "AT+WAKEY\r".encode(),
                "AT+WSCAN\r".encode(),
            ],
            address,
            timeout,
            reboot=False,
        )

DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'192.168.106.198,<SNIP>,AK001-ZJ2149'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=1C_26_20210818_CL-BL\r'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+WSLK\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=(<SNIP>)\r'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+WSSSID\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=<SNIP>\r'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+WSKEY\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=WPA2PSK,AES,<SNIP>\r'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+WMODE\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=STA\r'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+WAKEY\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=WPA2PSK,AES,<SNIP>\r'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+WSCAN\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok=\nCh,SSID,BSSID,Security,Indicator\n1,<SNIP>,6A:D7:9A:25:00:A2,WPA2PSK/AES,46\n6,<SNIP>,68:D7:9A:34:F9:6A,WPA2PSK/AES,49\n1,<SNIP>,6A:D7:9A:15:00:A2,WPA2PSK/AES,47\n1,<SNIP>,68:D7:9A:35:00:A2,WPA2PSK/AES,44\n6,<SNIP>,6A:D7:9A:14:F9:6A,WPA2PSK/AES,49\n11,<SNIP>,68:D7:9A:34:F9:EA,WPA2PSK/AES,51\n11,<SNIP>,6A:D7:9A:14:F9:EA,WPA2PSK/AES,50\n11,<SNIP>,26:5A:4C:9C:9C:92,WPA2PSK/AES,63\n11,<SNIP>,24:5A:4C:8C:9C:92,WPA2PSK/AES,62\n6,<SNIP>,6A:D7:9A:14:F9:BE,WPA2PSK/AES,54\n6,<SNIP>,68:D7:9A:34:F9:BE,WPA2PSK/AES,54\n1,<SNIP>,68:D7:9A:35:09:A6,WPA2PSK/AES,88\n'
DEBUG:flux_led.scanner:udp: ('192.168.106.198', 48899) => b'AT+Z\r'
DEBUG:flux_led.aioscanner:udp: ('192.168.106.198', 48899) <= b'+ok\r'

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bdraco]

We might have enough info to provision the newer ones over Bluetooth now