Generally speaking, the software that runs on IoT devices is designed with the unique constraints of IoT in mind (e.g. poor or intermittent network connectivity, limited processing capacity, small amount of memory, low power, etc.).
MQTT, for example, is often used for messaging in IoT contexts and it is designed to be light-weight and has features like will messages, retained messages, link stealing, session expiration, etc. to facilitate unique IoT use-cases. Furthermore, MQTT client implementations offer additional features not outlined in the MQTT specification. For example, most Paho MQTT clients [1] offer the ability to automatically reconnect, buffer messages when offline (which will be sent automatically when the connection is re-established), and persist messages (in case the application crashes before it has a chance to send them). In my opinion, adding a broker to an IoT device is not a good idea. It's adding complexity where it isn't really required. It will make configuration, deployment, and debugging more difficult, and it will require more hardware (which is notoriously limited in IoT). A good MQTT client implementation should be able to provide you with all the features you need to operate effectively in an IoT context. Justin [1] https://www.eclipse.org/paho/index.php?page=downloads.php On Tue, Mar 14, 2023 at 8:52 AM Yoann Gini <yoann.g...@gmail.com> wrote: > Hello, > > I'm new here and I'm working on an IoT issue where I'm wondering if > Artemis and federated queue could help. I'm learning the software in the > same time I'm trying to achieve something, so I would like to have your > opinion on this: will it work? Is it a good idea? And do you have sample > config / blog post to recommend to learn to achieve that? > > The idea: IoT devices with some computing capability running local needed > services as well as an Artemis local instance, with upstream set a Cloud > located one. > > Configuration in bidirectional to allow both Cloud to pass commands to IoT > and IoT to report feedback to Cloud. > > Goal of Artemis here in the IoT as federated layer (and not directly IoT > service connected to the cloud one) would be to provide some sort of > caching capabilities which would allow the local service to not have to > handle disconnected state. Local service will still be able to publish to > local Artemis and read what was lastly make available before a connectivity > cut. And when the Internet recovers, the federation (if I understand it > well) should resume bidirectional transfer of feedback and orders. > > Does that make sense for you? Is it a good usage of the solution that has > some chance to reliably works? > > If so do you have any recommendations for the implementation or any blog > post / conference I should look at to learn this? > > Cheers > Yoann > >
