We have machinery in place to allow Scada to connect to a local MQTT broker as well as to the ATN MQTT broker, but we have no current active use case for communicating to the local MQTT broker and were we to add one, a number of issues would need to be resolved - the existing code is insufficient and would not really work.
Other devices on the local area network that already communicate over mqtt.
Our own code, for some reason running on another PI, e.g. a HomeAloneish node in the same home but not on the pi.
Issues to be resolved include:
a local link not developed by us should not be handled like the ATN link. Unless the code running on the other side of the link is our code, it won't run our acking protocol.
a local link is without subscriptions (e.g. the current local connection) breaks the re-upload comm tests without without the complicated/confusing mqtt_quiescent() work around.
We'd need custom comm state machinery for each non-trivial device.
We'd need a proxy sensor for simplish sensors that are remote.
We have machinery in place to allow Scada to connect to a local MQTT broker as well as to the ATN MQTT broker, but we have no current active use case for communicating to the local MQTT broker and were we to add one, a number of issues would need to be resolved - the existing code is insufficient and would not really work.
See also similar issue in proactor.
The use cases for a local mqtt broker include:
Issues to be resolved include:
mqtt_quiescent()work around.