Future network topology (for discussion)

[axillent]

It is for discussion as a result of my discussion with @hek

Main: The idea is to have multi-gateway and multi-physical-layer network.
Multi-gateway means that it could be supported to have multiple Ethernet gateways in a single setup.
Each gateway on one side (from the ethernet side) is a standard MySensors gateway, able to work with supported Home Controll Center using a plugin to that Center. On other side a gateway can manage a different physical transport.
NRF24 can became a major standard but any other type can be supported as well and became a standard one.
for example it can be wired RS485 or CAN, can be wireless RF433 or Zigbee. From the Home Controll Center it should be NO difference which physical layer is used to pass messages to the end node.

Main: Ethernet side can be based on wired connection (wiznet etc.) or WIFI (ESP8266).
New topology allows to setup a network of theoretically unlimited size (in terms of number of nodes and in terms of the physical area). The only limitation - an existing ethernet @WIFI infrastructure. You even can join segments located in different locations.
Comparing to the current topology which is based on using NRF24 routing nodes.

Probably: Because multiple gateways allows to be more flexible on the supporting area and supporting physical layer I will propose to get rid from routing nodes. This will reduce complexity of the Mysensors and improve it stability. Allows to focus on other things like reusing an existing ethernet@WIFI infrastructure

Probably: Serial gateway can be kept for simple setup and for debugging purpose. But should be not in focus any more. Using universal ethernet gateways makes network more robust. For debugging a special IP sniffer can be used without interrupting other network components.
Also sniffing can be used for a new version of the cloud@node (raspberry pi) to have light approach to listen to network and to log configurable events to the MySensors@Cloud

Probably: Routing between different segments/gateways should be introduced. Some limitation can apply for certain physical layers (for example RF433 can be a one way layer, only for sensors like fire alarms, door sensors, motions sensors etc.)

Probably: For NRF24 gateways the BASE radio address should contain gateway@node ID, so there will be no conflicts between sens@nodes from different segments and also it allows to build network with more than 254 sensors while not complicating sens@nodes

[RJ_Make]

Would this be the place to discuss the addition of a security layer?

Anyway, I've been waiting for some stability on the Ethernet side, (seems like I read far more problems then with serial) before I make the switch. Bottom line, this topology looks vastly superior over existing.

[axillent]

@ServiceXp it is better to keep discussion about security separate.

with new topology a discussion about security layer can be limited only to NRF24 physical layer

[John]

@axillent I do get the point, but I'm having some difficulties with the drawing

The controller seems now also acting as a gateway between the home access router and the internet, introducing an extra router like device and immediate access from outside the home/business network.

I would say swap the home router and smart home texts and draw the arrow from the mobile phone to the newly located smart home text.

If the cloud@node is able to access the internet it should have a bidirectional arrow to the home router. It now seems it is able to access the internet just like the mobile without the need of a local access point. To make it more clear of the cloud@node's functionality to be able to access the internet keep the current arrow, and give the internet access arrow a different color, example green. Point the green arrow to the home router and from home router to internet icon.

[hek]

Encryption is handled by the cloud@node right?
Is the idea that gate@nodes post (or keep an data interchange connection open) to both "Smart Home" and cloud?

[axillent]

@John thanks to be so critical in small details))
My picture has no goal to replicate home ethernet network
The goal is only to show links between important components used directly or indirectly by MySensors
But any way, the new picture should reduce number of questions

[axillent]

@hek said:

Encryption is handled by the cloud@node right?
Is the idea that gate@nodes post (or keep an data interchange connection open) to both "Smart Home" and cloud?

in my idea the cloud@node is the node able to listen/sniff for the IP packets coming from sens@nodes to Controll Center. The cloud@node can be configured to filter needed devices and child_nodes and post this data to MySensors@Cloud for the storage, analysis and sharing
I do not assume that anyone else on the network need to take care about cloud@node job

[John]

@axillent Small details can often answer big questions ;)

Does this also mean that controllers would be able to interact with the cloud@node to be able to pass data eligible for remote storage to this instance?

How do you want to listen/sniff packets, broadcast, unicast, multicast? Or is the idea to have dedicated tcp connections to the gates?

[axillent]

@John All is for discussion
I think it will be much more flexible if cloud@node will be working in passive mode, sniffing unicast communication.
Etc. in my scenario sensor@node sends data (temperature for example) through the gate@node to Control Center
This data contains ID of the sensor@node and also child_ID of the particular sensor parameter.

cloud@node will sniffer all unicast packets to Control Center and will filter out IDs not matching it's configuration
Any matching packets will be post to MySensors@Cloud

For me it could be sufficient for the cloud@node to hear all sens@nodes.
Do you see any scenario for the Control Center to post data to cloud@node?

[John]

@axillent
All clear!

I see a lot of opportunities in having a controller post sensor data to the could@node, unless you want to restrict it only to mysensors (which those segments do not imply by the way).

Cheers.

[axillent]

@John OK
but can you provide an example?

the goal of the cloud@node is to collect data from very simple sensor@nodes and pass this data to MySensor@Cloud
he also contain a configuration about what to collect, when and how often

if Control Center needs to record data on MySensors@Cloud it can post data directly to MySensors@Cloud
What could be the additional value of the cloud@node in this need?

[John]

@axillent

The latter would then be the obvious choice, wasn't thinking of that... (discard my last question)

[Swati Sharma]

Network topology is the bargain of the assorted rudiments (links, nodes) of a computer network. Fundamentally, it is the topological arrangement of a complex & may represent actually or reasonably.

link text