Managing Multiple Edge Devices in UI app

[BKristenssonAlfsson]

For the multiple devices PR discussion:

@ivelin @sniperadmin

1. To handle multiple PeerID in same connection, I need to store all connections where? pnp.js just handles one connection at the moment, so I guess the action PEER_CONNECT have to be run for each PeerID while we save the old connection without disconnecting from it?
2. Timeline will run an EdgeAPI for each connection to then mutate the data into what we want
3. The list that displays the connected Edges will need to get some icons showing state of it (Disconnected, Connecting, Connected)
4. The current icon in Navbar.vue with connection state should be removed as it will be in the list view instead.

[sniperadmin]

Depends on how many connections a user could have... I guess we already save the information on local storage of the browser
but still the data will be exposed to losses by any means,.. our vuex can handle I think via caching all of these connections

After I checked previous discussions, still looking for clarity on these points:

• how the user could choose between connections (in case if they are saved)
• implementation of the best practice for saving the connections on vuex/storage/or on a 3rd party
• prioritizing channels in case of disconnection (e.g. network issues), so that it could automatically connects to the second or third priority connection

[BKristenssonAlfsson]

The first question is very interesting. Now we have a drop down list. Should we have multi select in it?

saving connection will be in Vuex

[sniperadmin]

if our code can handle multiple channels, let's do it multi-select

[ivelin]

• how the user could choose between connections (in case if they are saved)

What do you mean by choosing between connections. Do you mean which device timeline to display or choosing which edge device to connect to?

I think I will create a new UI mockup flow diagram that we can comment on.

• implementation of the best practice for saving the connections on vuex/storage/or on a 3rd party

We can just follow PWA local storage best practice. The UI code interacts with a vuex MagedEdgeDevices structure. We setup a vuex policy to store this structure in indexeddb with a keep-forever retention policy. If the PWA is deleted or browser local data is wiped partially or completely, the user would just have to add back missing edge devices as they did the first time.

• prioritizing channels in case of disconnection (e.g. network issues), so that it could automatically connects to the second or third priority connection

This seems like an overkill at this stage. Since we are practically dealing with 2-3 maybe 5 connections at most, I would treat them as equal peers for now.

[sniperadmin]

What do you mean by choosing between connections. Do you mean which device timeline to display or choosing which edge device to connect to?

Edge device

This seems like an overkill at this stage. Since we are practically dealing with 2-3 maybe 5 connections at most, I would treat them as equal peers for now.

seems right at this point, as it will open new issues for us

[ivelin]

For the multiple devices PR discussion:

@ivelin @sniperadmin

1. To handle multiple PeerID in same connection, I need to store all connections where? pnp.js just handles one connection at the moment, so I guess the action PEER_CONNECT have to be run for each PeerID while we save the old connection without disconnecting from it?

Yes, multiple layers of the UI need to be redesigned to manage multiple vs one device connection. Let's break it into small PRs. The first one could be just updating the data structures to be lists with one element (for now) vs a single RemotePeer connection variable.

2. Timeline will run an EdgeAPI for each connection to then mutate the data into what we want

Yes. All these edgeAPI data streams would be merged into the main timeline view with ability for the user to filter by device, source, time range, type of detections and other parameters in the future.

3. The list that displays the connected Edges will need to get some icons showing state of it (Disconnected, Connecting, Connected)

Yes.

4. The current icon in Navbar.vue with connection state should be removed as it will be in the list view instead.

Right. Or it can be updated to indicate an overall connection health state:

1. Red. UI offline (no Internet access and can't reach PnP server). May need user attention and intervention.
2. Yellow. UI connected to some but not all managed devices. Trying to reconnect to the rest. May need user attention.
3. Green. UI connected to all managed devices. All is good.

[ivelin]

OK, here is a strawman for multi device UI flow. Thoughts?

[ivelin]

So a complete rewrite on settings.vue. Timeline filters might need to be held back for next PR as we otherwise will come in with a huge rewrite. This will also cause some rewriting in pnp.js in order to shape up Vuex better. beeing able to edit a friendly name that has already been set is not possible atm. For now if you try to add in a PeerID that is already inserted, it will not be inserted as it checks if a PeerID is stored.
Considering how big this PR seems to be, I think there should be distinct User Stories handling all sections and we either merge in one at a time, or we will just wrap it up in one huge commit in the end.

Smaller PR scope matching incremental user stories is better when possible.

Smaller PR? How? This PR has the ability to store a friendlyname with it's PeerID. You can then through the dropdown decide which one you want to connect to making it have a memory. Still this only handles one Edge at a time.

Now you want to have an edit component and separate the remote / local function in another component ( which seems to be connected with #466), and have it handle multiple devices at the same time. There is no way we can have a small PR with all this functionality. I did say it before, this is an Epic, where we need to have defined User Stories, but now we end up with an Epic as an User Story.

If we want it small, then this PR should just be polished so it can be merged (as in some styling if needed, maybe code clean up, but some stuff will be needed for future tasks ( like the right now unused getter in pnp.js)), and then we create a new PR to handle multiple instances, which when that is done, we create a third PR to sort out Timeline stuff.

You are right. We turned an Epic into one big User Story. Maybe this is one of these user stories that doesn't make sense to be broken down any further.

The issue I'm having with the friendly name PR in its current form is that it will confuse users. As I mentioned in another comment, users will see that they can enter friendly name for remote peer, but not for a locally discovery peer. They will also see a drop down with a single known device, which makes no sense when they can't add any more devices.

Maybe we scope down the friendly name PR to only update the data structures and unit tests. Move UI changes to a new PR that will introduce a coherent new UI flow for multiple devices that makes sense to end users. WDYT?

[BKristenssonAlfsson]

Why wasn't this said earlier. I recall I asked on a roundtable call and people said to just implement more cards ans a dropdown to select from.
And I did lift the confusion in Settings.vue earlier too.

Only update datastructures? The array is in place, it is tested with Cypress that length is one after it receives an Edge.

Jest testing pnp.js is hard. Me and Nasr have been trying to unit test this file but in vain.

I'll remove the UI changes and make a new push later on.

[ivelin]

If I have this "Edit" component, it only has a pencil for writing a name. Where do the PeerID come from? Or will it be only a PeerID, blank name until the user writes it?

Another reason why I think the current settings page is becoming too convoluted and we need to split it into smaller ones with clear scope. Editing a peer friendly name should be only possible for known peers. During initial connectivity a default friendly name can assigned as New Edge Device 4. This is a familiar experience to users creating a new folder or a new file on their storage drive.

The name is stored inside Vuex with a proper getter so we can access it in any component without problem.

Yes, that makes sense. I already commented on the data structure you suggest. Looks good.

If I press Remote, what will happen? I push out my PeerID to someone else, or I connect to someone else in the flow from #466?

When the user presses Remote, they go into the sequence detailed in this diagram: 5R1-6.

If I receive an Edge, how will it be stored, and under what name?

See above. Assign a default name and once connection is confirmed, let the user change the name and other settings (such as AI pipeline configuration in the future).

[ivelin]

Why wasn't this said earlier. I recall I asked on a roundtable call and people said to just implement more cards ans a dropdown to select from.
And I did lift the confusion in Settings.vue earlier too.

Yes, I remember the discussion. Now that I see how it looks, I changed my mind. Sorry for misleading you.

Only update datastructures? The array is in place, it is tested with Cypress that length is one after it receives an Edge.

See my comments in the PR review. I think we need to do a little better with testing the state machine for the data structure.

Jest testing pnp.js is hard. Me and Nasr have been trying to unit test this file but in vain.

I'll remove the UI changes and make a new push later on.

Not sure what the datastructure will be, and unit testing pnp.js is very hard. The tutorials on how to test Vuex isn't helpful for us. Me and @sniperadmin have tried multiple attempts on it but there just is too many commits and dispatches. We indirectly test it with Cypress though

How about a mockup object for peer that replaces the peerjs implementation with a test mockup that allows tests to control specific state transitions.

We use mockup objects extensively in the edge testsuite to isolate unit test code from third party frameworks interactions with the python app (gstreamer, tensorflow, dynaconf). Example 1, example 2.

[BKristenssonAlfsson]

OK, I see now. I don't think this is the right place for a friendly name. It seems confusing that an auto discovered local network peer would not have a friendly name field, but for a remote manually connected peer does have a friendly name field.

The hardcoded line "My Home Ambianic" is the default value for your own localhost Ambianic

[vickywane]

.

[ivelin]

.

@vickywane @BKristenssonAlfsson

Here is how we can divide and conquer:

1. @BKristenssonAlfsson updates the friendly name PR to only introduce the new data structure and tests for managing multiple devices.
2. @vickywane introduces the new install UI flow using the current, single device management data structures.
3. Depends on who is ready first, we will help the second person with merging their code so the user gets the new UI flow and multi-device support in a new major app version.

Thoughts?

[BKristenssonAlfsson]

Not sure what the datastructure will be, and unit testing pnp.js is very hard. The tutorials on how to test Vuex isn't helpful for us. Me and @sniperadmin have tried multiple attempts on it but there just is too many commits and dispatches. We indirectly test it with Cypress though

[ivelin]

Multiple Edge Device support via PWA is now implemented and merged:
#757