Modularisation

[skalpt]

As per our call this morning, I think the best product to start with would be the remote switch. However, I am now thinking we could take this a step further.

What if we were to design the remote switch as a Base Node, on which all other modules could be attached? So imagine a cube, which has a wall plug on one side and a power socket on the other. On some other side of this cube, you could have a Module Connection Socket. Then let's say that I want to add a current sensor, a temperature sensor, or even an infra-red receiver so I can control the powerpoint from a remote. Each of these would be an Add-On Module, and could be purchased and plugged into the Module Connection Socket on the Base Node. All Add-On Modules would have the ability to switch the power in the Base Node on/off, and report back to the Master Receiver. Also each of the Add-On Modules would have a Module Connection Socket of their own, allowing multiple Add-On Modules to be connected to a single Base Node.

Alternatively, we could sell each module as its own stand-alone node. Advantages of the stand-alone approach would be:

• Keeps the product simple
• If I want a temperature-controlled switch, I only have to buy one node (rather than a Base Node and an Add-On Module)
• Still possible to connect multiple nodes in series (e.g. wall socket -> remote switch -> temperature sensor -> infra-red receiver -> current sensor)

Disadvantages would be:

• Stand-alone nodes will be more expensive as they will need to contain their own processor and wireless communication. Add-On Modules would only contain a single sensor and addressing interface, all processing and communication would be managed from the Base Module.
• Connecting multiple nodes in series could make it difficult/confusing to manage remotely (e.g. how can I tell which temperature sensor is connected in series with a particular remote switch?)
• Some limitations, e.g:
  • I want my infra-red receiver to override the fact that the temperature sensor has turned off my device. Not possible.
  • I still want my temperature sensor to log temperature when the remote switch is off, but I can't place it in series before the remote switch because I don't want the temperature trigger to turn the remote switch off.

What are your thoughts?

[skalpt]

De-Pa commented: Everything goes back to master for control; no override so, for example, infrared receiver can override temperature sensor. Redundant switches in series -> 1 off = all off; in parallel -> 1 on == all on: use series/parallel block so customer can decide Infrared receiver doesn't control anything; it goes back to the master which controls whatever Temperature sensor can sit on any socket in the room

Problem with all this is that it may be difficult to set-up the control in the first place; we want any old dummy to be able to do a standard set up with more intelligent users able to 'get into the controls' to do more sophisticated things.

Ok good ideas, but you can't implement any of this with stand-alone modules. Imagine you're stacking double adapters together. Switch the first one off, and you're switching off all of the ones after that. So anything that is supposed to be switching or logging information further down the line, isn't getting any power supplied to it.

So, I think it is important to identify a "master node" in a collection of nodes on a single powerpoint. To keep things as simple as possible, it seems like the easiest option would be to go with the original idea of designing the remote switch as the "master node", and the only product that actually has a powerpoint plug/socket on it. Everything else would plug into the side of this "master node".

Of course, that goes against your suggestion to allow the temperature sensor to sit on any socket in the room. It would have to be coupled with a remote switch a.k.a. master node. Same with a current sensor. Let's say I just want to measure how much current my fridge is using, I wouldn't want to be forced to put a remote switch there just to be able to plug a current sensor in the side. I certainly wouldn't want to accidentally turn my fridge off!

How about this as an idea. Create every product as a stand-alone node, with it's own powerpoint plug/socket to allow you to plug them in series. Only allow the remote switch node to switch power on and off, and remind users that it must be placed at the end of the stack. If a temperature sensor needs to switch off the power, it must inform the remote master, which will pass the instruction on to the relevant remote switch node. Give each node a unique address, and allow non-switching nodes to be linked to a switching node in the front-end application.

[De-Pa]

When I think of constructing actual systems, I keep seeing:

• a master that acts on thresholds (stored in the cloud), does stuff depending on links (stored in the cloud) between sensors and actions, turns things on and off as triggered by times (stored on the cloud) etc for everything in the house.

While I think you keep seeing:

• autonomous 'mini-masters'; one is a timer physically linked to a switch, another is a link between a sensor and a switch. The triggers in each mini-master is updated from the cloud via the 'house master node' and in any cluster there has to be a heirarchy to decide what overrides what.

The former plan is more reconfigurable using software, but requires a complicated house master that has to be in-place from the start while the latter is easy at the start but may be confining in the longer term?

How about we try to 'make' a complicated system in software emulation/block diagrams etc and see how easy it is to do all the things we would like to? This should highlight problems. In particular, perhaps we will be able to see where the smarts reside and how they will work, what is stored in the cloud and how we get the devices to talk to the cloud.

[De-Pa]

So consider the system design for a switch, which can be activated by a timer, a temperature sensor, from the internet (eg cause you want to turn it off from your phone while on holidays) while being monitored by a current sensor that stores the power useage every 5 minutes for later downloading (or turns the switch off if there is a direct short). Ideally, the temperature sensor can be placed away from the switch (which is near the floor and close to the heater it controls); perhaps it is battery powered and reports when the battery is getting low.

[De-Pa]

Alternatively, perhaps we recognise that we want to keep everything very simple (and cheap), and so accept that we can't do complicated things?

[skalpt]

a master that acts on thresholds (stored in the cloud)

What if there is a temporary connectivity issue between the master and the node? Should the entire system fail whenever the master is out of range or the lnternet is not available? What if we were to move the source of truth (and inter-node comms) to the nodes themselves? The master would then be responsible for:

1. Pushing new triggers/settings entered by the user from the application to the nodes

2. Pushing status/sensor data from the nodes to the cloud for storage. Although the nodes are now the source of truth, all of their data should still get pushed to the cloud whenever possible because:

   1. You should be able to bring up a dashboard on the application and see the status of all nodes without having to ping them all immediately. In other words, the data should be cached by the application. If it gets out of sync (because the master/Internet has been offline during a status change), the user would be able to click a 'Refresh' button against that node which would ping the node for an update. Obviously a node should also keep trying to communicate with the master when it has an update to send. (This probably makes the 'Refresh' button obsolete though.)

      De-Pa: but there is nothing like 'I want to know what the current is now' when the regular refresh rate is once per 10 minutes

   2. Sensor data should be stored somewhere that:
      1. Has the capacity to store unlimited historical data
      2. Can be viewed from anywhere.

3. Storing data whenever the cloud is not available, for pushing later. For this reason, the master should have an SD card socket.

   De-Pa: yeah

The application (web-based, stored on the cloud itself) would be responsible for:

1. Storing data in the cloud
2. Providing the UI to create triggers
3. Providing the UI to display sensor data and decipher it (using graphs, etc.)
4. Remembering default links between sensors and controllers for creating new triggers

[De-Pa]

So perhaps it is time for another block diagram, more complicated and saying what happens in each area, as well as a block diagram for my switch above, again saying what is done where. Note that devices on a mode may be virtually connected, but physically not connected, such as the temperature sensor.

[skalpt]

Actually I think it is time for a few block diagrams, to illustrate the flow of data in each of these steps:

1. Setting up the master (pairing it with an online account)
2. Setting up a node (pairing it with the master)
3. Setting up a trigger (application interface, flow of data, and how/where the trigger is stored)
4. Acting on a trigger (how one node triggers another, and reporting back to master/cloud)
5. Logging data (flow of data from node -> master -> cloud, including redundancy plan for each link)

So get on with it baby :)

[skalpt]

but there is nothing like 'I want to know what the current is now' when the regular refresh rate is once per 10 minutes

Ok, so the 'Refresh' button does have a purpose then.