I was testing the new modules v4.0.22 to see how server sets worked with the Engine module, and while trying to test it with 2 pre-existing servers I had with each pointing to different URLs (mqtt1.domain.com and mqtt2.domain.com) because they’re both behind a reverse proxy with the same public IP, it prevented me from using them because it did an IP lookup it seems and assumed they were the same MQTT server. I would think this would cause a lot of issues with a lot of cloud providers of MQTT as well as I assume they’re sharing some public IPs among multiple DNS names.
I didn’t see a way of disabling this, but I would think disabling at least the IP lookup as part of validation should be an option.
Is it TLS hostname validation that is failing? If so, this can be disabled via this option in the server configuration:
No, it won’t even let me save the configuration and is giving the following error:
Identical URLs (i.e new URL with InetAdresses: mqtt2.domain.com/x.x.x.x and existing one with InetAddress: mqtt1.domain.com/x.x.x.x are not allowed in Engine Server records.
The TLS cert is a valid wildcard cert (it’s a LetsEncrypt cert). Only difference in the configuration is the domain name mqtt1.domain.com vs mqtt2.domain.com
Ah right. That is a bit too restrictive. You should be able to work around this by using scripting to configure the module. See here: ME: Python Scripting - MQTT Modules for Ignition 8.x - Confluence
I’ll add an issue to our backlog to get this fixed in the future.
The main reason I was testing this out is to see how the server sets in Engine worked. So maybe just a quick confirmation on it would help. Does the Engine open connections to both servers and optionally publish the State topic so that it can accept data from either server? Use case I was thinking of is that if I have a redundant set of servers on Transmission and that same redundant set in Engine, that no matter what server the transmission side connects to, it should work as long as Engine is connected to both?
Server Sets in MQTT Engine work like they do in MQTT Transmission. Within a given server set, the module will connect to one of the servers. It will not connect to more than one at a time. This feature was added in part for running Ignition in a redundant environment. Without server sets, MQTT Engine would try to connect to all defined servers. Now with sets, Engine can be configured to connect to any one and not all at the same time.
So with Engine in this configuration, MQTT Engine will not continually try to connect to a redundant backup MQTT Server that isn’t online.
So is this more geared towards using the distributor where it’s only active on a single server at a time when using redundancy? I’m assuming when running redundancy on either side, only the active server attempts connecting to the broker? Is there any harm in having Engine connect to 2 brokers as long as each broker has unique “topics”/clients so that the UNS doesn’t overlap and then if one broker goes down and the transmission clieints fail over to the other everything would still be OK?
Yes - this was in part to cover the case where distributor is only active on one gateway in a redundant pair.
Your assumption on running redundancy is correct. MQTT Engine will only attempt to connect to an MQTT Server if it is the ‘active’ node in the redundant pair.
There is no harm in having Engine connect to two MQTT Servers simultaneously as long as there is no duplication of Sparkplug messages that are arriving. This setup is also still possible. You’d just need to have two server sets with one MQTT Server definition in each set.
