-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Autoconfigured device state not visible to HA #4683
Comments
On further inspection, state responses appear to be coming back on the wrong topic. Commands are going to ~cmnd/POWER, and state responses come back on stat/#. When switched via the web interface however, the state is reported on the correct topic. I think I didn't notice this behavior before because I had somehow enabled option 19 and kept the default |
Not a Tasmota issue. Check your HA configuration and/or open a issue in HA github. |
I'm confused- are you saying that it's a HA misconfiguration that it can't see state on a topic it hasn't been told about? The command comes in on I don't see how that can possibly be a HA issue, when Tasmota is publishing on a topic it hasn't said anything about. |
please try |
Option 59 is apparently already enabled. |
apparently ? Have you tried writing |
Yes, that's where I got that it was enabled:
I said apparently because I didn't expect it to be; sorry for any confusion there. |
Ok, do the following to delete retained messages on Home Assistant: Go to the Tasmota console and type:
After restart do:
|
Options off:
Restart:
Option 19 back on:
Turn the power on via Home Assistant again:
State messages in response to commands over MQTT remain on the wrong topic. States reported when I use the toggle button in the web interface remain correct (and are reflected in the Home Assistant UI as expected):
|
Ok, so that is weird. I can not reproduce that. In order to solve your issue please, erase all flash with esptool.py as explained in the wiki and flash again with the precompiled bins from release. |
This device was just flashed with full erase as described and release binaries, so I don't think that will help. I have another one of these devices that exhibits the same problem. To reproduce, I can do the following:
It turns on, but the response is on the wrong topic. This doesn't seem specific to autodiscovery. |
I think I found the problem, digging through code. The web UI and MQTT handlers both invoke The fallback flag is set if the received message's topic contains the client ID, and in this case I've set the Client ID and Topic ( So while I can fix this by changing the client ID back to the default, I also think it's a bug that a substring search is used to determine whether a message has been received on the fallback or regular topic; it should instead include the cmnd prefix to avoid false positives like this. |
Describe the bug
An autodiscovered device's state isn't visible to Home Assistant, so it can be turned on but not off (because HA doesn't see a state change from the device, so assumes nothing happened).
I'm not sure if this is a Tasmota problem or HA; I updated Tasmota to 6.4.0 (the release sonoff.bin) and HA to 0.84.3 at about the same time, after which I found state reporting wasn't working; prior to that, it did work.
Status 0 output:
To Reproduce
Enable options 19 and 55 for MQTT discovery and abbreviation, connect to MQTT with HA connected to the same broker.
Expected behavior
The device is discovered by HA and its state is correctly reported.
Additional context
I suspect this may actually be a HA bug, possibly caused by home-assistant/core#19010 or another change that's new in 0.84, but haven't been able to isolate it yet. There wasn't any obvious change when I temporarily downgraded to HA 0.83, but I didn't spend long poking at that version.
A sample exchange of messages, with the two power on commands coming from HA and the power off result is me manually turning it off via the web interface:
The autoconfiguration messages look okay at a glance (all empty except this one):
The text was updated successfully, but these errors were encountered: