Exploring how one might use systems and organise relationships

[Tim_Hoffman]

Hi

I am exploring how one might use systems. So this is less “Help” and more start a discussion

I see two quite distinct ways to organise systems and devices, in terms of physical and logical organisation.

For instance we have a site with electrical equipment deliberately distributed across multiple power and control buildings (3 in fact). This means for instance if we loose power to a single facility we only loose one third capacity. These facilities control equipment for 3 different aspects of the process.

We then have the choice of modelling this system as physical ie what is connected to each facility or logical the aspects of each facility that are directly related to each other.

At the moment devices/systems can only have a single parent so we have to choose one or the other and then try and work with tags to define the other relationship.

So a feature request would be - could a system (or possibly a device) have multiple parents ?

This would allow both expressions of organisation be achieved.

Following that it would also be nice for system tags/descriptions be accessible for us in dashboards this would allow the expression of these organisational structures when visualising.

That’s it for now, I have lots more questions and ideas that I would like to explore.

T

[Tim_Hoffman]

So one approach of collection and displaying the system level description is use webhooks and custom HTML blocks to display that additional information.

It would be nice to allow some dashboard widgets (especially titles) to be derived from devices

[anaptfox]

Hi @Tim_Hoffman,

You have some good points/questions that I’m going to address individually

We then have the choice of modeling this system as physical ie what is connected to each facility or logical the aspects of each facility that are directly related to each other.

Yes, you do have the choice. The defining feature of Systems is Data Propagation.. Looking at an example:

The aggregation in this example is a sum. Each parent system is taking a sum of an attribute across all of its children. All of the children just represent the presence of a person ( 0 or 1 ). Before systems, yes you can have all of these as tags but answering the question of: “How many devices of this tag are of value 1?” or relating to the problem (each device is a seat in a row of seats) “How many seats are filled for a row?”. Then, the problem gets harder when you want to say “How many people are in all of the rows combined?”. Systems are the answer to these questions.

Systems are a device type. The grouping of systems is really focused on data relationships. In your instance, deciding if it should be a system or not should be about data relationship. Depending on the use case, it could be logical or physical, but I think it’s best to think about Sytems from a physical relationship.

At the moment devices/systems can only have a single parent so we have to choose one or the other and then try and work with tags to define the other relationship.

So, yes. You will still use both. Since systems are devices and only define data relationships, you still need a mechanism to logically group devices. You can’t really say “give me all the devices in this system” (as you would using tags) Correction:You can using a Parent ID Query in the Device: Get Node, but you still can’t query systems devices in all the same ways you would tags.

Systems answer different questions (see above).

Following the example from above:

If you notice, there is a system for “Losant Row 2” but there is also a tag row of 2. The system allows me to capture the data relationship, and the tag allows me to query and group devices logically.

So a feature request would be - could a system (or possibly a device) have multiple parents?

This was discussed internally. Since systems really focus on the data relationships, and systems can be parents of systems, which are parents of devices and so on. It would be really difficult to calculate (and understand) the system attribute value the more complex that tree is.

Following that it would also be nice for system tags/descriptions to be accessible for use in dashboards this would allow the expression of these organizational structures when visualizing. It would be nice to allow some dashboard widgets (especially titles) to be derived from devices

You should check out: https://docs.losant.com/dashboards/context-variables/

Currently, you can use device name, description, and some other things all throughout your dashboard. But, it looks like attribute tags/descriptions don’t flow through. I’ll make a ticket for that.

As always, we appreciate your discussions. Let me know if this helps!

[Tim_Hoffman]

Thanks for the discussion. I need to digest this a bit more and will come back with more questions.

The interesting bit of my puzzle for modelling (in a specific example) is the relationship starts out physical then transitions to logical for aggregation. (So when I say physical I mean on the ground installation and wiring and piping, physical affects maintenance etc)

4 x HP pumps -> 1 x physical MCCA (flow for train) ->   |
 .                                           | ----> Logical grouping (High Pressure Water) (Total Flow)
4 x HP pumps -> 1 x physical MCCB (flow for train) ->   |

Then there are higher levels up from there.

Alongside this particular instance another set of physical devices in the same MCC as the above example but with a different logical grouping/function with a there own collective logical parent and their outcome.

4 x ST pumps -> 1 x physical MCCA (tonnage for train) ->   |
     .                                           | ----> Logical grouping (Slurry Transfer) (Total Tonnes)
4 x ST pumps -> 1 x physical MCCB (tonnage for train)->   |

So it would seem that MCC component should in fact be non physical or if physical a subset of the real set at that level.

An aggregation of total KW per MCC which needs the ST and HP pumps on the same MCC would not be able to propagate using systems if I address tonnage and flow (which is what we report on). Hence the conflict/tension between logical and functional/physical hierarchies

As to context variables, they seem to have limited value when creating complex dashboards showing multiple device values.

This means I spend a lot of time placing device name in the header of each gauge. It would be great to use templates to insert (name, description, or tag values) of the device selected in the gauge. That would also save enormous amounts of time when clone widgets . Especially indicators and gauges.

Thanks for all the on going evolution of the platform.

Cheers

T

[Kevin_Niemiller]

Hi @Tim_Hoffman,

I am going to try and answer some of your System aggregation questions using the example you provided (thanks for providing that example by the way - it makes it a lot easier to understand and provide an example in return).

Systems can handle more than one attribute for aggregation. In the screenshot below, I am showing your HP Pumps with attributes of flow and power and then your ST pumps with attributes of tonnage and power. From here on up the System tree, every System device has 3 attributes -> flow, tonnage, and power.

Now we have the ability to go to any System (MCCA, MCCB, etc.) and see the total flow, tonnage, and power for that System. An example of this is shown below for the highest level System, Facility 1.

We are going to add you to the application that I created when making this example so that you can dig in further if you would like.

I hope this is helpful. If you have any other questions please let us know!

Thank you Tim,
Kevin

[Tim_Hoffman]

Hi Kevin

Thanks for that, I can how we need to pull the details up to a higher level.
Now we need to plan naming etc… which is fine

In reality we would have flow and tonnage for the ST pumps and just flow for HP pumps.

Thanks for the walk through.

Cheers

T