Correct.
Could this be revisited?
I'm heavily leveraging the table methodology demonstrated in the "Light Usage" to provide a way to track energy usage and cost (that's device agnostic). I'm giving the option to link table values to variables. This can scale up quickly already and I'd like to add more.
For example, right now I have three variable options for "costs" per device and three for totals. If I'm using the app for 20 devices and want everything displayed, you're talking manually creating 63 variables. It would be nice to be able to do this for the user instead.
And if your app has a bug and runs away, you could destroy the users Hub Variables beyond repair. So, no, we aren't adding create Hub Variables to apps.
Surely you can figure out another way to get the information available to a user. Realistically, 63 Hub Variables is not the way to go.
And if my app has a bug and runs away creating child devices or I go and write a few million state variables? I understand the concern of potential app code bugs wreaking havoc, but I feel like that's an implicit risk to allowing community development in the first place.
I'm just not sure what the proper alternatives are. Do I start making child devices? Do I create one child device for each key object that have an attribute for each of the possible outputs? Do I create a single child device with an attribute for each output? I can't write the table HTML to a variable nor a device attribute, so I'm not sure how else to allow for displaying the data in a standard dashboard.
Not to mention that I'm providing a "global" way of calculating energy usage for a given day without having to setup an RM instance per device to either reset the values (if the driver has the ability) or to grab the starting energy reading for the day to track the difference. It would be nice to be able to provide this in a user friendly way that doesn't involve some multi-step process.
1 Like
I'm sorry that you don't like our decision about Hub Variable methods (I don't recall the reasoning that went into reaching the decision we made, but I suspect it wasn't done frivolously). I'm really not in a position to advise you on how to do what you want to do.
That's disheartening. Appreciate the input.
The issue has to do with possible errors corrupting Hub Variables (the Setting). This happened early on (beta?) from an app. The problem is that once corrupted, there is no way for a user to recover Hub Variables short of sending me their database to be fixed. The same is not a risk with devices, states, location variables, etc., only with Hub Variables. Hub Variables could probably be made more resilient, but this certainly is not a priority for us right now.
4 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
