Tasmota: support for `suggested_area`

Feature Requests
,
1

Hello everyone,

I would like to request support for suggested_area, similar to the MQTT integration.

Idea is simple: if the payload contains the attribute suggested_area and the device is not already assigned to an area, the suggested_area will be assigned to the device.

As the user can easily adjust what he/she wants to publish, adding this attribute to the payload and supporting it in the Tasmota integration would be very convenient and in line with the general MQTT approach.

Thank you :slight_smile:
Alex

2

Home Assistant’s Tasmota integration interprets Tasmota’s discovery protocol which was created, and is maintained, by the Tasmota project. They determine the properties included in their discovery payload.

In contrast, MQTT Discovery was developed by the Home Assistant project; it determines the properties included in its discovery payload.

1 Like
3

Well, actually the smart people in the Tasmota project want their users to have full control and only defined the defaults.

The user can fully customize everything and can easily publish whatever information he or she likes :slight_smile:

https://tasmota.github.io/docs/MQTT/#examples

https://tasmota.github.io/docs/Commands/#mqtt

So the user can add to or modify defaults without having to build a personal image.

Since the Tasmota integration is maintained by HA, maybe the same people who gave us MQTT device discovery support could enable the Tasmota feature to support suggested areas?
Or the smart people who wrote the Tasmota integration could?

P.S.:
Tasmota is really more of a universal firmware, so it is not specific to one home automation server. So the support for server specifics needs to be implemented on server side.
So for users to be able to use the functionality specific to Home Assistant (e.g. definition of areas), the HA integration must support it.

So whether or not Tasmota has suggested_areas in its default payload makes no difference because the support needs to be on server side.

Adding the msg property to the discovery topic can then be done by each user in Tasmota console without compiling.
Adding the support in HA can not :slight_smile:

4

As I’ve sucessfully used MQTT Discovery to create my own Python devices (with sa or suggested area) I’d agree with the sentiment, but there’s several steps to achieving this.

  1. Tasmota currently doesn’t capture area or location information - Tasmota FW change.
    The obvious location for this is on the “Configure Other” tab, as this is where other device specific details are entered along with individual entity names.
    N.B.: Remember to use different values for Device Name (i.e. TH16 Boiler) and Friendly Name 1 (Water Heater) to avoid issues with HASS Entity Naming Guidelines which separates device and entities it has (e.g. a AOFO 5-gang socket strip device controlling a fan, light, etc entities).

  2. Tasmota Discovery currently doesn’t include area or location information - Tasmota FW change.

  3. Update the Tasmota Integration to add location - HASS change.

Much as I’d love these changes to put all Tasmota device config in one place (the device), my suspicion is the Tasmota support for Matter will get there first.

(Statements are based on my running instances of Tasmota 13.1.0 Quentin, not a deep trawl of GitHub PRs and FRs.)

5

Thank you for your feedback.

I will start with your third point:

That is a essentially part of this request, so part of the FR.

I would argue that your first and second point are the same. Tasmota stock does not track area.

However, it is not true that a firmware change is needed. I can make an FR there, but honestly, it is not needed.
Just create a simple rule that publishes the property suggested_area and the area value. Done.
No need for firmware changes.

For everybody using Node-RED: just subscribe to the topic and add the msg property. Done.

So the Tasmota firmware already offers everything you need except a GUI setting.

The problem is that the Tasmota integration cannot handle any additional information. So the suggested_area support, which is one of the key features in MQTT discovery’s linking to devices, would not be processed.

Personally I would not mind aligning the Tasmota interpretations with those of MQTT, so all parameters supported in MQTT are supported by the Tasmota integration.
But I feel my chances are better if I focus on the basics and ask for just one addition :slight_smile:

N.B.:
As you mention the new naming guidelines, I have to admit that I was extremly suprised to see those. They really do mess up all devices.
I do not know the reason for this change, but a friendly_name is almost always a unique identifier by itself. Forcing device name into the friendly or entity_id is a surprising and, in my very personal view, very unfortunate step.
Making that optional would have been far more user friendly.

Fyi, I made a change request for the Tasmota integration for this new approach a week or two ago, when I thought it was a bug :smiley: