Pete Shepherd in Discussions
Letzte Aktivitätam 18 Aug. 2022

I have an ESP32 that has 5 values (solarW, batteryV, pumpW, pumpRPM and pumpLPM) that I'm writing to 5 fields on a Thingspeak channel. if ((millis() - fifteenTstart) > 15000){ Serial.println("Updating Thingspeak...."); ThingSpeak.setField(1, solarW); ThingSpeak.setField(2, batteryV); ThingSpeak.setField(3, pumpW); ThingSpeak.setField(4, pumpRPM); ThingSpeak.setField(5, pumpLPM); int x = ThingSpeak.writeFields(myChannelNumber, myWriteAPIKey); if(x == 200){ Serial.println("Channel update successful."); } else{ Serial.println("Problem updating channel. HTTP error code " + String(x)); } } It works fine when there's a good connection to the internet and Thingspeak, but there's a 10 second or so delay when Thingspeak is unavailable (WiFi, internet or website non-connectivity). I would like the code to recognise that there's no ThingSpeak connection musch faster (1 second or less woud be good, but I'll take two!). Or, if it's possible to just send the data out without the code waiting for a confirmation back (I only need the data to go OUT from the ESP32 to Thingspeak, nothing needs to come back). Need faster Thingspeak connection timeout in ESP32 code MQTT is more of a fire and forget routine that you can use with ThingSpeak, though you may still have some connection delay. Our REST interface requires your client to wait for the response from the server. If you disconnect before the response with the REST interface, your data wont be posted. I've also been able to get paralell processes running on an ESP32, here is one tutorial I've used. Thanks Christopher. Looks like the parallel prcoessing route will be a good solution. I didn't know the ESP32 had dual core processing, definitely worth learning about! Multi threading is fun, but it does add some serious complexity to debugging. I would still recomend MQTT for this purpose and do the multi threads for learning sake. Good luck either way. thingspeak esp32 updating speed delay faster code connection
Dirk Steinkopf in Discussions
Letzte Aktivitätam 10 Nov. 2021

Hello, I am sending mqtt values from esp8266 devices to different channels - e.g. https://thingspeak.com/channels/1182897 The values are sent correctly and also show up on the channel's page correctly and quickly in time. But mqtt receivers are getting the data with a varying long delay. Often the delay is 1h, so I first thought, this could be a time zone problem. But that's not the case. I tried two different mqtt clients: Both get the values at the same (late time): E.g. when I now get a value from channels/1182897/subscribe/fields/field3 and look into the history of values (using "Data Import/Export") then this value can be found 20 minutes up to 1 hour ago. This can also be confirmed when looking into the device's logs. What could I do to be up-to-date with my values? Thank you very much. Dirk thingspeak mqtt has big delay Are you sending data to mqtt3.thingspeak.com or the legacy MQTT interface? I am still using mqtt.thingspeak.com. Thank you for reminding me to switch. Could switching to mqtt3 improve the delay problem? Do I have to switch all publishers and subscribers at once? Or are messages sent from one broker to the other? Now, I changed the main subscriber to use the new mqtt3 while leaving the publishers untouched (using the old mqtt). This seems to have solved the problem by itself: Got current values for about 5 Minutes. - Switching back to the old broker resulted in getting delayed values again. Using the new broker still brings me up-to-date values. Thank you for the hint to switch to the new broker. I am aware that I also have to switch the other devices. Do you have an explanation for that? Is the old broker overloaded? We're *strongly* recommending moving over to the new MQTT broker @ mqtt3.thingspeak.com. The subscribers on the legacy MQTT service (mqtt.thingspeak.com) appear to be experiencing a delay between when the channel is updated and the subscriber receiving the message. We're looking into this. Note however that the legacy service is on a deprecation path. I'd recommend switching both publishers and subscribers to use mqtt3.thingspeak.com. It is more efficient and performant for your device as well. Sorry to hi-jack the thread. I also have delays on the old mqtt.thingspeak.com. But if I change to mqtt3.thingspeak, my data is not published. What else must be changed? I went through the documentation and examples for subscribers and publishers. The changes for one of my subscribers are for example: use client-id from registration instead of a random one; remove the write API key at the end of the topic (see my code: https://gitlab.steinkopf.net/iot/bme280ondisplay/-/commit/ecfd94ad29aafb959c2b2382bfb6180d3214f756) The changes for the subscriber are even simpler: I just changed the DNS name to mqtt3... Take a look at the <https://www.mathworks.com/help/thingspeak/mqtt-api.html updated documentation and examples here>. The changes required are very minor. It is working now!!! Thanks!! It was the format of the topic. Had to remove API key. The delay in the legacy MQTT system is resolved (a stuck node had to be restarted). The *recommendation is still to use the new broker* at mqtt3.thingspeak.com, which it appears both users on this thread were able to migrate to with minimal code changes. mqtt delay

Info zu ThingSpeak

The community for students, researchers, and engineers looking to use MATLAB, Simulink, and ThingSpeak for Internet of Things applications. You can find the latest ThingSpeak news, tutorials to jump-start your next IoT project, and a forum to engage in a discussion on your latest cloud-based project. You can see answers to problems other users have solved and share how you solved a problem.