I’ve made a change to the Landis+Gyr Heat Meter integration that will allow reading either MWh or GJ, whichever is available from the API. I want the entity that is unavailable to be hidden or deleted from the registry.
I’m wondering what a suitable way and place would be to do this. I’d prefer not to setup the entity at all (in async_setup_entry), but that’s not possible because there is no polling on reboot and I don’t have data at that point. Therefore I’ll have to wait until after an update. But if I do that, the entity will just be created again after reboot.
I could make it an entry configuration setting and add the entry configuration after the api update, but I’m not sure this is the way to go. Also I’m having trouble accessing the registry from that context.
I haven’t been able to find other integration dealing with this situation.
Nice suggestion! It just feels very wrong to change the unit of a variable. Although for new installations this will not be such an issue. For existing installations statistics will be messed up… Any suggestions on that part?
About polling the device on initialisation: it’s a battery powered device (at least some), therefore I’ve chosen not to poll on reboot/initialisation and instead restore saved sensor variables.
If you change the units HA will allow you to update units of history. I discovered this as making a gas meter sensor that i then changed from kwh to m3. Not 100% sure if it converts or just changes uom. Shows as an isue in developer stats which then asks if you want to change. Is changing these units something that would happen often? In any case, if you have 2 entities and change units, the old not available one will have the history.
I wouldnt think an extra poll on reboot would be too much of a battery drain especially as it will wait another day to poll again and if they are rebooting multiple times every day something is wrong with that.
Yeah, polling on reboot would make things easier. For me: I reboot all the time, since changing anything in the configuration or custom components require reboots. But, perhaps in the big picture it’s still not a problem. I’ll consider it some more…