I want to send a discovery message to HA from an addon but I can’t find any documentation on it apart from this
Is this the right endpoint?
Is there any documentation on, or an example of, what the config dictionary should contain?
I’m familiar with mqtt discovery but clearly the http api doesn’t have a state topic.
I have worked out how to set a state using the supervisor/core/api/states/ endpoint - I just need the discovery.
Thanks
Not sure what you mean by “http discovery”.
There is no http equivalent to the MQTT discovery. Integrations implement the discovery of the entities they manage.
That’s a shame
That’s what I’m trying to achieve - any pointers?
I had hoped this would be it in this api endpoint:
But I can’t find any docs on the structure of "config"
On reflection ESPHome devices announce themselves with sensors - maybe there’s a clue on Github…
What are you trying to achieve, exactly?
What addon is it about? A brand new of your own?
Mostly, addons go hand-in-hand with a custom integration, which will “discover” your entities…
Have a look at the developer doc to get insight
Home Assistant Core | Home Assistant Developer Docs (home-assistant.io)
Yes
It will contain a single device and several sensors
Sensor states will be posted to HA routinely.
I had a look at the ESPHome Github and got nowhere.
However I had a look in the settings->devices and had a look at one of my ESPHome devices.
I downloaded the diagnostics data and found this
{
"home_assistant": {
[blah blah]
},
"custom_components": {
[blah blah]
},
"integration_manifest": {
"domain": "esphome",
"name": "ESPHome",
"after_dependencies": [
"zeroconf",
"tag"
],
"codeowners": [
"@OttoWinter",
"@jesserockz",
"@kbx81",
"@bdraco"
],
"config_flow": true,
"dependencies": [
"assist_pipeline",
"bluetooth"
],
"dhcp": [
{
"registered_devices": true
}
],
"documentation": "https://www.home-assistant.io/integrations/esphome",
"integration_type": "device",
"iot_class": "local_push",
"loggers": [
"aioesphomeapi",
"noiseprotocol"
],
"requirements": [
"aioesphomeapi==19.2.1",
"bluetooth-data-tools==1.15.0",
"esphome-dashboard-api==1.2.3"
],
"zeroconf": [
"_esphomelib._tcp.local."
],
"is_built_in": true
},
"data": {
"config": {
"entry_id": "b73029e1626dea36053bd4d0b35879d6",
"version": 1,
"domain": "esphome",
"title": "solar-relay-box",
"data": {
"host": "192.168.1.63",
"port": 6053,
"password": "",
"noise_psk": "**REDACTED**",
"device_name": "solar-relay-box"
},
"options": {},
"pref_disable_new_entities": false,
"pref_disable_polling": false,
"source": "zeroconf",
"unique_id": "**REDACTED**",
"disabled_by": null
},
"storage_data": {
"device_info": {
"uses_password": false,
"name": "solar-relay-box",
"friendly_name": "Solar Relay Box",
"mac_address": "**REDACTED**",
"compilation_time": "Oct 10 2023, 14:46:26",
"model": "esp12e",
"manufacturer": "Espressif",
"has_deep_sleep": false,
"esphome_version": "2023.8.3",
"project_name": "",
"project_version": "",
"webserver_port": 0,
"voice_assistant_version": 0,
"legacy_bluetooth_proxy_version": 0,
"bluetooth_proxy_feature_flags": 0,
"suggested_area": ""
},
"services": [],
"api_version": {
"major": 1,
"minor": 9
},
"sensor": [
{
"object_id": "solar_tank_temperature",
"key": 2719621008,
"name": "Solar Tank Temperature",
"unique_id": "dallas-da0416a4c6beff28",
"disabled_by_default": false,
"icon": "",
"entity_category": 0,
"device_class": "temperature",
"unit_of_measurement": "\u00b0C",
"accuracy_decimals": 1,
"force_update": false,
"state_class": 1,
"last_reset_type": 0
},
{
"object_id": "wifi_signal_db",
"key": 1535411390,
"name": "WiFi Signal dB",
"unique_id": "e868e7d206f1-wifisignal",
"disabled_by_default": false,
"icon": "",
"entity_category": 2,
"device_class": "signal_strength",
"unit_of_measurement": "dBm",
"accuracy_decimals": 0,
"force_update": false,
"state_class": 1,
"last_reset_type": 0
}
],
"text_sensor": [],
"switch": [
{
"object_id": "dhw_pump_override_relay",
"key": 815455542,
"name": "DHW Pump Override Relay",
"unique_id": "solar-relay-boxswitchdhw_pump_override_relay",
"disabled_by_default": false,
"icon": "mdi:solar-power-variant",
"entity_category": 0,
"assumed_state": false,
"device_class": ""
}
]
},
"dashboard": "5c53de3b_esphome"
}
}
The data->storage_data->sensor array looks interesting as it specifies the sensors.
I suspect this came directly from the ESPHome device, possibly from the discovery api endpoint.
I might play around with structures like this using the discovery api endpoint
Once again, what are you trying to achieve?
Addons do not “post to HA routinely”. HA addons are ad-hoc docker container encapsulating 3rd party software (think Mosquitto MQTT, tailscale, SSH) for usage inside HAOS. They don’t “contain a single device and several sensors”.
Those typically need an integration for, well, integration within HA.
Integrations are piece of python software, typically installed through HACS, and working whatever the HA installation type.
Would you be confused between addons and integrations
Sorry if I’m being confusing/frustrating. [I did use `Sensor` when I meant `Entity`]
I’m developing an addon - definitely an addon - its has a Dockerfile etc and sits in /addons. It will need to post/send/whatever numeric measurement states to HA where they will be used as entitiy states.
I could do this via mqtt but I want to move away from this dependency if I can communicate directly with HA through the apis
It’s very like hdd-tools but I want to overcome the setup problems that has.
[you need to add template sensors to configuration.yaml and there’s no unique id to allow editing because the supervisor/core/api/states/ endpoint does not support unique_id]
That addon DOES post a state and its attributes routinely to HA without mqtt by using the supervisor/core/api/states/ endpoint.
I have written addons in the past which expose themselves for discovery through mqtt (whereby HA creates a [mqtt] device with several entities) AND post states routinely to HA through mqtt.
I could write my new addon to use mqtt but I want to move away from that dependency if I can.
What I think I’m picking up is that you believe I can’t have an addon which posts something to to HA that will create a device and its entities without using mqtt.
If that’s true what is the /discovery api end point for?
That endpoint is to tell the HA integration for a service that it can be used.
That addon creates sensors on-the-fly directly in HA, without going through a discovery step. You don’t have to use template sensor for those, but you’ll likely not have unique id’s indeed.
For sure, the supervisor API won’t help you on this. It’s purely for the supervisor.
HA uses REST API | Home Assistant Developer Docs, as you know.
So, bottom-line:
If unique ids are needed, you will have to create a dedicated integration that will talk to your addon, or indeed use template entities as a workaround.
EDIT: BTW, you don’t say why you need an addon in the first place, i.e. what that addon do that you cannot do in plain python.