Tasmota: Hue Emulation missbehavior

[chillje]

Hello,
I run 3x "Sonoff S20 plugs" and 6x Shelly1 with tasmota.
The " Sonoff S20 Plugs " are running with "Hue Emu", the Shelly1 with "Belkin WeMo".
All are learned and used with Amazons "Alexa".

Since yesterday the Sonoff devices don't react correctly anymore when using Alexa commands. Only one Sonoff device reacts to the voice commands for all three Sonoff devices.

Short scenario:
Alexa, switch on Sonoff1 -> Sonoff 1 switches on
Alexa, switch off Sonoff2 -> Sonoff 1 switches off
Alexa, switch on Sonoff3 -> Sonoff 1 switches on

I have already removed all Sonoff devices from Alexa and added them again.
Nothing has changed in the behaviour, only Sonoff2 now reacts to all commands for the different Sonoff devices.

I updated Sonoff1 via tasmota OTA via the website to a new tasmota version, but that didn't help either.

Changing Sonoff1 from "Hue Emu" to "Belkin WeMo" was not possible. Alexa doesn't find the device with the Belkin emulation.

I guess there is a problem with the "Hue Emulation".
Maybe an update in the protocol that Alexa is already aware of?

[ihavenonick]

Same Problem here, I think Amazon have something changes on the HUE detection.
This problem ist exist with all Tasmota versions wen use the HUE emulator.

[ascillato2]

Please, could you be so kind on completing the troubleshooting template in order to have more information so as to properly help you?

Remember to read the Contributing Guideline and Policy. Thanks.

---

Support Information (Guide)

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

[wernerk63]

Over 20 Sonoff Devices,
works perfect with the Workarounds (Hue brightness) before,
and then with Master 6.5.0.0 since publish for over 45 days.

now - same Problem with HueBridgeEmu after Alexa search Devices, since ca. 24h in Germany.

2x 4chpro and 2x T1EU with HueBridgeEmu and Tasmota Master 6.5.0.0 reacts false on Alexa.
Last night i do some Troubleshooting, it seams that Alexa only adresses/recognize one Hue Bridge.
With one HueBridgeEmu all is working, after adding the second one, a false Device switch..

The weblog's (Level 4) shows:

1. Alexa Search Devices, found and enumarate Hue Light's :
   /LastcharMac/light1 to light4 eg. light2 for each/all Devices
   (all correct, with different 'LastCharMac'/light x)

1. After adding the Second Device with HueBridgeEmu and switch a 'Light' a wrong Device switch...
   Weblog of the wrong switched Device show's the 'LastcharMac'/light x of the wrong Device,
   and not the 'HueAdress' (LastCharMac/light x) of the per VoiceCommand adressed Device

Maybe, it should works further, if i had not do a 'Search Devices'..... ( because of NetworkChanges)
I think, there is something changes on the Alexa HUE Support.

24.05 Edit TROUBLSHOOTING INFORMATION :
File Upload, same behavior as max0412 -> a lot of UDP: Packet (199) in between.
Hue Emulation missbehavior (#5849).txt

[Max0412]

Same problem here, i´ve added 2x H801 and enabled the Hue Emulation.
Both are found in the Alexa App but they both only switch the same H801.

Edit - i´ve just tried some variations.
switching a Shelly1 via App doesn´t work but with the Alexa Voice command it does work,

[s-hadinger]

This is strange, when you manually change the configuration of the light via the Tasmota console, the change is well reflected in Alexa. However when sending the commands from Alexa, it looks like it's sending UDP packets to try to discover which Hue bridge it should send to.

Will need to add more logs to troubleshoot.

[rherriage]

I'm running into the same issue as well. I noticed it this morning. I'm running 6 x Sonoff ifan02s with Tasmota 6.5. The status will change if I manually change the lights/fans on/off, but the app nor verbal commands with an echo will turn them off/on.

[ascillato]

Please, complete the troubleshooting template in order to have more debug information. Thanks

[Max0412]

ISSUE DESCRIPTION - TROUBLESHOOTING

Phillips Hue Emulation activated for 2 H801 with LED Strips
Phillips Hue Emulation activated for 1 Shelly1 as I/O Device

The H801 devices are both found in Alexa (Fernsehtisch and COUCH), but both(in-app and with voice command) just switch COUCH in the alexa app. Alexa does seem to recognize the current state/color of both H801 individually. - COUCH was set up first. -
The Shelly 1 does switch with voice command but doesn´t in-app. It does recognize the current state of the Shelly.

STATUS 0 of COUCH

20:56:56 MQT: stat/Wohnzimmer/STATUS = {"Status":{"Module":20,"FriendlyName":["COUCHLED"],"Topic":"Wohnzimmer","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 20:56:56 MQT: stat/Wohnzimmer/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"1T01:15:15","StartupUTC":"2019-05-23T18:41:41","Sleep":50,"CfgHolder":4617,"BootCount":9,"SaveCount":109,"SaveAddress":"F7000"}} 20:56:56 MQT: stat/Wohnzimmer/STATUS2 = {"StatusFWR":{"Version":"6.5.0.9(sonoff)","BuildDateTime":"2019-05-18T12:56:57","Boot":31,"Core":"2_5_0","SDK":"3.0.0-dev(c0f7b44)"}} 20:56:56 MQT: stat/Wohnzimmer/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["TP-Link_B33E",""],"TelePeriod":300,"Resolution":"55C180C0","SetOption":["00008009","280500000100000000000000000000000000","00000000"]}} 20:56:56 MQT: stat/Wohnzimmer/STATUS4 = {"StatusMEM":{"ProgramSize":600,"Free":400,"Heap":19,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"1440EF","FlashMode":3,"Features":["00000809","0FDAE394","000783A0","23B617CE","01003BC0"]}} 20:56:56 MQT: stat/Wohnzimmer/STATUS5 = {"StatusNET":{"Hostname":"Wohnzimmer-4859","IPAddress":"192.168.0.107","Gateway":"192.168.0.1","Subnetmask":"255.255.255.0","DNSServer":"193.31.25.87","Mac":"3C:71:BF:31:92:FB","Webserver":2,"WifiConfig":4}} 20:56:56 MQT: stat/Wohnzimmer/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.0.100","MqttPort":1883,"MqttClientMask":"COUCH_%06X","MqttClient":"COUCH_3192FB","MqttUser":"maxl","MqttCount":37,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 20:56:56 MQT: stat/Wohnzimmer/STATUS7 = {"StatusTIM":{"UTC":"Fri May 24 19:56:56 2019","Local":"Fri May 24 20:56:56 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"04:58","Sunset":"20:36"}} 20:56:56 MQT: stat/Wohnzimmer/STATUS10 = {"StatusSNS":{"Time":"2019-05-24T20:56:56"}} 20:56:56 MQT: stat/Wohnzimmer/STATUS11 = {"StatusSTS":{"Time":"2019-05-24T20:56:56","Uptime":"1T01:15:15","Vcc":3.405,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":24,"POWER":"OFF","Dimmer":61,"Color":"9B91000000","HSBColor":"56,100,61","Channel":[61,57,0,0,0],"CT":153,"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"TP-Link_B33E","BSSId":"0C:80:63:E5:B3:3E","Channel":6,"RSSI":90,"LinkCount":18,"Downtime":"0T00:01:12"}}}

STATUS 0 of the Shelly1

20:58:32 CMD: status 0 20:58:32 SRC: WebConsole from 192.168.0.101 20:58:32 RSL: Received Topic /status, Data Size 1, Data 0 20:58:32 RSL: Group 0, Index 1, Command STATUS, Data 0 20:58:32 MQT: stat/Wohnzimmer/STATUS = {"Status":{"Module":46,"FriendlyName":["Deckenlicht Wohnzimmer"],"Topic":"Wohnzimmer","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 20:58:32 MQT: stat/Wohnzimmer/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"2T01:55:39","StartupUTC":"2019-05-22T18:02:53","Sleep":50,"CfgHolder":4617,"BootCount":13,"SaveCount":147,"SaveAddress":"F9000"}} 20:58:32 MQT: stat/Wohnzimmer/STATUS2 = {"StatusFWR":{"Version":"6.5.0.9(sonoff)","BuildDateTime":"2019-05-11T04:03:33","Boot":31,"Core":"2_5_0","SDK":"3.0.0-dev(c0f7b44)"}} 20:58:32 MQT: stat/Wohnzimmer/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":4,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["TP-Link_B33E",""],"TelePeriod":300,"Resolution":"55C180C0","SetOption":["00008009","280500000100000000000000000000000000","00000000"]}} 20:58:32 MQT: stat/Wohnzimmer/STATUS4 = {"StatusMEM":{"ProgramSize":600,"Free":400,"Heap":18,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"1540EF","FlashMode":3,"Features":["00000809","0FDAE394","000783A0","23B617CE","01003BC0"]}} 20:58:32 MQT: stat/Wohnzimmer/STATUS5 = {"StatusNET":{"Hostname":"Wohnzimmer-4064","IPAddress":"192.168.0.104","Gateway":"192.168.0.1","Subnetmask":"255.255.255.0","DNSServer":"193.31.25.87","Mac":"B4:E6:2D:55:EF:E0","Webserver":2,"WifiConfig":4}} 20:58:32 MQT: stat/Wohnzimmer/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.0.100","MqttPort":1883,"MqttClientMask":"WZ_Deckenleuchte_%06X","MqttClient":"WZ_Deckenleuchte_55EFE0","MqttUser":"maxl","MqttCount":44,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 20:58:32 MQT: stat/Wohnzimmer/STATUS7 = {"StatusTIM":{"UTC":"Fri May 24 19:58:32 2019","Local":"Fri May 24 20:58:32 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"04:58","Sunset":"20:36"}} 20:58:32 MQT: stat/Wohnzimmer/STATUS10 = {"StatusSNS":{"Time":"2019-05-24T20:58:32","Switch1":"ON"}} 20:58:32 MQT: stat/Wohnzimmer/STATUS11 = {"StatusSTS":{"Time":"2019-05-24T20:58:32","Uptime":"2T01:55:39","Vcc":3.502,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"TP-Link_B33E","BSSId":"0C:80:63:E5:B3:3E","Channel":6,"RSSI":82,"LinkCount":10,"Downtime":"0T00:00:41"}}}

weblog4 of Shelly:
20:59:42 WIF: Checking connection... 20:59:42 WIF: Connected 21:00:01 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:01 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"}) 21:00:02 WIF: Checking connection... 21:00:02 WIF: Connected 21:00:07 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:07 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"}) 21:00:13 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:13 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"}) 21:00:16 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:16 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"}) 21:00:19 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:19 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"}) 21:00:22 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:22 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"}) 21:00:22 WIF: Checking connection... 21:00:22 WIF: Connected 21:00:25 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:00:25 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deckenlicht Wohnzimmer","modelid":"LCT007","uniqueid":"b4:e6:2d:55:ef:e0:00:11-1","swversion":"5.50.1.19085"})
with a lot of 20:59:34 UDP: Packet (199) in between.

weblog 4 of COUCH
21:02:20 CMD: weblog 4 21:02:20 MQT: stat/Wohnzimmer/RESULT = {"WebLog":4} 21:02:21 CFG: Saved to flash at F6, Count 110, Bytes 3584 21:02:26 WIF: Checking connection... 21:02:26 WIF: Connected 21:02:30 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:30 HTP: Hue Result ({"state":{"on":false,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:32 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1/state) 21:02:32 HTP: Hue POST args () 21:02:32 HTP: Hue POST args ({"on": true}) 21:02:32 SRC: Hue 21:02:32 MQT: stat/Wohnzimmer/RESULT = {"POWER":"ON"} 21:02:32 MQT: stat/Wohnzimmer/POWER = ON 21:02:32 HTP: Hue Result ([{"success":{"/lights/1/state/on":true}}]) 21:02:33 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:33 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:33 CFG: Saved to flash at F5, Count 111, Bytes 3584 21:02:36 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:36 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:38 UDP: Packet (199) 21:02:39 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:39 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:42 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:42 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:45 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:45 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:46 WIF: Checking connection... 21:02:46 WIF: Connected 21:02:48 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:48 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:51 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:51 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:54 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:54 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"}) 21:02:57 HTP: Hue API (/OD4gGlAzzyzQGfFrCZ59qPYYAFsDlNEPvFiNjQZZ/lights/1) 21:02:57 HTP: Hue Result ({"state":{"on":true,"bri":155,"colormode":"hs","xy":[0.44658,0.52597],"hue":10223,"sat":254,"ct":153,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"COUCHLED","modelid":"LCT007","uniqueid":"3c:71:bf:31:92:fb:00:11-1","swversion":"5.50.1.19085"})

hope that did help.

[s-hadinger]

@jay-wilkinson This is a different question from the main topic of this issue. Could you please open a separate Issue so we don't get people confused?

[s-hadinger]

I added some logs and I can confirm that Alexa sends a UDP UPNP discover just before sending the command to Tasmota. I guess this is a check to make sure the device hasn't change IP address since last discover. This is where something must be wrong, and Alexa gets confused by the Tasmota answer.

09:22:30 UDP Packet received m-search*http/1.1host:239.255.255.250:1900man:"ssdp:discover"mx:3st:ssdp:all
09:22:32 Packet 1 HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.1.203:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.17.0
hue-bridgeid: 840D8EFFFE59313E
ST: upnp:rootdevice
USN: uuid:f6543a06-da50-11ba-8d8f-840d8e59313e::upnp:rootdevice


09:22:32 Packet 2 HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.1.203:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.17.0
hue-bridgeid: 840D8EFFFE59313E
ST: uuid:f6543a06-da50-11ba-8d8f-840d8e59313e
USN: uuid:f6543a06-da50-11ba-8d8f-840d8e59313e


09:22:32 Packet 3 HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.1.203:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.17.0
hue-bridgeid: 840D8EFFFE59313E
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:f6543a06-da50-11ba-8d8f-840d8e59313e


09:22:32 UPP: Hue 3 response packets sent to 192.168.1.43:50000
09:22:32 HTP: Hue setup
09:22:32 Send XML description <?xml version="1.0"?><root xmlns="urn:schemas-upnp-org:device-1-0"><specVersion><major>1</major><minor>0</minor></specVersion><URLBase>http://192.168.1.203:80/</URLBase><device><deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType><friendlyName>Amazon-Echo-HA-Bridge (192.168.1.203)</friendlyName><manufacturer>Royal Philips Electronics</manufacturer><modelDescription>Philips hue Personal Wireless Lighting</modelDescription><modelName>Philips hue bridge 2012</modelName><modelNumber>9290002
09:22:46 HTP: Main Menu

[rherriage]

an update.... i tried 6.5.0.12 and now the echo dot voice is working, but the app still isn't working. It will return status, but it won't change status.

another update... I walked through my house this morning and alexa voice works on some of my 6.5.0 IFAN02s, but the app still isn't working. Looks like Amazon is changing stuff...

and I added some more weblogs for one of the ones that's not working via voice on 6.5.0 build 3-29. Although you may not want to spend too much time on it since that seems to be resolved with 6.5.0.12.

here is the template:

ISSUE DESCRIPTION - TROUBLESHOOTING

Alexa stopped working with hue emulation a couple of days ago. This happened all at the same time on 6 x Sonoff IFAN02s running 6.5.0. The alexa app nor echo dots could change the status of the switch; however, the app couldsee what the current status is (can see if the switch is on or off if changed manually). I updated one to 6.5.0.12 and now voice command works from echo, but the IOS app does not

• [x ] Read the Contributing Guide and Policy and the Code of Conduct
• [x ] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• [ x] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• [ x] Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers)
• [ x] Searched the problem in the chat (https://discord.gg/Ks2Kzd4)
• [x ] Device used (i.e. Sonoff Basic) : _sonoff IFAN02____
• [x ] Tasmota binary firmware version number used : __6.5 core 2.5 and 6.5.0.12 core 2.5.1 pre-compiled
• [x ] Development IDE - Compiler / Upload tools used : _arduino ide___ / _OTA upgrade___
• [x ] Provide the output of command status 0 :

STATUS 0 OUTPUT HERE:
14:48:59 CMD: status 0
14:48:59 RSL: STATUS = {"Status":{"Module":44,"FriendlyName":["Play Room lights"],"Topic":"Play Room","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
14:48:59 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/020501/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T00:10:00","StartupUTC":"2019-05-25T13:38:59","Sleep":50,"CfgHolder":4617,"BootCount":274,"SaveCount":283,"SaveAddress":"F8000"}}
14:48:59 RSL: STATUS2 = {"StatusFWR":{"Version":"6.5.0.12(4d070bf-sonoff)","BuildDateTime":"2019-05-24T16:02:07","Boot":7,"Core":"2_5_1","SDK":"2.2.1(cfd48f3)"}}
14:48:59 RSL: STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["rustytoo",""],"TelePeriod":300,"Resolution":"55C180C0","SetOption":["00008001","280500000100000000000000000000000000","00000000"]}}
14:48:59 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":574,"Free":428,"Heap":25,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","0FDAE394","001783A0","23B617CC","01003BC0"]}}
14:48:59 RSL: STATUS5 = {"StatusNET":{"Hostname":"Play Room-7970","IPAddress":"192.168.5.57","Gateway":"192.168.5.1","Subnetmask":"255.255.255.0","DNSServer":"208.67.222.222","Mac":"DC:4F:22:DB:9F:22","Webserver":2,"WifiConfig":4}}
14:48:59 RSL: STATUS7 = {"StatusTIM":{"UTC":"Sat May 25 13:48:59 2019","Local":"Sat May 25 14:48:59 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"04:57","Sunset":"20:37"}}
14:48:59 RSL: STATUS10 = {"StatusSNS":{"Time":"2019-05-25T14:48:59"}}
14:48:59 RSL: STATUS11 = {"StatusSTS":{"Time":"2019-05-25T14:48:59","Uptime":"0T00:10:00","SleepMode":"Dynamic","Sleep":50,"LoadAvg":23,"POWER1":"OFF","FanSpeed":0,"Wifi":{"AP":1,"SSId":"rustytoo","BSSId":"58:AC:78:F8:F0:B1","Channel":6,"RSSI":84,"LinkCount":1,"Downtime":"0T00:00:04"}}}
14:49:03 APP: Serial logging disabled

• [ x] Provide the output of console when you experience your issue if apply :
  _(Please use_ weblog 4 _for more debug information)_

CONSOLE OUTPUT HERE:
this is from the app test.  You can see that it returns the state, but it will not make a change.


14:51:44 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Play Room lights","modelid":"LCT007","uniqueid":"dc:4f:22:db:9f:22:00:11-1","swversion":"5.50.1.19085"})
14:51:48 WIF: Checking connection...
14:51:48 WIF: Connected
14:52:08 WIF: Checking connection...
14:52:08 WIF: Connected
14:52:10 HTP: Information
14:52:13 HTP: Hue API (/o61z9UvSfD2xIFxfM2iVhuo4xHz4XlpUseCkrfY0/lights/1)
14:52:13 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Play Room lights","modelid":"LCT007","uniqueid":"dc:4f:22:db:9f:22:00:11-1","swversion":"5.50.1.19085"})
14:52:28 WIF: Checking connection...
14:52:28 WIF: Connected
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:44 UDP: Packet (199)
14:52:48 WIF: Checking connection...
14:52:48 WIF: Connected
14:52:57 UDP: Packet (199)
14:52:57 UDP: Packet (199)
14:52:57 UDP: Packet (199)
14:52:58 UDP: Packet (199)
14:52:59 UDP: Packet (199)
14:53:00 UDP: Packet (199)
14:53:00 UDP: Packet (199)
14:53:00 UDP: Packet (199)
14:53:00 UDP: Packet (199)
14:53:01 UDP: Packet (199)
14:53:02 UDP: Packet (199)
14:53:03 UDP: Packet (199)
14:53:03 UDP: Packet (199)
14:53:03 UDP: Packet (199)
14:53:03 UDP: Packet (199)
14:53:04 UDP: Packet (199)
14:53:05 UDP: Packet (199)
14:53:08 WIF: Checking connection...
14:53:08 WIF: Connected
14:53:14 HTP: Hue API (/o61z9UvSfD2xIFxfM2iVhuo4xHz4XlpUseCkrfY0/lights/1)
14:53:14 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Play Room lights","modelid":"LCT007","uniqueid":"dc:4f:22:db:9f:22:00:11-1","swversion":"5.50.1.19085"})

CONSOLE OUTPUT HERE:
seems it won't turn on the fan, but it will turn on the light after turning it off and on manually several times.

5:06:45 RSL: POWER1 = ON
15:06:45 CFG: Saved to flash at F7, Count 693, Bytes 3584
15:06:46 HTP: Hue API (/or876gUfZOBgm0TZMU1DB0shnwI2lYpMhtzirWY6/lights/1)
15:06:52 WIF: Checking connection...
15:06:52 WIF: Connected
15:07:12 WIF: Checking connection...
15:07:12 WIF: Connected
15:07:13 HTP: Hue API (/or876gUfZOBgm0TZMU1DB0shnwI2lYpMhtzirWY6/lights/1/state)
15:07:13 HTP: Hue POST args ()
15:07:13 HTP: Hue POST args ({"on": false})
15:07:13 SRC: Hue
15:07:13 RSL: RESULT = {"POWER1":"OFF"}
15:07:13 RSL: POWER1 = OFF
15:07:13 CFG: Saved to flash at F6, Count 694, Bytes 3584
15:07:13 HTP: Hue API (/or876gUfZOBgm0TZMU1DB0shnwI2lYpMhtzirWY6/lights/1)
15:07:32 WIF: Checking connection...
15:07:32 WIF: Connected

(Please, remember to close the issue when the problem has been addressed)

[s-hadinger]

I've been spending some time on it. I confirm that voice control works but app or on-screen control (Echo Spot) does not work. It does not seem linked to Tasmota. But still digging.

[s-hadinger]

Interestingly, when you use the app, it looks like the commands are always dispatched to the Tasmota device with the smallest IP address. Though it works ok when using voice commands.
I have tweaked a lot of parameters in Tasmota (BridgeIDs...) with no change. I will contact Alexa support.

[wongnam]

@s-hadinger Please note that Echo Show, Echo Spot, Sonos One do not have the capability to discovery devices locally, in case it will work if one or more Echo gen1; Echo dot gen1/gen2 mix into one network with it.

[Supermicha81]

I have the same problem. But my issues only appear, if I try to switch Sonoffs in Groups.
All devices were listed correctly in the app and react fine, if I anounce them directly.
If I try to switch a Alexa group, the result is unpredictable.
Sometimes only on device or only on channel of an 4ch device react, sometimes a different multichannel device react. After deleting the devices from Alexa and search again, the behavior is newly different and other devices react on the same command.

Looks for me, that Amazon make some strage changes...

maybee off-topic:
Last night Alexa was not able to find a Sonoff Basic (WeMo-Emu). Only if I tried to search after televisons in the Alexa-App, the missing Basic was found... really strange...

I use only Echo-Dots (2.Gen) and all my Tasmota-Devices runs on 6.4.1.9-mod-1.43.9, the multichannel devices with Hue-Emu, the singlechannel with WeMo-Emu...

I'm sorry, today I'm out of time to create some logs...
If nessaccary, I will do later...

Update: My wife approved 5 Minutes ago, that at least one Alexa-Group with a multichannel-device works fine... I will observe.

[Cemal32]

I have the same problem since two days.

I think the issue is caused by Phillips end of support of the Hue Bridge V1.

I’ve installed Yonomi to test, if Yonomi can detect my Sonoff 3CH Switches.

Yonomi detects them as Hue Bridges V1 and controls them perfectly.

So my assumption is, that Amazon also ended their support for Hue Bridges V1 and supports only the V2. As Tasmota seems to emulate Hue Bridge V1, Alexa can’t control the Switches correctly.

[arendst]

@Cemal32 you're right considering the Philips Hue Bridge V1 support see https://www2.meethue.com/en-gb/hue-bridge-upgrade

It ends in April 2020 but starting from April 2019

Voice control unavailable

Voice assistants that function via cloud connection, such as Amazon Alexa and the Google Assistant, will not work with the Hue Bridge v1.

So either Amazon has to be convinced that many users with Hue V1 hardware still need support or we have to find a way to emulate Hue V2.

The above quote from Philips does not make me buy Hue hardware any time soon considering the simple fact that they stop (and force others) support for it and using security as the main reason also force others to stop support. If I was Hue V1 owner I would force Philips to send me V2 hardware for free.

[Jason2866]

Happy that i never bought Hue hardware. Not the first time Philips left customers standing in the rain.
I can remember the stopped support services for TVs in the past which where included...

[altelch]

If it's true that this is caused by a switch to v2 API then we have a problem: https://daenney.github.io/2019/04/09/emulating-philips-hue-bridge
After initial Handshake SSL is required to talk to the bridge. Tasmota would have to implement SSL as HTTP endpoint but with which ressources...hopefully it's only a minor incompatibility after an API change. Is the same behaviour detected by other emulation projects like Homeassistant or EspAlexa (https://github.com/Aircoookie/Espalexa)?

[arendst]

That's an easy one: https://github.com/Aircoookie/Espalexa/issues/71

Same problem. Nice future.

[s-hadinger]

I did change the advertised device name in Tasmota to "Philips hue bridge 2015" instead of "Philips hue bridge 2012" and it does not change anything. Alexa doesn't care about the model and uses the well documented Philips Hue API: https://developers.meethue.com/develop/hue-api/

I'm confident it has no link to the depreciation of Philips hardware nor linked to HTTP/HTTPS protocol. This would not explain why it still works on Voice Control.

It really looks like Alexa is confusing multiple Hue bridges on the same network. I'll contact Alexa on Monday to see if it's a bug on Alexa side.

[rherriage]

what's weird is it is now voice control is intermittently working. I can find no rhyme or reason. My devices are not changing IPs (host DHCP lease), so it's not a discovery thing. One device that was working yesterday is not working today. I've got two devices on the 5/24 build, and one works, the other doesn't. I've tried to force updates on all my echo dots (none needed them). I've even tried to just turn them off, and try them one by one. I've got echo, echo dot 2nd (like 4 of them) and echo dot 3rd gen..

Again, it'll detect status, but won't change on/off.

I'm not sure why this would be related to the lack of support on V1, since support ended 4/20, and this just stopped working a few days ago. It's definitely possible, but seems weird that even if it's not supported by phillips they would just nix that code in echo.

[clabnet]

Me too. Only for tracKing thread.

[wernerk63]

With one HueBridge Alexa App+Voice works correct for me. ( -> delete all other devices !)
After add a Second Bridge App+ Voice works also, but Alexa seams to be confused about HueID and switches the false Bridge Device. (-> also delete all other not used Devices in this scenario)
(m.E. it switches the last configured -> s-hadinger say this with the lowest IP) .
With more Bridges/Multichannel Devices in Alexa it gets very confused, the Status in App hangs or errors occur, voice switches or not.
Be patiently, wait for Alexa feedback.

[znanev]

I was using WeMo emulation for all my Tasmota devices until a week ago. Alexa had no troubles finding or controlling the Tasmota devices individually or in groups.
Then I decided that Philips Hue emulation is the way forward so I updated the firmwares of all Tasmota devices to latest dev. version available and changed the emulation to Philips Hue. Since then controlling the devices in groups from Alexa has unpredictable results. Controlling the devices individually works with no troubles, but switching groups of devices on/off is impossible when more that one device is in Hue emulation mode.
So if it turns out that Amazon did something on their end related to the old Philips V1 devices, this will be a deal breaker for me. I'll have to either live with WeMo emulation (although partially broken and deprecated), or if this doesn't work - changing the voice assistant to some DIY one...

[altelch]

Ok, just compiled a 6.5.0.12(sonoff)-2_5_2 and flashed it on a D1 mini, activated HUE and did a device search. Device was detected by Alexa and I can still switch my old Hue emulated devices or the new one without problems. I only have Echo and Echo-Dot Gen.1 devices on firmware 637566720 (Dot) and 635556820 (Echo). Maybe this is related to Gen.2 or later devices.

[peteakalad]

Same issue for me, basic with hue emulation on no longer working. Readded few times, seemed to work once but then stopped working.

I have two echo dots and a v2 hue bridge if that matters..

Reverted to using wemo and that’s working ok with Alexa.

[znanev]

@altelch Did you try to control Hue emulated devices in groups?

I also have no problems controlling Hue emulated devices from Alexa (mine is 3rd gen) individually, but once I add two or more in a group - the behaviour is erratic and unpredictable.

[altelch]

@znanev Ok, can reproduce the issue. If creating a group over two emulated bridges, the bridge with the highest IP (or latest added bridge) gets switched. After removing the newest device from the group and only leaving devices on one emulated bridge still the latest added bridge gets the requests also none of it's devices are member of the group.

[altelch]

Test 2: Created a group with only devices from latest added bridge. Switching works. Add a device from an older bridge, devices on older bridge don't get switched. Remove devices from latest added bridge, Echo responds with "No answer from device xxx". Didn't see any SSDP requests in front of switching commands. Something in Group-handling of Alexa got messed up I'd guess.

[wernerk63]

No groups.......,
only the existence of a second HueBridge in Alexa causes the issue.
Test One Hue Bridge 2 Devices (T1EU) every device in a Group works correct.
Another Group (sonoffs basic, s20) with wemo devices works all the Time.

Edit: 2 Devices (T1EU) in one group works also correct.

[znanev]

@wernerk63 Indeed existence of multiple Hue emulated bridges seems to cause troubles with Alexa. A single Hue emulated bridge (switch with RGB leds, emulated as two devices) works fine with Alexa. Adding another Hue emulated bridge somehow "steals" the packets from the earlier added ones...

Can anyone with at least two "real" Hue bridge v1 devices verify if Alexa exhibits the same problems?

[jemarr]

Same problem since four days ago... Amazon has changed something.

I tried Fauxmo and Espalexa Hue emulation libs as well with same results.

I have three ESP8266 boards with 1, 2 and 4 devices each. The last discovered devices board (casually is the lowest fixed IP adress) is which Alexa takes as 1st, 2nd.... device on Routines and Groups, doesn't matter the device name.

When you call by voice all devices runs well, the problem is just with Groups and Routines.

I've 2 Echo Dot 3rt Gen.

[Supermicha81]

I have another maybee intersting fact.
If I rename devices in the Alexa App. They are no longer controllable...
In detail: On my Sonoff 4ch with Hue-Emu the first channel ist named "TV" and Alexa switch this without any Problem. I tried to rename it to "Fernseher" and it does not work anymore.
Changing back to "TV" works fine.

If I set the friendly name in Tasmota to "Fernseher" and search for new devices, Alexa is able to switch the device "Fernseher" without problems.

Maybee this helps to delimit the problem..

P.S. Alexa was not able to discover the deleted and renamed device als lamp or socket
I have Alexa tried to look after television-device to find the new Sonoff.

[Supermicha81]

Is it possible to "duplicate" the Wemo-Emulation? So that multichannel-devices emulate 2 or 4 single Wemos?
This would also solve the problem that switches will have a dimming slider in the Alexa-App.

[rherriage]

so... one thing that I've noticed. For the IFAN02 to work with fan speeds, multiple switches need to be set simultaneously. Like for high, switch 1 and 3 needs to be turned on, with 2 off. In order to accommodate this, I've set up routines (set the fan to high), etc.

If I call the friendly names individually (turn fan 1 on, turn fan 3 on) they work. However the "routine" do do that does not. Also, I've noticed that if I call the friendly name for the light "office light" it will also turn on. But with the light attached to the office alexa, "turn the lights on" used to work, but it doesn't.

I've tested every SONOFF IFAN02 in my house with the same result, except 1. I've noticed that one random SONOFF will work properly. And it seems to change which one works properly from day to day without me running a rediscover from the webpage.

[s-hadinger]

All, although this is slightly off-topic, I wanted to dive into why Belkin Wemo emulation failed.
But to my surprise it actually worked with 6.5.0.13 (core 2_5_2).
It also appears that Alexa does not mix up devices with Wemo emulation.

Can you confirm? This would be a temporary workaround for some of you.

[znanev]

@s-hadinger I can confirm that Wemo emulation works for me too. It also used to work before I switched over to Hue emulation.

I'm not sure however how all this corresponds with the recently closed poll #5826 ?

[arendst]

The poll was initiated after users complaint of unusable wemo functionality.

As it turns out now it still works fine wemo will not be disabled any time soon.

Sorry for the miscommunication.

[wernerk63]

looks similar, probably the same trigger
https://github.com/bwssytems/ha-bridge/issues/1093#issuecomment-495918797

[znanev]

@s-hadinger I can confirm that Wemo emulation works for me too. It also used to work before I switched over to Hue emulation.

I was too quick to report... Now, having removed all Hue emulated devices and groups from Alexa, and discovered only WeMo emulated devices, groups are still unusable.

Individual devices respond fine, but when in groups - nothing turns on/off.

[s-hadinger]

I got additional information from Alexa. There is a work-around to solve this issue, assigning a different lightId to each light. Normally lights have ids "1", "2"... on each bridge. Enforcing unique lightIds ensures that Alexa does not get confused.

The new lightId is computed as follows: (last byte of IP address * 16) + light number.

Ex: for 192.168.1.100 - light 1, it would be (100*16+1 = 1601)

This works fine if Tasmota devices don't change IP address, you may have issues if the devices change IP addresses.

[s-hadinger]

I forgot to mention, you need to reflash all devices, remove all of them from Alexa and trigger a new discovery from Alexa.

[Jason2866]

@s-hadinger Great news!
Big THX for your investigations you spend effort and time in.

[Jason2866]

@s-hadinger is the IP based solution for Hue ID from Alexa Team or did you create it?
If it was yours, maybe considering to use MAC address (@meingraham had this idea)
So there would be no change if getting a different IP adress

[meingraham]

@Jason2866 and I were discussing this on Discord. The requirement is unique IDs, not the method to ensure uniqueness. If the IP address changes, the light will "announce" a different ID. Will Alexa have to "re-discover" it because the ID changed? With a MAC based uniqueness algorithm, uniqueness is still ensured, but the ID for the light will not change.

[s-hadinger]

IP address was my ID, let me explain below.

I agree that MAC would be better, but keep in mind that lightId is an integer, and not sure whether we can go up to 32 bits. This would mean hashing the MAC to let's say 26 bits (to keep 4 bits for multiple lights on the same device), with a potential risk of collision.

We need to do more testing obviously and IP may not be the best way, but I wanted to share the good news as soon as possible.

[Boris16]

Great solution. Thanks also from my side.
I think the last byte of the IP-address is more unique. The MAC-address consists of 6 bytes. You have to find a CRC-sum or other algorithm to reduce the length. And that may not be 100% unique.

I have another question: As mentioned above, the V1 protocol will be discontinued in April 2020. Do we have problems in one year again?

[Boris16]

I have just come up with another idea:
Why can not I assign a unique number (DeviceID=0..255) in the configuration to each Tasmota device. Is indeed a parameter more that you have to specify. But one is independent of IP and MAC address.

[rherriage]

thanks @s-hadinger!!! Like... a lot! This solution will work perfectly for me, as I create a host-based DHCP lease for my tasmota devices. Assuming this works, I'm ecstatic. Tired of my wife asking me why it doesn't work anymore ><

Thanks again, truly.

[znanev]

Just tested the latest build (up to commit 2641e8a), and I can confirm that most of the Hue emulation functionality works correctly with Alexa.

However one of my devices, consisting of a relay and 3 LEDs (RGB), has another issue with Alexa. I'm not sure if I should open a new issue, because the workaround applied may be related to the following problem:
Hue emulated Tasmota device is correctly discovered as two lights (let's say DeviceSwitch - controlling a relay, and DeviceLight - controlling the RGB LEDs). Selecting either device in Alexa App presents the brightness slider and "Set Colour" option. These work fine for both devices, however pressing the light on/off button works correctly only for the "first" device - DeviceSwitch. When pressing the light on/off button on the "second" device - DeviceLight, the relay is switched off if it was previously switched on, but a "Device malfunction" error message appears. Pressing this same on/off button once the relay has been switched off from the "second" device has no effect and just "Device malfunction" error appears. This was not the case before - pressing the light on/off button of DeviceLight turned on/off the LEDs and the light on/off button of DeviceSwitch turned on/off the relay (i.e. they were not mixed up as they are now).

[meingraham]

Unless a user assigns a static IP address, the lease could expire and a new IP address assigned giving the device a different Hue ID.

Each octet of the MAC address is a number in the range of 0 to 255 (like each octet of the IP address). The three most significant are assigned to a vendor (Espressif for these devices) and the lowest three enumerated within the ranges assigned to the vendor. Some hashing of the least significant octet (or two or three) are as random as the IP address... but constant over the life of the device.

An alternative to the MAC address would be the ESP chip ID. You could mask off a certain number of bits from the chip ID.

[s-hadinger]

Good feedback, thanks.

It's important to ensure that there is unicity within the local network so using the last 8 bits (or 10-12 if you have a large home) looks safe. The main issue is when you reboot your router and all devices, if you haven't assigned static IPs they will change addresses. I don't know how Alexa behaves when it happens. I.e. is Alexa confused if lightIds change.

My main concern is when you change IP addresses, a new Tasmota device may re-advertize a lightId already assigned to another Tasmota.

I propose to combine it with the last byte of Mac address to reduce probability of conflict if IP addresses are reused.

What about : (8 last bits of MAC) followed by (8-10 last bits of IP address) followed by (2-4 bits of local light)

[Jason2866]

As long the IP address is part of the lightID there will be issues when device gets a new IP.
So a wiki entry is neccessary anyway. I am fine with this. DHCP server has to be configured to give
devices with known MAC addresses always the same IP.
If there is a optimizing possibility to avoid the same lightID in a big LAN it is a good idea to do.

[arendst]

@s-hadinger did you find out what the max number of bits for a lightid may be?

On the philips hue developers pages (https://developers.meethue.com/develop/hue-api/datatypes-and-time-patterns/) I cannot find the datatype for lightid. From the list I guess it's just 16 bits (uint16) as that is the biggest one documented there.

In that case I suggest to use the last 12 bits from the MAC address and 4 bits for local light. You just do not have more bits available.

Below some dumps from my MAC addresses on my routers:

All addresses are unique at the last 12 bits. It's tricky but not all MAC addresses are being used by Alexa either. Using MAC only solves any IP address change issue.

[s-hadinger]

@arendst I missed your response and proposed another PR, but indeed it needs more testing.

It looks like we can go at least up to 24 bits. So we can try 16 bits from MAC and 4 for local light.

I will be off a few days, feel free to adjust the code accordingly :)

[arendst]

I will. Happy holidays

[s-hadinger]

We need to choose between an id guaranteed distinct (IP) but that can change and an id not guaranteed distinct (hash of Mac) but that doesn't change.

That's why I'm in favor of combining both. Anyways I don't know how Alexa rediscovers a Hue bridge when its IP changed. I didn't have time to try.

[s-hadinger]

@arendst Doing some hash collision probability:

If you have 50 devices and 16 bits of MAC hash, probability of collision is 2%.
If you have 50 devices and 20 bits of MAC hash, it drops to 1/1000.
With 24 bits, it's 1/10000.

Assuming 50 devices is a lot, I would still favor doing 20 bits of MAC address instead of 16, + 4 bits of local id that would mean using 24 bits.

The Philips Hue doesn't give any hint on lightId length, but what's important here is how Alexa stores it. It seems to be stored as 32 bits int, so let's not go beyond 30 bits to be safe.

[arendst]

@s-hadinger OK. I make it 28 then:

id = (mac[3] << 20) | (mac[4] << 12) | (mac[5] << 4) | (idx & 0xF);

[wongnam]

I also assuming 50 devices is a lot.
I wonder how an Amazon Echo could manage 50 Hue bridges.
As I experienced it and knowing that Echo only managed 16 Hue bridges, although I have not seen any official documents about this, it had to have a second Echo to manage the next 16 Hue bridges, and so on.

[Pawand15]

On flashing the latest code, Alexa is no longer confused between multiple Tasmota devices. Also control from Alexa App appears to be working, But is only Switching the first light for command to any of the relay.

Maybe increasing the LightId to 28 bits is causing it to overflow?
I will try with 20 bits commit and one before that to check if that works, in that case the lightId length may have to be reduced again.

[s-hadinger]

Can you please set log to level 4 and share the logs? Including logs when Alexa is doing the discovery? We'll be able to identify if Alexa sends the right lightId back.

[Pawand15]

Log When I try to switch third device:

:35:32 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/82838643/state)
07:35:32 HTP: Hue POST args ()
07:35:32 HTP: Hue POST args ({"on": true})
07:35:32 SRC: Hue
07:35:32 RSL: RESULT = {"POWER1":"ON"}
07:35:32 RSL: POWER1 = ON
07:35:32 HTP: Hue Result ([{"success":{"/lights/1/state/on":true}}])
07:35:32 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/82838643)
07:35:32 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Passage Light","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-3","swversion":"5.50.1.19085"})

[Pawand15]

Discovery Log:

07:41:06 UDP: Packet (107)
07:41:06 UDP: Packet (122)
07:41:06 UDP: Packet (107)
07:41:06 UDP: Packet (122)
07:41:06 UDP: Packet (122)
07:41:06 UDP: Packet (107)
07:41:06 UDP: Packet (122)
07:41:06 UDP: Packet (107)
07:41:07 UPP: Hue 3 response packets sent to 192.168.0.192:50000
07:41:07 HTP: Hue setup
07:41:08 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights)
07:41:08 HTP: Hue Result ({"82838641":{"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Bedroom Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-1","swversion":"5.50.1.19085"},"82838642":{"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"},"82838643":{"state":{"on":false,"bri"
07:41:10 WIF: Checking connection...

[Pawand15]

Same behavior with the IP address based Light ID. Log for discovery and when I try to switch second device out of 4:

08:55:59 HTP: Hue setup
08:55:59 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights)
08:55:59 HTP: Hue Result ({"3089":{"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Bedroom Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-1","swversion":"5.50.1.19085"},"3090":{"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"},"3091":{"state":{"on":false,"bri":254,"alert
08:56:00 UDP: Packet (137)
08:56:03 UDP: Packet (137)
08:56:04 WIF: Checking connection...
08:56:04 WIF: Connected
08:56:04 DNS: MDNS.update
08:56:06 UDP: Packet (137)
08:56:09 UDP: Packet (137)
08:56:12 UDP: Packet (137)
08:56:15 UDP: Packet (137)
08:56:43 SRC: WebGui from 192.168.0.128
08:56:43 RSL: RESULT = {"POWER1":"ON"}
08:56:43 RSL: POWER1 = ON
08:56:43 CFG: Saved to flash at F9, Count 43, Bytes 3584
08:56:44 SRC: WebGui from 192.168.0.128
08:56:44 RSL: RESULT = {"POWER1":"OFF"}
08:56:44 RSL: POWER1 = OFF
08:56:45 CFG: Saved to flash at F8, Count 44, Bytes 3584
08:56:54 SRC: WebGui from 192.168.0.128
08:56:54 RSL: RESULT = {"POWER2":"ON"}
08:56:54 RSL: POWER2 = ON
08:56:54 CFG: Saved to flash at F7, Count 45, Bytes 3584
08:56:56 SRC: WebGui from 192.168.0.128
08:56:56 RSL: RESULT = {"POWER2":"OFF"}
08:56:56 RSL: POWER2 = OFF
08:56:57 CFG: Saved to flash at F6, Count 46, Bytes 3584
08:57:14 UDP: Packet (174)
08:57:15 UDP: Packet (174)
08:57:16 UDP: Packet (174)
08:57:17 UDP: Packet (174)
08:57:23 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090)
08:57:23 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"})
08:57:25 WIF: Checking connection...
08:57:25 WIF: Connected
08:57:25 DNS: MDNS.update
08:57:26 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090)
08:57:26 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"})
08:57:29 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090)
08:57:29 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"})
08:57:32 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090)
08:57:32 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"})
08:57:35 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090)
08:57:35 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"})
08:57:37 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090/state)
08:57:37 HTP: Hue POST args ()
08:57:37 HTP: Hue POST args ({"on": true})
08:57:37 SRC: Hue
08:57:37 RSL: RESULT = {"POWER1":"ON"}
08:57:37 RSL: POWER1 = ON
08:57:37 HTP: Hue Result ([{"success":{"/lights/1/state/on":true}}])
08:57:37 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/3090)
08:57:37 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Common Bathroom","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-2","swversion":"5.50.1.19085"})
08:57:37 CFG: Saved to flash at F5, Count 47, Bytes 3584

[Pawand15]

I tried using the API directly via Postman and found that state changes only when you send 1,2,3 or 4 as the light Id and not the one advertised:
http://192.168.0.193/api/lights/2/state -- works
http://192.168.0.193/api/lights/3090/state -- switches on the first device but should have switched second

I guess changes are missing in the POST request part and light Id is only implemented in Alexa advertising

[s-hadinger]

Are you able to add logging in xdrv_20_hue.ino line 580? I wonder if atoi() is generating an overflow.
Logging the output of atoi() and the value of 'device' would be useful.

[Pawand15]

I am going through the code and I guess that the function HueLights() will need to be changed to accept larger device Ids . There is a check to set deviceId to 1 if it exceeds maxhue value..can you have a look?

[Pawand15]

I removed the device < maxhue check and logged atoi value, not correct. atoi() maxes out at max integer value 65,535

[s-hadinger]

Too bad. We could revert to sscanf() to convert from str to int.

[arendst]

Don't use scanf! It raises code size to much being the first time it is used.

Simply use strtol as being used by most functions in tasmota.

[Pawand15]

My bad I took unsigned 16 bit...its just that value needs to be decoded before saving to device variable.
line 422-428 : (Decode added at 425..rest all is fine)

else if (path->endsWith("/state")) {               // Got ID/state
    path->remove(0,8);                               // Remove /lights/
    path->remove(path->indexOf("/state"));           // Remove /state
    device = DecodeLightId(atoi(path->c_str()));
    if ((device < 1) || (device > maxhue)) {
      device = 1;
    }

[Pawand15]

atoi() is ok

[Pawand15]

Also encode again at 437 to give correct response. Doesnt seem to matter but I guess response should be correct.

       response += FPSTR(HUE_LIGHT_RESPONSE_JSON);
        response.replace("{id", String(EncodeLightId(device)));
        response.replace("{cm", "on");

[Pawand15]

Working fine..Log:

14:02:38 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/82838644/state)
14:02:38 HTP: Hue POST args ()
14:02:38 HTP: Hue POST args ({"on": true})
14:02:38 SRC: Hue
14:02:38 RSL: RESULT = {"POWER4":"ON"}
14:02:38 RSL: POWER4 = ON
14:02:38 HTP: Hue Result ([{"success":{"/lights/82838644/state/on":true}}])
14:02:38 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/82838644)
14:02:38 HTP: Hue Result ({"state":{"on":true,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Geyser","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-4","swversion":"5.50.1.19085"})
14:02:38 CFG: Saved to flash at F9, Count 27, Bytes 3584
14:02:52 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/82838644/state)
14:02:52 HTP: Hue POST args ()
14:02:52 HTP: Hue POST args ({"on": false})
14:02:52 SRC: Hue
14:02:52 RSL: RESULT = {"POWER4":"OFF"}
14:02:52 RSL: POWER4 = OFF
14:02:52 HTP: Hue Result ([{"success":{"/lights/82838644/state/on":false}}])
14:02:53 HTP: Hue API (/eBdSjoPzohggo2Zv6ZGOAx96VipsvbjpWgEOlnc/lights/82838644)
14:02:53 HTP: Hue Result ({"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Geyser","modelid":"LCT007","uniqueid":"60:01:94:4f:00:47:00:11-4","swversion":"5.50.1.19085"})
14:02:53 CFG: Saved to flash at F8, Count 28, Bytes 3584

[s-hadinger]

Thanks, good catch.

[Jason2866]

PR? 😊

[Pawand15]

Flashed the updated code on 5 tasmota devices. 17 switches in total. I can confirm everything working fine from voice and alexa app. Group, and routines functionality also restored.

Everything seems a littile faster maybe because all lights now have unique Ids so there less searching involved or caus I was on version 5 something before

[arendst]

Great.

So pls either document your patches here (again) or provide a PR

[Pawand15]

Following are the two patches:
Line 425:
device = DecodeLightId(atoi(path->c_str()));

Line 437:
response.replace("{id", String(EncodeLightId(device)));

Alexa gives the encoded ID in post request url which was overflowing when returned by atoi to device variable. Further as the value of device was more than maxhue it was being set to 1 again. The device I'd needs to be decoded switched and then encoded again for response.

[arendst]

Thx.

[znanev]

Just tested with the latest dev firmware (bb3fb7c) - now everything works as expected: Alexa (and wife!) are finally happy :)

Thanks @Pawand15 for the thorough investiagation and also @arendst for the quick patch!

[luislorenzo]

I tested also. It works

[wernerk63]

I tested also with one 2channel and two 4channel devices (sonoffs T1EU + 4chpro)
It works ! Thanks at all

[wongnam]

RF Bridge does not seem to be supported?

[s-hadinger]

No, Philips Hue protocol is only for smart-lights and Wemo only for switches (or on/off lights).

To manage your RF Bridge from Alexa, you will need to create an Alexa skill. I'm working on connecting Tasmota to AWS IoT so it should be quite easy to do. Stay tuned.

[s-hadinger]

I just got information back from Alexa team. This issue should be fixed now.

However I suggest we keep the distinct lightIds and leave code as it is now, it does not do any harm.

[arendst]

Agree.

Thx for your tenacity.