Discovery MAC address

[fermentfan]

Hey,
I just finished building a DIY milight hub. Unfortunately when I try to pair it with the V6 protocoll and Openhab the discovery package gets the following return:

18 00 00 00 40 02 00 00 00 00 C7 6A 00 20 39 38 35 62 31 35 37 62 66 36 66 63 34 33 33 36 38 61 36 33 34 36 37 65 61 33 62 31 39 64 30 64 01 00 01 17 63 00 00 05 00 09 78 6C 69 6E 6B 5F 64 65 76 07 5B CD 15

Is it something like an encoded address?

I tracked it down to this part of the code:

uint8_t V6MiLightUdpServer::SEARCH_RESPONSE[] = {
  0x18, 0x00, 0x00, 0x00, 0x40, 0x02,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // mac address
  0x00, 0x20, 0x39, 0x38, 0x35, 0x62,
  0x31, 0x35, 0x37, 0x62, 0x66, 0x36,
  0x66, 0x63, 0x34, 0x33, 0x33, 0x36,
  0x38, 0x61, 0x36, 0x33, 0x34, 0x36,
  0x37, 0x65, 0x61, 0x33, 0x62, 0x31,
  0x39, 0x64, 0x30, 0x64, 0x01, 0x00,
  0x01,
  0x17, 0x63,  // this is 5987 in hex. specifying a different value seems to
               // cause client to connect on a different port for some commands
  0x00, 0x00, 0x05, 0x00, 0x09, 0x78,
  0x6C, 0x69, 0x6E, 0x6B, 0x5F, 0x64,
  0x65, 0x76, 0x07, 0x5B, 0xCD, 0x15
};

The OpenHab implementation doesn't allow the usage of a device without the right mac address in a config. Sadly I don't really get this code. Is it a hardcoded MAC address or is just something buggy? I would appreciate your help!

Thanks.

[sidoh]

I think there's maybe some related discussion in #46.

It makes a copy of the packet and fills in the hardware address here.

By "right" MAC address, do you mean the one that the IP is bound to? Is OpenHAB actually doing an ARP lookup to verify that the MAC is correct?

[fermentfan]

Yes OpenHAB needs me to set the right mac address before it's accepted and ready to interact.

So does the device answer the right way already or is there a wrong MAC inside or something else?

[sidoh]

The ID esp8266_milight_hub responds with is the device ID bound to the UDP port (e.g., 00:00:00:00:11:22 if your device ID is 0x1122).

I poked through the OpenHAB code for the MiLight binding, and it doesn't look like it's doing any ARP lookups, so I don't think the MAC needs to be the right value from a network perspective. It does seem like OpenHAB needs to run the discovery protocol and get a response with a matching ID. Right now the discovery protocol isn't implemented at all, which is probably why you're seeing it not working. There's some relevant discussion in #46.

I'm taking a stab at implementing the discovery protocol. Should have a testable version within the next couple of days.

[fermentfan]

Ok, I just tried adding it with the the MAC "00:00:00:00:XX:YY" and voilà it works. I am gonna try everything now. Maybe a tip in your web overlay would be helpful? Thanks again for all your work! :)

[sidoh]

Sweet! Good find. I'm hoping that implementing discovery makes this more automatic, but I definitely want to document integrating with different HA platforms.

@alexeinz FYI, looks like @dennisvonderbey got it working with OpenHAB without discovery (see above).

[alexeinz]

DennisVonDerBey , could you clarify how did you add it ?
I have tried adding as per screenshot 00000000B55D when my gateway device id is 0xB55D and it does not work, the bridge remains offline

[sidoh]

Do you mean to be using protocol version 5? What kind of bulbs are you trying control?

[alexeinz]

i have both v6 and v5 bulbs the 55 in screenshot is rgbw and should work on v5 and lower with no issues

…

Sent from my cell

On Apr 27, 2017, at 9:15, Chris Mullins ***@***.***> wrote:b Do you mean to be using protocol version 5? What kind of bulbs are you trying control? ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[sidoh]

Have you already tried it with v6? It should indeed work with v5, but I can imagine it not working because v5 is unidirectional with the exception of discovery, whereas v6 packets are always met with a response.

Might be helpful to get Serial output with MILIGHT_UDP_DEBUG turned on.

If discovery is indeed the issue, adding it should fix for both v5 and v6.

[alexeinz]

Yes I tried setting the Gateway as v6 and v5 , the result is similar. My OpenHab installation simply does not see the 00000000XXYY mac adresses at all,and cant add the gateway except in the v2compat. mode. how can I test that ESP indeed responds with the correct mac adresses ?

…

------ Regards Alex Einz Tel - +81(0) 80-6749-1800 dj@alexeinz.info http://www.alexeinz.info Weekly quote: “The true sign of intelligence is not knowledge but imagination - Albert Einstein

On Thu, Apr 27, 2017 at 1:17 PM, Chris Mullins ***@***.***> wrote: Have you already tried it with v6? It should indeed work with v5, but I can imagine it not working because v5 is unidirectional with the exception of discovery, whereas v6 packets are always met with a response. Might be helpful to get Serial output with MILIGHT_UDP_DEBUG turned on. If discovery is indeed the issue, adding it should fix for both v5 and v6. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGeYSauupH4k4VCtGH_ExM9y9yDrzUU1ks5r0BbtgaJpZM4NIDFA> .

[fermentfan]

@alexeinz Which version of OpenHAB are you running? I am using the snaphshot (unstable) one which uses the new developement binding for the iBox bridges. I also needed to add it manually via the PaperUI. Gonna take a look at it again, because I like adding all my things via the files.

You can also try to look at the log. The Karaf console will give you more details than the default log file. You cann access it via ssh from the Pi (or what you're running it from):

ssh -p8101 openhab@localhost

The password is habopen. In there you can tail the log with log:tail.

[alexeinz]

I run oh2, and offcourse did debug on milight plugin.

16:35:28.288 [ERROR] [ht.internal.protocol.MilightDiscover] - Sending a discovery packet failed. Could not update status, because callback is missing

is what I get when the 00000000B55D mac is added.

Once mac is removed, v2 mode is discovered and added correctly

6:37:47.638 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'milight:bridge:b8595b89' has been updated. 16:37:47.931 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'milight:bridge:b8595b89' has been updated. 16:37:48.068 [WARN ] [milight.handler.MilightBridgeHandler] - BridgeID not known. Version 2 fallback behaviour activated, no periodical refresh available! 16:37:48.090 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'milight:whiteLed:b8595b89:0' has been added.

Can you tell which version of milight binding you running, or better yet send me a link - and i can test right now.

[sidoh]

Took an initial stab at the discovery protocol. You can try it out in this branch.

[alexeinz]

Nice one, is there a way to do remote upgrade using http console or I need to reflash the esp?

[sidoh]

> UDPSock = UDPSocket.new
=> #<UDPSocket:fd 10>
> UDPSock.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
=> 0
> UDPSock.send('HF-A11ASSISTHREAD', 0, '<broadcast>', 48899)
=> 17
> UDPSock.recvfrom(100)
=> ["10.133.8.146,000000000001,HF-LPB100", ["AF_INET", 48899, "10.133.8.146", "10.133.8.146"]]
> UDPSock.recvfrom(100)
=> ["10.133.8.146,000000000002,HF-LPB100", ["AF_INET", 48899, "10.133.8.146", "10.133.8.146"]]

[sidoh]

Yeah you can POST a compiled binary to the /firmware endpoint. This is the command I use:

$ pio run -e d1_mini && curl -vvv -X POST -u':'  -F 'image=@.pioenvs/d1_mini/firmware.bin' milight-hub/firmware && pio device monitor

There's also a modal in the UI if that's easier. A button at the bottom opens it.

[sidoh]

There is also a feature that pulls the latest release from github if that's what you meant, but right now it only looks at the latest stable release, and I'm afraid this feature is not super stable right now because SSL needs like 16 KBs of RAM, which is pretty close to steady state.

[alexeinz]

oh I see, cant compile the binary right now because at work ( i have access to the http UI remotely )... ( i got nodemcuv2 if you can hit compile for me on your end and up it here... btw whats is the udp response if you send “Link_Wi-Fi”

…

------ Regards Alex Einz Tel - +81(0) 80-6749-1800 dj@alexeinz.info http://www.alexeinz.info Weekly quote: “The true sign of intelligence is not knowledge but imagination - Albert Einstein

On Thu, Apr 27, 2017 at 5:03 PM, Chris Mullins ***@***.***> wrote: There is also a feature that pulls the latest release from github if that's what you meant, but right now it only looks at the latest stable release, and I'm afraid this feature is not super stable right now because SSL needs like 16 KBs of RAM, which is pretty close to steady state. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGeYSW08aIOYT1XvnvldP5zK5R7k0AiZks5r0EvTgaJpZM4NIDFA> .

[sidoh]

I can tag the release. Travis CI should upload compiled binaries momentarily:

https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.3.0-dev

It should have no output with the example configuration I gave since neither of the UDP servers are version 5. It responds with something like xx.yy.zz.ww,AABBCCDDEEFF for each version 5 server.

[alexeinz]

i mean if it would respond with macadress,ipadress to Link wifi , wouldnt it make the gateway fully compatible with v5 and lower boxes ?

…

Sent from my cell

On Apr 27, 2017, at 17:13, Chris Mullins ***@***.***> wrote: I can tag the release. Travis CI should upload compiled binaries momentarily: https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.3.0-dev It should have no output with the example configuration I gave since neither of the UDP servers are version 5. It responds with something like xx.yy.zz.ww,AABBCCDDEEFF for each version 5 server. ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[alexeinz]

seems no change here with the new one.

7:54:36.298 [ERROR] [ht.internal.protocol.MilightDiscover] - Sending a discovery packet failed. Could not update status, because callback is missing 17:54:36.335 [ERROR] [ht.internal.protocol.MilightDiscover] - Unexpected data received 192.168.1.78

[sidoh]

I don't think OpenHAB or anything else is (or should be) relying on the ID getting sent back being a hardware address bound to the IP. The argument for having it respond with generated IDs is that this is a device that supports multiple gateways, and it makes sense to me to distinguish them somehow. You're certainly welcome to try sending the MAC instead of the generated ID. Relevant bits of code are here and here.

The error you're seeing is from here, it seems:

                String[] msg = new String(buffer, 0, packet.getLength()).split(",");
                if (msg.length >= 2 && msg[1].length() == 12) {
                    // Stop resend timer if we got a packet.
                    if (resendTimer != null) {
                        resendTimer.cancel(true);
                        resendTimer = null;
                    }
                    // Determine version: Version 6 sends a third argument != ""
                    int version = msg.length >= 3 && msg[2].trim().length() > 0 ? 6 : 3;
                    // Notify all observers
                    discoverResult.bridgeDetected(((InetSocketAddress) packet.getSocketAddress()).getAddress(), msg[1],
                            version);
                } else {
                    logger.error("Unexpected data received {}", msg[0]);
                }

Having a hard time seeing how the messages it received are invalid. They should split into 2 or 3 tokens, and the ID should have length 12. Is it possible for you to modify the logger.error line to print out new String(buffer) instead of msg[0]?

[alexeinz]

it seem now with the new firmware and updated openhab addon, the mac ids are detected correctly.
Thank you!
For some reason though even though openhab2 detects v5 and v6 gateways correctly, I can only initialize one v5 gateway... but 2 v6 initializing fine and I guess it should function even with rgbw since they are backwards compatible anyway.
I am going to play a bit and try to force initialize a second v5 gateway .. and will look at the code over the weekend.
Thank you for your work, I can finally get rid off those controller boxes taking up space!

[sidoh]

Sweet. Glad it's working!

Interesting that v5 won't work with multiple ports. I don't think there's any reason this has to be the case, but could imagine the way OpenHAB has implemented version discovery doesn't work well because the v5 protocol is unidirectional.

Yeah -- v6 should work with every bulb type. And it's reasonably easy to add handlers for new remotes/bulbs :)