[FEATURE]

[AchimWilden]

Daikin hardware
not relevant

Is your feature request related to a problem? Please describe.

1. Lack of Semantic Meaning: A MAC address or hostname is not a useful identifier for home automation logic. Topics should represent location or function (e.g., KlimaFlur) for better readability.

2. Maintenance Overhead: Replacing a failed module changes the MAC address, forcing manual updates of all downstream services, databases, and logic engines that depend on the specific topic path.

Describe the solution you'd like

1. Persistent Device Name Field: A standard field in the Web UI to set a custom name that reliably replaces the MAC address fallback.

2. Topic Toggle: A "Disable Hostname/MAC in Topic" switch or a way to define a custom path that does not automatically inject hardware IDs.

3. Standardized System Commands: Ensure system-level configuration (naming, saving, rebooting) is accessible via a standardized and documented MQTT command path, as current builds often ignore these when sent via MQTT subtopics.

Describe alternatives you've considered

1. Serial Console: Using name, save, and reboot via USB works but is inconvenient and not scalable as it requires physical access.
2. HTTP API / Telnet: Often disabled or not implemented in specific builds, making remote naming impossible.

Additional context
From a technical perspective (industrial automation and OT system architect), hardware-independent semantic topics are crucial for maintainability and downtime. Aside from using the MAC address as the hostname to indicate that the item is unique, it offers no added value. On the contrary, it actively prevents anyone from remembering the topic name. Decoupling the hardware ID (MAC address) from the logic path enables simple hardware replacement ("plug-and-play") by simply assigning the same user-defined name to the new device.

[revk]

Surely you just set hostname?

[AchimWilden]

Could I have specified the hostname? Was that included in the initial setup? But again, the hostname has no place in MQTT topics.
Changing the hostname would be a workaround, not a solution.
The semantic model should show what the topic is about, not how it's implemented. At least that's my opinion, and the option I described allows you to do this as you wish. And it does so with increased transparency because the topics are exactly as you specify them.

[revk]

Hostname is even on the main WIFi set up, allowing hostname.local for web interface.

And there are options for the topic structure including the app name as well as the hostname if you want, and the order of the topic parts.

There is also an HTTP API (the old Daikin control API).

[nicolas5000]

Hello,

As I had issue with MQTT today and found this discussion...

1. In HA, the device is seen/displayed with its hostname (default is MAC if not changed in Faikout settings)
2. MQTT will think devices are different if they have different unique_id (that is always chip MAC)

So it is easy to change 'displayed name" seen in HA by setting hostname. But for now if you want to replace a Faikout board you will have new device detected.

@revk perhaps a new bool setting to enable hostname as unique_id instead of MAC, false by default? By default unique_id will remain MAC so no breaking change for everyone?

[revk]

Hmmm... Possible...

Is this really a big issue?

[AchimWilden]

Okay, the hostname should definitely be on the initial, one-time-visit Wi-Fi setup page. I find it unusual that it doesn't appear later. But the hostname isn't really my main concern.

I've structured all the MQTT topics in the house by location: /somewhere/in/the/house/airconditioner/{all topics belonging to the air conditioner}

It would also be conceivable to organize them by thing.
Something like: /airconditioner/somewhere/in/the/house/{all topics belonging to the air conditioner}

But I deliberately want to keep both the hostname of the adapter I connected to the air conditioner and the app name out of it. At home, it's still relatively manageable, but professionally, I do this for a factory with over 1000 measuring points, and it's always just about the device that needs to be monitored or controlled. The fact that some adapter is connected is irrelevant. And the end user of the data doesn't need to know that either.
If I want to achieve this: /somewhere/in/the/house/airconditioner/{all topics related to the air conditioner}
my hostname has to be somewhere, which is completely creazy. As I said, misusing the hostname for my purposes is possible, but it's nothing more than a workaround. Either I haven't fully grasped it yet, or there's no other way.

You've built something like
[appname]/{<topiccommand>,<topicsetting>,...}/<hostname>/...
That's a valid approach, and you're already doing it :) It's perfectly fine to like it; there's no right or wrong here.
What I'd like is a little more flexibility so I can implement what I'm familiar with.

Don't get me wrong, what you've accomplished here is fantastic. Finally, I can use Daiking cloudless. This is much simpler than trying to retrieve the data from my air conditioner, which is just one room away, from somewhere else in the world using the local control system.

I was just very surprised that the topics are set up differently than how I write them in the UI, and I can't find a way to omit the hostname (which remains unchanged during initialization).

Sorry, my English isn't great, but you understand what I mean, right?

[revk]

"the hostname should definitely be on the initial, one-time-visit Wi-Fi setup page" ---- IT IS!

Have you checked all the topic options... normally it command/name but can me command/app/name or other ways around.

A lot of people have used Faikout with various systems that need different topic structures, and I have tried to accommodate them.

[nicolas5000]

Hmmm... Possible...

Is this really a big issue?

In HA a new device with same hostname but different unique_id (MAC) will create new device entities, possibly with suffix "_2".
However it seems that deleting the old device and pushing the "recreate entities identifiers" permits to return to previous entities (without "_2") and do not change everything.
So for HA, I would say no, it's not a big issue. For other systems based on MQTT unique_id I don't know.

[revk]

OK, the MQTT ID being used as anything more than a feature of MQTT is surprising. Is it the MQTT ID that you want to be hostname not the HA config MQTT message unique_id. I mean I can do that, but I did not know any systems worried about that apart from MQTT brokers.

It would be a change in my library, but doable... Perhaps even a separate settable MQTT ID defaulting to MAC.

[AchimWilden]

Have you checked all the topic options... normally it command/name but can me command/app/name or other ways around.

I think so, otherwise I wouldn't have written :)

Like I said, either it's not possible or I haven't grasped the options. My initial assumption was that I could write it exactly how I wanted it, and then I stumbled across the hostname, or in my case, the MAC address :)

Could you tell me what the settings would be to implement something like this?
/House/ground floor/living room/air conditioning/command/Temp

I haven't found a way other than setting the hostname to "house" (which I'm not going to do ;))

[revk]

OK, there may be some limitations with that many / as I am not 100% sure the settings handle a / in them well, but they may do not.

i.e. you can set the mqtt command to /House/ground floor/living room/air conditioning/command/ I expect.

Or maybe hostname to /House/ground floor/living room, and set hostname before command, and then have command set as air conditioning/command/

There really are a lot of options, have a look.

[AchimWilden]

Let's try this out. I'll use the state that sends automatic updates; that makes it easier to track.
I've set topicstate to /House/groundfloor/living room/airconditioning/state/
(without a leading / and without a space)

And you'll receive zklisch messages to the topic
House/groundfloor/living room/airconditioning/state//4C7525F57A10/status

For the sake of completeness:
prefixapp = false
prefixhost = false
topicgroup1 = ''
topicgroup2 = ''

(btw: if you accidentally enter a leading / in the topics, the module scans the S21 variants and cannot establish a connection -> not relevant to the topic, but perhaps this information will help someone someday)

[revk]

Check all of the options, the command topic maybe?

[AchimWilden]

Check all of the options, the command topic maybe?
Sorry, I don't understand the question.

There are hardly any options. I can specify the individual topics (state, command, info, event, etc.), then there are the two Boolean buttons (prefixapp, prefixhost), and two whose function I haven't yet understood: topicgroup1 and topicgroup2. From their names and descriptions, I can't conclude that they influence the structure of the state topics.

To clarify again:

I receive House/groundfloor/living room/airconditioning/state/4C7525F57A10/status
and I want House/groundfloor/living room/airconditioning/state/status

(ignore the double // ->I accidentally ended the input field with a /.)