setDeviceUniqueId only sets first 12 characters of uniqueId

dancavallaro commented 1 year ago

I'm trying to customize my devices' unique IDs using setDeviceUniqueId but I'm finding that it only sets the first 12 characters of the unique ID. Can you confirm whether this is expected behavior, or a bug?

What I'm doing

Something like this, to set my device's unique ID to a random string:

unsigned char deviceId = fauxmo.addDevice("my device");
fauxmo.setDeviceUniqueId(deviceId, "ZX5AwfPGNfBt");
fauxmo.enable(true);

What I expected

I expected that my device's unique ID would be exactly equal to ZX5AwfPGNfBt after calling setDeviceUniqueId.

What actually happened

According to the verbose logs, my device's uniqueId is actually: ZX5AwfPGNfBt87:AC:00:00-00.

87:AC is the last two bytes of this ESP32's MAC address, that whole 87:AC:00:00-00 suffix looks like the part of the unique ID that's generated in addDevice. This suffix sticks around because it looks like setDeviceUniqueId only overwrites the first 12 characters of the unique ID (here).

Is this behavior intentional, or is it a bug leftover from https://github.com/vintlabs/fauxmoESP/commit/73ff88e725af7d5b40315e75819d1fb74a5b8459 or https://github.com/vintlabs/fauxmoESP/commit/2b49757194959fa35bbf3dca7435e3315056bd79?

dancavallaro commented 1 year ago

I wanted to briefly elaborate on my use case in case I'm misunderstanding how the device unique ID is used by Alexa. I have a few personal projects (mostly home automation type things) I'm working on that use fauxmoESP for Alexa integration, and I have a few ESP32 devices in varying states of deployed-ness that I'm using for testing. So there are two cases that I'd like to be able to handle, particularly while I'm still in development/testing (this all becomes less of a problem once a particular project is "permanently" deployed to a particular device):

I want to be able to flash different applications to the same ESP32 device at different times and have the correct devices respond to Alexa requests. For example, after testing application "A" which presents device "a", I want to be able to flash application "B" with device "b", and have it correctly respond to requests for device "b" but not device "a".
I also want to be able to flash the same application to different ESP32 devices at different times and have the "active" device respond to the right Alexa device for that application.

I was running into some odd behavior with case #⁠1, and that's what led me to find the new setDeviceUniqueId method. Having thought about this a bit more, the current implementation of setDeviceUniqueId should solve that problem for me, even though it's not completely overwriting the MAC address part.

I guess it's case #⁠2 that made me concerned about this limitation and open this issue, since even now that I'm setting my own custom unique ID, when I flash the same application on different ESP32 devices each one will use a slightly different actual unique ID because the MAC address part will differ. But to be clear, I'm not currently sure whether this is actually a problem, I haven't been able to test it as thoroughly as I'd like yet.

So, it's possible that there isn't really a problem here, but I'm still curious about whether the behavior I've described here is intentional or a bug in setDeviceUniqueId.

pvint commented 1 year ago

Yup, definitely a bug.

It might be a bit before I can address this (it's not a big deal, just that I am short on time and don't want to cheat on testing etc).

After a quick look, it seems to me that we need to set FAUXMO_DEVICE_UNIQUE_ID_LENGTH in fauxmoESP.h to 27, and then find each occurrence of setting the UniqueID and use it properly.

A PR is more than welcome, but if not I'll try to address this soon.

Thanks! Paul

dancavallaro commented 1 year ago

Thanks for confirming Paul! I've got a fix, and a plot twist :-). As for the fix, I'll submit a PR as soon as I submit this comment.

As for the plot twist, in testing my bugfix I've found that the format of the unique ID seems to matter, and Alexa won't discover your device if the unique ID isn't in a particular format. I've found some references online to the unique ID mattering (e.g. https://github.com/bwssytems/ha-bridge/issues/1325 and https://www.sigmdel.ca/michel/ha/opi/ha-bridge_03_en.html), but I haven't found anyone that's fully reverse-engineered the required format.

From my testing, here are some examples of unique IDs that seem to work:

AA:BB:CC:DD:EE:FF:AB:CD-00
- Similar to your default, but changing the "00:00" to "AB:CD".
AA:BB:CC:DD:EE:FF:FF:FF-Bu
- Similar again to the default, but showing that the final 2 characters don't have to be numeric (or even valid hex).
AA:BB:CC:DD:EE:FF:FF-FF-zz
- Showing that the final colon can be changed to a hyphen
AA-BB-CC-DD-EE-FF-FF-FF-zz
- Showing that all the colons can be changed to hyphens

And here are some that don't work:

ZX5AwfPGNfBt
- Can't just be a random string
vfBaP8F4JWMKBYctQaQmU7B8FE
- Can't just be a random string, even if it's the right length
7z:6Z:Ik:XN:Ev:QE:xn:ve-VA
- Not good enough to be structured like the default, the actual values seem to matter.
AA:BB:CC:DD:EE:FF:xn:ve-VA
- Not good enough for the first 6 pairs to be hex, the 7th and 8th pairs seem to have to be hex.
AA.BB.CC.DD.EE.FF.FF.FF-zz
- Doesn't work to change all colons to periods (but hyphens worked!)
AABBCCDDEEFFFFFF-zz
- Omitting all but final separators doesn't work either

And then I stopped at that point since that was good enough to give me a sense of what would and wouldn't work.

So anyway, bottom line is that I'm pretty sure my fix works, but this unique ID is definitely tricky and you have to be careful to set it to a value that will work.

dancavallaro commented 1 year ago

Here's the PR I opened: https://github.com/vintlabs/fauxmoESP/pull/243

vintlabs / fauxmoESP