MQTT Working for some Flexy but not others

Hello,

I have a few Flexy’s that I believe are configured the same but one has a functioning MQTT and the others do not. These Flexy’s are on the same network, scripts are nearly identical and I am able to connect to them via ecatcher but on only one of them is the MQTT working, all the rest I am seeing MQTT Failed - WAN Interface not ready. Here are logs for the one that is working and one of the ones not working. These two implementations are too my AWS but I have tested with the HMS test broker on them as well and that also didn’t work. Is there some configuration differences I am missing? Anything I can try on my end?

MOVED TO STAFF NOTE (2.0 MB)
MOVED TO STAFF NOTE (1.6 MB)

Is there any updates to this??

Sorry for the delay Gary. In the future, if you need immediate support, please create a case at support.hms-networks.com.

Looking at the logs and the logs from our servers, it doesn’t look like the non-working device is currently connected to the internet, while the working one is. Can you try re-running the internet Wizard on the non-working Flexy to make sure it can connect?

Hey Kyle,

I changed my connection from Static to DHCP and then back to Static again and this seems to have corrected the issue. Thanks for the insight.

On my end I was seeing that the internet and VPN was “OK” (bottom right icons were both green) and I was able to connect to the devices via ecatcher and M2Web. What part of the Log showed the devices weren’t connected in case this happens again? Do you know why it showed that the connection was OK on the browser UI? Can this indication be trusted?

I looked it up from the server side and noticed the device was currently offline since 10/21. The logs I have are from the 17th though, so I don’t have the logs from when it happened.

No, but I think we were looking at it at different times. Yes, the indications are accurate. I’ve never seen them show online when the device is offline (or vice versa).

Looking at the logs from 10/17 though, it looks like the device was going online only for a few seconds, just enough to update the the NTP, and then going back offline. I can’t really tell why, just that it looked like there was a network connectivity problem.

Hmm, the Flexy for log I sent may have been unplugged when you checked it on the 21st but its strange that it was flipping offline before that, seems that resetting the IP did the trick for now though.

Here is logs from one more that is not working and that I haven’t reset yet, this one is currently connected.
MOVED TO STAFF NOTE (790 KB)

As you can see from the image, bottom right shows connections but MQTT not working. Can you learn anything from this one before I reset it? I’d like to understand what’s happened as it was seemingly random on my end. Thanks for the help.

Hi @garyR,

I’m seeing a lot of DNS errors.

It’s possible that the Ewon is using the IP address instead of the domain name to reach the VPN Server, hence the green icons, but it cannot reach the MQTT broker (tools.ewonsupport.biz). Are you sure that the Ewon can reach the DNS servers, which are on a different subnet?

WAN IP: 172.23.10.32 GW: 172.23.10.1 DNS: 172.23.15.8 and 172.23.15.10

Have you tried using a public DNS server like 8.8.8.8?

Also, is there a reason why the LAN subnet is so large?

IP: 192.168.1.75 Mask: 255.255.0.0

I would recommend changing the mask to at least 255.255.255.0 and generally don’t recommend using common subnets, like those beginning with 192.168.1.x or 192.168.0.x as they can cause IP conflicts, especially with the VPN.

Also, if you aren’t using OPCUA or DataMailbox, you should disable them to save resources for MQTT.

Hey Kyle, I this is working now. Really not sure what did the trick running through the internet wizards seemed to work. I also had to change the value of WANltfprot in the com config file to see the Flexys locally.

Hi @garyR,

I’m glad to hear it’s working. Changing WANitProt will allow incoming traffic so you can connect from the WAN interface, but shouldn’t effect MQTT (outgoing traffic).

Maybe re-running the Internet Wizard fixed the DNS issue?

Kyle