AirLink In/Out.

[HansR]

To complete my remark, I suggest the AQM-III includes an mDNS procedure (like e.g. described here)

My guess is that would solve the issue elegantly.

[mcrossley]

You can ask...

Bit I'll fix the disabling of auto discovery - at present the toggle is saved and displayed but not actually used.

I had a quick look at the code, and it is a bit more sophisticated than I outlined above, but still flawed if one of two devices does not respond to mDNS.

[HansR]

You can ask...

I did...

[Phil23]

Few points of note for the hell of it.

I don't know where it gets that my AQM's (192.168.59.237) host name is airlink-1001B0, as that's the outdoor one on 236.

When I complied the AQM code I set it's OTA name in the code to be Sps30_AQM. (Their term in the code was OTA name, not actually Host Name).

I've had no need to try pinging either Host Name till now & just tried & pinging either name resolves to to the correct IP address.

That's not to say I haven't seen weird things in the past relating to DNS due to stale or corrupted ARP or DNS caches.

One that caused a brief hair tearing session was one of my office PC's that was playing up.
(Newly installed & given 192.168.59.13).
It replied to from pings on it's known & confirmed Ip address, xxxxxxx.13 but I couldn't connect.

Also still kept replying when I pulled the Lan cable out
But then I couldn't from others......
Looked at my main PC's ARP cache & the record for the new PC's IP was stale & had the wrong MAC address.
Simple issues in the end, my Up for weeks main PC had had a hissy fit in the ARP update service thingo.


As for the solution here, The discovery service is a good & probably required for the less IT Savy users,
but it would probably good if it turned off totally if the user disables Discovery, CMX just reads the defined IP, checks it's alive & gives valid response & goes with that.
If it fails, it looks no further, just handles the error appropriately.

Cheers

Phil.

[Werk_AG]

I will try to add mDNS procedure on next release of the AQM-III firmware.

There is already some work done.

CumulusMX is now able to discover the device via zero-config:

2021-09-26 05:09:04.447 ZeroConf Service: Attempting to find AirLink via zero-config...
2021-09-26 05:09:04.840 ZeroConfig Service: AirLink found 'AQM-DevK1', reporting its IP address as: 192.168.1.114
2021-09-26 05:09:05.448 ZeroConf Service: Auto-discovery found the AirLink, reporting its IP address as: 192.168.1.114

Cheers
Werk_AG

[HansR]

@Werk_AG:

[Phil23]

I don't know a whole lot about mDNS at this point, but I'm curious how it would handle certain situations.

Example below is what I'm thinking of.
I have quite a few TP-Link Wifi Smart switches, all on Wifi & discovered by the App.

But looking In my Omada Wifi AP management controller I see the info Below,
a collection of devices with multiple same Host Names; HS100 & HS110.

I wonder how mDNS would deal with that & whether it relates at all to the MX AirLink situation?

Screenshot 2021-09-26 195147.jpg

[mcrossley]

I don't know where it gets that my AQM's (192.168.59.237) host name is airlink-1001B0, as that's the outdoor one on 236.

The current code assumes that if only one AirLink replies to mDNS AND the AirLink hostname is blank in the config file, then it will use the returned hostname and save that against the AirLink.

The next time you start CMX the hostname is no longer blank, and it compares the returned hostname against the saved named and if they match use that IP address.

So if you edit your config and add the AQM hostname it *should* ignore your real AirLink response.

The basic problem is still MX not coping correctly with two AirLink devices where one does not respond to mDNS.

[Werk_AG]

...
The basic problem is still MX not coping correctly with two AirLink devices where one does not respond to mDNS.

As soon as I heard that (on a previous post from you) I started to work to make the WeatherDuino AQM-III respond to mDNS, so it could be used together with a Davis Airlink.

To those which currently are using an AQM-III together with a Davis Airlink: I hope that in a few days a new AQM-III firmware with mDNS support will be ready to be published.

[Phil23]

The next time you start CMX the hostname is no longer blank, and it compares the returned hostname against the saved named and if they match use that IP address.

So if you edit your config and add the AQM hostname it *should* ignore your real AirLink response.

Thanks Mark,

That seems to resolve the issue. Indoor AQM is now staying fixed at it's correct IP address.

I also Notice the Console log reports slightly different now the Hostname has been set.

Code: Select all

2021-09-27 06:33:32.444 Starting on Windows
2021-09-27 06:33:32.446 Running interactively
2021-09-27 06:33:32.447 Creating Windows Exit Handler
2021-09-27 06:33:32.524 Creating main MX log file - MXdiags\20210927-063332.txt
2021-09-27 06:33:32.527 Cumulus MX v.3.13.3 build 3148
2021-09-27 06:33:32.527 Working Dir: C:\CumulusMX\
2021-09-27 06:33:33.196                     http://192.168.59.15:8998/
2021-09-27 06:33:33.196   Open the admin interface by entering one of the above URLs into a web browser.
2021-09-27 06:33:33.208 Today.ini = data\today.ini
2021-09-27 06:33:33.211 Last update=2021-09-27T06:30:00
2021-09-27 06:33:34.371 Connected to station
2021-09-27 06:33:35.598 *** Discovered more than one potential AirLink device.
2021-09-27 06:33:35.598 *** Please select the Host name/IP address from the list and enter it manually into the configuration
2021-09-27 06:33:35.598 *** Discovered AirLinks = airlink-1001B0/192.168.59.236 
2021-09-27 06:33:36.909 Missing AirLink WeatherLink API key/secret in the cumulus.ini file
2021-09-27 06:33:37.187 Missing AirLink WeatherLink API key/secret in the cumulus.ini file
2021-09-27 06:33:37.187 Connecting real time FTP
2021-09-27 06:33:37.429 Normal running

[HansR]

The current code assumes that if only one AirLink replies to mDNS AND the AirLink hostname is blank in the config file, then it will use the returned hostname and save that against the AirLink.

The next time you start CMX the hostname is no longer blank, and it compares the returned hostname against the saved named and if they match use that IP address.

So if you edit your config and add the AQM hostname it *should* ignore your real AirLink response.

The basic problem is still MX not coping correctly with two AirLink devices where one does not respond to mDNS.

Now, I have two AirLink devices of which one is the AQM-III which now responds correctly to the mDNS.

The second is an RPi with avahi-daemon running but that apparently does not work in this context. What must the response actually be? Is it aimed specifically at the software or at the device? Do I need to have my emulator respond specifically to the (or a) request or should avahi suffice?

CMX still gets very confused and changing the hostname in the inifile does not help. I have explicitly two addresses, two hostnames (both non true AirLink devices) and CMX only picks up the first (which is the AQM-III). When the second has a filled in hostname CMX does not change the entries but neither does it pick up the second emulated AirLink. Did I create an impossible combination?

[HansR]

Added to previous: it seems the logfiles does not give the correct message:

Code: Select all

2021-10-01 09:59:09.392 Extra Sensor = Davis AirLink (Indoor) - stand-alone=True
2021-10-01 09:59:09.490 ZeroConf Service: Attempting to find AirLink via zero-config...
2021-10-01 09:59:09.952 ZeroConfig Service: AirLink found 'DeWilgenEsp', reporting its IP address as: 192.168.178.221
2021-10-01 09:59:10.490 ZeroConf Service: Auto-discovery found the AirLink, reporting its IP address as: 192.168.178.221
2021-10-01 09:59:10.493 Extra Sensor = Davis AirLink (Outdoor) - stand-alone=True
2021-10-01 09:59:10.499 ZeroConf Service: Attempting to find AirLink via zero-config...
2021-10-01 09:59:10.738 ZeroConfig Service: AirLink found 'DeWilgenEsp', reporting its IP address as: 192.168.178.221
2021-10-01 09:59:11.499 ZeroConf Service: *** Discovered more than one potential AirLink device.
2021-10-01 09:59:11.500 ZeroConf Service: *** Please select the Host name/IP address from the list and enter it manually into the configuration
2021-10-01 09:59:11.500 ZeroConf Service: *** Discovered AirLinks = DeWilgenEsp/192.168.178.221 
2021-10-01 09:59:11.504 Last update time from today.ini: 1-10-2021 09:42:00
2021-10-01 09:59:11.504 Read today file: Date = 1-10-2021, LastUpdateTime = 1-10-2021 09:42:00, Month = 10

But the data registered seem to be OK. So its just confusion from looking in the logfile after editing the ini and filling in the hostnames and IPs.

[mcrossley]

Do you have two "AirLink" devices then Hans? It seems to be discovering an AQM as your indoor, but no second device for your outdoor?

[HansR]

Yes, I have. The 'outdoor' one is my own RPi emulator which does a perfect job. And it does now as well (you can see it's data on my site).

After the discovery of of the AQM-III it failed conform the way it failed at Phil's install. Then I set the correct hostname and the ip in the Cumulus.ini and it all functions correctly apart from the message in the log.

I thought the mDNS would be handled by avahi but apparently I am mistaken so my emulator is not recognised as an AirLink.
Which was all fine when single but in combination it has a failing message and it causes some confusion.
As said: the data are fetched fine.

[HansR]

@mcrossley: OK, I found the message I need to deliver: "_airlink._tcp", I'll implement that.
The only thing left then is the message as above where both hostname and ip are correct and working, but the log messages indicate failure.