I run out of memory space for my sketch on my Yun so I’m thinking to add a second board to my project.
The reason why the sketch is so big it’s because I’m monitoring several different sensors (water leak, temperatures/humidity, temp from thermistor, display to LCD, Blynk (remote access), sending out SMS and emails alerts.
Having two Yun boards I can easily separate the tasks. Yun1 will monitor my hardware (sensors) and Yun2 will do the internet communication.
When Yun1 detects a problem with a sensor, flags a digital pin say, 4. The latter is connected to pin 4 on Yun2. A sketch on this board monitors pin 4 and sends out an email if triggered.
So there’s a direct wire from Yun1 digital pin 4 to Yun2 digital pin 4.
Probably it’s not the best way to go, but it may be the fastest.
Without seeing your code it is hard to know how efficiently you have written it. In my experience adding a second processor board is almost always not necessary.
From a very quick look at your program why not do all the email stuff on the Linux side of the Yun where there is far more processing power and far more memory.
I followed the suggestion above using Command Line with Gmail (Msmtp) and worked from Linux but I cannot get the sketch to send out the cmd string.
How to concatenate a cmd string?
TIA
EDIT: The following code solved it.
#include <Process.h>
String cmd = "echo ";
String cmd1 = "\"body of my email \"";
String cmd2 = " | mutt -s ";
String cmd3 = "\"test my mail \"";
String cmd4 = " emilio@mydomain.net";
void setup() {
Bridge.begin(); // Initialize the Bridge
Console.begin();
while (! Console) {
Process p;
p.runShellCommand(cmd + cmd1 + cmd2 + cmd3 + cmd4);
// do nothing until the process finishes, so you get the whole output:
while (p.running());
}
}
void loop() {
}
sonnyyu:
Use Linux shell script make code easy readable and easy debug.
I agree that this is the way to go, whenever possible. Use the sketch to do any low level I/O with sensors and actuators, and try to do as much of the rest of the processing as possible on the Linux side.
Examples of ways to take sonnyyu's code even farther:
Is the email address always the same? Put it in the script and don't pass it as a parameter (saves memory in the sketch, and saves sketch/Linux communications time.)
Same for the subject: is it always the same?
How about the body? It's short now, presumably because you are testing. Will it be larger, perhaps lots of fixed text and a few variable fields? Consider passing just the variable items and have the Linux code format it and build the message body.
How about the logic to decide when to send the message? Does it make sense to just send raw sensor values to the Linux side and have the script do the calculations and decisions? (Could be yes if the data rate is low and the calculations are complex; probably not if the data rate is very high and/or calculations are trivial.)
It may seem daunting at first, because it is different. But once you get some familiarity working with the SSH command line and editing files on the Linux side (or setting up a file transfer method like SCP and editing the files locally on your computer) you may find that maintaining the Linux side code is faster and easier than constantly updating and uploading the sketch. But even if the Linux code updates are a bit more tedious than updating a sketch, the Linux side processor is faster and has much more memory (code and data) than the sketch processor - making use of it can really help out when the sketch memory constraints get too tight.
ShapeShifter:
...
Examples of ways to take sonnyyu's code even farther:
Is the email address always the same? Put it in the script and don't pass it as a parameter (saves memory in the sketch, and saves sketch/Linux communications time.)
Same for the subject: is it always the same?
How about the body? It's short now, presumably because you are testing. Will it be larger, perhaps lots of fixed text and a few variable fields? Consider passing just the variable items and have the Linux code format it and build the message body.
How about the logic to decide when to send the message? Does it make sense to just send raw sensor values to the Linux side and have the script do the calculations and decisions? (Could be yes if the data rate is low and the calculations are complex; probably not if the data rate is very high and/or calculations are trivial.)
...
Wrote ash shell script takes optional input arguments:
nano /mnt/sda1/sendemail2.sh
#!/bin/ash
/bin/echo "${1-body of email}" | /usr/bin/mutt -s "${2-subject of email}" "${3-somebody@gmail.com}"
chmod 755 /mnt/sda1/sendemail2.sh
/mnt/sda1/sendemail2.sh
/mnt/sda1/sendemail2.sh 'body of email2'
/mnt/sda1/sendemail2.sh 'body of email2' 'subject of email2'
/mnt/sda1/sendemail2.sh 'body of email2' 'subject of email2' somebody2@gmail.com
ATmega32u4 code:
p.begin("/mnt/sda1/sendemail2.sh");
p.addParameter("body of email"); // optional
p.addParameter("subject of email"); // optional
p.addParameter("somebody@gmail.com"); // optional
/bin/echo "${1-body of email}" | /usr/bin/mutt -s "${2-subject of email}" "${3-somebody@gmail.com}"
Cool! I wasn't aware of that default parameter value syntax. That can come in handy.
ATmega32u4 code:
p.begin("/mnt/sda1/sendemail2.sh");
p.addParameter("body of email"); // optional
p.addParameter("subject of email"); // optional
p.addParameter("somebody@gmail.com"); // optional
It's worth mentioning that while the parameters are optional, if any parameter is included, all parameters before it must also be included. So it can be called with:
No parameters
Body only
Body + subject
Body + subject + address
But you cannot call it with just an address, or just a subject. This is all implied by the command line examples provided above this, but it's worth mentioning it explicitly in case this subtlety was missed by an inexperienced reader.
but I'm a quick learner!