When to Use Separate Networks?

[DonpK]

I have a Gateway displaying data from a weather sensor Node. I also have another Gateway displaying different data from several soil moisture Nodes.

Are there any "good practices" about when to set up separate Gateways/Networks?

[TomWS]

I have a Gateway displaying data from a weather sensor Node. I also have another Gateway displaying different data from several soil moisture Nodes.

Are there any "good practices" about when to set up separate Gateways/Networks?

There certainly are a wide variety of practices, but I'm not sure there is a 'right' one.  I think, first and foremost, separate gateways should operate on separate networks, simply to keep the traffic limited on each. 

But why have separate gateways?  Well, if you have distinct 'regions' on your property that are widely separately physically, having a gateway for each region is a good thing, keeping the distance from node to gateway within reachable bounds.  Also, if you have separate 'logical' regions, you might have multiple gateways - in my case, I have a 'household/landscape/ gateway and I have a 'workshop' gateway.  This keeps my Dust Collector Remotes off the household network and localized to the workshop where they belong.   

This then brings up the pragmatic approach to the question.  If I want to install a mailbox monitor, it's too far away from the household/landscape gateway unless I do something drastic.  However, it is well within reach of my Workshop gateway.  Guess which one I'll use...

UPDATE: one more thought, since the backend of both of my gateways is MQTT messaging, it doesn't really matter which gateway a node is connected to, all messages will get funneled through the central MQTT broker anyway.

Tom

[DonpK]

Thanks, Tom, for the overview.

I'm curious how you have implemented Moteino in you dust collection setup. I am still using the ancient X-10 technology to control my dust collector. I have an X-10 key fob transmitter which activates an X-10 receiver with a contact closure output. This closes a 120VAC relay which in tern closes a 240VAC relay turning on the dust collector.

Do you have a Moteino transmitter at each piece of  equipment which controls a gateway receiver which turns on the dust collector motor? Are the transmitters automatically activated when a piece of equipment is turned on or do you do that manually?

[TomWS]

Thanks, Tom, for the overview.

I'm curious how you have implemented Moteino in you dust collection setup. I am still using the ancient X-10 technology to control my dust collector. I have an X-10 key fob transmitter which activates an X-10 receiver with a contact closure output. This closes a 120VAC relay which in tern closes a 240VAC relay turning on the dust collector.

X10 was my second generation implementation (my first was made out of custom 433MHz garage remote technology).  It worked about as well as one would expect X10 to work - make sure you cut off main DC power when you're not in the shop as X10 tends to have a mind of its own sometimes.  BTW, in that implementation I used a Rain8 X10 Irrigation module to drive the air valves.  That worked well for an easy to implement solution.

Do you have a Moteino transmitter at each piece of  equipment which controls a gateway receiver which turns on the dust collector motor? Are the transmitters automatically activated when a piece of equipment is turned on or do you do that manually?

My projects have been posted, but it's been a while and have been updated significantly.

For details, see:
https://lowpowerlab.com/forum/projects/controller-for-workshop-dust-collector/
https://lowpowerlab.com/forum/projects/remote-for-the-dc-controller/

The current version of the controller replaces the Moteino implementation with an ESP8266 monitoring MQTT messages from the DC Remotes.  The SW on the remotes has been upgraded to talk to my newer gateway, which, in turn, produces the MQTT publications. 

Logically it's the same, just different fabric. 

Each remote monitors the current drawn from one or more pieces of equipment and each are bound to a particular zone, with each zone representing a blast gate on a particular branch of my ducting.  When some equipment turns on, the DC controller gets the MQTT publication and opens or closes the respective blast gate (via pneumatic valves/cylinders).  There are some additional timing and lockout functions (making sure the gates aren't all closed when the DC is running or letting the DC run for a while after one piece of equipment is turned off so I can move between tools without having the DC continuously turning on or off).

Tom

[DonpK]

Thanks, Tom, the the description and links. Very impressive!

[Sergegsx]

The current version of the controller replaces the Moteino implementation with an ESP8266 monitoring MQTT messages from the DC Remotes.  The SW on the remotes has been upgraded to talk to my newer gateway, which, in turn, produces the MQTT publications. 

Tom

Hello Tom,
could you give a very quick insight of how your MQTT system works? Just the key points. where do you store the data, what do you use to graph it.
thank you.

[TomWS]

Hello Tom,
could you give a very quick insight of how your MQTT system works? Just the key points. where do you store the data, what do you use to graph it.
thank you.

Since this will be a brief answer, I'll post it here, but if it becomes a 'conversation', I'll split off to a new thread.

My network, as you can imagine, has had a number of evolutionary changes, with each element going through incremental changes.  My switch to the new gateway was, in a sense, a large change, but not a major change to the overall structure of my system.  Consequently, it is still evolving and the MQTT part of it is in it's infancy.   My system has always posted sample data to a local MySQL database on a local server, from there, various tasks would fire periodically and collate the collected data into respective tables (temp&Humidity, rainfall, water usage, power usage, etc).  This data is accessed by local custom webpages for local review and presentation, and also collated hourly to gather and send to my Webhosting server, where I can access it offsite.  This way I don't open my LAN to remote access, but I can still see what's going on no matter where I am.  Nothing tricky or sophisticated.

I'm in the process of deploying a RaspberryPi that will have sensor type specific node.js apps that subscribe directly to the MQTT messages and collate the data in real time.  And the purpose of all of this is to keep me off the streets and out of other people's way 

[Sergegsx]

Since this will be a brief answer, I'll post it here, but if it becomes a 'conversation', I'll split off to a new thread.

My network, as you can imagine, has had a number of evolutionary changes, with each element going through incremental changes.  My switch to the new gateway was, in a sense, a large change, but not a major change to the overall structure of my system.  Consequently, it is still evolving and the MQTT part of it is in it's infancy.   My system has always posted sample data to a local MySQL database on a local server, from there, various tasks would fire periodically and collate the collected data into respective tables (temp&Humidity, rainfall, water usage, power usage, etc).  This data is accessed by local custom webpages for local review and presentation, and also collated hourly to gather and send to my Webhosting server, where I can access it offsite.  This way I don't open my LAN to remote access, but I can still see what's going on no matter where I am.  Nothing tricky or sophisticated.

I'm in the process of deploying a RaspberryPi that will have sensor type specific node.js apps that subscribe directly to the MQTT messages and collate the data in real time.  And the purpose of all of this is to keep me off the streets and out of other people's way 

just ended up in here and noticed I never thanked you for your answer!
it just happens that I am right now in the same situation as you, various different communication systems (radio, wifi, ethernet) with different platforms (esp8266, moteino, custom boards, etc) posting via different methods (http, mqtt, radio to Raspberry to mysql).

Still deciding what to keep and what to eliminate in order to have a more maintainable system.
Its quite hard to change from the concept of sending data to mysql in a single line with various parameters towards the mqtt where each message only has one data and is saved in tables in a completely different way.

[TomWS]

just ended up in here and noticed I never thanked you for your answer!

Well, you waited long enough that everything has changed!   

I now have node.js 'apps' running in my home server that catch the MQTT messages from my gateway.  The MQTT schema has changed so that a subtopic identifies the mote's type.  Each app is tailored to a specific type or class of mote and they only subscribe to topics of that class.  The apps, in turn, parse the MQTT message and, among other things, save the posted data in the appropriate MYSQL table.  No further collation is necessary and the data is fresher.  All the apps are managed by PM2 so it's easy to start/stop/update/restart the apps individually or as a group.