Help using ThingSpeak TimeControl Recurring

Hello:

Using the Timecontrol app, I want to execute a MatlabAnalysis recurring daily at 6:00 A.M. but execute it only ONCE. The MatlabAnalysis code performs a Thingspeakwrite() to a channel. I have the impression that the execution of this code is called multiple times during minute 00. I cannot write to a field more than every 30 seconds i believe. What can I do? Thanks in advance!

Below is my MatlabAnalysis code:

NHRS=6;
disp(['process the last ' num2str(NHRS) ' hours of pool level measurements']);  
channelID = xxxxxx; 
[data timestamps]= thingSpeakRead(channelID, 'NumPoints', 100, 'Fields', 5);
ts=timestamps;
indx=find(~isnan(data));
data1=data(indx);
ts1=ts(indx);
[N dummy]=size(data1);
[data2]=data1(N-NHRS+1:N);
ts2=ts1(N);
%disp('last 24 pool data levels');
%disp(data2);
disp(' ');
disp('time stamp of last pool level measurement');
disp(ts2);
% Calculate the average
avgValue = mean(data2);
% display the aveage
disp(['mean: ' num2str(avgValue) ' cm']);
% calcul the std deviation
sd=std(data2,1); 
%display the std deviation
disp(['sd: ' num2str(sd) ' cm']);
thingSpeakWrite(xxxxxx,[avgValue,sd],'WriteKey','xxxxxx');

[Christopher Stapels]

You should be able to complete your goal with this code and the appropriate timeControl.

What do you mean by "I have the impression that the execution of this code is called multiple times during minute 00" Your code seems fine at first glance, though im nto sure the use of the disp statements will help you when you run the timeControl, except for debug.

Answer 1

[William Glass]

below is my results and attached is my timecontrol config

process the last 6 hours of pool level measurements

time stamp of last pool level measurement

03-Nov-2026 18:09:49

mean: -9.99 cm

sd: 1.1801 cm

Error using Calculate and display average and sd of poolLvl (line 25)

Requests are too frequent. For further information, see Limitations in the documentation.

[William Glass]

See my message showing results in my other post. The channel is written to OK though but will it work the next days?

[dpb]

@William Glass, why did you make this an Accepted Answer instead of a Comment?

Anyway, that is an artifact I overlooked...

Is that log from a schedule execution or from a manual submittal to test the code? If it were scheduled at 6:20 PM, there's a 10 min difference so the 15-sec (free account) write update limit wouldn't have come into play.

However, if you're manually testing, then would have to be sure to not try to execute the code again inside that window -- and 15 sec is quite a long time if just sitting at the terminal.

The other thing to check is to look at the channel upload data -- use

https://thingspeak.com/channels/ID_NUMBER/feeds.json?api_key=YOUR_KEY&results=5

to see the actual time stamps of all uploaded data to make sure some other process isn't still running in the background and causing the conflict.

[dpb]

@William Glass - "The channel is written to OK though but will it work the next days?"

As noted, it's not clear from the post how the test was run -- see my follow-on above. If you try manually, if you have/are using a free account then you'll need to be sure you don't try a second time too soon. Otherwise, it's "wait a day and see". Unless there's something else going on we can't see, it appears it should work ok. As above, you can double-check for certain the update proceess is the only one actually writing and it isn't conflicting. The posted timestamps make it appear at superficially to not be an issue. What is the intended update frequency and who's doing the updating?

[William Glass]

Scheduled result for 6:15 pm. Manually, no errors if I don't run the code for > every 15 sec. If you see my config I'm not a sprcialist about sending questions so didn't know about "accepted answer". If you say that my code will be executed only once every 10 minutes , there should not be the error? Anyway,wait and see tomorrow.

[dpb]

If you don't get the error manually, there's nothing in the code for the daily task that is going to be a problem unless the task is scheduled for a time that is inside the window after the periodic updating has occurred within the 15 sec window.

You could add a check that the current time is greater than 15 sec after the last read timestamp and if not, do a pause() for long enough to satisfy the refresh cycle delay.

As far as the forum, the intent is that Answers are solutions to the Question raised of which there may be like cats, multiple ways of skinning. "Accepted" is way to provide an indicator there is a solution to the question that is satisfactory as an indicator to the community as well as provide the recognition to the contributor.

[William Glass]

See results.txt

I added to timestamps to the code near the end

[dpb]

Well, that's a kick in the head, isn't it? I've never used thingSpeak so no real hands-on experience but the AI 'bot says it's possible that despite the documentation to the contrary, it is treating the read and write as same for the channel access. If that is the case, adding a

pause(20)

after the read before the write operation should make the symptom disappear.

The other alternative would be to write the summary statistics to a second independent channel.

The last thing would be if somehow whatever other process is updating the routine data has the channel accessed in the background that isn't visible at all from this side; we have no information at all on what/how/where the other data are coming from.

[Christopher Stapels]

I think this seems consistant with the behavior you are seing. This line

[data timestamps]= thingSpeakRead(yyyyy, 'NumPoints', 1, 'Fields', 1);
disp(timestamps);

gets the last time stamp in the channel.

04-Nov-2026 16:10:03

You said you ran the execution at 4:10, but the last time stamp is at 4:10 and 3 seconds. That seems to be within 15 seconds, though it actually seems to be after the present time of 4:10. Time controls may be scheduled at the intended time, but it is possible that they run a little late. Can you also output datetime("now") so we know the present time when this happens? It definitely seems to me htat there is data written to the channel right about the same time that you execute this code, thus the frequency rejection.

[dpb]

I guess I misread the timestamp @Christopher Stapels :>)

[Christopher Stapels]

no worries @dpb In my time zone we are still reeling from daylight savings adjustments, so most times are read wrong ;). BTW I did want to point out that reads arent ever treated as writes with respect to rate limits, though you arent crazy to think of it.

[dpb]

Well, I knew weren't supposed to be and that AI can make up stuff out of the ether...good to have confirmation there aren't other circumstances; undoubtedly there was a posting somewhere that drew that conclusion it picked up on as fact.

We shifted as well, thankfully. On the farm, wish they would set at Standard and leave it alone... :>) It's the sun that controls the time of day, not the clock...when it's 11PM by the clock and the sun isn't much yet under the yardarm, it just ain't right when have to match up to something on town time.

[William Glass]

" if that is the case, adding a pause(20) after the read before the write operation should make the symptom disappear. The other alternative would be to write the summary statistics to a second independent channel. The last thing would be if somehow whatever other process is updating the routine data has the channel accessed in the background that isn't visible at all from this side; we have no information at all on what/how/where the other data are coming from."

Well, I still have the same error with the pause and I am already writing the stats to another channel. In the meantime, I have done this processing on my ESP32 used for other stuff as well. It works fine.

Answer 2

[dpb]

One of two possible issues could trigger the observed behavior. The first would be the TimeControl is using the Recurrence setting on "Hour" instead of "Day". You should not see an "Every" field when select "Day" but is/will be replaced by the "Time" field which should then be 06:00.

Alternatively, you may have a correctly formatted TimeControl, but since ThingSpeak allows up to 12 active TimeControls, it is easy have other schedule daemons left running in the background from prior testing. Select "Apps > TimeControl" and ensure there are not multiple entries for the desired MATLAB app. Delete or make inactive any duplicates that might show up there.

That should prevent the application from being either scheduled multiple times or executing more than once when it is executed/called/scheduled.

I took the liberty of reducing the MATLAB code just a little to eliminate some unneeded temporaries

NHRS=6;
disp(['process the last ' num2str(NHRS) ' hours of pool level measurements']);  
channelID = xxxxxx; 
[data ts]= thingSpeakRead(channelID, 'NumPoints', 100, 'Fields', 5);    % only ts was used, don't need to copy 
isOK=isfinite(data);    % valid data logical addressing vector
data=data(isOK);        % use logical addressing vector directly, no need for find() here
ts=ts(isOK);            % ditto for timestamps
N=nnz(isOK);            % how many were saved 
[data2]=data(N-NHRS+1:N);   % NOTE: could replace N here with internal keyword 'end'
ts2=ts(N);
%disp('last 24 pool data levels');
%disp(data2);
disp([newline 'time stamp of last pool level measurement']);
disp(ts2);
% Calculate the average
avgValue = mean(data2);
% display the aveage
disp(['mean: ' num2str(avgValue) ' cm']);
% calcul the std deviation
sd=std(data2,1); 
%display the std deviation
disp(['sd: ' num2str(sd) ' cm']);
thingSpeakWrite(xxxxxx,[avgValue,sd],'WriteKey','xxxxxx');