Distributed communications ideas?

Official Hardware Classic Yún
1

First post here. While this is a a "project ideas" sort of post, it's quite specific to the Yun so I hope it belongs here and not in the general project ideas forum. I'm sorry for the length, but I figure it's better to get the background in first, rather than providing it later after inappropriate suggestions are made (trying to avoid the "why didn't you say that before?" situation.)

I'm working on a distributed data collection and control system that I will be putting in my motorhome. It will consist of several modules placed around the motorhome with various sensors and inputs, and relay outputs. There is too much total I/O, and it would require too many difficult to run long wires, to do it all with a single board. The distributed modules will communicate with a master control module to report input states and respond to output change requests. The Yun seems ideal for my system concept: hard real time and hardware intefacing done on the Arduino side, while the communications processing is done on the openWRT side. One Yun will be the master, and serve as a Wi-Fi access point that the other Yuns will associate with. The master Yun will also have a wired ethernet connection to a router to give it access to the outside world.

I have over 30 years embedded system development and I think I have the hardware end of it sorted out pretty good, along with the low level control code. However, while I have done lots of serial communications, and a little bit of network sockets programming, and I understand the principles of TCP/IP, I'm not an expert on network communications and I need some communications suggestions.

Embedded programming is my life, so I'm looking for easy solutions for this project, I don't need this to be a science project and write code for the sake of writing code. I just want to make this thing work. Therefore, I'm really looking for established solutions wherever possible. One big limitation is that the Internet connection through the router is not full-time: there will be long periods where no connection is available. And when it is available, it will be through a cellular connection with expensive and limited bandwidth. So a cloud based service (Xively, ThingSpeak, etc.) is NOT going to be a solution. Temboo may have some utility for sending unusual event notifications, but not for data collection or storage.

There will be lots of inputs, but the data rates don't need to be very fast: somewhere around once a second to once every ten seconds should be enough. Mostly, I want to collect and log values/statistics of the input data. But I also need a little bit of logic to watch for various input occurrences, and control some output relays accordingly. I want to be able to see the current status locally and remotely, and remotely control various outputs or initiate automated sequences. (Yes, I know I won't be able to do that when the Internet connection is not available.)

This thread on collectd is very interesting: HOWTO for simple monitoring and WWW graphs - Arduino Yún - Arduino Forum That could be a solution to gathering data from all of the nodes and storing it at the master using round robin databases that give high resolution for a short period, and lower resolution for longer periods. It also gives some historical trend plotting abilities. Is there a different option out there that would be more appropriate?

Something like that seems good for the statistics side of things. For the control side, I'm picturing something along the lines of the Arduino code collecting input data and using Bridge.put() to store the current state. Then, a Python script on the master side would access http:/ /arduino.local/data/get to fetch the entire input state at once. The master does this for each remote node, and collates the data. It then decides if any outputs need to change, and sends bridge mailbox messages to the proper Yun to make the output happen.

Does this sound like a reasonable approach? Are there better options?

I'm not looking to make a career out of developing this code. I don't need super high data rates, so efficiency is not the prime motivator. Ease and reliability, and low development effort are the prime considerations.

Any suggestions are very much appreciated.

2

I would say you're on the good way. Please remind that the computational power of the yun is limited: it's now slow, but some software just require more power as they expect to run on recent environments.

Therefore I would prefer an approach where the master yun only collects data: making reports, crunching data to change its resolution depending on how old it is, it's a task that I would give to another computer.

3

Thanks for the confirmation and information! My original concept was to use several Arduinos with XBees talking to a master node that is a Raspberry Pi or similar class machine. I was not looking forward to developing a communications protocol for it (been there, done that, takes too much time and code space.) Then I found the Yun and it seemed like the communications answer.

I will put a more capable master node into the plan. Is it still reasonable to use one of the Yuns as the access point for the other Yuns and route the collected data to the wired Ethernet? In that case, the master node would be on the wired network. It seems that most of the RPi and similar class boards have no native WiFi, and I'm not thrilled with the idea of trying to add it via USB.

What do you think of the idea of using http:/ /arduino.local/data/get to fetch the current data state? Or would I be better off trying to write a collectd custom writer module to extract the data from the collectd stream? Seems like a toss-up for the development effort, but the latter would lessen the load on the Yuns and the network.

4

ShapeShifter:
Thanks for the confirmation and information! My original concept was to use several Arduinos with XBees talking to a master node that is a Raspberry Pi or similar class machine. I was not looking forward to developing a communications protocol for it (been there, done that, takes too much time and code space.) Then I found the Yun and it seemed like the communications answer.

Yes indeed :slight_smile:

ShapeShifter:
I will put a more capable master node into the plan. Is it still reasonable to use one of the Yuns as the access point for the other Yuns and route the collected data to the wired Ethernet? In that case, the master node would be on the wired network. It seems that most of the RPi and similar class boards have no native WiFi, and I'm not thrilled with the idea of trying to add it via USB.

Yes. Yun CPU and linux distribution was born in the network router world, so forwarding network data comes natural.

ShapeShifter:
What do you think of the idea of using http:/ /arduino.local/data/get to fetch the current data state? Or would I be better off trying to write a collectd custom writer module to extract the data from the collectd stream? Seems like a toss-up for the development effort, but the latter would lessen the load on the Yuns and the network.

It's definitely good for a first implementation. It greatly depends on the rate of requests. Start with that and monitor it. Switch to something else once you have measured the improvement this "else" brings.

5

Update: I'm making progress, even with the limited time I have to work on this. I started with the most unknown portion of it to make sure it works: collectd. While the topic on it that I referenced above works, there was a more recent topic with an interesting twist, using LuCI: HERE

Using the built-in user interface, it was easy collecting machine statistics, and even sending them from one machine to another. That just left the matter of getting the custom sensor data into the stream. I figured the Python plugin would be a good way to go, but that plugin is not available on OpenWRT. But the above linked thread uses the exec plugin with Python, so I built on that: HERE. That was my first foray into Python. I have plans to make it more generic.

In this project, I will have several Yuns collecting data and I want to try to run the same generic sketch on each one: basically reporting the pin states, analog inputs, and OneWire temperatures in a generic manner (somewhat like Firmata.) The mapping from generic pin number to meaningful signal name would be done by this script as it copies data from the sketch to collectd. Reasons: more memory to perform string manipulation on the Linux side, and easier to configure/maintain without needing to modify and upload a sketch each time. Once in the local collectd database, the collectd network plugin will then be used to move the data from each remote Yun node to the master node for display/analysis.

The steps I need to do now:

  • learn much more about Python, and figure out the best way to handle configuring this script. I want the main body of the script in a generic file, and the per-node configuration in a different file. To do this, do I:

  • use an include file that has the code to initialize a key:value data array?

  • read and parse a data file that includes key:value pairs?

  • find an existing configuration data management method?

  • ? ? ? ?

  • learn more about how LuCI displays these graphs. On the remote node, I can see all of the data. On the master node, I can select whether it shows the master's local data, or the data from the remote node. However, the only remote data I can show is that data which is also collected by the master node. In my eventual system there will be lots of data collected by the remote node(s) that is not pre-configured in the master. How do I display that?

  • figure out how to tell LuCI about that data?

  • force all of the possible data into the local RRD database, adding dummy data? (Yuk!)

  • Write custom web pages using rrdcgi?

  • ? ? ? ?

  • The network plugin only forwards the data as it is collected. If the master node goes down (or the network goes down) any data collected by a remote node is only available on the local node. I need to figure out if there is a way to synchronize this historical data when the network comes back up. (Probably not, since RRD won't accept any samples older than the last sample processed.)

  • plus I will still have to learn a lot more to overcome the hurdles I haven't even seen yet.

I've got a lot of research and learning to do. I just wish my real job and the rest of my life (like yard work!) didn't take up so much if my time, I hardly have any left over for fun like this!