So who's in charge here?

[BenCranston]

After a few interactions I figured that I should open a new thread.

This is for the purpose of discussion the control roles in a Mote network.

Is the gateway the ultimate point of control?  Should the Motes listen and respond with status or requested data?

Is the Mote better suited to do some compute and tell the gateway of it's capability.  Managing it's functions and interacting with the gateway as it is needed by the Mote?

Where is the balance?  What are the practical experiences of the community?  Is there a protocol decision that should be considered that would tip the role in one direction or the other?

thoughts? 

[TomWS]

Interesting thread and questions. 

In your response to my post in the other thread, you asked what influenced my decision to use a 'pull' model for code download, simple:

Most of my motes are battery operated (not 'most' in quantity, but 'most' in distinct types) and, once they're deployed, I want these to run, literally, for years before I need to replace the batteries.  I can't have them constantly listening for commands.  They wake up, take a measurement, report the measurement and expect that the gateway will tell them if something needs attention via the Ack back (which is one REALLY cool feature of the Moteino RFM library - you can essentially send an entire packet back in the Ack data!), then they go back to sleep. 

Environmental data (Water Feature Levels, Moisture, Temperature, Humidity, etc) don't change rapidly so a 10 minute reporting interval is more than often enough.  Figure the whole RF transaction takes about 10-12mS, that's a pretty low duty cycle!  It might take few seconds to take a reading for some sensors, but the radio is kept off until the very last instant that it's needed.  Based on my calculations (and experience) with this model, the power consumed by the radio has very little effect on battery life - and I use RFM69HWs...

Also, I try not to put too much 'smarts' in the Gateway.  That stuff just gets in the way of any changes I might want to make with respect to overall Home Automation control.  For example, my liquid level sensor simply reports on the current level of the water in my stream.  The gateway passes it on.  There is a daemon in the Home Server that handles auto-filling Water Features (actually, that's a cron job, but you get the picture) and, if the level is too low in the stream, based on limits that I can set in my database, the auto-filler knows which Moteino based water valve to turn on (and for how long). Gateway just passes messages back and forth...

UPDATE: I should have mentioned that AC powered Motes stay 'on the air' so they can get updates immediately - the Gateway is 'smart' enough to know that...  But control is still centralized at the Server, not the Gateway.

Tom

[Felix]

As Tom pointed out in most cases it makes sense to keep a lot of the control centralized where you have more power available and want to be in RX mode all the time.
But that doesn't mean it always has to be that way. For instance the SwitchMotes can talk in between themselves without a gateway. They can SYNC and tell each other to "push" a button. I should add these are always powered as well so can afford to be in RX mode to listen for any incomming commands.
So there are no hard rules, just common sense sometimes suggests a certain approach.

[Emil]

Is the gateway the ultimate point of control?

It might be best to define the terminology being discussed here. One popular definition of the gateway pattern:

A gateway provides a simple uniform view of external resources to the internals of an application.

By that definition, a gateway is never in control. Typically control resides in one or more

Should the Motes listen and respond with status or requested data?

Sometimes the requirements dictate this type of node, always listening so it can instantly perform a command (e.g. turn on the music) or provide immediate status (e.g. what is the current sensor value?).

Sometimes the requirements call for nodes that are usually sleeping (to save power) that wake up, send or check for new messages, and go back to sleep.
If messages need to be reliably delivered to the sleeping node, then a store-and-forward pattern is commonly used.

A store and forward pattern uses an intermediary to hold messages that and then made available to the receiver when it becomes available.

Often you will deploy both types of nodes. Some always on, some usually sleeping and only occasionally on.

A properly designed gateway can offer your "control" a unified view of these networked resources as well as other types of resources (XBee's, Sonos speakers, etc.)

Not sure if I added anything to the discussion.

Emil




For your Moteino