If it really is just latency, and a local server is the only solution, then that may be the only way to go. It just increases the hurdles to be overcome - dedicating a computer to the server job, powering it continuously and of course the setup expertise required.
My own situation is that I will be away from the property for several days every month, and wanting visibility of my sensors when I am away, so the satellite link will be involved inevitably. I suppose that works OK, but the quality of the data I am seeing on my phone is hard to assess because I know the data is not getting to your server reliably.
It’s not the only way to go and if you are regularly away from your property then local server via satellite is probably a bad choice. I would stick with the cloud and build lots of checks into the code.
5V and 1A with a $10 Pi is not a huge burden.
Just code up “retry” when the satellite gives you poor results.
Ask the satellite company if they can preposition their satellite at 1000m over Sydney.
@farmerkeith I think you are drastically overestimating the complexity, cost and maintenance needs of a Blynk Local Server. As per @Costas, an RPI is more than enough for the job, but you can easily install it on your PC just to get the hang of it before committing to the “expense” of an RPI.
Local Server was one of my first Blynk projects 7 months ago… It was very basic for me to set up. And I have mine running on an old Acer Aspire netbook with 1GB RAM and 4GB SSD, running Linux Mint… very low end. And the main job for that netbook isn’t even Blynk, rather it is a repeater for viewing my security cameras 24/7… so Local Server is just puttering in the background and largely ignored until I update it with whatever new version the developers release (about 10 minutes of my time).
In my opinion, I would say that having the server on the same local network as your devices and associated sensors is more important than tweaking things to work over a high latency connection to a Cloud Server. The App <->Server link (which honestly is not being actively used 24/7 anyhow), can probably work well enough over that Sat link… better than the Server <-> MCU connection would… Not to many people have their IOT system crash because their phone battery died or they drive into a bad cell area 
Basicly we can argue stats, specs and opinions till the kangaroos come home,… but until you try all your options, I don’t think you will fully understand them.
@Gunner on reflection you might be right that all running perfect with a local server and then poor port forwarding due to the satellite will give better results than a permanently bad system (a cloud based server using a satellite link).
Only testing will tell.
Thanks for the helpful advice and suggestions. There are lots of things for me to learn about and to try. I take your point that I need to try things to fully understand them. the local server has been put onto my list (which is already too long for comfort).
Regarding “just code up “retry” when the satellite gives you poor results” - as you know I was working with Blynk.connected() and Blynk.connect() with their result flag as a way of detecting a problem. However I would like to know if there is a better way of assuring the data actually got to the server.
So my questions on this particular topic are:
a) is that connection result flag an end-to-end check, or is it just done at the local end of the connection?
b) is there a way of reading the TCP data acknowledgement?
c) I thought of coding up a widget that would send the received data back to the sending hardware. Is that feasible?
Thank you.
Keith
@farmerkeith which is most important:
A. The days you are at, or near, home because this is say 80% of your time.
or
B. When you are way as it’s too far to return home.
Please advise your most important sensor, including a link to the product and what your system will do based on certain parameters. We can then advise how you can be sure your app is showing the correct data. The basics are reading and writing values to the server and checking to see if they are what you expect. If they are not, repeat until they are.
@Costas, interesting questions, to which I don’t have any simple answers.
Which is most important, at home or away? They are both important - more or less.
Many of my projects are at the “gleam in the eye” stage - things I would like to do, but have not done yet. I have a box of sensors and transducers and many other bits I need to make the subsystems. It seemed to me (still seems to me) when I discovered Blynk that Blynk offers a really powerful way of integrating my many ideas into a working solution. It is very much a work in progress - not helped of course by finding my link to the blynk-cloud server is problematic.
I have been running one of those small scale multi-product farms that produce small quantities of many things. I have been growing vegetables (which need irrigation), eggs (per favour of a flock of about 40 chickens, being increased), a small vineyard, olive trees, 3 types of nut trees, and a small fruit orchard. It is spread out over 80 hectares (200 acres) of fairly hilly country, with a river frontage at 600 m and the vineyard at 720m. Most of the controls are around the main house, including a greenhouse where I can give an early start to my summer vegetables. Some of the sensors will be further away, and will need radio links with intermediate repeaters to make the distance which is up to about 800m.
A significant part of the work is fixing things when they go wrong (like a pump or a dripper line gets blocked with debris), or just checking that nothing has gone wrong. So timely warning that something is about to fail, or has just failed, can be very useful. If i am there, I go and fix it sooner than otherwise. If I am not there, I exercise some judgement and decide whether to do nothing, telephone a neighbour to come over and do something simple, or shorten my absence and return early, maybe at some inconvenience. It all depends on what the issue is.
I think the above story leads towards the local server, because when I am there the information is more valuable if it is very timely, whereas when I am away a few hours delay may not make much difference to how I respond.
As a system concept, the idea I am pursuing is that there is a single item to check as a Blynk widget, which says either “all OK” or “something is wrong”. If (or When) the “something is wrong” widget says that, I can press a button that tells the server and/or the appropriate hadware sensors to show me the particular values that led it to that status. The details of this are still very fuzzy and will evolve as I build some of the bits.
If you look on Instructables for farmerkeith you will find 5 projects that I have put there. This link will get you to one of them, and I think you can easily find the others if you like to do that.
I need to build a better one that has about 10 temperature sensors (to monitor compost and greenhouse temperature) and control greenhouse ventilation (via linear actuator) and irrigation. I got going with WeMos and Blynk as what I thought would be a good journey to get there.
When that is under control, I have more projects, such as my pumping system for irrigation water from the river (the pump in the river is subject to debris which is very sporadic), irrigation water distribution, chicken house and chicken management, … the list goes on.
I hope I have explained sufficiently my state of mind of what I am trying to do. When you say “The basics are reading and writing values to the server and checking to see if they are what you expect. If they are not, repeat until they are.” I could not agree more. I think the “how do I do that” was the last part of my previous 3-question message. I hope you can use some of your deep system knowledge to steer me in the right direction.
Thank you,
Keith
@farmerkeith I took a look at your original sketch and it serves no purposes checking if you are still connected to the server a few ms after the last time you checked.
Test this, it has a new function name and the pins are V10 to V13 rather than 0 to 3. Just because I am using the other pins to do something else. Also set timed interval at 4s instead of 30s.
void sendTime()
{
// Please don't send more that 10 values per second.
cycles ++;
Serial.println ("\nTimer Event triggered");
Serial.print ("sending millis/1000 to Blynk V10 value=");
Serial.print (millis()/1000%1000);
byte yesConnected = Blynk.connected();
if (yesConnected == 0) notConnectedCount0 ++;
Serial.print (" Blynk connection flag=");
Serial.print (yesConnected);
Serial.print (" millis=");
Serial.println (millis());
Blynk.virtualWrite(V10, millis() / 1000 %1000);
Serial.print ("sending millis/1000+1 to Blynk V11 value=");
Serial.println ((millis()/1000+1)%1000);
/*yesConnected = Blynk.connected(); // no need to check again so soon
if (yesConnected == 0) notConnectedCount1 ++;
Serial.print (" Blynk connection flag=");
Serial.print (yesConnected);
Serial.print (" millis=");
Serial.println (millis());
*/
Blynk.virtualWrite(V11, (millis() / 1000+1) %1000);
Serial.print ("sending millis/1000+2 to Blynk V12 value=");
Serial.println ((millis()/1000+2)%1000);
/*yesConnected = Blynk.connected(); // no need to check again so soon
if (yesConnected == 0) notConnectedCount2 ++;
Serial.print (" Blynk connection flag=");
Serial.print (yesConnected);
Serial.print (" millis=");
Serial.println (millis());
*/
Blynk.virtualWrite(V12, (millis() / 1000+2) %1000);
Serial.print ("sending millis/1000+3 to Blynk V13 value=");
Serial.println ((millis()/1000+3)%1000);
/*yesConnected = Blynk.connected(); // no need to check again so soon
if (yesConnected == 0) notConnectedCount3 ++;
Serial.print (" Blynk connection flag=");
Serial.print (yesConnected);
Serial.print (" millis=");
Serial.println (millis());
*/
Blynk.virtualWrite(V13, (millis() / 1000+3) %1000);
Serial.print ("Not Connected counts = ");
Serial.print (notConnectedCount0);
/*
Serial.print (' ');
Serial.print (notConnectedCount1);
Serial.print (' ');
Serial.print (notConnectedCount2);
Serial.print (' ');
Serial.print (notConnectedCount3);
*/
Serial.print (" cycles = ");
Serial.println (cycles);
}
I will put something regarding reading and writing to the server.
@farmerkeith a common procedure used to determine if your app is connected to your ESP is simply to blink a Blynk LED at intervals. Normally at 500 to 1000ms but perhaps at least 1000ms for your satellite link. So if the LED is not blinking you can’t trust the data in the app.
There are also details for Connection Management in the docs.
Change your timed interval to say 10s.
Add the following global variable:
unsigned int validation = 1; // unique identifier for validate() timed function
Add the following 2 lines as the last lines in setup()
validation = timer.setInterval(4000L, validate); // create 4s timed interval
timer.disable(validation); // disable 4s timed interval
then add these 2 lines as the last lines of sendTime() (formerly called myTimerEvent() )
Blynk.virtualWrite(V1, cycles);
timer.enable(validation);
Add a value display widget to your project on V1 with a READING RATE of PUSH.
Then add this to your sketch
void validate(){
timer.disable(validation);
Serial.println("Validation routine");
Blynk.syncVirtual(V1);
}
BLYNK_WRITE(V1){ // value display, write value to MCU from server
long checkcycles = param.asDouble(); // or use int for cycles and checkcylces but watch rollover
if(checkcycles != cycles){
Serial.println("Server update error");
sendTime(); // failed last time so try again
// perhaps count here the number of failures and respond accordingly, even ESP reset etc
}
else{
Serial.println("Server update OK");
}
}
What this will do is basically send the data over and over again at 4s intervals, rather than the general 10s timer, until the server has the correct information.
It’s simply sending to the server and then reading back from the server to see if “cycles” is the same value. Just a guide for the sort of thing you might need to do with your satellite system.
1 Like
@farmerkeith I’ll try to use a loose analogy to see if it helps your understanding of Blynk…
The Server is like the Heart… storing and passing the information around between MCU(s) and Apps(s).
The MCU is the Brain, it senses and controls the “body”, sensors, valves, motors, etc. (via logic and code) in an autonomous like fashion, even without the heart for short moments (if coded accordingly),
The App is like your “awareness” of the surroundings… useful to consciously keep track of and direct everything when awake, but when asleep, the rest of the “body” keeps on working as per the MCU’s(brain) & Server’s(heart) programming autonomy.
Thus keep your Heart and Brain close to the Body and “check in” once in awhile when awake 
Blynk is more like a GUI (graphical user interface) with some optimised for IoT commands/controls… but you will still need to create the “logic and action” for all your sensors and controls.
It sounds like you have a large enough operation that Blynk integration could be beneficial, but also challenging to setup… I recommend you start with a basic server install on your PC (it will just run in a “window” in the background and talk to your MCU & App, via your router’s WiFi) and some simple sensors/controls, i.e a thermometer and a relay for a fan. Play around with the programming until you have a good feel for it. Then start worrying about Internet integration, long repeater runs to sensors, etc. one step at a time.
1 Like
I just got to read here, and it’s very interesting.
My father had to work around a similar problem at his job.
Basically, in his tests for connecting isolated post offices to the internet, a banking application fails due to latency.
Updating the application to not timeout too early would require different sections of the company to cooperate (incredible, right?), which is not going to happen quickly enough.
So, they got the provider to spoof the aknowledge packet from the terrestrial node. This fakes a lower latwncy and allows the application to work.
In the end, either you get a better connection, or the blynk servers and library get their timeout increased, or you somehow spoof the reply (maybe the provider can do it for you, but i’m not sure they’d do that for a small customer).
1 Like
Thanks for your input @Gspin. Faking the ack is fine so long as the transport protocol is actually very reliable - which is probably the case for me, but not actually known at the moment.
I am pleased you find this interesting. Keep watching, there will be more to come as I learn, with the excellent support from the Blynk end.
Keith