To answer the other questions:
- Same cable as mentioned earlier
- OS is Linux Mint 21.3 ("Virginia")
- Yes, there is a
void setup()....Serial.begin(9600)
I don't see that at all, I wonder why.
The cloud editor would not put a Serial.begin, it's a wifi connection, that is what clkoud means. Very strange, but could be usefull.
Not sure, but you are using a Mac so the interface might be different
Well 2 points, A Mac is BSD Unix under the fancy GUI, and the GUI may be different, but the function has to be the same.
I am stumped, maybe someone else will know.
Yes, I know that is true. But that doesn't mean that the interface would be exactly the same. The Linux version certainly does not normally look like the Mac version (whatever the application!)
Meanwhile, I have made some solid progress toward understanding this rather quirky collection of entities. Here is what I observed lately:
I modified the very basic Sketch provided by the Cloud Agent, to include the R4's on-board RTC, and incremented my Variable "Seconds" using the RTC by updating it every 10 seconds.
It took a couple of attempts, but I finally got the sketch Verified and Uploaded to the board (using, in my case, the USB).
I verified that the value for Seconds was updating every 10 seconds, using the Serial Monitor within the Cloud Agent. Now, here is something not-so-obvious :
Though the Serial Monitor showed the Seconds value updating every 10 seconds, and even though the Data window of the Thing shows it to be Online and Operational, the very basic Dashboard I created would not display the values of Seconds updating. I thought this to be very strange, given that the Thing was Online and Operational and so (one would think....) communicating as a cloud device, and so (presumably) able to update the Dashboard.
After some pondering, and once I returned to the Sketch tab of the Thing window and switched from USB-to-Cloud using the slider, I suddenly had (nearly) real-time data reporting to the Dashboard widget.
Additional observations:
- When the USB cable is unplugged (and so the board is only able to use its WiFi comms), the slider-bar disappears.
- When the USB cable is plugged-in AFTER the Dashboard gets up-and-running (i.e., displaying nearly real-time data), the slider-bar on the Sketch tab automatically shifts to the USB setting but (and here is the incongruent fact -- ) the Dashboard is still functioning. Go figure ⸺ previously, I had to shift it to the Cloud position, but perhaps that is a one-time trigger after uploading a new Sketch (???)
I have an R4 WiFi somewhere, post the sketch so I and others can try it. This is indeed interesting behaviour and sounds like it could be useful.
Are you sure about that ?
I am sure as I can be that the IDE uses the .ino file with the same name as the folder in which it is saved as the "master" and only after that any other .ino files are compiled in alphabetical order
If you have not yet save the sketch and therefore have not created a folder I believe that the IDE uses a temporary folder that it has created which has the name of the it gave to the new sketch and hence follows the same rule
Not sure at all, and your explanation sounds right. It's not something I have done in years and back then I had no idea and didn't seem to matter. I wonder what the result is with 2 sketches that I bet are both a 'main' sketch as the OP has?
Hello (and also to UKHeliBob):
I deleted the 2nd *.ino file mid-day yesterday, after the Cloud's AI-agent told me that the compilation errors I was getting were due to the compiler trying to concatenate two or more *.ino files. After the deletion, those compilation errors / compilation failures disappeared.
Here is the Arduino *.ino, as it exists & running on my R4 right now. The only thing I altered is to remove the device-specific address (see 3rd line of code, <<Device_address_goes_here>>).
As I have related on the Post, the quirky and non-intuitive behaviour certainly makes the learning-curve steeper!
/*
Sketch generated by the Arduino IoT Cloud Thing "Untitled 2"
https://create.arduino.cc/cloud/things/<<Device_address_goes_here>>
Arduino IoT Cloud Variables description
The following variables are automatically generated and updated when changes are made to the Thing
float CO2_ppm;
float Mass;
float RHumidity;
float TempC;
int Seconds;
Variables which are marked as READ/WRITE in the Cloud Thing will also have functions
which are called when their values are changed from the Dashboard.
These functions are generated with the Thing and added at the end of this sketch.
*/
#include "thingProperties.h"
#include "RTC.h"
// void setup() {
// Serial.begin(9600);
// RTC.begin();
// RTCTime startTime(30, Month::JUNE, 2023, 13, 37, 00, DayOfWeek::WEDNESDAY, SaveLight::SAVING_TIME_ACTIVE);
// RTC.setTime(startTime);
// }
void setup() {
// Initialize serial and wait for port to open:
Serial.begin(9600);
// This delay gives the chance to wait for a Serial Monitor without blocking if none is found
delay(1500);
RTC.begin();
RTCTime startTime(30, Month::JUNE, 2023, 13, 37, 00, DayOfWeek::WEDNESDAY, SaveLight::SAVING_TIME_ACTIVE);
RTC.setTime(startTime);
// here I make a comment
// Defined in thingProperties.h
initProperties();
// Connect to Arduino IoT Cloud
ArduinoCloud.begin(ArduinoIoTPreferredConnection);
/*
The following function allows you to obtain more information
related to the state of network and IoT Cloud connection and errors
the higher number the more granular information you’ll get.
The default is 0 (only errors).
Maximum is 4
*/
setDebugMessageLevel(2);
ArduinoCloud.printDebugInfo();
}
void loop() {
ArduinoCloud.update();
// Your code here
RTCTime currentTime;
// Get current time from RTC
RTC.getTime(currentTime);
Serial.println(currentTime.getSeconds());
Seconds=(currentTime.getSeconds());
delay(10000);
}
/*
Since Mass is READ_WRITE variable, onMassChange() is
executed every time a new value is received from IoT Cloud.
*/
void onMassChange() {
// Add your code here to act upon Mass change
}
/*
Since TempC is READ_WRITE variable, onTempCChange() is
executed every time a new value is received from IoT Cloud.
*/
void onTempCChange() {
// Add your code here to act upon TempC change
}
/*
Since RHumidity is READ_WRITE variable, onRHumidityChange() is
executed every time a new value is received from IoT Cloud.
*/
void onRHumidityChange() {
// Add your code here to act upon RHumidity change
}
/*
Since CO2PerCent is READ_WRITE variable, onCO2PerCentChange() is
executed every time a new value is received from IoT Cloud.
*/
void onCO2PerCentChange() {
// Add your code here to act upon CO2PerCent change
}
/*
Since CO2Ppm is READ_WRITE variable, onCO2PpmChange() is
executed every time a new value is received from IoT Cloud.
*/
void onCO2PpmChange() {
// Add your code here to act upon CO2Ppm change
}
/*
Since Seconds is READ_WRITE variable, onSecondsChange() is
executed every time a new value is received from IoT Cloud.
*/
void onSecondsChange() {
// Add your code here to act upon Seconds change
}
Only 1 sketch would match the folder name but both would have at least a setup() and loop() function so would fail to compile when the IDE combined them because of redefinition of the functions
I give up. Goodbye.
That was the gist of what the AI assistant told me, as I recall, when I asked for the Cloud Agent to "fix the errors". Thanks for the confirmation.
I do find it rather odd that the Cloud Agent would attempt to merge several *.ino files. I do not think that any of the other Arduino IDEs attempt to do that (but, correct me if I am wrong).
I don't understand ⸺ Did I do something offensive?
You are wrong.
The Arduino IDE will merge all .ino files in a sketch directory into a single file before compiling the combined file
Arduino is trying to make C++ development a little simpler. So it has .ino files. A sketch must have one with the same name as the folder. That's considered the main one. Then you can have other tabs with other .ino files so you can "arrange" your code horizontally in the Cloud editor or the local IDE. Certainly not a bad idea to allow better code organization.
When compiling, it will take the main one, and all the rest in alphabetical order (to at least be deterministic?) and glue them all together in one big file, with an .ino.cpp extension: i.e. just another C++ translation unit. It then applies some "magic" -- not always entirely successfully -- to paper over some of the rough edges that nick beginners, like requiring forward references.
But that means that you can't have the same function defined in more than one .ino, for example.
This is an area where it pays to be precise. It depends what you mean by "same function"
You could have the same function in two different namespaces, but would they then really be the same function ?
You can, of course, have two functions with the same name without using namespaces as long as their signature is different.
Hi @polarmolar. You have misunderstood what Arduino Cloud Agent is:
Arduino Cloud Agent is a simple open source application that runs locally in the background on your computer. The sole function of Arduino Cloud Agent is to act as a "bridge" between the Arduino Cloud web service and an Arduino board connected to your computer via a USB cable.
It isn't possible for the Arduino Cloud web service to communicate directly with the board via the USB interface (web browsers have recently gained some of the required capabilities with the introduction of WebUSB, but they still aren't sufficient to meet all the requirements of Arduino Cloud users). So the Arduino Cloud web service must instead work through a local application running on your computer, which acts as its "agent".
Everything you described in the passages I quoted above are components of the Arduino Cloud web service, not Arduino Cloud Agent.
This is all normal and expected.
The sketch program you upload to the UNO R4 WiFi is what makes it function as an Arduino Cloud IoT Thing. When you upload a sketch to the board, it overwrites the program that was previously loaded on the board. So when you uploaded the example sketch to the board, you erased the Arduino Cloud IoT Thing sketch.
If you want the board to act as Thing once again, just open the Thing sketch in Arduino Cloud and upload it to the board again.
It is highly unlikely any of that was necessary. You only needed to upload the Thing sketch to the board again.
Yes, just like any Arduino sketch, regardless of whether they are Thing sketches or not.
If you want to combine the functionalities of two sketches, you must carefully merge the code from the two sketches. You could never accomplish that by uploading each separate sketch program in sequence.
You can see it all in the sketch source code, which is visible in Arduino Cloud Editor. Note that the Thing sketch generated by Arduino Cloud is split up into multiple files. These are each represented by a tab in the editor. So if you want to see the code that was generated in the thingProperties.h file of the sketch, just select that tab at the top of the editor panel.
Great job troubleshooting the problem! I'm glad the Arduino Cloud web service is now able to communicate with Arduino Cloud Agent.
This line is indeed part of the default Thing sketch skeleton code Arduino Cloud generates whenever you create a Thing:
It is true that the Thing is able to operate exclusively with a connection via the Internet. However, the user will typically want to use Serial Monitor for debugging during the development of the project. So it will be convenient to connect the Arduino board to the computer with a USB cable during development and use the serial port. Once you complete development, you can then use a network connection for communication between the Thing and the Arduino Cloud IoT service.
In order to avoid any possibility of confusion with Arduino Cloud Agent, I recommend referring to this feature by its official name: Arduino AI Assistant.
It is true that "AI agents" are a real thing. However, Arduino AI Assistant is not an AI agent.
OK -- thanks. I never had experience of that happening... I guess I never made the error of putting two *.ino files into the same directory!