Make the temperature preset persistent entities

[jmcollin78]

Changing a temperature preset should be simplier.

We could add some entities as domain number which can be changed easily in the VTherm and can be directly set into dabshboard.

Then we can remove the configuration presets which will simplify the configuration. As a general way, keep configuration which change rarely into the configuration panel and add persistent configuration entities for each parameters which can be modified. Target temperature is the good example.

[jmcollin78]

Be careful to the migration: how to keep the configured values.

Should we remove the central configuration for preset temperature as well ? Or just init the values of the new entities with the central configuration values ? Then we lost the diffusion of changing a central configuration to all VTherm.

[gunmalmg]

This would be awesome 👏 I think your suggestion is really good. Create Presets as Entities under the VT Device. For the "migration: how to keep the configured values" I think your suggestion is good : Fill the new preset entities with the preset values from the Configuration/central configuration - and then remove the presets from the Configuration. From that on - we will change the presets in the UI by changing the preset-entities. 👍

[jmcollin78]

Thank you for your feedback, I was pretty sure, you will be interested 😉

[HACS-bank]

If it is easier during migration to leave the config in place, then perhaps the config values become "initial value" used until someone changed them.

This might allow newly defined VTherms to have a value before the user defines a UI for changing values, and covers the scenario where a VTherm exists without a UI.

[gunmalmg]

I'm really looking forward to this enhancement :-)

I'm planning a UI like this as i short list for all my climate entities on each floor(and one for the whole house). I have many climate entities and I need a place to get quick glance over them all. Its not usable to have to maneuver through many "room" cards for this.
In this way I can get a quick glance over the temperatures and preset-states of every entity. And the ability to quickly change preset-mode on many entities.

And when you have made the preset-temperatures an alterable entity in the UI, I will be able to enhance my “card” with a “Hold-action” over the preset-mode buttons to let the user alter the preset temps right there. That is a user-friendly UI :-) I think. 👍

[maia]

I'm planning a UI like this as i short list for all my climate entities on each floor(and one for the whole house). I have many climate entities and I need a place to get quick glance over them all. Its not usable to have to maneuver through many "room" cards for this. In this way I can get a quick glance over the temperatures and preset-states of every entity. And the ability to quickly change preset-mode on many entities.

Oh that's great, can you please share how you managed to create that UI? I was trying a super-compact layout as well but gave up. This here is what I managed using multiple-entity-row, but the icons did not change state depending on the selected preset, and that was rather unusable.

[jmcollin78]

@gunmalmg

I love your card and the compacity. Maybe an idea for a future UI card given out of the box by the VersatileThermostat UI Card. I will keep that in my TODO list, if you agree with that.

https://github.com/jmcollin78/versatile-thermostat-ui-card/issues/27

[jmcollin78]

On the development of this feature itself, it is finally very complex and I'm running into race conditions:

1. temp entities should be initialized before VTherm climate (because VTherm need them),
2. but temp entities itself relies on VTherm configuration itself (to see if central configuration is used),
3. When central configuration is used, the Central VTherm should be initialized before all others.

So it is a nightmare to have all initialized depending on all configuration options. 😮‍💨

[gunmalmg]

@gunmalmg

I love your card and the compacity. Maybe an idea for a future UI card given out of the box by the VersatileThermostat UI Card. I will keep that in my TODO list, if you agree with that.

jmcollin78/versatile-thermostat-ui-card#27

That's fine with me. Just happy to contribute 😀

[gunmalmg]

On the development of this feature itself, it is finally very complex and I'm running into race conditions:

1. temp entities should be initialized before VTherm climate (because VTherm need them),
2. but temp entities itself relies on VTherm configuration itself (to see if central configuration is used),
3. When central configuration is used, the Central VTherm should be initialized before all others.

So it is a nightmare to have all initialized depending on all configuration options. 😮‍💨

I sense that you may have painted yourself into a corner with the central-config system. As it seems from your bullet list. 😜 It seems that it may have to be resolved with another perspective. 🤔 I may not see the whole picture regarding all the underlaying considerations, but what if :

When a user upgrades the VT-system (with the new preset-temp entities release). You make(generates) preset-temp entities for the already configured VT-devices, and preloads them with the temp values from the existing VT-config. Then you remove the temp preset-values from the VT-config-interface, for the already defined VT's(the real ones - not the central-config).
You may be able to keep the central-config with temp preset-values that still can be used as default-values for new configuration of VT-thermostats with generated preset-temp entities. But you should not keep preset-temp settings in both the VT-config(the real ones - not the central-config) and the new Preset-temp entities at the same time. That would be hard to manage.

The new solution with preset-temp entities would open many new possibilities regarding altering many presets at one time(that I sense is one of the benefits with the central-config). Users can e.g make an easy script that alters all the preset-entities for vt-Thermostats in e.g certain areas or all of them at ones. This gives the users the possibility to take control of this themselves - not depending on you in all this (take some of the burden off you :-)

Does this give any meaning ? Regards Gunnar

[jmcollin78]

Thank you @gunmalmg for your tips. That is aproximatively what I'm trying to do to keep as much as possible the current behavior:

• i keep central configuration temp but transform them as number entities so that they can be used directly by VTherm if central configuration is used. If someone change the central config temp entity, this will change all VTherm configured with central.
• a VTherm which doesn't rely on the central configuration will have its own number temperature entities so that it can be changed alone without having impact or the others.

My concern was much about the startup dependencies but I found something to deal with that.

[jmcollin78]

Hello, I have developed this improvement. It is available here for testing in a real environment: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.0.0.alpha1

Caution it may contains bug because it has made many important changes and refactoring. If you can test in // of me, it could be great.

Please use this discussion if more information are needed: https://github.com/jmcollin78/versatile_thermostat/discussions/404

[gunmalmg]

Exiting

I'll test it. But it will take some days - before I have the time. :-)

Med vennlig hilsen Horisont Eiendom AS https://tingsakertorv.no/horisont-eiendom / Lillesand Senter http://lillesandsenter.no / Agder Helsepark https://tingsakertorv.no/forside-helse / Tingsaker Torv https://tingsakertorv.no/om-tingsaker-torv / Horisont Utvikling https://tingsakertorv.no/om-tingsaker-torv

Gunnar Malmgård Tlf: 91686522, @.*** Senterveien 30, 4790 Lillesand

søn. 10. mars 2024 kl. 19:09 skrev Jean-Marc Collin < @.***>:

Hello, I have developed this improvement. It is available here for testing in a real environment: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.0.0.alpha1

Caution it may contains bug because it has made many important changes and refactoring. If you can test in // of me, it could be great.

— Reply to this email directly, view it on GitHub https://github.com/jmcollin78/versatile_thermostat/issues/354#issuecomment-1987313882, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6ULHFZYTVWFXLXZ7VL6VDDYXSOXDAVCNFSM6AAAAABCD2EUJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGMYTGOBYGI . You are receiving this because you were mentioned.Message ID: @.***>

[gunmalmg]

Hallo Thank you for your effort on making this improvement.

The transition to present-temp entities seems to function well on my installation. (I don't use the central config) and I have not noticed any difference in base function of the vt_thermostat.

It is really nice to play with the possibilities thees UI exposed present-entities now gives. Based on my first «playing around» - I have thees two suggestions :

1. Regarding the preset Entities ID’s name, I think it could be beneficial to add «preset». Now it generates e.g the entityID like this : «number.vt_bath_comfort_away_temp». But I would suggest «number.vt_bath_preset_comfort_away_temp» I see a potential in using the phrase «preset» as a filter opportunity in e.g an auto-entities card.

2. When the preset number entities are generated, the numbers «Display mode» seams to be set to «input field». But I would suggest «slider». This will give a slider instead of an input number field in the UI for entity- and entities- cards. This would also give the slider on «more-info»card. In UI - often used on smartphones and tablets - the slider is a more user friendly and intuitive way to alter a number than going over to «keyboard» to type a number.

Regards Gunnar 👏👏

[gunmalmg]

Here is some examples of me playing around with UI possibilities :

https://github.com/jmcollin78/versatile_thermostat/assets/128496535/e6340ae2-433e-4b50-bd1a-e6895c81aa06

https://github.com/jmcollin78/versatile_thermostat/assets/128496535/459690d8-c80d-4969-b882-c72cea5b2d62

This is done by utilizing the more-info action.

[jmcollin78]

Thank you @gunmalmg for your valuable feedback. I will see what I take for the release (this week-end), all is working fine on my side also.

[jmcollin78]

https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.0.0

@gunmalmg I have rename the entities with preset. I don't have change the Number UI form to slider. My tries with a mobile device was not conclusive. The slider is very difficult to use. So I keep it like that and you can always long click on the entity to get the full configuration window.

[systempal]

Is it possible to add a step attribute to the number entity? This way, a slider could control the preset in increments of 0.5 or 0.1, for example.

[gunmalmg]

It's already there