Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alexa discovery issue with latest 1.15.0(221212) #2567

Open
m-planck opened this issue Dec 20, 2022 · 4 comments
Open

Alexa discovery issue with latest 1.15.0(221212) #2567

m-planck opened this issue Dec 20, 2022 · 4 comments
Labels

Comments

@m-planck
Copy link

Device

Sonoff Slampher

Version

espurna-1.15.0-dev.git312c3ef2+github221212-itead-slampher.bin

Bug description

I changed the IPs of Espurna devices in my router, power cycled etc.
After that two Gosund/Blitzwolf plugs with Espurna 1.13.5 were correctly recognized from Alexa under the new IP, however this was not the case for two ITEAD Slampher with a 1.15.0 build date Nov 2021 (other functions working correctly, e.g. MQTT). So I updated them to the latest 1.15.0-dev.git312c3ef2+github221212 build.

This 2 slampher devices refused to get discovered by Alexa. Removed them from Alexa account, tried the discovery through Echo 2. Gen, Alexa app, Alexa manual add device light/Hue bridge v1, Alexa website. Unpluged Echo, router and Slampher multiple times. Reflashed firmware. I tried to change Alexa on/off in Espurna firmware, changed Hostname, nothing worked.

Unfortunately there are no Alexa output debug logs of discovery protocol (is there an option to see it in the debug window?).
There are hints that Alexa protocol checks for proper uuid vintlabs/fauxmoESP#166 and problems with Echo gen 1 (but I own gen 2).
As last resort I flashed 1st Slampher to stable 1.14.1 and Alexa was able to discover the device again:

[149535] [ALEXA] Device #0 state: ON value: 255
[149537] [RELAY] #0 scheduled ON in 0 ms
[149549] [RELAY] #0 set to ON
[149551] [MQTT] Sending LICHT/relay/0 => 1 (PID 1)

Was there a change on Alexa protocol Hue emulation between 1.14.1 and latest dev build you can trace to this behavior?
2nd slampher still on 1.15, if you need some info for debug, otherwise I will flash it also to 1.14.1 in next couple days.

Steps to reproduce

No response

Build tools used

No response

Any relevant log output (when available)

No response

Decoded stack trace (when available)

No response

@m-planck m-planck added the bug label Dec 20, 2022
@m-planck
Copy link
Author

After reading more through the fauxmoESP threads, it seems Alexa is using the json at /api/lights/

The json of the working 1.14.1 device:

{"1":{"type":"Extended Color Light","name":"LICHT","uniqueid":"600194c14c51-1","modelid":"LCT007","state":{"on":false,"bri":0,"xy":[0,0],"reachable": true},"capabilities":{"certified":false,"streaming":{"renderer":true,"proxy":false}},"swversion":"5.105.0.21169"}}

The json of the non-discoverable 1.15.0 dev
{"1":{"type": "Extended color light","name": "LAMPE","uniqueid": "DC:4F:22:AA:1F:84:00:00-00"}}

Notice all the missing fields. The fauxmoESP library is not in the repo, so it is not traceable which version was used in the builds.

@mcspr
Copy link
Collaborator

mcspr commented Dec 20, 2022

Notice all the missing fields.

Depends on the input? 'all' sends short version, specific id would send out this full one
https://github.com/vintlabs/fauxmoESP/search?q=FAUXMO_DEVICE_JSON_TEMPLATE

The fauxmoESP library is not in the repo, so it is not traceable which version was used in the builds.

vintlabs/FauxmoESP@^3.4

@m-planck
Copy link
Author

m-planck commented Dec 20, 2022

If I ask for the first device in the v1.15.0 I get the full response (from http:///api/LAMPE/lights/1/):

{"type": "Extended color light","name": "LAMPE","uniqueid": "DC:4F:22:AA:1F:84:00:00-00","modelid": "LCT015","manufacturername": "Philips","productname": "E4","state":{"on": true,"bri": 255,"xy": [0,0],"hue": 0,"sat": 0,"effect": "none","colormode": "xy","ct": 500,"mode": "homeautomation","reachable": true},"capabilities": {"certified": false,"streaming": {"renderer":true,"proxy":false}},"swversion": "5.105.0.21169"}

So I suspect an issue in the short response that Alexa gets confused. As there are not so many fields, I suspect the uniqueid. Where in Tasmota it is set to "uniqueid":"xx:xx:xx:xx:xx:xx:00:11-01" (xx being the MAC) in fauxmoESP it is "uniqueid":"xx:xx:xx:xx:xx:xx:00:00-00", calculated by

unsigned int device_id = _devices.size();
snprintf(device.uniqueid, 27, "%s:%s-%02X", mac.c_str(), "00:00", device_id);

Can anyone confirm that Alexa's device discovery is happy with the string ending in 00:00-00, specifically the -00 ? The %02X operator is something mysterious, as I would assume from the output _devices.size() is zero but this is in conflict that it should be 1?

@mcspr
Copy link
Collaborator

mcspr commented Dec 21, 2022

Tasmota Ids are indeed starting from 1
https://github.com/arendst/Tasmota/blob/082380a800d7b60a3cad1f9df613d131d0e7e171/tasmota/tasmota_xdrv_driver/xdrv_20_hue.ino#L1078 (see every time maxhue is used)

This is the specific func that generates uniqueid string
https://github.com/arendst/Tasmota/blob/082380a800d7b60a3cad1f9df613d131d0e7e171/tasmota/tasmota_xdrv_driver/xdrv_20_hue.ino#L418-L428
https://github.com/arendst/Tasmota/search?q=GetHueDeviceId
(not really sure why they used u16 though)

String formatting is in the lib, so you'd have to rebuild and check the result. I assume the only change would be device_id + 1 instead of device_id
https://github.com/xoseperez/espurna/wiki/PlatformIO
We install dependencies before building, see code/libraries/FauxmoESP after calling pio run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants