xoseperez / espurna

Home automation firmware for ESP8266-based devices
http://tinkerman.cat
GNU General Public License v3.0
3k stars 636 forks source link

Alexa discovery issue with latest 1.15.0(221212) #2567

Open m-planck opened 1 year ago

m-planck commented 1 year ago

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 https://github.com/vintlabs/fauxmoESP/issues/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 commented 1 year ago

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 commented 1 year ago

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.

https://github.com/xoseperez/espurna/blob/68310b6d46f7adca41dd5c8e93891814beef5718/code/platformio.ini#L146

m-planck commented 1 year ago

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 commented 1 year ago

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