[werk_ag]

Hi t3g

1000ms to 1500ms is not bad for 4 sensors. If we take in account that its a routine which runs only once every 3 ou 4 minutes, the impact on the general system performance should not be significant.

Just for comparison a single upload to WU takes from 700ms to 1000ms, sometimes less, sometimes more.

Regards

[engolling]

If this would be working in future a new tx module branch with the ESP module would be thinkable (like the compact receiver) to make it quicker and better useable for people being not so deep into electronics.

Everything is possible, however I'm convinced that the best way to transmit data from the weather sensors to the receiver is by mean of an one way communication like RF.

This have many other advantages like allowing multiple receivers sharing the same transmitters, without increasing the load on the transmitter unit.
Range is another advantage, its hard to get a range of 50 to 100 meters with WiFi.

Concerning this matter, our development route is toward the use of better RF technologies like LoRa. We already have some prototypes where the transmitters are 1.5Km away from the receiver.

Personally I'm not a fan of weather stations fully IP based, like netatmo and others. Most of them don't report instant gust speeds, I can be wrong but I'm convinced they don't do it because they can't communicate fast enough to do it.

Concerning this point I just thought that consequently to the compact receiver a compact transmitter could follow communicating via WIFI and T/H sensor onboard and maybe an input for a tipping bucket but that's another point and not the main aspect in this thread.

As far as I have talked to t3g everything seems to run smooth now for the communication. But I think he will write later how things are doing.

engolling

[t3gathome]

Hi Werk_AG,

I did some new measurements for 24h. Now the code is a lot better but I try to improve it more!
E.g. setting down timeout limits and trying to detect a "long runner" if there comes no answer or the tcp connection cannot be closed.
One main point I see now is, that sending the data of all extra sensors consumes much time (even more than communication to the wireless displays).
Now I have changed the behaviour of my simulated sensors to real world (but random) values.
As an attachement to this post I have some graphs about:

• comparison: send extra sensors vs communication with 4 TCP sensors
  
• Wifi_Sensors: comparison with all 4 Sensors
  
• Wifi_Extra: comparison of the sum of WIFI and the sum of sending extra sensor data
  

In this data you see, that:

• tcp now is pretty fast
  
• sending the new data out (via 433) consumes some time
  
• there was one error and the tcp connection could not be closed, what lead to a timeout of around 8000ms (Right now I cannot determine, if it was the wireless display, or a rasp - because the time of "sensor 2" data has been left out, so I only know the time sum of 1+2)
  
• local sensors are faster
  
• two identical raspberry pis are different, because one sits in a metal case
  

I will send another post with plots of each tcp Sensor also.

[t3gathome]

and here come 4 plots - one for each sensor.
They all are adjusted to the same x/y axis - to compare easier .

[t3gathome]

I found another bug in the beta version.
There is the routine, that checks and counts sensors, without an IP with a leading zero.
And this amount is the limit of the for loop.
So if one WD is not connected and sits between two other ones (e.g. 3 Sensors: "WD1","0.0.0.0",WD2","WD3"), than the WDs  do not match the IP lookup table --> Sensor 1: WD1; Sensor 2:0.0.0.0; Sensor 3: WD2.
A mask would be better. I try to make a suggestion.

[t3gathome]

Hi altogether,

over the last few days, I did some tweaks, tryouts and research.
To cut it down simply:
The biggest problem is the esp library. Some timeouts are predefined (3000ms/10000ms) and the functions are wating for an esp response over uart (no interrupt, so the mega could do sth. else, like detecting a touch or draw the display).
I discussed pretty much with engolling and we came to the conclusion to check if a connection was lost and try again some attempts later.
Normally 4 WDs need between 400 and 700ms to receive over TCP and the sending of extra sensors comes afterwards with additional 1500ms+x (depending on the configured extra sensors amount) 
Each not responding device needs sth. like 3000ms more. After this time, the createTCP (inside) function returns error and this means false.
If we try to release a connection, that has not been established (releaseTCP function on the wrong place, or no error handling of the createTCP function), it takes aroung 8000ms per device.
I added a check if the payload (http body) is in the first TCP package or in the second (sometimes the first is only the header,and the second it the body, or they come together).

I created a struct for a WD object with the following variables:

•     bool WIFIunit_configured; --> it checks, if a WD is configured.
  
•     bool WIFIunit_connected; --> It safes the state, if it is connected (or it did not have a connection loss)
  
•     int WIFIunit_attempts; --> it counts up the attempts not trying to connect again (the variable that is being compared to that can be adjusted; e.g. 5 is sth. like 15min and 10 is like 30min; if the interval of checking data is 3min)
  
•     char* WIFIunit_address; --> the unit adress or IP (both working at my network)
  
•     int WIFIunit_port; --> the port of the device, if this differs and is not the standard port 80
  

So now a device can have another port and one can be left out in the middle also, so extra sensors 5,1;5,3 and 5,4 for example can be configured.
Right now the code is in debugging mode and not nice. I will send an Email to (you) Werk_AG and all of us can discuss how to implement it (even better) and if my recent changes could go into production branch.

If somebody also has ideas, feel free to join the discussion   .

[werk_ag]

Hi t3gathome,

Sorry for the late reply.
I did a quick look to the code you sent to me, but haven't try to implement it yet (at moment I'm quite busy with my work). As soon as I can I will return to this matter.

[werk_ag]

I found another bug in the beta version.
There is the routine, that checks and counts sensors, without an IP with a leading zero.
And this amount is the limit of the for loop.
So if one WD is not connected and sits between two other ones (e.g. 3 Sensors: "WD1","0.0.0.0",WD2","WD3"), than the WDs  do not match the IP lookup table --> Sensor 1: WD1; Sensor 2:0.0.0.0; Sensor 3: WD2.
A mask would be better. I try to make a suggestion.

Well that routine is a quick solution which surely can be improved without wasting to much sram.  

Code:

So if one WD is not connected and sits between two other ones (e.g. 3 Sensors: "WD1","0.0.0.0",WD2","WD3"), than the WDs  do not match the IP lookup table --> Sensor 1: WD1; Sensor 2:0.0.0.0; Sensor 3: WD2

This is why I had put the comment: "Don't leave holes"

                                                                // Sequencial list of WiFi sensors IP Addresses. Don't leave holes
const char* WIFIunit_address [][4]= { "192.168.1.154"            // IP address of first WiFi sensor
                                   , "192.168.1.153"            // IP address of second WiFi sensor
                                   , "192.168.1.152"            // IP address of third WiFi sensor
                                   , "0"                        // IP address of fourth WiFi sensor
                                   };

[t3gathome]

Hi Werk_AG,

thanks for your reply! Yes you are right, I saw it afterwards... After detecting the counter and immediately after writing the comment... I thought, that this could lead to problems in (mis)configuration.
If you have more free time feel free to discuss suggestions. I would be happy, if this idea (in whatever form) could find its way into the main version .

[werk_ag]

I discussed pretty much with engolling and we came to the conclusion to check if a connection was lost and try again some attempts later.

...

I created a struct for a WD object with the following variables:

•     bool WIFIunit_configured; --> it checks, if a WD is configured.
  
•     bool WIFIunit_connected; --> It safes the state, if it is connected (or it did not have a connection loss)
  
•     int WIFIunit_attempts; --> it counts up the attempts not trying to connect again (the variable that is being compared to that can be adjusted; e.g. 5 is sth. like 15min and 10 is like 30min; if the interval of checking data is 3min)
  
•     char* WIFIunit_address; --> the unit adress or IP (both working at my network)
  
•     int WIFIunit_port; --> the port of the device, if this differs and is not the standard port 80
  

So now a device can have another port and one can be left out in the middle also, so extra sensors 5,1;5,3 and 5,4 for example can be configured.

Hi t3gathome,

A completely agree that a check to determine if the remote units are dead or alive should be done.
Regarding the proposed struct, I have some concerns: It requires at least 10 bytes (maybe more if an name address is used instead of an IP) for each unit, so at least 40 bytes for 4 units.

I'm working in an alternatively way to reach the same result, but with a lower memory consumption.
Sensors address (IP or address) can be defined in any order, with or without holes in between.

Code:

const char* WIFIunit_address [][4]= { "192.168.1.154"            // IP address of first WiFi sensor
                                  , "192.168.1.153"            // IP address of second WiFi sensor
                                  , ""                           // IP address of third WiFi sensor
                                  , "192.168.1.152"                        // IP address of fourth WiFi sensor
                                  };

At startup, and every 15 minutes the system try to ping each device, if it doesn't reply its marked as "dead", and it will not be used next time we try to read T/H from remote WD units.

Every thing seems to be working fine. For now I haven't implemented the possibility to choose the port (instead of the default port 80). I will try to do it next, however I would prefer to have a defined port for all four units, instead a defined port per unit.

As soon as I can I will send you the code for testing and suggestions.
Thank you for your collaboration.