CMX Not Connecting to WLL

[stefanbagnato]

I am in the process of trying to switch CMX from my old, wired VP2, connected via a bellfryboy logger, to my new, wireless VP2, connected via WeatherLink Live. I've taken the last several days to get the new station mounted, confirm the data is valid, get both the original and new Davis consoles up, and get the WLL and weatherlink.com dashboard working. I am aware I don't need a Pro subscription, thus I dont' plan to add it.

I have attempted to switch CMX to the new station today but I am running into issues. I switch the station type to WLL, leave auto discovery enabled (I could just set the IP, but I only have the one WLL so I figure it should not matter), enable the solar sensors, omit the APIv2 details (again, no Pro), and restart CMX. However, it's not finding the WLL. Log attached.

I have a slight hunch that it could be due to my devices being on the 192.168.27.0/24 subnet (with vlans) but my server, and thus CMX, being isolated on the 192.168.29.0/24 subnet. However, I have rules configured to allow traffic (it's been setup like this for years) and CMX can find my Airlink which is on the other subnet.

Since both stations are up, I've just rolled back the ini config so that I am not missing any day. However, I certainly want to figure out what I am missing here...

[mcrossley]

MX is not finding your AirLink either...

Code: Select all

2023-03-06 09:53:34.280 ZeroConf Service: Attempting to find AirLink via zero-config...
2023-03-06 09:53:35.296 ZeroConf Service: Failed to discover any AirLink devices

You will have to manually configure your WLL IP address as that has the same issue.

The WLL is unlikely to work (at least not for real time data, or discovery) unless you have a single UDP broadcast domain across your VLANs, that normally means setting up a forwarder on your router. I don't remember off hand if the WLL uses limited broadcasts or not.

The WLL devices were designed to work on a single network, if you split them across multiple networks you are in for a painful time.

[stefanbagnato]

Hey Mark. Yes, I've noticed that logged for a while now. Which is super weird because MX does in fact see and work with Airlink. I have live data. I have the static IP in the config, so I guess it's the auto discover that can't find it, which would probably be the same root cause for WLL.

I have enough custom config for the server (including CMX) that I would rather not move it off it's own subnet. However, I can work on the broadcast domain. pfSense is granular enough I should be able to limit the allowed broadcasts to just WLL:22222

[stefanbagnato]

I got the auto discover error for Airlink to go away. Since the device is statically set, auto discover should have been disabled from the start. I can statically set WLL too, but as you said the real time updates won't work, I'll work on the firewall rules.

[stefanbagnato]

So after working on this til the middle of the night, I've made progress. I have a FreeBSD package running on my pfSense box that forwards all UDP 22222 broadcasts from the main subnet to the server subnet. I can confirm via Wireshark that the server nic see's those 22222 broadcasts every half second or so. I switched MX over to the WLL config (statically set the WLL IP instead of using zero conf) and it does appear to work. But, it looks like it only updates every 10 seconds or so, and the log is littered with 'Missed a WLL broadcast message'. Which I do not understand why since the broadcasts are received by the server nic. Debug and a snippet of the pcap attached. Any ideas?

[stefanbagnato]

Okay so I have the fix. I know my setup is super-custom, this may not be helpful for most. But as mentioned, udpbroadcastrelay on FreeBSD13 is available for pfSense 2.7 (beta) and works well with a rule for forwarding UDP 22222 across interfaces and/or vlans. Additionally, the network firewall, pfSense in my case, needs a rule allowing UDP 22222 FROM the same subnet/vlan as the WLL. The target device (my server), needs a rule to allow inbound traffic to local UDP 22222 (ephemeral source port).

I installed a 'test instance' of CMX with just a basic setup for WLL and it is updating 'Live'. I am going to monitor it for a day or so before switching the WLL input to my live CMX instance. It's technically a different station, as it's a new wireless VP2 vs the old wired, but I plan to keep all the historical records as if they were recorded with the new station. It 'should' be as simple as switching the config to WLL and restarting MX, right?

[mcrossley]

It 'should' be as simple as switching the config to WLL and restarting MX, right?

Right!

[stefanbagnato]

It 'should' be as simple as switching the config to WLL and restarting MX, right?

Right!

Lol, you're scaring me. I will dig into it tonight.

[mcrossley]

No, you are right, it should just work. It did for me when I switched from a VP2 console to a WLL

[stefanbagnato]

So did the swap this morning. This makes no sense, but my live instance of MX is only doing the 10 second update, as if UDP 22222 broadcasts were being blocked. But the test instance, pulling from the same WLL is updating 'live'..... no idea lol. Settings match and everything. Need to think on this one.

[stefanbagnato]

When in doubt, the magical reboot is always a good step

[mcrossley]

So it is all working now?

[stefanbagnato]

So it is all working now?

Appears so. Now on to your update!