-
-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inputs and outputs to handle non-numerical values #1400
Comments
@bchwtz Just pinging my project manager... |
There are two databases that Mycodo uses, influxdb for time-series data and an SQL db for all other data (settings, etc.). I would suggest using the SQL db if you need to store text. |
To save/retrieve data from the SQL db you can use self.set_custom_option() and self.get_custom_option(). |
Thanks for the quick reply, Kyle. As a follow-up, I found this post on your other forum: Reading and writing data to database tables. So would you suggest the approach mentioned therein to me as well? @kizniche |
Widgets can communicate directly with Functions. There is an example widget and function showing how data of a Function is received and displayed by a widget. |
@kizniche I'm figuring out now how to translate your bits of info into actually implementing them... First question: Is your first response about "self.set_custom_option() and self.get_custom_option()" still relevant and connected to your second comment (using functions in widgets), or have these been independent approaches? Second question: Are the exemplary items you are referring to widget_function_status.py and example_function_all_options.py? I presume you brought up the widget/function approach to eliminate the need of using in-/outputs as those are restricted to being compatible with numerical data only. Correct? So, I'm supposed to prepare a custom function (based on example_function_all_options). Therein, I plan to implement the execution of a bash command inside a custom_command definition and later have my custom widget (based on widget_function_status) display the returned text value. Could you please give me a hint if I'm on the right track with this, Kyle? |
The set/get functions can be used to save/retrieve data from the database. I'm merely showing a method that doesn't rely on influxdb, not necessarily how I would approach solving the problem. There are multiple ways and I'm just helping you understand your options. The accompanying function for the status widget is custom_function_simple_loop_with_status.py What I would do is associate specific strings with numerical values, similar to how status and error codes work, and save the numerical value with the function. The widget can then display the string. The widget will simply display a string returned from the function, so all the processing occurs in the function. |
In my first weeks of actively working with Mycodo (v8.16.0), I focus on using inputs and outputs that specifically allow the execution of bash commands. Those commands include addressing a Python file which eventually performs I2C transmissions. The response data (being chopped by regex) is what I intend to display in a widget on my dashboard, for instance.
Unfortunately, I run into problems when I have my commands return or receive data that is alphanumerical, e.g. a simple text value for a device name. With this in mind, both tasks of displaying some text in an input widget or using an output widget for updating that text value cannot be accomplished so easily. As far as I can tell, this is due to Mycodo (and its underlying time series DB) only accepting numerical data that fits any compatible measurement and unit.
Frankly, for this kind of tasks dealing with plain data that originates from outside of the Mycodo system, I'm not even interested in contacting the Influx DB and thus, I could also do without picking any measurement which forces my values to meet certain conditions...
@kizniche Is there any way to safely configure my inputs/outputs to cope with non-numerical data without being at risk of breaking Mycodo's underlying mechanics?
The text was updated successfully, but these errors were encountered: