Multiple gateways in MiLIght app V3 ?

[itProfi]

Can any chance make support (may be in library?) for support multiple gateways in MiLIght app V3 (in tabs of gateways) works with one ESP - maybe on other UPD ports? Very cool and comfortable application for bulbs and LED strips..

[sidoh]

For context on what I said in the other thread:

• I did notice that the response to the discovery protocol contains a port number, and that the app attempts to send some of its communications to the specified port.
• Unfortunately it doesn't send all of its communications to that port.

I didn't actually try very hard, so it might be possible. But it seemed like it was sending packets to the discovery port that needed to get sent to the command port.

Worth taking another crack at.

[itProfi]

May be this repo help - https://github.com/jjensn/milight-decompile ?

[sidoh]

Hah, interesting. It could!

Unrelated, but there goes the theory that they're doing anything sane to construct the UDP packets. Messy byte arrays like the rest of us scrubs.

[sidoh]

Alright, I poked at it a little more thoroughly, and I'm feeling disheartened again.

For background, the connection process looks like this:

P1. (Client -> Server): send search packet via UDP broadcast on port 5987 P2. (Server -> Client): send search response P3. (Client -> Server): send session start request P4. (Server -> Client): send session ID, to be used with all further requests

The challenge is:

1. In order for a single device to serve multiple IDs, there has to be a way for the client to specify which one it means to control.
2. I've tried two rough approaches with this. A. The search response packet contains a field for port. Changing this field in the response causes the client to send the session start request (P3) to the new port, but further requests are on port 5987, and the session started on the other port is never used again as far as I can tell. B. I had thought that P3 includes some scrutable identifier (this is why I felt positive in my last update), like the mac address of the device it was trying to start a session with, but it's the same packet every time. Not sure why I thought that it was any other way.
3. I could be wrong about some of my assumptions above, but if they're all true, I don't think it's possible to do this. :(

I poked around the decompiled source for a bit, but it's pretty hard to follow.

Have you used HomeAssistant or something like that, @Lstt2005? It should integrate nicely with this project and I think has most of the same controls that the Milight app does.

[itProfi]

Thank you very much for your attempts to understand. Very sorry. I wanted to avoid additional layers between the smartphone and ESP8266. Probably, I'll have to go in a different direction ..

[sidoh]

Haha, nothing to be sorry for. I had fun digging into it.

Could always write a phone app that leverages the multiple ports!

[itProfi]

I agree. Simply this ready-to-use application was very pleased by the design and functionality, so it's native. Unfortunately, in the Android studio I'm just beginner ..

[sidoh]

I agree - was pleasantly surprised with it as well!

[itProfi]

I could be wrong about some of my assumptions above, but if they're all true, I don't think it's possible to do this. :(

Can I help you on this situation than anything (with my beginner level)?

[sidoh]

If you could find the place in the decompiled app where it's sending/receiving each of the above packets (P1..P4), we could probably tell for sure whether it's possible or not.

[itProfi]

Ok, i will try...

[itProfi]

Have you used HomeAssistant or something like that, @Lstt2005?

They NO support multiples ID .. https://home-assistant.io/components/light.limitlessled/

[sidoh]

But they have support for multiple ports :)

This is basically the entire point of esp8266_milight_hub being able to spin up multiple UDP servers on different ports, each bound to its own device ID.

[itProfi]

If you could find the place in the decompiled app where it's sending/receiving each of the above packets (P1..P4), we could probably tell for sure whether it's possible or not.

Is it pcap file maybe help you ? https://cloud.mail.ru/public/DE1c/9EKRsvsfR Android ip 192.168.0.115, milight gateway 192.168.0.138, i just launch Milight and press @Searching for device"...

[sidoh]

Packet captures are basically what I've been working with here. Appreciate you providing one, but looks pretty much like the ones I've been dealing with.

[itProfi]

Maybe i found, what you say..) I analyze pakets and found, that in each session, Milight App send number of udp port, on wich it connect to ESP8266 to 5987 port in hex. Please, see attachment in doc. PacketAnalyze-5987-5988.docx

In addition, you can try to ask the application for a response with the option of working, for example, on port 5988 (in the answer - 18:00:00:00:40:02:00:00:00:00:11:11: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:64:00:00:05:00:09:78:6c:69:6e:6b:5f:64:65:76:07:5b:cd:15), but only do this once, only at the beginning of the session, on port 5987, and then, already work with the application on port 5988

[sidoh]

Yeah that's what I was noticing as well. This is the response to the broadcasted search request.

The problem I noticed was that the client seemed to start the session on the discovery port (5987), and use the session ID it was assigned there when sending packets to the custom port. This means you can't tell which session is attached to which port.

[itProfi]

((((

[sidoh]

:(

Hopefully it becomes possible (or more doable) in the future!