Closed lenwar closed 1 year ago
I think there are ~3.5 reasons:
(0.5). Based on initial feedback, there is a strong desire to keep the ability to create these via YAML. Currently in beta is the continued ability to create variable entities in YAML in addition to the option of creating and managing in the UI. Not sure the YAML based ones will have all of the options/features of the UI ones, but if we can get it working correctly, we will try to support both.
Thank you for the complete answer. I hadn't considered the attributes as an advantage. At this point I have variables per device and use attributes per item. (for example target brightness and target colour temperature for specific lights). As I wrote I am currently migrating to helpers and now have separate helpers for that. Though I don't have a personal use for it, I can imagine plenty of reasons why someone would need to have larger amounts of data in the attributes, so I think you really have a valid point there.
Point 2 and 3 feel a bit out of scope for the concept of a "variable" to be honest. I do understand that it can be handy, but to me a variable... well, is a variable. So in my logic it is a string, an integer, a boolean, etc, etc, etc. To me it doesn't make sense to have a variable have a Device Class, state class, etc, etc. Again: I do understand that it can be handy, but it feels out of scope for this. The classes should be pushed on the relevant items I think. (just my two cents of course :) )
The native helpers of course are also a mix of 'variables' (input_number, input_boolean, etc, etc), pseudo-sensors (binary_sensor, etc, etc) and other stuff like "groups".
And as a final remark/opinion in regards to the yaml-files: Though I do understand that a lot of people feel the need to be able to work in yaml-files (As a Linux engineer I really do understand), Home Assistant, however, is (actively??) migrating to a principle where everything can/should be done in the UI. To actively work towards yaml files where a choice was made to pull away from it, feels... illogical :) I am also currently migrating my yaml automations/scripts/etc/etc towards the UI for this reason. I do want to follow up with the idea of the product.
At any rate. Thank you for your quick reply and please keep up the good work!! I'm pretty sure a lot of people really benefit from this project!! :)
Hi,
First off, I don't want to bash or be disrespectful to the makers of this custom Integration. I just want to ask a question :)
I have been in the process of migrating my variable.* variables to native HA-helpers for a number of weeks now. Mostly because the helpers are configurable via the web interface. (taking my time, doing a few small things in between everything every now and then)
In the recent 3.x upgrade (which I didn't do, because a lot of my automations depend on the variable.xyz entities, and it would cost me too much time to change everything in one go). I was looking in to the new features of this Integration, but I really can't make out what the current added value over this integration is, over the native 'helpers' of HA.
So my question is:
What is the functional added value of this integration in comparison to the native HA-helpers? What can this integration do, that I can't do with the HA-helpers. (or at least make life a lot easier than to work with the HA-helpers)