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!
i have problems with the name of the machines:
it doesnât like the â-â ?
How can i solve this?
ps. I love this component!
What do you mean it doesnât like the â-â? What behavior are you getting and what are you expecting?
Thereâs a very specific format that you must use when attempting to pull data from a VM whose hostname contains a dash. Notice the enclosing brackets and apostrophe surrouding vm-hostname in the example below. If you do not enclose the hostname of your VM in that fashion, the result is what you are seeing now.
${states['sensor.esxi_stats_vms'].attributes['vm-hostname'].uptime_hours}
That being said, you may want to wait until the next version is released since VMs will become their own entities and therefore, the above method will no longer be necessary.
@wxt9861 - I meant to report this a few days ago but got distracted with the beta and completely forgot. Considering the upcoming changes, I donât know if itâs even worth updating the documentation since youâll likely just remove those examples anyway.