Add attribute with active underlyings for easier tracking and setup #658
Conversation
|
Hello @s256 This is great idea and very helpful. Thank you for this. |
| self._attr_active_device_names = [] # Holds the names of active devices | ||
|
|
||
| @property | ||
| def extra_state_attributes(self) -> dict: |
There was a problem hiding this comment.
Add the active_device_names into the list of _entity_component_unrecorded_attributes so that it will not be persisted and save place on the hard drive.
See base_thermostat.py at line 32 to have an exemple.
There was a problem hiding this comment.
Thank you for your feedback! Happy to adapt it :)
But I am not sure if I can follow. L32 doesnt look right as an example.
Generally yes: we don't want to persist this on the hard drive.
My code extends the general configuration.
So I was now looking to the list of _entity_component_unrecorded_attributes which is assigned to the central configuration.
But all _entity_component_unrecorded_attributes I could find are assigned to either the base thermostat (which hands down basic attributes and entities to all other climate entities) or the actual thermostats.
(I am not a dev, so chances are pretty high, I don't understand the code ;) ) sorry :/
|
Hello @s256 , I have terminated some big changes. Can you please rebase you modifications so that I will be able to integrate it for the next release ? |
* With Sonoff configuration ok * Fix configuration * Next (not finished) * With 1rst implementation of VTherm TRVZB and underlying * Work in simuated environment * Fix Testus * Release * Fix release name * Add jmcollin78#602 - implement a max_on_percent setting * Calculate offset_calibration as room_temp - local_temp Fix hvac_action calculation * Fix hvac_action Fix offset_calibration=room_temp - (local_temp - current_offset) * Fix underlying target is not updated * Issue jmcollin78#655 - combine motion and presence * Fix Valve testus. Improve sending the open percent to valve * Update custom_components/versatile_thermostat/translations/en.json Co-authored-by: Alexander Dransfield <[email protected]> * Indus step1 * Step 2 - renaming. All tests ok * Step 2: manual tests ok * First unit test ok * Test multi ok * All tests ok. Add a multi test for climate with valve regulation * With testu for config_flow ok * Documentation (not finished) * Fix jmcollin78#661 - central boiler doesn't starts with Sonoff TRVZB * Remove // testing * Fix exception when there is no offset at all * Fix class attributes and instance attributes mixing * Documentation 2 * Documentation 3 * Documentation ++ * documentation * Try to fix the central boiler calculation * Fix jmcollin78#669 * Documentation ++ * Documentation ok for FR * Readme FR|EN --------- Co-authored-by: Jean-Marc Collin <[email protected]> Co-authored-by: Alexander Dransfield <[email protected]>
|
it's rebased. But I still haven't found place to add this attribute to |
Hi everyone,
I discovered this project with the plan to improve my heating setup. I used schedy before and am now looking for an alternative.
Setting up
versatile_thermostatwas pretty easy. Not super straight forward with all the options, but obviously a lot more sophisticated compared to what I had before.So I have a central unit (boiler) which needs to be activated by the TRVs(Climate entities) when necessary.
One thing I struggled with, was to determine which Climate Entity was keeping the Boiler going, as the plan is to only have it running, when necessary. So I thought about listing the underlyings which activate the boiler in an attribute in the existing sensor. From a user-perspective, I preferred this instead of a dedicated sensor.
Let me know what you think about this.