Why is 'variable' domain bad?

[gribouk]

Dear All,
The latest release (3.0) is not a step into the wright direction for the obvious reasons:

1. Why do you think that everything falls into existing platforms like sensor and ect? By definition, people use abstract variables to describe complex structres and have nothing to do with sensors and ect...
2. From the above it follows that one would need comments to explain what different attributes are introduced for, which is not possible with add from UI approach...
3. Everything you justify this change with can be done with old relese - what stops you from introducing attribute device_class and others? You have complex data structure, let's say a variable describung a climate controller and you want one of it's attributes to be treated as sensor - make a template sensor from that specific attribute - done! Sensor is sensor, variable is variable!

Why spoil something that is simple and works with something which will never work? KISS - Keep It Simple Silly

Regards,

P.S. to make thing clear an example of oversimplified variable one may have in real life:

test_pump_controller:
# value can be on/off
   value: 'off'
   restore: true
   attributes:
# stores instant pressure data as {time: int, val: float} to obtain average over 100 secs
       press_bins: []
# where to read the pressure
       press_sensor: sensor.pressure_sensor
# result of avg pressure computation
       average_pressure: 0
       set_pressure: 3
       pressure_delta: 0.5
       pump_switch: switch.pump_on_off

Above example can be used when attribute pressure_sensor triggers automation to process variable's test_pump_controller data. From this it is clear, that variables are NOT sensors. And if you want average_pressure as a sensor - create template sensor from this attribute! It is already in he HA. Moreover, you need comments, because you will never remember what these attributes denote in a couple of month. And you need it to be declared in YAML, because you can do simple 'search in files' when you want to find variable with attribute 'average_sensor' - something you cannot do from UI...

[MrSnakeSPb]

I also really didn’t like that now the setting for each variable needs to be added to the integration.
I understand that for most users it is easier to sculpt through integrations, but why is YAML removed for existing users? Why is variable. removed?
Not ready to accept such a fate.
With all due respect to the author, I will stay on the previous version, and after that I will switch the integration to var.
https://github.com/snarky-snark/home-assistant-variables

[gribouk]

I also really didn’t like that now the setting for each variable needs to be added to the integration. I understand that for most users it is easier to sculpt through integrations, but why is YAML removed for existing users? Why is variable. removed? Not ready to accept such a fate. With all due respect to the author, I will stay on the previous version, and after that I will switch the integration to var. https://github.com/snarky-snark/home-assistant-variables

The problem with UI is that variable and variable attributes are not searcheble within HA. How would you know what variables you have to controll pump now if you have several houndreds of such sensors in the system and now your variable is also a 'sensor'? Comments are crutial as well - how do you remember that your attribute 'avg_data_bins' store a list of dicts of a certain structure? And the most important - sensor and binary_sensor are already implemented in the HA with 'templete' integration - why would I need variable as a sensor if I already have it? I need variable as an abstract data type...

P.S. it is not an issue of new and existing users. It is an issue of being usefull and useless. I cannot imagine anyone would seriosly need variable set up from UI - such people use basic functionality and do not need 'variables', but when you need it, it has to be introduced with YAML...

[enkama]

I mean I guess u can change it so u could be able to set it up over UI and yaml. But I do not have the time do that right now for the next weeks.

But thats why we asked for feedback to change it to the needs but also have new possibilities.

@Snuffy2 ?

[gribouk]

I mean I guess u can change it so u could be able to set it up over UI and yaml. But I do not have the time do that right now for the next weeks.

But thats why we asked for feedback to change it to the needs but also have new possibilities.

@Snuffy2 ?

It does not add possibilities but cuts these instead - this is the problem.

Any extension MUST be reverse compatible, which implies that already stored data must not be lost. Just an example: some of my variables store statistics for over a year which I need (monthly insolation data). Reworking all scripts will take days, and the system will not be operational during this time. Regathering the data will take month... And I seriosly do not see enything you've introduced that was not already in the HA by today. Maybe we are missing something? Give an example and we may think of how to make it clear that this feature is already in HA and does not require a change to the 'variables'...

[pickonedev]

I don't like the idea to have other than variables as well... A sensor is a sensor, a switch is a switch, variable should be as variable...

It is not about the Breaking Change and the need to do everything from the beginning, even if I have thousand of variables with data already created, I don't mind to change something for a new better version, but having sensors and other things different than variables, I don't find it useful.
If this is the new version of this addon and it will remain the same, I think that I will stick with the old version and try to find an official HA solution to use instead variables, maybe helpers, I don't know...

[pickonedev]

I don't like the idea to have other than variables as well... A sensor is a sensor, a switch is a switch, variable should be as variable...

It is not about the Breaking Change and the need to do everything from the beginning, even if I have thousand of variables with data already created, I don't mind to change something for a new better version, but having sensors and other things different than variables, I don't find it useful.
If this is the new version of this addon and it will remain the same, I think that I will stick with the old version and try to find an official HA solution to use instead variables, maybe helpers, I don't know...

I also really didn’t like that now the setting for each variable needs to be added to the integration. I understand that for most users it is easier to sculpt through integrations, but why is YAML removed for existing users? Why is variable. removed? Not ready to accept such a fate. With all due respect to the author, I will stay on the previous version, and after that I will switch the integration to var. https://github.com/snarky-snark/home-assistant-variables

The problem with UI is that variable and variable attributes are not searcheble within HA. How would you know what variables you have to controll pump now if you have several houndreds of such sensors in the system and now your variable is also a 'sensor'? Comments are crutial as well - how do you remember that your attribute 'avg_data_bins' store a list of dicts of a certain structure? And the most important - sensor and binary_sensor are already implemented in the HA with 'templete' integration - why would I need variable as a sensor if I already have it? I need variable as an abstract data type...

P.S. it is not an issue of new and existing users. It is an issue of being usefull and useless. I cannot imagine anyone would seriosly need variable set up from UI - such people use basic functionality and do not need 'variables', but when you need it, it has to be introduced with YAML...

Lets be real, if someone knows how to install HACS, it will know how to use YAML as well.... So yes, no need for UI, or if there is an UI, i'm fine with if there is YAML as well...

[Snuffy2]

I'll attempt to respond with my opinions on why these changes were made.

1. I agree that the variable. was nice, but as far as I can tell, a custom platform is not supported if you want to have these entities created into the entity_registry and into the UI which was one of my goals.

2. I tried hard to bring the history and prior state of existing variables into the new ones on upgrade, but since they didn't have unique_ids and are not registered into HA like normal, I have not found a way to grab these histories or restore states and move them into the new entity.

3. I worry that the rather unsupported/hacky method that the prior variable integration was created may break at any time. Not saying that it wasn't well developed and I've used it heavily in many of my scripts and other integrations. But in many ways it is tricking HA into creating an entity that starts with variable. Not sure what could break it in the future, but because it does not follow the defined methods for creating entities (either in yaml or in the config_flow) the risk is there.

4. Even though the entities changed from variable.xxx to sensor.xxx you do not lose any functionality. You can still have abstract variables to describe complex structures as sensors.

5. While you can set device_class, unit_of_measurement (and presumably state_class although I've not tested that) as an Attribute, it then is obliterated if you overwrite your attributes on a subsequent Service Call even though those items don't actually show as an attribute once set.

   • Additionally, you can set a unit_of_measurement attribute, but this does not allow you to then change the displayed unit of measurement from the entity settings using the newer HA conversion ability.

6. The lack of comments is a good point. I'm not sure what to suggest for this at this time.

7. You can still search for variable entities. In the Entities screen search for variable and they will all show.

8. The ability to create and remove variables without restarting HA each time is a big positive in my view.

9. By using native platforms, these variables can then be used anywhere that the normal platform can be used. Examples include:

   • Adding a device_tracker variable to a Person (although the device_tracker variable option doesn't exist yet)
   • They can be grouped using the Helpers Platform-specific Groups and used in other math helpers.
   • They can be selected when adding automations from blueprints
   • Unsure, but could variables be added to the Energy configuration previously?

10. Not sure I agree that anyone who can install HACS can use yaml (at least not well), but I think this lowers the bar for those who may want to utilize this but are more comfortable in the UI.

11. There may be ways that we can keep support for yaml and the config_flow, but I worry that it may cause more problems. As I'm sure you've seen from many other integration upgrades, the standard is to have the yaml removed when transitioning to config_flow.

    • If you have an entity with both a config_flow and yaml defining it, if you change it in the config_flow, it won't be reflected in the yaml. Then on HA restart, the yaml may overwrite the config_flow changes or ignore the yaml depending on how it is set. In short, keeping the yaml and config_flow in sync is not straightforward.
      • Off the top of my head, one option might be to disable config_flow changes to any variable entities if they have been created by yaml. Not sure if that can actually be done, but I can think of an approach that might work.
    • Even with yaml support, it would still not allow creating variables that start with variable.
    • It would default all variables without domain specified to be sensors (as the current v3 import does), but I should be able to respect the domain option, only if it lists a valid platform that the variable integration supports.

[gribouk]

I'll attempt to respond with my opinions on why these changes were made.

1. I agree that the variable. was nice, but as far as I can tell, a custom platform is not supported if you want to have these entities created into the entity_registry and into the UI which was one of my goals.

The point is that use of UI to set up complex data structures is a bad idea from the start. Add from UI works well if all of your objects have similar structure. But if every object is different... It is a nightmare. You will never rememer the structure of your objects by theis names and will not be able to use them...

2. I tried hard to bring the history and prior state of existing variables into the new ones on upgrade, but since they didn't have unique_ids and are not registered into HA like normal, I have not found a way to grab these histories or restore states and move them into the new entity.

You can write a migration service for the new integration - keep both, new and old integrations alive (name them differently), On first boot, empty entities of a new type created, and after HA loads, you may run a migration service of the newest integration, which runs through the states.variable set and ads attributes to the entities of the new integration with same object_id... Then the old integration may be removed maually.

6. The lack of comments is a good point. I'm not sure what to suggest for this at this time.

It is a must if every object is different from others...

7. You can still search for variable entities. In the Entities screen search for variable and they will all show.

The problem is not to find a variable, but to find a proper one. Script development is happening in the Notepad++ and from time to time in my old scripts I find a references of the type var.attributes.attr1, and I need to find all variables with attribute attr1. Normally, variables are arranged in files by topic, i.e. heating_contoller.yaml contains related variables of same type and so on. So, search in files swiftly brings me into the necessery file dedicated to a structure searched and I can read comments and recall the purpose of the fields... Search in WEB interface of the HA is absolutely useless.

8. The ability to create and remove variables without restarting HA each time is a big positive in my view.

Does not play any role at all. It is absolutely not important because once created you do not add or remove variables normally, after a set of relateed scripts is developed and tested, expirience tells that you never touch these again. So, this is the last in the list of prioritiess - it does not require massive rebooting, so it is o,k, to reboot couple of times when developng structure... Moreover, you reboot only if you declare new variable. But if you only need to add attribute, you can simply set this attribute and it will appear in the list.

9. By using native platforms, these variables can then be used anywhere that the normal platform can be used. Examples include:

• Adding a device_tracker variable to a Person (although the device_tracker variable option doesn't exist yet)
• They can be grouped using the Helpers Platform-specific Groups and used in other math helpers.
• They can be selected when adding automations from blueprints
• Unsure, but could variables be added to the Energy configuration previously?

The variables are needed in the first place because standard methods fail to deliver the result. We use them because we want abit more than standard methods can provide. Every variable is a RECORD/STRUCT/CLASS emulator which comes with it's own set of scripts to substitute the blueprints, groups and so on which everyone developes for his needs. So, this feature is not that important also.

10. Not sure I agree that anyone who can install HACS can use yaml (at least not well), but I think this lowers the bar for those who may want to utilize this but are more comfortable in the UI.

UI limits use of variable due to the lack of convenience. Sonner or later, when variables get complex enough one will need to migrate to YAML after all... UI is sort os saying option for the beginners. But all beginners want more eventually and this is YAML...

11. There may be ways that we can keep support for yaml and the config_flow, but I worry that it may cause more problems. As I'm sure you've seen from many other integration upgrades, the standard is to have the yaml removed when transitioning to config_flow.

As I wrote, config_flow is a bad idea for this case in the first place.

P.S. just to illustrate, here is a sample of my small real life structure implemented as variable: think for yourself how convenient is that to have it set up in the UI, and this is by far not the complex one...

    climate_room_livingroom:
# value - off, water_heating, air_heating, electric_heating, drying, ventelation, cooling
        value: 'off'
        restore: true
        attributes:
            type: climate_room
            climate_manager: variable.climate_manager_tigraresidence
            
            state: []         
            manual: {'state': false, 'expires': 0}
# AI section            
#   occupation_tracer: provides schedule and AI operation based on occupation statistics
            occupation_tracer: variable.room_occupation_tracer_livingroom
            occupation_tracer_mode: ignored
            
            allow_operation: true
            supported_features: [water_heating, air_heating, ventelation, drying, cooling]
            summer_permissions: [ventelation, drying, cooling]
            winter_permissions: [water_heating]
            spring_fall_permissions: [air_heating, ventelation]

# priority of sensor data processing - absolute - active param measurments are not effected by other param.
#                                      conditional - humidity is capped by temp and vice versa. In the summer priority is set to conditional by default to bind temperature-humidity regulation
            priority: 'absolute'
            humidity_sensors: [{active: true, sensor: sensor.hymidity_livingroom}]
            temperature_sensors: [{active: true, sensor: sensor.temperature_livingroom}]
# devices by type: {'state': boolean, 'entity': entity_id, 'priority': int, 'speeds': int, 'integration': string, 'device_type': string, 'weight': int, 'pwm': {'step_true': int, 'step_false': int, 'updated': timestamp, 'status': boolean}},...
#               priority - what devices to activate in fist turn...
#               speeds - if several devices with same priority are present, every speed number is considered to be common for all of them, i.e. speed 1 would imply all devices have to switch speed 1. If some devices do not
#                    have certain speed, than they stop at their maximal speed. I.e. if speed 4 is requested, and priority_1 devices have max speed 3, they take 3 speeds to their account and 1 speed will be ordered to switch
#                    for devices of priority_2...
#               integration - ac/switch
#               device_type - floor/radiator/hvac/humidifier/fan
#               weight - int - portion of total amount of the devices of that type in a room i.e. 2 of 5 => 2. I.e. weight|sum = total volume
#               pwm - optional for pwm supporting devices, like electric heated floors.

            water_heaters: [{   state: true, 
                                entity: switch.climate_heater_livingroom_stage1, 
                                priority: 1, 
                                speeds: 1, 
                                integration: switch, 
                                device_type: floor, 
                                weight: 5, 
                                pwm: {'step_true': 0, 'step_false': 0, 'updated': 0, 'status': true}}, 
                            {   state: true, 
                                entity: switch.climate_heater_livingroom_stage2, 
                                priority: 2, 
                                speeds: 1, 
                                integration: switch, 
                                device_type: radiator, 
                                weight: 2, 
                                pwm: {'step_true': 0, 'step_false': 0, 'updated': 0, 'status': true}}]
            air_heaters: [
                {   state: true, 
                    entity: climate.ac_livingroom, 
                    priority: 1, 
                    speeds: 3, 
                    integration: ac,
                    cop: [  
                            {t_in: 15, t_out: -15, val: 3.47}, 
                            {t_in: 15, t_out: -10, val: 3.5}, 
                            {t_in: 15, t_out: -5, val: 3.52},
                            {t_in: 15, t_out: 0, val: 3,65},
                            {t_in: 15, t_out: 5, val: 3.88}, 
                            {t_in: 15, t_out: 10, val: 4.11}, 
                            {t_in: 15, t_out: 15, val: 4.41}, 
                            {t_in: 15, t_out: 20, val: 4.77},
                            {t_in: 21, t_out: -15, val: 3.06}, 
                            {t_in: 21, t_out: -10, val: 3.1}, 
                            {t_in: 21, t_out: -5, val: 3.14},
                            {t_in: 21, t_out: 0, val: 3,34},
                            {t_in: 21, t_out: 5, val: 3.53}, 
                            {t_in: 21, t_out: 10, val: 3.82}, 
                            {t_in: 21, t_out: 15, val: 4.12}, 
                            {t_in: 21, t_out: 20, val: 4.38}, 
                            {t_in: 26, t_out: -15, val: 2.47}, 
                            {t_in: 26, t_out: -10, val: 2.61}, 
                            {t_in: 26, t_out: -5, val: 2.74},
                            {t_in: 26, t_out: 0, val: 2.94},
                            {t_in: 26, t_out: 5, val: 3.2}, 
                            {t_in: 26, t_out: 10, val: 3.49}, 
                            {t_in: 26, t_out: 15, val: 3.77}, 
                            {t_in: 26, t_out: 20, val: 4.08}                            
                            ],
                    device_type: hvac, 
                    weight: 1, 
                    pwm: {'step_true': 0, 'step_false': 0, 'updated': 0, 'status': true}
                    }]
            electric_heaters: []
            fans: [{    state: true, 
                        entity: climate.ac_livingroom, 
                        priority: 1, 
                        speeds: 3, 
                        integration: ac, 
                        device_type: hvac, 
                        weight: 1, 
                        pwm: {'step_true': 0, 'step_false': 0, 'updated': 0, 'status': true}}]
            dehumidifiers: [{   state: true, 
                                entity: climate.ac_livingroom, 
                                priority: 1, 
                                speeds: 3,
                                integration: ac, 
                                device_type: hvac, 
                                weight: 1, 
                                pwm: {'step_true': 0, 'step_false': 0, 'updated': 0, 'status': true}}]
            air_conditioners: [{    state: true, 
                                    entity: climate.ac_livingroom, 
                                    priority: 1, 
                                    speeds: 3, 
                                    integration: ac, 
                                    device_type: hvac, 
                                    weight: 1, 
                                    pwm: {'step_true': 0, 'step_false': 0, 'updated': 0, 'status': true}}]
            humidifiers: []
            
            delta_temperature: 0.5
            delta_humidity: 5
# names of the pipes which store the data for temp and humidity            
            set_temp: {'pipe': 'livingroom_climate', 'param': 'temperature'}
            set_humid: {'pipe': 'livingroom_climate', 'param': 'humidity'}

# process_speed - int - how many deltas away from the set value of a parameter climate is tracing - 0,1,2...
#                 0 - process is off
#            process_speed: 0
# circulating loops            
            heat_floors_demand: 0
            heat_floors_loop: variable.engineering_circulating_loop_heatfloors
            radiators_demand: 0
            radiators_loop: variable.engineering_circulating_loop_radiators
# if all speeds are distributed between heatfloors and radiators and still some speeds > 0 are left - these are the excess demand speeds that will form extra request for energy for that room.            
            excess_heat_demand: 0
            front_end_object: front_end_climate_room_livingroom
            front_end_domain: variable            
            front_end_location: tigraresidence_front_end_                       

P.S.2 Is there a limit to the size of a sensor? For some of my sensors I see warnings that their size exids 16kB and attributes will not be stored: State attributes for sensor.nmi_weather_complete_forcast exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored. I guess if it's true, it also may cause problems...

[Snuffy2]

The Attribute size-limit is part of 2023.3:
home-assistant/core#87105

I don't want to exclude all Variables from the Recorder, but as a future enhancement could look into an option to exclude per entity. If you think this would be helpful/the right solution, free free to open a separate Issue so it can be tracked.

Still looking into the possibility of a hybrid integration that supports yaml and config_flow. Will update when I have more.

[jazzyisj]

I worry that the rather unsupported/hacky method that the prior variable integration was created may break at any time.

For this reason I continue to use built in helpers where I can. Really the only instance I actually really require this variable integration is when I need to set the attributes. The replace_attributes option is a very useful tool indeed.

There is nothing stopping y'all from forking the previous version to keep using it as you were prior to v3.0. You could probably even run the forked version and v3.0 side by side!

Not to say that there aren't some very valid points raised here but we all use the integration differently. For me it's slightly comforting knowing it's come more in line with current HASS standards and thus less likely to break unexpectedly. YAML option off the hop may have been nice, but I've converted so c'est la vie!

I do appreciate having this option available to me in the first place, because the core devs certainly aren't interested in developing it.

[pickonedev]

I have an idea, if it not too much what i ask....

Can you make two different variable addons and let people to choose what to use?
One which is the old version 2.3.6 and you just update what is necessary when a new HA version arrive and another version starting with the new implementations from 3.0.0 and so on?
It will be far easier for everyone, maybe there are people which finds the new version more helpful and some which are finding the old version better...

[gribouk]

I have an idea, if it not too much what i ask....

Can you make two different variable addons and let people to choose what to use? One which is the old version 2.3.6 and you just update what is necessary when a new HA version arrive and another version starting with the new implementations from 3.0.0 and so on? It will be far easier for everyone, maybe there are people which finds the new version more helpful and some which are finding the old version better...

Basically, you reiterate my suggestion on how to restore old variables in the new integration - you have to have both running and have a migration service. It could be like this:

1. Call 3.0... Variables+Sensor
2. Install it independently from Variables+History
3. Add migration service from Variables+History => Variables+Sensor in old integration and similar in the new one where you have to specify source variable and target variable as an options.
4. Done!
   But yet the problem is that if old one will not be possible to mantain, you will need YAML fro the new one...
   As a solution for that could be a flag for each variable, YAML or UI mode - true/false. If flag set to true - always YAML, if false - always UI...

[pickonedev]

Yes but I don't say nothing about restoring or anything else which involves using only the new addon
Two different addons, the default old one and the new one. Both updated when is needed

[gribouk]

Yes but I don't say nothing about restoring or anything else which involves using only the new addon Two different addons, the default old one and the new one. Both updated when is needed

You did not say it, bat basically it is what it should be - you need two integrations running at the same time for migration primarily (otherwise just use new one) - one day the old one may become unmantainable and you will need to migrate, no options. But, before this day came, you may continue using 2.6... Actually, you do not need a migration service if both integrations are running - anyone can migrate using simple script. In this sence - yes, running both integrations is enough. But, you need an option of YAML in the new one anyway - because when 2.6 will be gone, you will still need YAML in the new one...

[pickonedev]

For me, the most annoying thing is that all the variables will not have the "variable." prefix... I want to know which entity is variable and which is other, you can't... Then, the UI thing...

[finity69x2]

This is a horrible update for organizational purposes.

Having all of my variables in yaml in their related packages was extremely useful. I could quickly copy/paste an existing variable config multiple times and place it in the related package of where it is used. Now if I need to go thru the UI to to configure a variable and then jump back into the package to configure everything else via yaml it's going to pretty well suck.

Having the "variable" domain was instrumental in knowing how and where the entity was configured.

As mentioned above being able to create a variable (which now isn't a variable any longer - it's now more like a template sensor) without restarting is no big deal for me. It's a once and done thing. I will usually never need to update the entity id and the restore option solved all of the issues with losing the variable state on HA restarts. I really fail to see the benefits of UI only config, etc.

IMHO, this change totally destroyed the usefullness of this integration.

The whole move to "only UI" is misdirected. UI is mostly for beginners. Beginners don't stay that way for long.

And again as mentioned creating potentially complex data structures via the UI is likely impossible or next to it.

I have an integration that was originally in yaml only. Others wanted a config flow option and I was fortunate that another dev was willing to make that happen. But the one requirement before I accepted his PR was to make sure that yaml config was still possible. So maintaining both is possible.

Thanks to Wibias for taking it over and maintaining it after Rogro82 abandoned it but I guess it's time to lock my current version and hope it doesn't stop working in the future. It's a good thing I actually read the change notes for this update before I did it. I usually don't for this one since it's been so reliable. That would have been a not so nice surprise.

Another question tho..

was there a discussion about this upcoming totally breaking change in the forums and I missed it?

[enkama]

I just realeased the new version from @Snuffy2 as a beta release. Feel free to try it.
If you are not sure how to enable beta releases:

HACS --> Integrations --> Variables+History --> Three Dots in the upper right corner --> Redownload --> Show beta versions

Then you can select it by yourself in the version selector or it will show up in the HACS Dashboard

[pickonedev]

@Snuffy2 or @Wibias , can you please tell me if there is any plan to have two different addons, one as a new one (with sensors) and one with variables (like the old version) ? Or at least a change in the future for the new addon, which will make it more like the old version? with "variable." entities and config from yaml?

I just want to know if I need to wait or I should find another similar addon.

Thank you!

[gribouk]

@Snuffy2 or @Wibias , can you please tell me if there is any plan to have two different addons, one as a new one (with sensors) and one with variables (like the old version) ? Or at least a change in the future for the new addon, which will make it more like the old version? with "variable." entities and config from yaml?

I just want to know if I need to wait or I should find another similar addon.

Thank you!

Relex and enjoy life. Some reading for you to calm down:

Variables is an integration (not add-on) which is designed to implement complex data structures, which in it's turn enable to implement full scale functional programming (no kidding, I've done it) with Jinja templating. I was using it intensivelly for integration prototyping - this is when you want to try if your idea works or not and do a sample integration instead of proper one in Python - it works great.
After these events I've decided to rework my sample integration prototypes into Python (I had no experience with this specific lenguage, therefore I was with variables for so long...). As a part of my studdy of HA backend and API I've looked into potential hazards for the future of the variables. and from what I can see, it's not very likely that something drastic would happed to make it unmantainable - I know how and why it works and where variable. turns possible. Anything might happen, but as I see you can use the version with variable. for quite a while without any threats. If some minor updare would be needed - you can do it youreself - most of the mantainance was about changing manifest file up to the standards, once it was about updating API of HA and once about removal of from_json conversion - in 5 years...
Conclusion: use it as before and ignore the updates if you do not want to move to sensors, if see warnings in the logs, most likely you will manage to mantain it yourself, do not worry, enjoy life!

[enkama]

Will close this for now!