{"id":12956,"date":"2026-09-10T07:35:00","date_gmt":"2026-09-10T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12956"},"modified":"2026-09-09T13:24:05","modified_gmt":"2026-09-09T11:24:05","slug":"tutorial-publishing-an-mqtt-discovery-payload-that-reaches-the-energy-dashboard","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/smart-home\/tutorials-en-smart-home\/tutorial-publishing-an-mqtt-discovery-payload-that-reaches-the-energy-dashboard\/","title":{"rendered":"Tutorial: Publishing an MQTT Discovery Payload That Reaches the Energy Dashboard"},"content":{"rendered":"

A device that announces itself over MQTT does so with a single message. It lands on a topic Home Assistant is already listening to, it carries JSON, and it has to be retained – otherwise it exists only until the next restart of either side.<\/p>\n

Creating an entity that way is a matter of six lines. Getting that entity accepted as an energy source is a matter of three more, and those three are where the work actually sits: each of them is silently ignored when it is wrong, and the symptom is always the same empty dropdown.<\/p>\n

\n\"A
The entity appears as soon as the payload is valid JSON. The three highlighted fields decide something else: whether it can also be picked as an energy source.<\/figcaption><\/figure>\n

The Topic Decides Where the Entity Appears<\/h2>\n

Discovery works over a topic pattern rather than a registration call. Home Assistant subscribes to a prefix, and everything published beneath it in the right shape becomes an entity.<\/p>\n

homeassistant\/sensor\/kellerzaehler\/energie\/config\n      \u2502          \u2502         \u2502           \u2502\n   prefix     component  node_id    object_id<\/code><\/pre>\n
The prefix is homeassistant<\/code> unless it was changed in the MQTT integration. The component decides the entity type and has to match what the payload describes – a sensor<\/code> for a reading, a binary_sensor<\/code> for a yes-or-no state, a switch<\/code> for something that can be commanded.<\/p>\n
Node ID and object ID are free text and serve only to keep the topic unique. They are not the entity ID: that one is built from the name later, and changing the topic afterwards creates a second entity rather than renaming the first.<\/p>\n
The Smallest Payload That Actually Works<\/h2>\n
Four keys are enough for an entity to exist. A name, the topic the readings arrive on, a unit, and an identifier that stays stable across restarts.<\/p>\n
{\n  \"name\": \"Cellar meter\",\n  \"state_topic\": \"haus\/keller\/zaehler\",\n  \"unit_of_measurement\": \"kWh\",\n  \"unique_id\": \"kellerzaehler_energie\"\n}<\/code><\/pre>\n
Of those four, unique_id<\/code> is the one worth insisting on. Without it the entity shows up but cannot be renamed, cannot be assigned to an area, and cannot be selected in the Energy dashboard at all. It has to be unique across the whole installation, which is why the topic segments make a good basis for it.<\/p>\n
A device<\/code> block is optional and pays for itself immediately: entities that share the same identifier are grouped under one device, and one device with eight readings is far easier to live with than eight loose entities.<\/p>\n
  \"device\": {\n    \"identifiers\": [\"kellerzaehler\"],\n    \"name\": \"Cellar meter\",\n    \"manufacturer\": \"Eastron\",\n    \"model\": \"SDM630\"\n  }<\/code><\/pre>\n
The Three Fields the Energy Dashboard Reads<\/h2>\n
An entity with a number in it is still not an energy source. Three fields have to agree before it turns up in the selection list, and all three describe something different.<\/p>\n\n\n\n\n\n\n\n
Field<\/th>\nRequired value<\/th>\nWhat it says<\/th>\n<\/tr>\n<\/thead>\n
device_class<\/td>\nenergy<\/td>\nThe number is an amount of energy, not a power<\/td>\n<\/tr>\n
unit_of_measurement<\/td>\nWh, kWh, MJ or GJ<\/td>\nThe unit that amount is counted in<\/td>\n<\/tr>\n
state_class<\/td>\ntotal_increasing<\/td>\nThe value only ever counts upwards<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The most frequent mismatch is between the first two. A meter reporting watts is a power sensor: device_class<\/code> power, state_class<\/code> measurement, unit W. That sensor is useful and correct, and it will never appear as an energy source, because power is not energy. What the Energy dashboard wants is the counter that adds up.<\/p>\n
The third field is the one that decides how a meter reset is handled. With total_increasing<\/code>, a value that suddenly drops is read as a new counting cycle rather than as negative consumption, and the statistics carry on. With total<\/code>, the same drop needs a last_reset<\/code> timestamp to be interpreted, and without it the hour in question becomes a spike. For a physical meter that runs forwards and occasionally starts over, total_increasing<\/code> is the honest choice.<\/p>\n
Publishing It by Hand<\/h2>\n
Nothing about this needs a device. A single command creates the entity, and the same command with different content updates it.<\/p>\n
mosquitto_pub -h 192.168.1.10 -u ha -P geheim -r \\\n  -t \"homeassistant\/sensor\/kellerzaehler\/energie\/config\" \\\n  -m '{\n    \"name\": \"Cellar meter\",\n    \"state_topic\": \"haus\/keller\/zaehler\",\n    \"unit_of_measurement\": \"kWh\",\n    \"device_class\": \"energy\",\n    \"state_class\": \"total_increasing\",\n    \"unique_id\": \"kellerzaehler_energie\",\n    \"device\": { \"identifiers\": [\"kellerzaehler\"], \"name\": \"Cellar meter\" }\n  }'\n\nmosquitto_pub -h 192.168.1.10 -u ha -P geheim -r \\\n  -t \"haus\/keller\/zaehler\" -m \"18234.7\"<\/code><\/pre>\n
The -r<\/code> flag is the part that gets forgotten, and it belongs on both messages for different reasons. On the config topic it means the description survives a Home Assistant restart, which would otherwise wipe the entity until the device happens to announce itself again. On the state topic it means the entity has a value immediately after a restart instead of sitting unavailable until the next reading arrives.<\/p>\n
One caveat about payload size: firmware that speaks discovery usually sends abbreviated keys – stat_t<\/code>, dev_cla<\/code>, stat_cla<\/code>, unit_of_meas<\/code>, uniq_id<\/code>, dev<\/code>. Both spellings work and can even be mixed. Handwritten payloads are easier to read in full form.<\/p>\n
When the Entity Appears and Stays Empty<\/h2>\n
An entity that exists but shows nothing is almost always a topic mismatch: the state_topic<\/code> in the payload and the topic the value is published on differ by a character. Subscribing to the wildcard shows both sides at once.<\/p>\n
mosquitto_sub -h 192.168.1.10 -u ha -P geheim -v -t \"haus\/#\"<\/code><\/pre>\n
If the value arrives but is nested inside a larger JSON message, a value_template<\/code> picks it out – \"value_template\": \"{{ value_json.total_kwh }}\"<\/code>. Without it the entity receives the whole object and reports it as unknown.<\/p>\n
And a warning about a field that looks helpful: expire_after<\/code> marks the entity unavailable when no update arrives within the given number of seconds. On a switch that is useful. On an energy counter it tears holes into the long-term statistics, because every gap ends a counting run. A meter that reports every fifteen minutes is better off without it.<\/p>\n
Patience helps with the last step. Long-term statistics are computed in five-minute intervals and the Energy dashboard aggregates by the hour, so a freshly created sensor stays blank until the first full hour has passed. That is not a fault, and re-publishing the payload does not speed it up.<\/p>\n
Removing a Device Without Leaving a Ghost<\/h2>\n
Deleting the entity in the interface removes it until the next restart, at which point the retained config message recreates it. The removal has to happen where the creation happened.<\/p>\n
mosquitto_pub -h 192.168.1.10 -u ha -P geheim -r \\\n  -t \"homeassistant\/sensor\/kellerzaehler\/energie\/config\" -m \"\"<\/code><\/pre>\n
An empty retained payload on the config topic deletes both the entity and the stored message. The state topic keeps its own retained value and is worth clearing the same way, otherwise the next device to use that topic inherits a reading that belongs to something else.<\/p>\n
\n
Sources<\/h2>\n