FlowFuse
Refine MQTT offering details
With technical feasibility established, we can now begin to shape the MQTT offering for FlowFuse. Outstanding items to consider are:
### Tasks
- [ ] How will MQTT offering be priced?
- [ ] How will MQTT broker(s) be exposed?
- [ ] Define MQTT service limitations
Following these outstanding items being addressed, sizing and delivery estimation can be established and #4433 should be consulted to refine the user experience designs before front-end development work can begin.
Customer Insights Here are private notes from a call with a prospect who has asked for an MQTT service. https://docs.google.com/document/d/1ENdhMQTK0_WVtVhh47eS6aBmK0gOajAf8u4x9PGzur8/edit#heading=h.rodpwdh8kk4r
How will MQTT broker(s) be exposed?
It is my understanding we will be going for single broker, multiple clients. So each team will be able to provision/manage clients rather than brokers - is my understanding correct here @hardillb?
Yes, current plan is a single shared multi-tenant broker.
Teams will be able to provision client credentials/acls that will be allowed to connect to their tenant.
Still to be decided which protocols to offer (MQTT, MQTT over WebSockets and secure version of both), My suggestion is MQTT, MQTTS and MQTToWSS (no insecure WebSockets)
Pricing proposal added to the end of this doc, for privacy: https://docs.google.com/document/d/12BueZ6zpUDAgW3bFa2wVB1dgdWeOsCPh4-aL9INj9Rw/edit
@hardillb Can we limit on the number of client? (I assume so?) And does that imply that if X clients are configured the number of concurrent connections is also limited to X?
@hardillb Does that also limit the connections? Or are those different? I could see use cases where a set of credentials are configured and rolled out on mass? Or is that not how MQTT works?
Yes, for MVP it will require 1 set of credentials per device.
MQTT credentials consist of 3 things (normally), username, password and client-id.
client-id must be unique across a broker, so to enforce limits on number of connected clients MVP will require that username = client-id.
Future developments of the broker we are using will allow per tenant client limiting that will remove this requirement.
This will mean that you can not re-use a single set of username/password across multiple devices to start with.
I've added a proposal for an SLA for our broker service to the meeting/pricing doc, at the very bottom of the page. https://docs.google.com/document/d/12BueZ6zpUDAgW3bFa2wVB1dgdWeOsCPh4-aL9INj9Rw/edit
@hardillb I'd be grateful if you could give it a thumbs up that the proposal fits with our discussion.
@joepavitt Can we add PostHog events for MQTT usage? For example: connected a client, published to a topic, subscribed to a topic.
@gstout52 no, we cannot instrument the activity of a client on the broker at that level.
Yes - any activity on the FF UI can be instrumented into PH; although the specific implementation details for that is not something I have to hand.
We will also need to add info to the telemetry data - #4693
I think we can tick the define service limitations for current MVP
We've started to discuss Project node integration, but I think that should be it's own issue.
although the specific implementation details for that is not something I have to hand.
PH will pick this up automatically, no need to do anything
@gstout52 I've added an MQTT Client section to our Product Feature Tracking Dashboard: https://eu.posthog.com/project/2209/dashboard/2923?highlightInsightId=ZG26N2a9
I've added a section at the bottom of the pricing doc that describes usage limitations we can publish. Please review @ZJvandeWeg , @knolleary , @hardillb . Thank you!
Closed final item in our todo list here with https://github.com/FlowFuse/website/pull/2730