enkama / hass-variables

Home Assistant variables component
90 stars 12 forks source link

Question: Added value over the HA helpers? #44

Closed lenwar closed 1 year ago

lenwar commented 1 year ago

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)

Snuffy2 commented 1 year ago

I think there are ~3.5 reasons:

  1. Probably the biggest one: You can set and updates attributes to the entities in addition to just the values/states. The state has a max length of 255 characters while the attributes limit (for all attributes combined) is 16384 bytes and possibly longer if not stored in the recorder.
  2. Still in progress but a big reason for this change: the ability to set Device Class, State Class, Unit of Measurement in native ways that isn't just set in the Attributes and susceptible to being removed by future Attribute updates.
  3. Similar to # 2, you can create native entities with more classes than what is supported by the current helpers. First will be for the sensors, then binary_sensors. Future will be for other platforms.

(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.

lenwar commented 1 year ago

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!! :)