Yes! This would be AWESOME!
Component just stopped to work for me… On description page I can see some information about issue wqith v4 and above if installed via HACS:
- Due to addition of licenses sensor, the platform will fail to load after the reboot.
- To fix - 1. restart Home Assistant 2. remove and re-add the integration from the Integrations UI
I followed these steps, but no change… all of sensors are unavailable. Any idea how to fix this?
Enable debug and open an issue case with the debug information on the github page. https://github.com/wxt9861/esxi_stats/issues
Done with some additional support information.
Solved! I added step to uninstall and install again from HACS before removing/adding via integration UI and it properly started this time. Perhaps installation got somehow corrupted during recovery from SD crash that I have few days ago…
1 Like
0.5.0beta is available. If you can, please test and provide feedback.
Changes here are:
- All objects (hosts, datastores, licenses, vms) have been broken out into their own sensors. So instead of 4 sensors you will now have many sensors.
- You can control what is being show as a state of the sensors. For example, you can set your VM sensors to show their CPU Usage % as the state. And if you decide later to show uptime, you can change that at any time.
- This is only available if you’re using Integrations UI to configure the platform. If you’re using yaml mode, you’re stuck with the defaults
- This can be accessed by going to the ESXi Stats configurion UI page and clicking on the gears icon in the upper right corner
- Initially default values are entered, but you can change them to be any attribute available in a sensor
- Minimum version of HA required to run this release is 0.98 (because of 2nd bullet point)
Some of the things that still need work:
- If the platform pulls data for a new object (ex. you add a new datastore), the sensor for that new object will now show up until hass is restarted.
- Sensors are trying to show a graph, instead of a history bar, when there are no numerical values to show. I think this has to do with device class and unit_of_measurement but I am not 100% certain
Any help to point me in the right direction for these issues would be appreciated.
1 Like
Awesome work!! I’ll have to update my HA before I can test, but I’ll try to this week!
Some initial feedback.
Upgrading to the beta was painless through HACS but my pre-existing integration did not like the new version. All kinds of errors popped up in the home-assistant.log and the pre-existing functionality ceased. To fix the issue, I simply blew away the integration and re-added it. After that, all of the sensors were added as expected.
One initial observation is that the switches and network_adapters attributes for the VM Host have their own nested data (See example below). You might want to consider breaking these out into their own sensors as well, while you are at it. My example may not be very elaborate, but others may have more intricacies.
I’ll try to play around with this once I’m home later tonight and see what else I can accomplish with the new functionality. Still, this new functionality is very exciting!
switches: {
"vSwitch0": [
"VM Network",
"ISCSI-B",
"Management Network"
]
}
network_adapters: {
"vmnic0": 1000,
"vmnic32": 1000
}
@wxt9861 - I just realized that datastores are no longer reporting the free_space_gb key pair, only total_space_gb.
More reports as time (and my three year old) allow. 
Successfully updated to HA 0.99.0 and updated esxi_stats to 0.5.0beta. I also changed from using configuration.yaml mode to integrations mode. I can see 1 sensor per host, datastore, and VM. I was expecting each of the attributes to be their own sensor so I wouldn’t have to create custom sensors for each. I’ll keep looking for a good way to display the attributes for each sensor.
Awesome work though! This kind of stuff is what makes HA so awesome!
Having a unique entity for each attribute would be excessive. Each VM would consist of 10-12 different entities. The thought of that gives me a headache.
Thanks for the feedback! I should’ve been more clear - there are breaking changes here that will require to remove/re-add the integration from the integrations UI.
@daphatty
You’re not seeing the database show free space as the state? I set it up to hide an attribute for a key that is configured as a state (for databases the default is free_space_gb), because that’s displaying the same information twice. So in this case, that key is displayed as a state, like in the screenshot.
For the NIC and switch info, i am not really sure what I want to do with this and if its worth keeping.
vSwitch - I can’t think why to show it, generally you setup your vswitch and forget it. Maybe there is something of interest to show if you have a distributed switch, but I don’t run a vcenter at this time, so I can’t really make that work. And if there is something of interest, it should get its own sensor, anyway.
Network adapters - the idea is to notify when a network adapter fails or becomes disconnected. But current implementation doesn’t allow for that. Instead, I am thinking it might be a better idea to watch for host events that are generated when an adapter goes down/comes back up and use those events to send notification.
@kryt1kal I definitely don’t want to go that route, as that would create way too many sensors. Instead, a lovelace card that presents all that information would be a an ideal solution. And it could possibly allow you to run services directly from that card.
My apologies. In my haste to report my findings I failed to be specific enough.
To clarify, the free_space_gb key pair is no longer being presented as its own attribute under Developer Tools -> States, likely because the value is being assigned as the primary value for the entity itself. As you can see in the screenshot below, free_space_gb no longer appears in the list of available attributes., even though the value is shown in the center column as the primary entity statistic. In this instance, the free_space_gb key pair is obfuscated by the functionality of assigning a key pair as primary attribute to the entity.
I didn’t realize the value was still available until you pointed it out in your screenshot above.
Yep, that was by design. Any key that you set as the state is hidden as an attribute. By default I set free_space_gb key as the state, so it is hidden. But if you change the state key to be connected_hosts, than connected_hosts will be hidden from attributes view, but free_space_gb will show up in its place.
Like this:
I can definitely add it back and it would display the information twice. In the Tools > States and the pop-up.
Like this:
I’d say keeping the attribute visible despite being listed twice is a better option, if for no other reason than remaining consistent with the way Home Assistant presents attributes. It appears to be more difficult to retrieve the value of the primary attribute, in my case free_space_gb, via a template. Although in hindsight, I’m not entirely certain whether or not that is intended.
Should this method of retrieving the attribute value still work if the attribute itself has been set as the primary? {{ states['<entity_id>'].attributes.free_space_gb }}
In that case you would pull it directly from the state.
Using the datastore from my last screenshot, it would be like this.
{{ states.sensor.esxi_datastore_system.state }}
If we keep the data available in both places (state and attribute), you can do it using multiple ways
Keeping the data available in both places might be the right way to go. According to the Template docs, the use of states.sensor.esxi_datastore_system.state is specifically called out as a method that should be avoided due to potential errors. (See the warning section under States.)
I’ll read up on this in more detail and revisit it later.
For now, the next beta should have support for multiple hosts
2 Likes
HELL YES!!!
You’ve done some awesome work with this component!
Thank you!