It seems that data is not recorded

Hello, since this morning (around 8h00 am, Paris time), data sent by my iots is not recorded. I have not changed any settings on my iots and my internet connection is OK. On the page with my channels, it seems that the channels are updated because I see that the "updated" times are evolving. Is there a problem today with Thingspeak?

[Roland Morla]

Hello, it seems that the problem has come again around 20h00 Paris time (12/152023).

[Christopher Stapels]

My channels seem to be fine, and some public ones I watch are ingesting normally up to now (23h49 paris time).

The status page indicates ThingSpeak is fine at present. Feel free to post again if you continue to see the issue. If we detect a system wide event Ill post an update.

[Roland Morla]

The problem is still present. 02h35 paris time. Data from 6 iots dispatched on 3 different channels are not updated on the servers. Some other iots using my own server are ok as well as my internet access (I could not write this comment if was not the case).

[Roland Morla]

Hello, I think I found the problem. In order to save battery on my iots I used a less secure set of cipher algorithms for TLS, but it seems that from yesterday thingspeaks servers demand more secure algorithms. I tried a patch suppressiong the "espClient.setCiphersLessSecure();" line in my code and my test iot can again connect. So it seems I will have to reprogram my iots.

Would you please confirm that you changed security requirements for TLS on your servers? Best Regards.

[Christopher Stapels]

What hardware and software are you using?

[Roland Morla]

Hello, I am using esp8266 microcontrolers and home made software using the arduino IDE and the librairies that go with it. Best Regards.

[Christopher Stapels]

Are you using the ThingSpeak library? It works nicely with ESP8266.

https://github.com/mathworks/thingspeak-arduino

[Roland Morla]

No, this is my own (dirty) code. My code is rather old and I did not know there were such a library at the time I wrote it. In fact maybe it even did not exist. As I told you before, I tried to save as much as battery power as I could, and I found a significant difference of execution time between the "normal" and the less secure version of cipher algorithms, so I decided to use the less secure version. ( more security is good, but who cares about the temperature of my freezer ? ). Anyway I took sometime this week-end to recompile my code and re flash my iots and everthing is alright now. Best Regards

Answer 1

[Christopher Stapels]

There was a short downtime for ThingSpeak on July 19 from approximentally 6 am UTC until 10am. You can always see the present status of MathWorks online services here.

[Roland Morla]

Hello, on some of my channels, i notice a 15 hour delay between the time of update and the time when i can read the data.

[Christopher Stapels]

That's not common. Ive never seen that for any of my channels. The channel clear and bulk updates can sometimes be slow but not that long either. What kind of device are you using to update the channel? Are you using the ThingSpeak timestamp or a created at timestamp?

[Jagienka]

Hello, I wanted to ask for future refference what might be the ussuall hang-up for bulk updates? Couple minutes/hours?

In the last ~3 hours the data on my channel also is not being updated by bulk-write json. I don't get errors, the response is 202 and I've tried switching between created_at/delta_t.

Channel data is being updated just fine by simple GET/POST write https://api.thingspeak.com/update.json?api_key=...&field1=...

Best Regards,

Maria

[Roland Morla]

Hello, I use esp8266 and my own code. It worked fine until 2 days ago or so, and works fine on some other channels. By the way, I have no real time clock on my esp8266s so the timestamps are given by thingspeak. I have alreay experienced this kind of delay 2 or 3 times in the past, but it didn't last so long, and finaly the delay gradualy decreased. Best Regards

[Christopher Stapels]

@Jagienka In my experience, the bulk update is generally consistent in 30 seconds or less, though there have been three or so times I remember in the past four or five years that it extended to many minutes and up to a few hours as you said. The data is always eventually consistent, certainly in the same day (and usually well under a minute). I’ve checked in with the dev team, they will consider intervening if they see a big lag built up.

[Christopher Stapels]

@Roland Morla I'm sorry to hear that you are experiencing such large delays. This is not my experience. The esp8266 is starting to get old, ive replaced almost all of mine with esp32, but I think its still good. There is one here on my desk that is working fine, but it only reads from cheerlights, it doesnt do any posting of data. I would consider upgrading the firmware libraries and reflashing the code if possible. I know there were increased TLS security requirements within the last year. Is it a public or private channel? If public, can you share the id?

[Roland Morla]

Thank you for your message. M'y channels are primate. I do not know if it is possible to temporary switch them to public. I wonder if the number of records could be the cause of the problem. One of the channels have more than 3 millions entries. But i have another channel with even more entries that is perfectly fine. Do you think clearing the channel data could help? The delay continue to grow and is now 19h. Best Regards

[Christopher Stapels]

I do not think clearing the channel will help. The bulk write service should be mostly agnostic to the channel size. I would expect the ingest gap to improve over the next few hours. If it is still substantially behind by tomorrow, please post on the forum again.

[Roland Morla]

Hello. The delay gradualy decreased znd has now disapeared. Thank you.

[Christopher Stapels]

Great to hear. Thank you for the confirmation.