The message that will pass between instances are robots work orders in one way and robots feedback in the other way
All of them are fixed robots (not automotive) and with on prem safety, not dependent of any networks Order are basic JSON document with list of instructions to pass once, and then during the execution and at the end the feedbacks allow us to report where we are in the process > Le 15 mars 2023 à 19:38, Justin Bertram <jbert...@apache.org> a écrit : > > I'm not sure what exactly you're doing on your edge node so it's hard to > make a recommendation. > > > Justin > > On Wed, Mar 15, 2023 at 1:07 PM Yoann Gini <yoann.g...@gmail.com> wrote: > >> Thanks a lot for that feedback! >> >> Between the three option (bridges, federation, and broker connection) what >> would be the most suited for a configuration only at the edge side? >> >> All our edges have a certificate available published by a private CA, >> ideally I would like my central instance to be with the minimum >> configuration possible, accepting anything from anyone with a valid >> certificate, letting the Edge instance in charge of all the replication >> (bi-directional) settings. >> >> >>> Le 15 mars 2023 à 17:38, Justin Bertram <jbert...@apache.org> a écrit : >>> >>> The edge use-case with substantial hardware is quite different from the >>> classic IoT use-case. Also, the fact that you want to use messaging >> between >>> clients on the edge device is also a significant difference. Therefore, >> my >>> answer certainly would change given that the underlying assumptions from >> my >>> previous answer are invalid. >>> >>> I have no doubt that some of our users are running a broker on their edge >>> devices. The broker can be tuned to run effectively even on very modest >>> hardware when necessary. I can't rightly say whether that's a "good >> usage" >>> in your use-case when it's clear that important details are easy to omit. >>> Also, it's hard to say whether core bridges [1], federation, or even >> broker >>> connections [2] would best fit your needs. >>> >>> >>> Justin >>> >>> [1] >>> >> https://activemq.apache.org/components/artemis/documentation/latest/core-bridges.html >>> [1] >>> >> https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html >>> >>> On Tue, Mar 14, 2023 at 3:12 PM Yoann Gini <yoann.g...@gmail.com> wrote: >>> >>>> Thanks for your input Justin! >>>> >>>> Maybe IoT was missleading here, if I speak about EdgeComputing does it >>>> change your answer? >>>> >>>> One of the reasons I was looking for that architecture and that I forgot >>>> to mention was the ability to use also the MQ between multiple services >>>> locally to the edge. >>>> >>>> So each edge would be autonomous for their own internal messaging and >> then >>>> have federations for upstream communications. >>>> >>>> I was in my context forgetting that IoT usually mean low end device. >>>> >>>> In my context it’s IoT but with 64 GB of RAM, i7 CPU and Cuda >> capabilities >>>> on the GPU. >>>> >>>> So maybe Edge Computer is more appropriate wording. >>>> >>>> Yoann >>>> >>>>> Le 14 mars 2023 à 20:02, Justin Bertram <jbert...@apache.org> a écrit >> : >>>>> >>>>> 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 >>>>>> >>>>>> >>>> >>>> >> >>
