I have an ESP32 system that starts up w/ WiFi and MQTT disabled.
Then it performs some actions, measures sensors and determines if data needs to be reported back to the MQTT broker.
I’m trying to figure out if:
ESPHome will publish MQTT messages on MQTT connect for sensor data that has already been measured earlier in the application?
I can trigger the “publish existing data” somehow?
I need to use the explicit “mqtt.publish” method to send data when I know MQTT has connected?
*If WiFi & MQTT is running and connected, a “component.update” automatically triggers publishing of data over MQTT.
Any input is appreciated or a pointer to documentation that may already cover this topic?
Based on your question, it sounds like you might have a battery powered device. I would say this is not a core competency of esphome, is it was NOT designed to do this well. Based on my reading of many posts here, some people have gotten acceptable (to them) results. It all depends on what you are trying to optimize.
I have an idea for a battery powered device that is in the very earliest stages and I am just thinking of the strategies I might try. It is not clear esphome will be a great choice and I might need to switch to a custom platformio project to get the results I might want. I will try it with esphome first, because I really like the OTA update capability of esphome. For an always connected device esphome is great. For a mostly sleeping device, which is what you need for good battery life, esphome provides not so much help (from what I have seen).
But, search the forum, there are people who have been successful.
Thank you @neel-m
Great info.
Overall, I think my post was fairly clear: “how does MQTT-publishing works if MQTT is enabled after the data is collected”.
If you believe more information about the project will make this post clearer, then:
Yes, this is a battery powered device that needs to report temperature data only if it changed by more than (max_delta_t).
So the device measures temperature often but reports rarely.
This way I can keep WiFi and MQTT off unless data needs to be sent.
Esphome is likely NOT the best choice for your use case (this is my opinion based on my knowledge of esphome to date). You likely can make it “work”, but it was not designed to do what you want, so you will be “working uphill” with it. It might be easier to create a custom project in platformio that includes just what you need in the way that you need it.
My study of the code indicates there are some assumptions/givens that your use case likely requires violating. It is not impossible to make it work, but it won’t be easy and ChatGPT is unlikely to be able to help.
All of the successful battery powered projects I have seen here use MQTT and stay powered long enough to make sure the data gets sent out. If you want better battery life you will need to do more work and go against the (apparent) design principles of esphome. If you do that, it really isn’t clear what value esphome is providing you.
@neel-m: Now that you’ve answered a question that has not been asked, can somebody who has more knowledge of MQTT, WiFi and deep sleep chime in based on my original (concise) question?
Is there an inverse “xyproblem”? When a forum member makes broad assumptions and decides to redesign the entire system for the original poster as opposed to answering the direct question?
@neel-m you’ve mentioned in other posts that you’ve never used deep sleep, so perhaps your knowledge is better used on topics that don’t deal with enabling / disabling WiFi & MQTT and trying to maximize battery life.
Sorry my answer didn’t please you. I am assuming (and yes I know what that means) that you tried it and found that it doesn’t work the way you want it to, think it should.
That means:
no
no
maybe, but that goes against the “design” of esphome as I understand it
It is likely that my understanding of esphome is incomplete and you really should do your own investigation into how it really works. But I have read a lot of posts similar to yours with people having difficulty because they are “working uphill”.
The beauty of open source is the code is freely available to view and modify to work as you see fit. You can even do things that the people who wrote it might think go against the design, but you will have to work at it, at least a little.