Closed sammachin closed 2 years ago
Do we want to keep polling as a fallback mechanism?
Do we want to keep polling as a fallback mechanism?
I think so. I wouldn't choose to rip it out straight away as we'll have a period of 'legacy' device agents out there that only know to do polling.
@ Does this still need its own design work or can it be estimated and scheduled (tentatively) for development in 0.8?
It does require some design work, although I think much of the unknowns are fairly well understood at this point.
Happy for this to go in to 0.8
updated 21/7 to add project
to status payload and update topics used
Lets start to fill out the design details for how devices will make use the broker.
From #464 we have defined the top level topic structures.
ff/v1/<team>/d/<device>/command
to receive commands from the platformff/v1/<team>/d/<device>/status
to send their status to the platform
ff/v1/<team>/p/<project>/command
to receive commands from the platform sent to all devices for a give projectThe Device status event has the form:
{
state: '<state>',
snapshot: '<snapshot>',
settings: '<settings>',
health: {
uptime: 123,
snapshotRestartCount: 1
}
}
This is the same structure as the existing HTTP Ping - which we need to keep consistent with. We haven't properly specified the health
properties and formalised how they are used. Will need to come back to that.
It publishes status events whenever there is a change in the local status, including:
The precise values of state
are TBD.
Commands published by the platform are JSON blobs containing the type of command and any additional meta data the particular command provides.
Currently, the only command the platform may send the device is a notification there is a new project snapshot to load.
update
{
"command": "update",
"project": "<project-id>",
"snapshot": "<snapshot-id>",
"settings": "<settings-hash>"
}
When the device receives this command it must compare the snapshot
and settings
values with its locally stored values. If either differs, then:
updating
status messagerunning
status messageThis is proving to be more involved than simply adding MQTT instead of HTTP.
With the current topic structure design each device subscribes to its own 'command' topic. But the most common command to send is that the snapshot a device should be using has changed - and that has to be sent to all devices. This means the platform has to get a list of all devices and publish a message to each one. Having implemented it, it feels wrong - that's a lot of unnecessary work.
It would be better if the platform could publish one message to notify all devices assigned to the project of any change. But to achieve that, the devices would have to subscribe to a topic specific to the project - which in turn means:
I have updated the topic table in https://github.com/flowforge/flowforge/issues/464#issuecomment-1155300019 to reflect this.
ff/v1/<team>/l/<project>/command
and ff/v1/<team>/l/<project>/status
- (note the /l/
to indicate this is for the launcher).ff/v1/<team>/p/<project>/command
(note the /p/
) is used to send commands to all devices assigned to this project.ff/v1/<team>/d/<device>/status
- with its current snapshot/settings hashes (project can be inferred from snapshot) - with a state
of <to be defined>
. This is the 'birth' message. It does not start the project running at this point in time.<to be defined>
, or the snapshot/settings hashes are wrong, it publishes an update
message to the device command topic - this includes the project
id.update
message - on either its .../d/...
or .../p/...
topic, it compares the snapshot/settings/project with its local configuration.
Event | Response |
---|---|
Device is added/removed from a project | Platform publishes to ff/v1/<team>/d/<device>/command to notify the device |
Device settings modified (env vars) | Platform publishes to ff/v1/<team>/d/<device>/command to notify the device |
Target Snapshot is changed (including when deleted) | Platform publishes to ff/v1/<team>/p/<project>/command to notify all devices |
Project deleted | Platform publishes to ff/v1/<team>/p/<project>/command to notify all devices (with project: null ) |
@sammachin Can this issue be updated? I think the milestone is incorrect and it has been fully delivered?
Epic
464
Description
As a: User
I want: my devices to communicate with the forge application over MQTT
So that: I have a realtime channel and do not rely on polling.
This is dependent on #464 delivering the MQTT broker infrastructure.
Dependencies
Acceptance Criteria