Hi everyone
I've been using ThingSpeak for several years now without an issue until last Thursday.
I have four ThingSpeak channels which are used by three Arduino devices (in two locations/on two distinct networks) all running the same code.
All three devices stopped being able to write data to my ThingSpeak channels around 17:00 CET on 4 Dec and are still unable to.
Nothing changed on this side, let alone something that would explain the problem.
I would note that data can still be written to all the channels via a browser so there is no fundamental problem with the channels (such as being full).
Since the above date and time, any HTTP/1.1 'update' (write) requests via the REST API (using both simple one-write GET requests or bulk JSON POST requests) are timing out after 5 seconds and no data is being written. The 5 second timeout is my Arduino code's default, but even increasing it to 30 seconds makes no difference. Before all this, responses from ThingSpeak were sub-second.
I have recompiled the Arduino code using the latest libraries and that didn't help.
I have tested the same code again another random api (api.ipify.org) and that works just fine.
Curl works just fine too, also usng HTTP/1.1
So the issue appears to be something particular to the combination of my Arduino code *and* the ThingSpeak environment, where something changed on the ThingSpeak end at the above date and time.
If anyone in the community has any suggestions as to what might be going on, I would greatly appreciate the help.
Peter
49 Commenti
Tempo discendente
Have you read this thread or just posted on it without making the effort to read it?
If you've read it, it would be helpful if your posted commented on what you've read and whether that helped - or specifically didn't - in any way.
If you read (or re-read) it, I believe you will find a strong pointer to the cause of your issue. Clue: it sounds the same as Brian's.
Hi Peter,
It seems to me that you suggest to wait for an update of the geographically distributed thingspeak servers and the problem will be solved.
Also as I said, I send a request to api.thingspeak.com and not some kind of proxy.
Regards,
Please share your sketch. I am specifically interested in what the "HOST: " header is set to. See my recommendation in this message.
My channel has stopped receiving data since 8th of December.
Its been working 2 years now without issues.
I send http to api.thingspeak.com
Please share your sketch. I am specifically interested in what the "HOST: " header is set to. See my recommendation in this message.
AT^HTTPCMD=1,POST,"http://api.thingspeak.com:80/update?api_key=xxxxxxxxxxxxx&field1=48.130&field2=99&field3=99&field4=100&field5=99&field6=99",0,"text/plain"
All my channels stopped working at the same time about (16:50) 10 hrs ago today. Whats going on here?
@Brian My channels are still working just fine, having recovered from the mysterious issue about 18 hours ago (at the time of posting). The pattern that's emerging here suggests that, not unusually, ThingSpeak has multiple servers (perhaps distributed geographically) handling inbound traffic where only some of them have been updated with troublesome code. Given that whichever server(s) my Arduinos hit(s) is/are now working again, one can hope that the one(s) you depend on will also recover.
@Brian By any chance, are you setting a HOST header that is not api.thingspeak.com, or, sending the update request to ThingSpeak through some sort of proxy that is setting a header that is not api.thingspeak.com?
EDIT: Looking at the logs, it appears that whatever process is updating your channels is making a request to api.thingspeak.com, with a HOST header incorrectly set to "a.c.d". This request is now being rejected.
This is what my code uses...
const char* server = "api.thingspeak.com";
Nothing changed on my side they all just stopped updating all at the same time and havent recovered yet
Channel Stats
- Created: 7 years ago
- Last entry: about 22 hours ago
- Entries: 939189
@Brian Please share a sketch that reproduces the issue. There was a config change deployed yesterday to block requests that come in to api.thingspeak.com with an invalid HOST header.
Hi @Vinod. Is there a formal statement about these changes so that ThinkSpeak users can understand the detail and scope of them? At the most basic level, for example, I wonder what is meant by an invalid HOST header. From @Brian's experience, it would appear that a "wrong" one will be consider invalid (reasonably enough) but what about no HOST header? Rather than focusing on that particular point, I do think a statement is required here. If it has already been published, where can it be found please?
"your channels is making a request to api.thingspeak.com, with a HOST header incorrectly set to "a.c.d". This request is now being rejected."
What does this mean? how do I resolve this?
Thanks,
Brian
If you can share your Arduino sketch or program that updates your channels, I can potentially make suggestions.
// Send data to ThingSpeak
WiFiClient client;
if (client.connect(server,80)) {
Serial.println("Connect to ThingSpeak - OK");
String postStr = "";
postStr+="GET /update?api_key=";
postStr+=api_key;
postStr+="&field1=";
postStr+=String(pressure);
postStr+="&field2=";
postStr+=String(temperature * 1.8 + 32);
postStr+="&field3=";
postStr+=String(humidity);
postStr+="&field4=";
postStr+=String(rssi);
postStr+="&field5=";
postStr+=String(volt);
postStr+="&field6=";
postStr+=String(busvoltage + (shuntvoltage / 1000));
postStr+="&field7=";
postStr+=String(mean);
postStr+="&field8=";
postStr+=String(power_mW);
postStr+=" HTTP/1.1\r\nHost: a.c.d\r\nConnection: close\r\n\r\n";
postStr+="";
client.print(postStr);
//*******************************************************************************
This line needs to change:
postStr+=" HTTP/1.1\r\nHost: a.c.d\r\nConnection: close\r\n\r\n";
The host you are making the request to is "api.thingspeak.com", so this should be:
postStr+=" HTTP/1.1\r\nHost: api.thingspeak.com\r\nConnection: close\r\n\r\n";
Vinod,
Thanks for your support. I haven't made your suggested changes to my channels yet but on 12/11/25 at 15:55 EST they all started to work again. Now I am not sure if I still need to make your suggested changes
Thanks, Brian
@Brian: You do need to make the changes in your sketch. What is being sent today is only being accepted temporarily to provide time for folks to fix their code. We do intend to block these incorrect headers again in the future.
I'm not sure of this is possible, but it would be ideal if these types of code changes (aka a change that potentially denies service) could be announced in advance. :)
Or maybe I don't know where I should have been watching?
Again, dunno if possible, but I've got 8 bricked IOT projects in my house, some of them very remote and hard to get to (attics etc) that I'll have to retrieve physically, and of course spent a day chasing my tail when it broke initially, and then it magically came back to life randomly a day or so ago.
Dunno where the original "a.c.d" code snippet came from, but it's been working OK for years, and I'm not the only one using it evidently. :)
That is fair feedback. We'll try and pre-announce the changes in the future. The reason we put in a workaround for now is based on user feedback, and, to allow time for users to update their code.
Hi Brian,
Is this code correct?
AT^HTTPCMD=1,POST,"http://api.thingspeak.com:80/update?api_key=xxxxxxxxxxxxx&field1=48.130&field2=99&field3=99&field4=100&field5=99&field6=99",0,"text/plain"
Regards
@Vinod Where are the logs that you're referring to? I'm not aware that ThingSpeak maintains logs on their side that are visible to the user. Or perhaps you mean something else.
Thanks for your interest and comment Vinod.
The public channels are interesting (thank you), particularly https://thingspeak.mathworks.com/channels/1293177 which, from the notes there, appears to be running on ESP8266 (same as me) although I'm using NodeMCU 1.0 (ESP-12E) versus their (claimed) UNO R3. And yes, still working, as you say.
For GET (single write), my sketch uses no explicit HTTP headers (unless they are added by the ESP8266HTTPClient library it's using, which I haven't checked).
Prompted by your question, I tried adding the following headers to GET but it still didn't work:
client.println(F("GET /update HTTP/1.1"));
client.print(F("Host: "));
client.println(thingspeakServer);//api.thingspeak.com
client.println(F("Connection: close"));
For POST/JSON, my sketch uses headers as shown by this code:
client.println(F("/bulk_update.json HTTP/1.1"));
client.print(F("Host: "));
client.println(thingspeakServer);//api.thingspeak.com
client.println(F("User-Agent: mw.doc.bulk-update (Arduino ESP8266)"));
client.println(F("Connection: close"));
client.println(F("Content-Type: application/json"));
client.print(F("Content-Length: "));
I think that's answered all your great questions. Does it help to make sense of what's going on?
I note that J.D. has added a comment to my post saying that his Arduinos experienced the same issue at the same date/time. Something's going on here!
Cheers, Peter
@Peter: Can you please share a complete sketch that reproduces the issue? Also if you can share if this is an esp8266 connected by WiFi or some sort of LTE modem or such that would be helpful.
Hi again Vinod
I've just spotted that my original code has started working again so it looks as it ThingSpeak have fixed whatever was up at their end.
Still, it's strange that some ways of "writing" messages stopped working while others were just fine. I'm sure there will be a fascinating (yawn!) explanation for that but I haven't the time (or, frankly, the inclination) to find out what that is.
Thank you for your kind assistance.
Mine also started working again today at about 15:00 GMT. I'm glad it is apparently sorted.
I will work on a cut-down sketch to post here.
All three Arduinos (ESP8266) connect via WiFi - actually two WiFi networks in two countries as two devices are at the same location in one country and the other is in a second location/country.
Both of my Arduinos stopped uploading data at the same time (Dec. 4). The last entry is 2025-12-04T15:36:58Z. They had been running for around 8 years on the same code, so something changed on ThingSpeak. I doubt I still have a copy of the code.
Mine works great with no interruption. Do you have code to share?
Thanks for your interest and comment Shore. I'll get working on a (very) stripped-down sketch that reproduces the issue although, for the reasons I've stated, I believe the issue lies on the ThingSpeak side. That said, perhaps there's something I can do on my side to compensate for whatever's (surely) changed there.
I'll post the stripped-down code tomorrow.
Meanwhile, a question for you. When you say "mine works great", what is the "mine" that you're referring to? Something Arduino-related?
Hi all,
My channels have stopped working 3 days now.
I do POST,"http://api.thingspeak.com:80/update?api_key=...... " using GSM modem.
There is a good network coverage and I see traffic on my sim cards.
It looks to me like an issue on thingspeak server.
Can someone suggest ?
Regards
@kolias, @karabalhs: It appears your devices are attempting to send data through a DNS CNAME, iot.zygi.gr, that is not authorized or controlled by MathWorks. When the data comes through this, the HOST header is set to iot.zygi.gr. ThingSpeak API cannot accept data coming through this as it presents a risk to users of man-in-the-middle attacks.
Your devices need to be updated to be sending data directly to api.thingspeak.com.
PS: Please consider purchasing a standard license of ThingSpeak if zygi.gr is using ThingSpeak for commercial purposes.
Hi Vivod and thanks for your time. This account (<mailto:sade@zygi.gr sade@zygi.gr>) is sending directly to api.thingspeak.com but it also can't send data. Do you think that if I remove the dns record iot.zygi.gr will solve the problem for the (sade) account ? Also, why you think the paid licence will solve my issue?
Regards
Can you share more about how your devices are sending data to ThingSpeak? Can you please share the public IP address of the device? Is it an 8266 or Arduino? Is it going through the same service as the other zygi.gr devices?
As for using a paid license, if you are using ThingSpeak for commercial purposes, to be in compliance with terms of service, you should purchase a license.
Hi Vinod,
I use arm microcontroller with huaweii gsm modules (mu709s-2) and sim cards from thingsmobile.com
All zygi.gr devices use the same setup.
All IP addresses are dynamic and I don't know them.
Also, I have removed the cname dns record of iot.zygi.gr -> api.thingspeak.com from my dns server 4 hours ago.
Regards,
Once the DNS CNAME is removed, you may need to restart any routers and devices to clear caches. If you can get me an IP of one device I can try and lookup in a few hours what we see on the incoming requests.
Hi Vinod,
I will wait one more day for the caches of routers and firewalls to be cleared to see if the problem solved.
As for IP addresses, unfortunately I have no access in such info at the moment.
Latest info soon in this post.
Thanks a lot,
Regards
Please share the full sequence of AT commands your microcontroller is sending the SIM card. I looked up the spec sheet and my understanding is that the AT command needs to be like this:
AT^HTTPCMD=1,POST,"https://api.thingspeak.com:443/update?api_key=xxxxxxxxxxxxx&field1=48.130&field2=99&field3=99&field4=100&field5=99&field6=99"
If you're using plain HTTP, it would be something like this:
AT^HTTPCMD=1,POST,"http://api.thingspeak.com:80/update?api_key=xxxxxxxxxxxxx&field1=48.130&field2=99&field3=99&field4=100&field5=99&field6=99"
Keep in mind the entire string cannot be more than 255 characters, per the spec sheet.
I think the sequence of AT commands using this modem should be something like:
AT^IPCFL=14,1
AT^HTTPCMD=1,POST,"http://api.thingspeak.com:80/update?api_key=xxxxxxxxxxxxx&field1=48.130&field2=99&field3=99&field4=100&field5=99&field6=99"
AT^IPSENDEX=1,2,<REPLACE_WITH_NUMBER_OF_BYTES_IN_STRING_ABOVE>
Again, it would be required to get the full sequence of AT commands your device is using to be able to help you.
Dear Vinod,
You previously said that if http headers comes from another domain, like iot.zygi.gr then security policies rejects such packets.
As my devices are geographically very far and its very hard to install new firmware, is there a possibility to exclude my domain iot.zygi.gr from your security policies just to see if problem solved and then included it again ?
Regards,
If the code is working on other channels, then I would recommend finding the differences between the devices that are working and those that are not. I can tell you there is nothing on the ThingSpeak end that can tell the differences between your devices.
Accedi per partecipare
