Hue Emulation missbehavior #5849
Comments
|
Same Problem here, I think Amazon have something changes on the HUE detection. |
ascillato2
added
awaiting feedback
|
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. |
|
Over 20 Sonoff Devices, 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. The weblog's (Level 4) shows:
Maybe, it should works further, if i had not do a 'Search Devices'..... ( because of NetworkChanges) 24.05 Edit TROUBLSHOOTING INFORMATION : |
|
Same problem here, i´ve added 2x H801 and enabled the Hue Emulation. Edit - i´ve just tried some variations. |
|
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. |
|
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. |
|
Please, complete the troubleshooting template in order to have more debug information. Thanks |
ISSUE DESCRIPTION - TROUBLESHOOTINGPhillips Hue Emulation activated for 2 H801 with LED Strips 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. - STATUS 0 of COUCH
STATUS 0 of the Shelly1
weblog4 of Shelly: weblog 4 of COUCH hope that did help. |
This comment has been minimized.
This comment has been minimized.
|
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. |
ascillato2
removed
the
template missing/incomplete
|
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 - TROUBLESHOOTINGAlexa 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
(Please, remember to close the issue when the problem has been addressed) |
|
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. |
|
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. |
|
@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. |
|
I have the same problem. But my issues only appear, if I try to switch Sonoffs in Groups. Looks for me, that Amazon make some strage changes... maybee off-topic: 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... Update: My wife approved 5 Minutes ago, that at least one Alexa-Group with a multichannel-device works fine... I will observe. |
|
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. |
|
@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
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. |
|
Happy that i never bought Hue hardware. Not the first time Philips left customers standing in the rain. |
|
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 |
|
That's an easy one: Aircoookie/Espalexa#71 Same problem. Nice future. |
|
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. |
|
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. |
|
Me too. Only for tracKing thread. |
|
With one HueBridge Alexa App+Voice works correct for me. ( -> delete all other devices !) |
|
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. |
|
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. |
|
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. |
|
Log When I try to switch third device: |
|
Discovery Log: |
|
Same behavior with the IP address based Light ID. Log for discovery and when I try to switch second device out of 4: |
|
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: I guess changes are missing in the POST request part and light Id is only implemented in Alexa advertising |
|
Are you able to add logging in xdrv_20_hue.ino line 580? I wonder if atoi() is generating an overflow. |
|
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? |
|
I removed the device < maxhue check and logged atoi value, not correct. atoi() maxes out at max integer value 65,535 |
|
Too bad. We could revert to sscanf() to convert from str to int. |
|
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. |
|
My bad I took unsigned 16 bit...its just that value needs to be decoded before saving to device variable. |
|
atoi() is ok |
|
Also encode again at 437 to give correct response. Doesnt seem to matter but I guess response should be correct. |
|
Working fine..Log: |
|
Thanks, good catch. |
|
PR? 😊 |
|
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 |
|
Great. So pls either document your patches here (again) or provide a PR |
|
Following are the two patches: Line 437: 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. |
|
Thx. |
|
I tested also. It works |
|
I tested also with one 2channel and two 4channel devices (sonoffs T1EU + 4chpro) |
|
RF Bridge does not seem to be supported? |
|
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. |
|
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. |
|
Agree. Thx for your tenacity. |
and others
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?
The text was updated successfully, but these errors were encountered: