arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.05k stars 4.78k forks source link

Alexa Tasmota Hue Bug (Server doesn't respond) #21747

Closed jtauscher closed 2 months ago

jtauscher commented 3 months ago

Hi guys,

I have latest Tasmota with Hue enabled. This Tasmota drives a shutter (Relay 1&2) and four other devices. Shutter of course doesnt work with Alexa App but all other devices work, except for device #3 "friendly name 3".

Unbenannt

Alexa detects all 6 devices, or if I add $ to friendly names 1&2, shutter relays 1&2 are hidden. Problem is, if I toggle device 3 (Light) in Alexa app, Tasmota console tells me this:

16:18:00.270 HTP: Hue API (/647d5a/lights/105371043) from 192.168.0.169
16:18:00.273 /lights path=/lights/105371043
16:18:00.283 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"LichtWC","modelid":"WiGaRollWC","manufacturername":"Tasmota","uniqueid":"c8:c9:a3:64:7d:5a:00:11-03"})
16:18:00.422 HTP: Hue API (/647d5a/lights/105371043/state) from 192.168.0.169
16:18:00.423 HTP: Hue POST args ({"on":false})
16:18:00.430 Settings->shutter_invert: 0
16:18:00.432 SRC: Shutter
16:18:00.434 CMD: Grp 0, Cmd 'SHUTTERPOSITION', Idx 3, Len 1, Pld 0, Data '0'
16:18:00.442 MQT: stat/WiGaRollWC/RESULT = {"Command":"Error"}
16:18:00.444 HTP: Hue Result ([{"success":{"/lights/105371043/state/on":false}}])
16:18:00.570 HTP: Hue API (/647d5a/lights/105371043) from 192.168.0.169
16:18:00.573 /lights path=/lights/105371043
16:18:00.582 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"LichtWC","modelid":"WiGaRollWC","manufacturername":"Tasmota","uniqueid":"c8:c9:a3:64:7d:5a:00:11-03"})
16:18:00.720 HTP: Hue API (/647d5a/lights/105371043) from 192.168.0.169
16:18:00.724 /lights path=/lights/105371043
16:18:00.733 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"LichtWC","modelid":"WiGaRollWC","manufacturername":"Tasmota","uniqueid":"c8:c9:a3:64:7d:5a:00:11-03"})
16:18:00.871 HTP: Hue API (/647d5a/lights/105371043) from 192.168.0.169
16:18:00.874 /lights path=/lights/105371043
16:18:00.884 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"LichtWC","modelid":"WiGaRollWC","manufacturername":"Tasmota","uniqueid":"c8:c9:a3:64:7d:5a:00:11-03"})

device 4-6 output would be similar to:

16:13:28.435 SRC: Hue
16:13:28.442 MQT: stat/WiGaRollWC/RESULT = {"POWER5":"ON"}
16:13:28.445 MQT: stat/WiGaRollWC/POWER5 = ON

I remember it worked fine after resetting everything but after a day or so Alexa app tells me that "server doesn't respond"

Is there a bug in numbering relay 1 to 6? Because 1 and 2 are somehow "one shutter unit" ?

selection of SetOptions:

SO15 1 SO32 40 SO33 5 SO34 200 SO35 0 SO36 1 SO37 0 SO38 6 SO39 0 SO40 0 SO41 60 SO42 90 SO43 10 SO44 25 SO45 40 SO57 1 SO80 1 (-> Shutter) SO91 1 SO114 1 (detach switches -> sensors for HA) SO128 1

s-hadinger commented 3 months ago

This code hasn't changed in a while. Can you please share the logs when the problem happens? The problem you describe could simply be a network reachability problem unrelated to the numbering of relays.

jtauscher commented 3 months ago

I don't think so, RSSI is 56% and its only faulty with this Relay#3. I'm pretty sure its a problem connected to shutter settings. As you can see in the logs, when switching Relay3 in alexa app, some strange interpretation of the incoming command in tasmota happens:

16:18:00.423 HTP: Hue POST args ({"on":false}) 16:18:00.430 Settings->shutter_invert: 0 16:18:00.432 SRC: Shutter 16:18:00.434 CMD: Grp 0, Cmd 'SHUTTERPOSITION', Idx 3, Len 1, Pld 0, Data '0' 16:18:00.442 MQT: stat/WiGaRollWC/RESULT = {"Command":"Error"} 16:18:00.444 HTP: Hue Result ([{"success":{"/lights/105371043/state/on":false}}])

Why are there even shutter states/settings triggered. Doesn't make sense.

Update: I redefined relay 3 as 6 (friendly name 7) and defined another unused GPIO as Relay 3 (hidden $friendly name 3) and now it works like a charm. So it is definitly a bug connected to shutter setting so80.

s-hadinger commented 2 months ago

It's not so easy to reproduce. Can you share logs when it works (after pairing if I understand well)? And the corresponding log when it does not work anymore? And please include the full log: the log above lacks the full URL with the Hue identifier

Jason2866 commented 2 months ago

Btw. " RSSI is 56%" is bad, especially when using UDP. UDP is send and forget. No check if successful.

Jason2866 commented 2 months ago

@jtauscher Are you going to provide the logs asked for?

stefanbode commented 2 months ago

All under the assumption that we have a normal shutter relay1 is up and relay2 is down. no stepper motors, no servos and so on. There is an option to LOCK the shutter. this uses relay3 if defined. I did not get it why there is an INVERT. But let me check. I will update the documentation regarding the lock. This was introduced about a year ago and "highjack" the relay after up/down to lock it. This is made to prevent ALEXA from operating the shutter in some situations. In my case ALEXA conection is done through HomeAssistant not HUE

Jason2866 commented 2 months ago

Closing since no feedback. Feel free to ping when the logs needed and asked for are provided