[Announce] LMS-lite certified Smart Home skill for Alexa

[Paul Webster]

I removed Squeeze* from Alexa ... and ran discover again ... and again it said that it did not find anything BUT my players were back (without Squeeze in front).
I tried one (Office) and it worked fine.

The JSON from Skill to Alexa has a macAddress field ... so I wonder if that is it.
It is Optional according to https://developer.amazon.com/en-US/d...ections-object
So maybe simply leave it out if not being used.

Edit:
Might be reading too much into this but ...

From RFC342
"Two bits within the initial 3 octets of an EUI-48 have special
significance: the Group bit (01-00-00) and the Local bit (02-00-00).
OUIs and IABs are allocated with the Local bit zero and the Group bit
unspecified. Multicast identifiers may be constructed by turning on
the Group bit, and unicast identifiers constructed by leaving the
Group bit zero."

"AA" sets the "Group bit" ...

Edit2:
I might be reading too much into it though ... because Philippe's "Group Player" starts 02:
which also sets that bit and I did not remove that from LMS.

Anyway - scope to experiment ...

[philchillbill]

I removed Squeeze* from Alexa ... and ran discover again ... and again it said that it did not find anything BUT my players were back (without Squeeze in front).
I tried one (Office) and it worked fine.

The JSON from Skill to Alexa has a macAddress field ... so I wonder if that is it.

Edit:
Might be reading too much into this but ...

From RFC342
"Two bits within the initial 3 octets of an EUI-48 have special
significance: the Group bit (01-00-00) and the Local bit (02-00-00).
OUIs and IABs are allocated with the Local bit zero and the Group bit
unspecified. Multicast identifiers may be constructed by turning on
the Group bit, and unicast identifiers constructed by leaving the
Group bit zero."

"AA" sets the "Group bit" ...

Excellent !

The fact that Alexa does or does not say anything during discovery is rather random and totally up to whether Alexa is PMS'ing or not. You always have to look in the App for the truth.

The skill returns the new/optional 'connections' discovery object and sets {"type": "TCP_IP", "macAddress": endpoint.playerid.upper() }. As it's optional, I removed it in testing with @dunk, but it didn't help him any so I think it's harmless to leave it in. But it's interesting that some of the faked MACs might be causing an unreported error by being illegal for a smart home device. I'll ping Amazon and ask if they have any unpublished requirements on that.

If @dunk also gets all his players discovered with the beta code then I'll push it to the live build of LMS-lite.

[Paul Webster]

You might have missed my later edit

"I might be reading too much into it though ... because Philippe's "Group Player" starts 02:
which also sets that bit and I did not remove that from LMS.

Anyway - scope to experiment ..."

[philchillbill]

You might have missed my later edit

"I might be reading too much into it though ... because Philippe's "Group Player" starts 02:
which also sets that bit and I did not remove that from LMS.

Anyway - scope to experiment ..."

Yep, missed it. Would be worth disabling the beta, deleting the players, re-enabling LMS-lite again and seeing if that unmodified code can discover your players with your account junk removed. After all, it worked for many...

[Paul Webster]

Done ... devices did not come back.
So still not working with the released skill for me.

[Paul Webster]

Odd ... just initiated another discover - by voice this time (previous was within the workflow of enabling the skill) ... and now I do have my players listed again.

[philchillbill]

Odd ... just initiated another discover - by voice this time (previous was within the workflow of enabling the skill) ... and now I do have my players listed again.

So it does seem related to account history rather than to the skill code. In all honesty, there's no substantial difference between the two codesets, other than that the new beta keeps MAC address out of the endpointId. Still a mystery.

[philchillbill]

I'm starting to wonder if the whole MAC address thing was a misleading train of thought. I have noticed in the past that Amazon will not eat their own JSON, although not strictly related to discovery as such. If you write a skill manifest in JSON and upload the skill, you can download from Amazon what your current manifest state is in case you modified it in their online console. If you then try to upload that file instead of your original, ASK CLI will shout out an error that the JSON is invalid. The reason is because VSCODE will add a BOM (Byte Order Marker) to the file via the underlying PowerShell hook script. Amazon will not tolerate that BOM. Go figure - it's their code that adds it!

I'm just wondering if the JSON that LMS returns via jsonrpc in response to the [players ?] query might not have some illegal (invisible) characters or odd charset encodings. If you have a player you think is called 'Bedroom Player', is that really a space between the two words or is it something that looks like a space but is actually encoded oddly? @dunk's software players cause discovery to fail - maybe it's in the charset of the player details rather than the spoofed MAC address. I'm going to play with this today and see if I can uncover anything.

[Paul Webster]

Yesterday I did have a look through the json file that you shared with me.

No bad (including no hidden) characters in it as far as I (or a messy regex - [ a-zA-Z0-9@,\.\-\x0a\x0d"\:\{\}\[\]\_éç]* ) could see.
The only 2 sort of special ones were the accented ones in the French translations of a couple of fields (see end of the regex) - but they would be there for everyone.

[philchillbill]

No bad (including no hidden) characters in it as far as I (or a messy regex - [ a-zA-Z0-9@,\.\-\x0a\x0d"\:\{\}\[\]\_éç]* ) could see.
The only 2 sort of special ones were the accented ones in the French translations of a couple of fields (see end of the regex) - but they would be there for everyone.

Yes, the accented characters are there for everyone and are also present in @dunk's non-squeezelite players that are being discovered OK. I don't suspect they're the issue because I typed them myself as part of a device capability/interface I add to the discovery response. It has to be the characters in the player name, model or mac address as these are the only ones returned by jsonrpc that are 'externally' sourced.