Align on Hardware Provider Requirements for FlowFuse Device Agent

[dgatti0213]

Description

Before engaging hardware partners, we need engineering alignment on:

1. What minimum requirements we place on partner hardware
2. How Device Agent is expected to be deployed
3. What the end-user workflow looks like

Goal: make this simple, repeatable, and low-friction for customers.

---

Two Integration Scenarios

Scenario A – Managed Mode (Preferred?)

• Disable/remove vanilla Node-RED
• Device Agent is the only Node-RED runtime
• Full lifecycle (provisioning, updates, config) controlled by FlowFuse

Questions:

• Do we require vanilla Node-RED to be removed?
• Do we enforce ownership of port 1880?
• Do we require systemd service control?

---

Scenario B – Coexistence Mode

• Leave existing Node-RED intact
• Install Device Agent alongside
• Configure via environment variables
• Customer decides which runtime to use

Questions:

• Are we okay competing with a preinstalled Node-RED?
• How do we prevent port conflicts?
• Do we support side-by-side long term?

---

Minimum Hardware Requirements (Proposed)

• Linux-based OS (systemd preferred)
• Persistent writable storage
• Outbound HTTPS access to FlowFuse
• Stable clock (NTP)
• Sufficient RAM/CPU for Node-RED workloads

Open questions:

• Do we define minimum RAM/CPU?
• Do we require container runtime, or support native install?
• Do we require secure element / TPM for identity?

---

End-User Workflow (Target)

From customer perspective:

1. Device boots
2. Device appears in FlowFuse (pre-provisioned or claim code?)
3. User assigns to instance
4. Flows deploy
5. Device updates managed centrally

Questions:

• Are we standardizing on claim-code model?
• Who owns first-boot provisioning?
• Do we require factory pre-provisioning?

---

Ask

Engineering feedback on:

• Preferred integration model (A vs B)
• Non-negotiable hardware requirements
• Simplest provisioning flow for customers

We need alignment before sending requirements to partners.

[dgatti0213]

We need to finalize alignment within one week. Four major manufacturers are actively evaluating certified device integrations.
One existing partner rework and three large new opportunities.

[knolleary]

A lot will depend on what UX the device offers in terms of preloaded software. There may not be a one-size-fits-all answer.

Answers to some of the questions:

• Do we enforce ownership of port 1880?
  • I don't see any technical reason to require this. The editor is accessed remotely via the FF platform, rather than direct to the device.
  • If we go the coexistence path, then the device agent will need to be assigned its own port and setup to run on that port

Regarding fully managed vs coexistence, I think the latter would give a path for a non-FF customer to start using Node-RED on the device and then migrate into being a FF customer and switching over to the device agent managed version.

From a hardware spec POV, absolute bare minimum I'd suggest is 512Mb/1Ghz CPU - obvs the more the merrier.

The OS must support Node JS v20 or later (this will be a moving target over time...).

Either docker or native install is fine - will depend on what they already have on there.

In terms of seamless provisioning - this gets trickier. We have various ways of provisioning the device, some more seamless than others. We do support provisioning tokens that can be written to the device for it a self-register with the platform. However, it will get registered into whatever team created the provisioning token. So that would need to be done on a per-customer basis in the factory, rather than having a stock install image. If the user has command-line access to the device, they can run the device agent command with a one-time provisioning token. As I said before, it will depend on what existing UX the device offers.

[dgatti0213]

Nick, I think we may be missing the core premise here. Before we get too deep into specific scenarios, we should define the generic requirements we expect from hardware partners; especially around runtime ownership and lifecycle control. For example, if Device Agent is enabled, do we require the original Node-RED to be disabled, or at minimum ensure we have a clear update path for the Node-RED version (either managed by us or strictly controlled via their firmware process)? I think we need alignment on those non-negotiables first of what we consider a certified device, then we can decide how flexible we want to be on coexistence and provisioning models.

To me, certification means there is a clear, repeatable, low-friction path to getting our software on the hardware where the deployment method has been reviewed and approved by us. It should feel turnkey; not something that requires SSH access or manual command-line steps by the end user. If we’re calling something certified, the install, provisioning, and lifecycle model should be predictable and aligned with how we expect Device Agent to run.

[dgatti0213]

Hey @lbeau please review, mind adding some input here and ill put it all together for review from the team.

[dgatti0213]

@knolleary When someone puts the device agent on an edge device, do they need to disable the original Node-red that is running on the device? I ask because I seem to have to do this when I put device agent on the Goov Rio. Just making sure I wasn't doing something wrong.

[lbeau]

Important to consider whose customer it is in this case- the HW providers or ours?

Another way of asking this, who is our customer- the hardware vendor or the end user?

This matters when defining the experience.

I love a self-provisioning device and observe the constraint Nick introduced- the device will register under the team that created it. Is this okay in a scenario where the partner is the customer managing all the remote instances, or do they intend to pass that ownership, governance and RBAC onto the customer and they will have their own isolated instance?

As for scenarios, start with managed mode as its simpler and doesn't introduce the prospect of runtime collisions/incoherence that sounds like a major PITA to workaround. (I could be over rotating)

• Disable/remove vanilla Node-RED
• Device Agent is the only Node-RED runtime
• Full lifecycle (provisioning, updates, config) controlled by FlowFuse
• • do we really want to sign up for this? The hw partner could also manage the devices...

Questions:

• Do we require vanilla Node-RED to be removed?
• • yes
• Do we enforce ownership of port 1880?
• • not necessary, could be configurable if port collisions are afoot
• Do we require systemd service control?
• • unsure, defer to Nick.

[dgatti0213]

All, I have summarized and written up a doc for us to collaborate on: https://docs.google.com/document/d/1R-TTYl4nTpysB5DcFD4cUWAjqoOh57y9ojbNe9Ltevc/edit?tab=t.0

Please review and provide feedback asap, there hardware partnerships need continued momentum.

[dgatti0213]

Thank you Lori for your comments. @allthedoll Could you help fill in these gaps?

1. Runtime: Do we require vendor Node-RED to be disabled/removed for certification?

2. Packaging: If shipped in hardware's firmware, does the device need to be ready-to-run with zero CLI setup? (Meaning node-red and device agent already installed together rather than just device agent)

3. Service Control: Must Device Agent run as a system service and control Node-RED (start/stop/restart)?

4. Permissions: What minimum permissions does Device Agent need (can it run non-root)?

5. Ports: Do we just require a non-conflicting, configurable port, not ownership of 1880?