rhammen
commented
7 months ago I'm not sure implementing this is really worth the effort, for a one-off conversion, of parameters that are used by one or maybe a couple of users. So far we have had several request of users who needed additional parameters. Those have been implemented without much discussion about keeping historical values. Main question is whether there are still many other parameters that users have added manually, and that are not yet implemented. If there are only a small amount, manually implementing them like we did so far could work well. My guess would be that at this stage, time spent on manually implementation of some additional sensors (on user requests) would be less work than writing an automated detection and conversion routine. (And users would still have to make changes to dashboards). Do others feel the same or do you think writing an automatic conversion utility would be simple and less time-consuming?
The YAML config is not provided > 2023.03.24 It would be worthwhile to implement a migration that searches the YAML configs (luxtronik <- Bouni and luxtronik2) and migrates the sensors to the new ones. This would preserve the history and activate the sensor automatically. However, the ID will change and the user will have to manually adjust their links in LoveLace and automation.