Allow to specify only the unique part of mDNS (i.e. 5 characters of the device ID)

[Sibgatulin]

Currently core.AirQcan be instantiated with either IP address or full mDNS string, both accepted implicitly and interchangeably.

It may be convenient, to be able to interpolate the latter from only its unique part. Smth along the lines of

@staticmethod
def _interpolate_mdns(serial: str) -> str:
    assert isinstance(serial, str) and len(serial) == 5, f"expecting a 5 character string, got {serial}"
    return serial + "_air-q.local"

The question is simply about a good design pattern for AirQ.__init__ to allow for either an IP address, full mDNS, or a 5 character serial number substring.

[theHacker]

Just about to open another issue, but I think, I can place that here:
Home Assistant just failed re-starting after I changed the mDNS to a FQHN.

Why did I do that? I just ordered more air-Q devices and I do not want to remember each one's magic 5 digits. Instead I like to use my DNS entries (e.g. airq-living-room.example.org).

I tracked the issue down to aioairq and its validation in https://github.com/CorantGmbH/aioairq/blob/main/aioairq/core.py#L64.

For now I use the IP address of the device, this is still better than the mDNS.
But it kinda defeats the purpose of DHCP (the default setting of an air-Q anyway): If I ever reassign IP addresses within the DHCP/DNS configuration, I have to remember that Home Assistant configuration has hardwired all air-Qs' addresses.

[theHacker]

An additional thought:
While your idea with the proposed _interpolate_mdns is helpful to assist run-of-the-mill users, it could be hurtful to advanced users. If the user just intends to use a hostname having exactly 5 character, for example airq1 or just air-q.

I would rather like to see an option to choose.
UI sketch for the config dialog in HA:

--------------------------
| Connect to by
| (*) mDNS, just type the first 5 digits of your device's serial number
| [_____  _air-q.local ]
| ( ) IP or hostname
| [                         ]
|
| Password
| [                ]
----------------------------- 

The user must choose by radio button, which option he wants.
By this you make it unambiguous if abcde means mDNS (abcde are the first 5 digits of the serial, gets translated to abcde_air-q.local) or is a hostname abcde which the DNS server in the network can resolve.

[Sibgatulin]

Curious idea, thanks for experimenting. And it is a fair point that even in its present form _validate_address is rather restrictive.

Keeping the proposed HA UI aside at the moment, do you believe that dropping the validation would suffice? The only thing that aioairq does is posting GET requests to "http://" + self.address + /average" (or /data). If this is going to work with your DHCP/DNS configuration and self.address being set to "airq-living-room.example.org", it should be a simple fix.

Unfortunately, I have no immediate ability to test such settings. Could you, by chance, test if simply removing the validation call can do the trick? If you are using a local installation of home assistant (as opposed to running it in a container for example), you should be able to locate aioairq installed in your python (virtual) environment (something along the lines of $PATH_TO_PYTHON_ENV/lib/python3.*/site-packages/aioairq/core.py) and simply modify the code there as a crude way to test.
Sorry that I am outsourcing the testing to you, but it may be much less effort for you if you already have the desirable DHCP/DNS setup at hand.

[theHacker]

Simply dropping the validation is fine for me. And I see say that from the looks of the code.

Unfortunately, I cannot test this. I am running HA productive with HA Supervisor. This is the most restrictive piece of software I ever dealt with, I cannot even SSH into the real machine, everything is managed by HA.
I can only test, after you have released a new version of aioairq, have increased the HA's integration's dependency to that new version and after HA has released that new version of the air-Q integration. *gasp* 😉

I assume, you more easily can test this.
To test DNS setup, you can very easily setup with a single line of text edit on any OS.

Edit this file

• On Linux: /etc/hosts (must be done as root)
• On Windows (I only vouch until Windows 7, but as I know M$ it's still working with Windows 11): %SystemRoot%\System32\Drivers\etc\hosts

Append a new line like 127.0.0.1 your-dns-name.
You can use any name, would even work with google.de (but then you wouldn't be able to access Google anymore 😆 ).
Same goes for the IP. The above example does not fit for air-Q as it is its own machine, so has an IP of its own.
Usually you might want to have sth like 192.168.0.42 air-q. Use air Q's IP address.

The setting usually works instantly (if Windows does not play along, latest after a reboot).
You can verify if it works, by

• Linux: dig air-q
• Windows nslookup air-q.

This command should output the IP you assigned.

---

If that's still too much trouble, you have https://github.com/CorantGmbH/aioairq/blob/main/tests/test_core.py.
If I were to create a PR, I would have tried to create a test which verifies foo.example.org won't throw an error InvalidInput (TDD: before the change, there should have been an error). That would be sufficient to me.

I did a dig command inside the HA container (more precise: another container). That resolves. Besides that, everything in my home uses the same DNS, so there could not be any way to circumvent the DNS. So, I am pretty sure, if the validation lets the string through, it will work :-)

[Sibgatulin]

Thanks for the suggestion, I'll try to test it in the upcoming days

[Sibgatulin]

Just a quick update from me. This repo now has as a branch with a little test, which appears to work just fine following your, @theHacker, proposition. I'll proceed to prepare a PR for HA.

As of the original mDNS interpolation idea, I'll see if it can be conveniently accommodated within the HA integration too (without any explicit UI, but maybe with a try-except clause instead). Until such attempt, I'll keep this issue open.

[Sibgatulin]

@theHacker, the latest release of HA includes the changes to aioairq which should permit using custom host names, would you give it a try?

[theHacker]

Only the 2024.1.0 has the new dependency, not the linked 2023.12.4.
I was scanning the changelog, looking forward for the entry :-)

Gave it a try, upgrading to HA 2024.1.0, and changed for one of my air-Qs the IP to a FQHN.
Seems to work. I had no error in the logs, integration is started and the changed device receives updated values 👍

---

For anyone wanting to do the same thing:
Since AirQ's integration does not support changing the data afterwards (yet? 😉 @Sibgatulin), you must do that by changing the file /config/.storage/core.config_entries. Search for "domain": "airq" and carefully change the data→ ip_address.
Save, and restart HA (not just reloading YAMLs).

The community forum warns about changing this file manually, but it works.

(I wouldn't recommend the only available UI way, deleting and then re-creating the device. Most likely, this will lead to new entities and in consequence loss of all your history on the air-Q! I did not try that out.)

[Sibgatulin]

My apologies for the wrong link.
Thanks for testing and the hint on how to update an existing integration.