When you define a "thing" in the Arduino Cloud IoT, you can assign a cloud variable to that "thing" which you can control in the associated sketch.
In addition, you can define another "thing" with a similar cloud variable, and you can sync those two variables so that when either one changes, the other is updated. Pretty cool!
So I can have Thing0 and Thing1 that each contain a similar cloud variable, and those variables will stay in sync. Either thing can change it, and the other will be updated to match.
In addition, I can define a dashboard that contains a widget that is connected to that variable. So let's assume that I set up a widget that is connected to my cloud variable on Thing0. Now all three will stay in sync!
Unless Thing0 gets disconnected. If that happens, Thing1 and the dashboard widget have no way to communicate. They will not stay in sync. This is a problem.
Now let's add Thing2 and Thing3 with their cloud variables. Neither of them can participate because Thing0 is connected to Thing1 and vice versa. Neither of their cloud variables are available to Thing2 or Thing3. Nor can either of the new things be connected to the dashboard widget. It can only be connected to one thing at a time. This exacerbates the problem.
Maybe it would be possible to have each thing contain two cloud variables, letting the sketch keep those two variables in sync. Then you could create a chain of things each linked to one on either side of it. That would work - until one of them got disconnected. Then some large or small part of the chain would be disconnected. So it's not a great solution.
Am I missing something? Is there a way to make this all work seamlessly?
The obvious solution (to my mind, at least) would be to have an independent cloud variable that was not associated with any individual thing, and to give that cloud variable the ability to sync with as many things as necessary. The Dashboard widget could also link to that central cloud variable. Then any device that was online would be connected to any other, all would be connected to the dashboard, and any that came back online at some future time could be updated quickly with the current settings.
Does the Arduino cloud offer any such functionality or some other method to accomplish the same goal?
Maybe there is some large body of documentation on the Arduino IoT Cloud that I have yet to discover. That is entirely possible. Most of what I have learned so far comes from Youtube videos, Google searches, example code, and experimenting.
@jimgilliland Why not read the Arduino documentation?
I don't have a good grasp of what you are trying to do but if you think a 'thing' can only have one variable check out my iPhone thing, it has two pages of variables
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
I don't think your description as follows is how it works, the variable(s) would still reflect the real world and be updated in each thing still on-line. I have to admit I have not tested this, but based on my experience and understanding I would bet a coffee, extra-large even!
Unless Thing0 gets disconnected. If that happens, Thing1 and the dashboard widget have no way to communicate. They will not stay in sync. This is a problem.
Now let's add Thing2 and Thing3 with their cloud variables. Neither of them can participate because Thing0 is connected to Thing1 and vice versa. Neither of their cloud variables are available to Thing2 or Thing3. Nor can either of the new things be connected to the dashboard widget. It can only be connected to one thing at a time. This exacerbates the
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@zander Sorry, it seems that I didn't write as clearly as I thought I had. The number of variables for given thing is not in question, nor is the ability to sync one with another. The problem comes when you then want to sync a variable from a third thing to the first two. You can't do that. One cloud variable on one thing can be linked to exactly one other cloud variable on exactly one other thing.
Let's say I want to have a signal, a light or a buzzer or something. I want it to be visible or audible in N different locations, say 12. And in each of those locations, I want to have the ability to set or reset that signal. I also want the signal to be represented on a dashboard that will be kept in sync with my signal no matter which of the 12 things sets it or resets it, even if one or more of the 12 are offline at the moment.
I can't sync one cloud variable from each of 12 different things together to act as one; I can only sync two of them.
And if I put a widget on a dashboard, that widget can only be linked to one variable on one thing. Not more than one. So even if N was just 2 (which is the only N that actually can be supported), I still can't link the dashboard widget to both of them.
Everything is in a one-to-one relationship. There are no one-to-many relationships, nor many-to-many relationships. If I'm wrong, set me straight. I'm basing this on direct observation of the system. The minute I choose one variable to be linked, all of the others turn grey and can't be selected. Dashboard widgets are the same way.
I can't see any reason for this limitation. As far as I can tell the Arduino IoT is built using an MQTT base. And MQTT has no trouble allowing multiple things to publish and/or subscribe to the same topic.
Maybe I'm missing something. I hope so.
@jimgilliland I think we need to test it, I didn't see any limitations. I am in the midst of a full blown AFIB attack and on my way to see the cardiologist 2.5 hrs away. It will be a while before I can play with this.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@jimgilliland This looks hopefull
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
Geez, of course. Take care of your health! This stuff is very low priority, even for me. I'm just toying with it, not doing anything serious. Maybe someday, but so far it's just to educate myself.
@jimgilliland Got back from the heart D=r earlier, here is what was said.
Just more tests and waiting. The only real good news is the Cardiologist in Sudbury is going to refer me to an Electrophysiologist.
That means one or more trips to Toronto, but is the absolute best expert to get for my condition.
The Cardiologist did see the 40 bpm on my last holter session so I can't take the 'normal' meds. Most likely the Electrophysiologist will recommend an ablation. That is where they snake a tube up inside the heart and make a series of burns. The scar tissue does not conduct electricity so if they get the scars in the right place it stops the random signals I get now. It works about 50% of the time but a second session usually results in 100%. My hearing aid tech person tells me the wait list for her 2nd ablation is about 1 yr!
If it works, it can change my life and I may live for another 10+ years.
Ron (@zander)
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
I'm hoping for the best for you, and I'm certain I'm not the only one. Let's hope it works the first time!
Great news, I was wrong! I was being limited by my plan. It turns out that, yes, it is possible to link variables from multiple things together, and the cloud will keep them all in sync. This makes the use case that I described above much more realistic.
However, it is still true that a dashboard widget can be linked to only one variable on one thing. If that variable is linked to similar variables on other devices, they will all stay in sync, and the dashboard will be correct - as long as the thing that is linked to the dashboard is online. But if the one thing linked to the dashboard goes offline, the dashboard will no longer reflect any changes in the rest of the linked variables. They will still be linked, and they will keep each other in sync, but the dashboard will be disconnected from them.
This is not ideal, but the solution would be to have at least one thing that is completely reliable, or as much so as possible, and then link the dashboard to that one. A UPS, secure location, redundant access points, etc. might be important for the "thing" that feeds the dashboard.
Anyway, in this instance, I am very glad to prove myself wrong. 🙂