ThingSpeak

关注

My pofile has the Time Zone set to US Mountain (GMT-07:00), but the data is being displayed with US Pacific time (GMT-08:00). I am not encoding any explict time or zone information with my data. How do I get the data to display in Mountain Time?

I have this channel: https://thingspeak.com/channels/957733 Where I monitor a fridge arduino control, used thingspeak visualizations for temp and humidity, and started experimenting with matlab visualizations, managed to combine both readings and adjusted their scales according to my needs, but I cant change the timezone, even after adding the proper timezone to each plot like this: t.TimeZone = '-3:00' % Visualize Data yyaxis left plot(timeStamps, temperatureData); ylabel('Temperatura'); ylim([-5 45]) t.TimeZone = '-3:00' yyaxis right plot(timeStamps, humedadData); ylabel('Humedad'); ylim([1 100]) t.TimeZone = '-3:00' How can I make it to show local time? I'm Argentina, UTC-3 Thanks

Hi, Is there a way of setting the current time zone in the Thing Speak channels permanantly. Because when data collected with the time stamp it come up with a different time zones out puts if we do not set the time zone during read request. Thanks

I have a CSV generated from ThingSpeak, which contains a datetime containing a time zone identifier (CEST in my case). It looks like this: created_at,entry_id,field1,field2,field3,latitude,longitude,elevation,status 2020-06-06 18:36:17 CEST,1,434,2.12121212121,30.3487192708,,,, 2020-06-06 18:36:33 CEST,2,433,2.11632453568,30.2823285934,,,, 2020-06-06 18:36:48 CEST,3,436,2.13098729228,30.4815006257,,,, 2020-06-06 18:37:03 CEST,4,433,2.11632453568,30.2823285934,,,, Now, when I edit the file and remove " CEST" from all rows, readtimetable imports the file properly, with no issues. But when I leave it as is, readtable imports the field as text, while readtimetable refuses altogether. I tried to specify the format manually, as so: opts.VariableNames = ["created_at", "Var2", "field1", "Var4", "Var5", "Var6", "Var7", "Var8", "Var9"]; opts.SelectedVariableNames = ["created_at", "field1"]; opts.VariableTypes = ["datetime", "string", "double", "string", "string", "string", "string", "string", "string"]; opts = setvaropts(opts, "created_at", "InputFormat", "dd-MM-yyyy HH:mm:ss z", "TimeZone", 'Europe/Warsaw'); With this, readtimetable works but... all fields are turned into NaT. Now, this is some weird behavior, because using the datetime function with one of those fields copied works flawlessly: >> date = datetime("2020-06-06 18:36:17 CEST","InputFormat","yyyy-MM-dd HH:mm:ss z","TimeZone","Europe/Warsaw") date = datetime 06-Jun-2020 18:36:17 Matlab's importer also can't handle it, when I use the CSV file as the input it wrongly detects the delimiter, once that's corrected and field type set to datetime, any way I tried configuring the input format just fails and results in NaTs. I even attempted to set the format to "yyyy-MM-dd HH:mm:ss 'CEST'", so the time zone gets treated as a string, but it still fails to recognize it as a correct datetime. Using Matlab R2020a

I have a bunch of files with hourly data that I need to upload into several ThingSpeak Channels. The CSV-files are formatted according to https://se.mathworks.com/help/thingspeak/channel-data-import.html, and look like this (each file is about 8000 lines): datetime,field1,field2 2019-03-31 00:00:00 UTC,43, 2019-03-31 01:00:00 UTC,47, 2019-03-31 02:00:00 UTC,61, 2019-03-31 03:00:00 UTC,68, 2019-03-31 04:00:00 UTC,85, However the upload fails,ThingSpeak claims that there are duplicate data in the CSV file (at this point it would have been super-useful if ThingSpeak could tell me which line had duplicated data, but I had to figure that out by myself - please consider this a feature request!). Anyway after a while I figured out that the problem was related to the date "2019-03-31". I suddenly understood why - this is the day Daylight Savings Time starts. So, by removing EITHER the line 02:00 or the line 03:00 then the upload works. This sort of makes sense: when daylight savings time starts the clock is advanced from 0200 to 0300, so 0200 and 0300 is actually the same point in time and hence they are overlapping data. BUT: I am using UTC which does not use daylight savings time - the whole point of UTC is to provide a constant reference. Hence, my time series above should not fail when doing a data import. Try it yourself: create an empty Thingspeak channel, copy/paste the above lines into a file, upload it. It fails. Now try with either 0200 or 0300 deleted. It works. I could of course write a script that adjusts all times by one hour from March 31 to October 27, but it seems to me that ThingSpeak/Matlab should handle this by properly supporting UTC?