-
Notifications
You must be signed in to change notification settings - Fork 51
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
Create minimqtt_multipub_simpletest.py #191
base: main
Are you sure you want to change the base?
Conversation
Adds a simple demo for publishing multiple feeds. Designed to be used with the BME280 sensor but filled in with fake values so it should work as is. Most other demos are using the ESP32SPI library. This one is more designed for the newer ESP32-S2 & S3 with no coprocessor.
added #pylint ignore unused arguments... seems like that's cheating.
# slight delay required between publishes! | ||
# otherwise only the 1st publish will succeed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's curious. Do you have any idea why ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'm unsure why that happens. I only found the workaround by giving it a delay. Was quite puzzled about that myself.
I have 2 values that are being graphed together. By giving it a short delay it will publish the first two within a small enough time frame to be registered together by AdafruitIO dashboard. The other 3 data points I'm not concerned if they all publish together. This is so when I view it in the dashboard the first two points are grouped together.
while wifi.radio.ipv4_address: | ||
try: | ||
# Connect to MQTT Broker | ||
mqtt_client.connect() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to connect (and later) disconnect from the broker repeatedly. This is most likely undesired - single TCP connection is better in terms of resource utilization. The right approach is to connect first and then enter a cycle with loop()
inside.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured that was the right approach as AdafruitIO /overview seems to like that approach.
Also in this screenshot if the delay isn't provided then only the first publish is recorded. I'll assume AdafruitIO wants them somewhat spaced apart with delays. They typically all show up registered as within the same minute.
I know loop is preferred for checking messages but since I'm not checking messages and this is only as a publish example I figured loop was unnecessary?
Also in my example it only connects/disconnects every 15 minutes. There's more than can go wrong by staying connected permanently in that time frame with wifi going down and other errors that I figured connect/disconnect would be a better way to go.
Will look into adding loop. Hopefully that will get all data points to publish at the same identical time too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling loop()
is necessary to avoid being disconnected from the server once the keep alive timer expires.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit confusing as that's not how the simpletest example works. Connect, publish, disconnect works fine even without increasing the keep alive timer manually in mqtt_client setup. loop is mainly for checking for messages which I'm not at all interested in if all I want to do is connect & publish. If that's not how it should be done then the simpletest example needs to be corrected to reflect that and the RTD for MQTT.loop() needs to be updated with that bit of information.
If I remove the explicit disconnect from the bottom of the script then the next time I publish it will automatically disconnect & reconnect anyway. For subscribing keeping that connection alive would be very important but since I'm only publishing I can close it immediately.
I believe it's best practice while only publishing to disconnect explicitly because I've run into an issue where keeping that connection open while using it with multiple other API's can end up running out of sockets. Disconnecting closes the socket to be reused by another API immediately afterwards in the script.
===============================
Board Uptime: 4.9 days
Temp: 81.8589
Actual Temp: 81.1
| Connecting to WiFi...
| ✅ WiFi!
| | Attempting to GET Weather!
| | Account within Request Limit message
| | ✅ Connected to OpenWeatherMap
| | | Sunrise: 06:55
| | | Sunset: 17:26
| | | Temp: 82.85
| | | Pressure: 1017
| | | Humidity: 74
| | | Weather Type: Clouds
| | | Wind Speed: 10.36
| | | Timestamp: 2023/12/02 13:45
| | ✂️ Disconnected from OpenWeatherMap
| | ✅ Connected to MQTT Broker!
| | | Published DJDevon3/feeds/BME280-Unbiased
| | | Published DJDevon3/feeds/BME280-RealTemp
| | | Published DJDevon3/feeds/BME280-Pressure
| | | Published DJDevon3/feeds/BME280-Humidity
| | | Published DJDevon3/feeds/BME280-Altitude
| | ✂️ Disconnected from MQTT Broker
| ✂️ Disconnected from Wifi
Next Update: 15 minutes
In my main script it functions exactly as intended. This example is just a small snippet of that. I wanted to share so others don't have to pull out their hair for a week trying to figure out how to do multiple publish using pure MQTT. This is for a multi-publish simpletest so I wanted to keep it simple.
Adds a simple demo for publishing multiple feeds. Designed to be used with the BME280 sensor but filled in with fake values so it should work as is. Most other demos are using the ESP32SPI library. This one is more designed for the newer ESP32-S2 & S3 with no coprocessor.