If you intend to provide a solution to a customer, then there are a few things that you should be aware of when considering the Arduino IoT Cloud.
Devices
• Very difficult to configure RP2040 Connect as a device. The process fails on step 3 of 3. I note from comments on the forum that I'm not the only one suffering this. I can find no time frame for a fix.
• The cloud uses the built-in device serial number to maintain uniqueness on the cloud. Since I have two RP2040 Connect devices with the same serial number, I can only ever configure 1 device (on a good day) even once the issue above has been rectified.
• Yun Rev 2 is not yet supported.
• I have no other Arduino devices that can join the Cloud directly, but third party devices based on ESP8266 and ESP32 work very well.
Widget
• The selection of widgets is ok, but lacks a few important things.
• Widgets are a bit clunky and could do with being more compact for use in the app.
• No text widget
• No divider widget
• No transcript widget
• No polar chart widget
• No table widget
• No clock widget
• No bar chart widget
• No compass widget
• No container widget to group widget by meaning
• Chart widget can only display a single variable and there's no control over the axes. X-axis is time or don't use it. I.e. no x-y plotting supported.
• No framework for custom widgets
App
• Charts don't update correctly when the App is opened with a dashboard already selected. You either have to leave the dashboard and return or switch to a different display range (e.g. 7 days) and go back (e.g. 1 day).
• App only works in portrait mode on an iPhone.
API
• My experience of the API is limited to Python, but from comments I have seen on the Forum, I suspect the same is true of the Java Script API.
• Documentation is incorrect. The examples are simply wrong. I suspect they weren't updated at the shift from V1 to V2. You have to extrapolate from the "smoke test" example given on the API repository on github. Once you get the pattern, it's not that difficult to use.
MQTT
• It doesn't appear to be possible to run a second MQTT client withing a script, though I'd love someone to prove me wrong. The first client being part of the normal Arduino Cloud software. If you want to use a Thing as a bridge between the Arduino IoT Cloud and some other IoT system you may have, then for a Thing to be a client of both systems is the obvious solution.
• It is still possible to bridge the two systems, but it is necessary to resort to messier methods.
Documentation
• Overall the documentation appears to be a weak point. Much of my time has been wasted searching the net for clues as to how something might be done, when a good reference would clear it up in minutes.
Zigbee
• There's no easy route to supporting Zigbee devices. This is a hardware issue really, but with Zigbee sensors and controls being two-a-penny and low enough energy to run for a year off a button cell, a board with support for Zigbee would be warmly welcomed by the Arduino fanbase, I'm sure.
Portable Things
• Things are dedicated to a WiFi network prior to compilation, so Things that have to work at more than one site are not supported.
Having said all that, the Arduino cloud does work and it is pretty good value. A maker plan works out about half the cost of my bespoke web-based IoT. That makes a difference over time. I'd also hope that the current set of wrinkles and limitations listed above will be ironed out with time.
Regards,
Another Bob.
p.s. I'd be delighted to be proved wrong on any of these points.