(For example, I have some Shelly scripts that increment a counter based on impulses that come from a water meter, hence the number in KVS is actually the collected consumption value.)
This feature is more widely supported than Virtual Components, which are only Gen3 and Gen2 Pro currently.
It would be great to expose these values as entities on Shelly devices.
I don’t need write access, simply making them available as sensor values would be sufficient.
It’s a bit tricky that the KVS is dynamic, so keys can appear / disappear randomly.
I think we don’t have to be super dynamic here: it would be sufficient to collect the list of keys at configuration time, and create the necessary sensor entities based on them.
(If we want to add more values, we can just reconfigure the device.)
Of course, as an alternative, I could just implement the counter independently of the device, inside Home Assistant, and increase it in automations, but having it right inside the physical device is way more robust, considering random WiFi outages etc.
HA 2024.8 supports Shelly virtual components and this is a right way to pass data from Shelly scripts to HA or from HA to Shelly scripts.
KVS is data storage. We don’t know what the user will put there and creating HA entities for all the values that will be there is a bad idea in my opinion.
HA 2024.8 supports Shelly virtual components and this is a right way to pass data from Shelly scripts to HA or from HA to Shelly scripts.
Virtual Components are available only for Gen3 and Gen2 Pro* devices.
I have 82 devices, and only 2 or 3 or them are Gen3. Most is Gen2
So, Virtual Components are not a real alternative for me (and anybody else who has Gen2 devices, not Gen3 or Gen2 Pro)
KVS is data storage. We don’t know what the user will put there and creating HA entities for all the values that will be there is a bad idea in my opinion.
Indeed. In that case, it would be nice to selectively create sensors only from the values the user selects. But requires some kind if configuration. (Maybe a single input field, where I can list the keys in a comma-separated list?)
I suggested creating sensors from everything because it’s less work than creating the configuration UI. Useless sensors can still be disabled. Indeed, they can be created disabled by the integration, and the user can just enable the ones he wants…
All in all, I still think it would be nice. (And it would certainly solve my use case.)
I think we should ask Shelly why Gen2 Plus devices don’t support virtual components. Is the reason a real technical limitation?
We don’t know what type of data we’re dealing with (string, int, float, list, dict) in KVS, we don’t know if it’s a numeric value should it have a unit or not, we don’t know anything. Generating entities automatically for every value is a bad idea. The result would definitely be not very user friendly.
Personally, I think we shouldn’t implement every feature just because it’s possible. We should implement a feature that brings real value, is safe and user friendly.