-
Notifications
You must be signed in to change notification settings - Fork 30
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
MQTT Out Message Not Accurate When Returning to Previously Selected Mode #80
Comments
It also appears that I am unable to get regular MQTT messages when using ENABLE_HOMEASSISTANT. The only way I can get status updates to be sent to my broker is to use the Aysync method but that results in a rather significant delay between the change taking place and the message being sent to my broker. (Relatively new to MQTT, so I'm assuming that latency is because the messages is asynchronous.) I am trying to use the message to detect the state of the controller since I have two possible control points outside of my McLighting controller. Rather than go through the trouble of colating them before being sent to the controller I figured I could just use the MQTT messages to detect a change initiated by the other system. But when I subscribe to home/_ha/state/out, I only get messages when using the ASYNC method. Any assistance would be greatly appreciated. This is the relevant section of my definitions.h file. #define ENABLE_OTA 1 If you could let me know how to fix either of these issues, that would be a huge help. |
I will have a look. |
First i can not reproduce.
Would you please post http://{ip_of_your_device}/esp_status. The second not updating homeassistant using PubSubClient i can reproduce. FYI: There is a 2-3 sec delay if you use AsyncMqtt. This can be reduced to almost 0, but is not recommended. |
Sure. Here's the esp_status:
I'm seeing more of a 5-7 second delay. Could that is be because of my setup? Do I need to change one of the settings for QoS (i'm still wrapping my head around the MQTT).
Oh good...so I'm not going crazy(er) 😉
Here are the logs from Node Red. You can clearly see, first both the /out and /ha/state/out both report off. Then I turn it to static mode by clicking on static in the WEB Gui. (That and the HTTP API are the only two control methods I have tried and confirmed this issue with). You can see /out goes to "OK /0" and the same is reported to HA. Then I turn it off by clicking off in the web GUI. Again, both statuses show the correct status of "off". Good so far. Next, I click "Static" again in the web GUI. You can clearly see the /out reports "OK =OFF" and HA reports "State": ON. This is where the problem lies. Should the last report to /out really be "OK =off"? The strip is on at that point. |
Fixed HA not working with PubSubClient |
Ahh, now i can reproduce, but i have no solution yet. |
I was about to get out my phone and record it for you. I might be going Covid-crazy but not THAT crazy. ;-) Thanks for all your help! |
I'm still not able to get HA MQTT messages if I only enable: #define ENABLE_MQTT 0 I get MQTT messages on /out. They're wrong, but I get them. Then if I change the settings to this: #define ENABLE_MQTT 0 I then get no MQTT messages at all, either on /out or on home/_ha/state/out. It is only when I change the settings to: #define ENABLE_MQTT 0 do I start to get MQTT messages again. So, am I totally misunderstanding how those setting are supposed to work or is something seriously wrong here? Because, I thought you had to have AMQTT enabled for MQTT_HOME_ASSISTANT_SUPPORT but it is working with PUBSUB. I have everything I need now that you have the customizable delay option available. This is purely for my edification that it just doesn't seem right. But "That's how it works." would be a completely acceptable answer at this point. Don't want you to think I'm harping or nagging. It just didn't look right to me and I know that kinda stuff bugs the hell out of me (pun totally intended) so I thought I would bring it up. 😄 |
@ryancasler |
YAY!!! You rock. I checked all the permutations I could think of and everything seems to be working per the docs now. Great work! Thank you!!! |
When monitoring the MQTT /out topic, if the controller is set to go back to the previously selected mode, the payload sent is still "OK =off". Only when the newly selected mode is something other than what was previously selected does the topic change correctly.
To reproduce this problem:
This works for any combination of mode/color and brightness. Simply selecting off and then returning to the previously selected mode produces the wrong payload.
The text was updated successfully, but these errors were encountered: