[t3gathome]

Werk_AG you are awesome !
Yes the batroom is a very inspiring place

Mapping to extra Sensors is a good idea... I tried this only as a proof of concept...
Yes indeed, I see the possibilities coming up!

Maybe by the weekend I will have a test version. Would you like to test it?

Yes of course I would be happy to do so! I can write you a pm with my mail adress...!

The code I shared was not optimized yet... So you are right,there are some points that need attention.

[werk_ag]

Hi t3gathome,

Tomorrow night I should be able to send you a test version. Things are running well...

How it is implemented:
* Data from WiFi sensors (WD units) are pulled each 3 minutes. I'm still observing the impact of this on RF reception, perhaps I have to increase it to 4 minutes.
* The maximum number of WiFi sensors supported is four. I'm testing with two.
* WiFi sensors can be mapped to any Extra Sensor (1 to 7) - Usually the T/H sensor of the Air Quality Monitor will use one of them.

I'm testing it with two different receivers, pulling data from the same two Wireless Display units. Its working!

What I haven't tested:
* Getting data from an WD unit outside of my local network.
* I only can access units by the IP address, using the host name defined in the WD software isn't working
  This works:

Code:

    char *get_json = "GET / HTTP/1.1\r\nHost: 192.168.1.140 host:80\r\nConnection: close\r\n\r\n";

  This isn't working:
   

Code:

//char *get_json = "GET / HTTP/1.1\r\nHost: ESP-17F41F host:80\r\nConnection: close\r\n\r\n";

Address of WiFi sensors are defined in the User_Config.h file. Perhaps instead of an IP, an external URL will work, I have no way to test it. Maybe you can test it with your friend engolling

Example:

Code:

//---------------------------------------------------------
//    Enable / Disable getting Temperature / Humidity from WiFI sensors (Usually the local T/H sensor on Wireless Display units)
//---------------------------------------------------------
#define ENABLE_TH_FROM_WIFISENSORS     1                            // 1= Enable, 0= Disable

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

[t3gathome]

Hi Werk,

3 minutes of pull time would be ok. 4 WiFi Sensors also are fine. And mapping them to extra sensor 1 to 7 is a good idea, to include them!
BUT I would also think about preparing for more wifi sensors e.g. provided by a Raspberry Pi/ESPXX in the network (Wifi, or even wired in the same net).

Getting data outside the local network worked with engolling over a static IP and he is preparing right now a WD at his homebase, so I can receive real data of a WD over the net
He had the idea to extend this feature one step further:
Having a gsm sensor pushing data to a webserver (e.g. with a php script and JSON data format) and then the RX pulling data from that web server (also via php, that provides the data).
So we could also include sensors, that are out of range of 433 radio with that technique and already prepared routines (only changing the hostname/ip and port) .

Setting a hostname works also, but one big problem with the OTA name...: it is with an underscore "_" and the esp changes it unfortunately to a minus "-". That's why I think it was not working for you :/.
I have it working again at my setup :

Code:

if (wifi.createTCP(mux_id, "WD-1", 80, 0)) {

and

char *get_json = "GET / HTTP/1.1\r\nHost: WD-1 host:80\r\nConnection: close\r\n\r\n";

for the final setup I would recommend changing to hostnames (the idea also came from engolling). Sometimes users don't have access to ip management... Or they could change because of a dhcp server, that cannot be switched off.

[t3gathome]

If we want to use a concatenated String variable (let's assume: "WD-"+X) as Hostname, than we can use these two assignments:

if (wifi.createTCP(mux_id, "WD-"+String(variableX), 80, 0)) {

String s_VariableX = String(variableX);
char *prefix = "GET / HTTP/1.1\r\nHost: WD-";
char *postfix =" host:80\r\nConnection: close\r\n\r\n"; 
String url = prefix +s_VariableX+ postfix;
const char *get_json = url.c_str(); //this whole thing can be done once as init also... --> then I think we can save microcontroller cycles!


I hope this helps you a bit for convincing to switch to hostnames

[werk_ag]

Setting a hostname works also, but one big problem with the OTA name...: it is with an underscore "_" and the esp changes it unfortunately to a minus "-". That's why I think it was not working for you :/.
I have it working again at my setup :

Code:

if (wifi.createTCP(mux_id, "WD-1", 80, 0)) {

and

char *get_json = "GET / HTTP/1.1\r\nHost: WD-1 host:80\r\nConnection: close\r\n\r\n";

for the final setup I would recommend changing to hostnames (the idea also came from engolling). Sometimes users don't have access to ip management... Or they could change because of a dhcp server, that cannot be switched off.

If we want to use a concatenated String variable (let's assume: "WD-"+X) as Hostname, than we can use these two assignments:

if (wifi.createTCP(mux_id, "WD-"+String(variableX), 80, 0)) {

String s_VariableX = String(variableX);
char *prefix = "GET / HTTP/1.1\r\nHost: WD-";
char *postfix =" host:80\r\nConnection: close\r\n\r\n"; 
String url = prefix +s_VariableX+ postfix;
const char *get_json = url.c_str(); //this whole thing can be done once as init also... --> then I think we can save microcontroller cycles!


I hope this helps you a bit for convincing to switch to hostnames

At least in my local network, no matter the host name I define for each WD unit, it isn't work. I can only reach them when using their IP address.
Anyway, if it is working for you, instead of an IP address you can use an host name. Everything you put between " " will be used as the host name:

if (wifi.createTCP(WIFIunit_address [0] [i], 80, 0))

Code:

//---------------------------------------------------------
//    Enable / Disable getting Temperature / Humidity from WiFI sensors (Usually the local T/H sensor on Wireless Display units)
//---------------------------------------------------------
#define ENABLE_TH_FROM_WIFISENSORS     1                        // 1= Enable, 0= Disable

                                                                // Sequencial list of WiFi sensors 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
                                   , "0"                        // IP address of third WiFi sensor
                                   , "0"                        // IP address of fourth WiFi sensor
                                   };

Per example, instead of 192.168.1.154 you can put there "WD-1". Unused sensors SHOULD start by ZERO

I already sent to your email a test version (Pro2 PLUS and WD software)

[engolling]

Hello folks,

me an t3g made some tests with the data transfer of the WD unit over www and in case the host is not responding and so on.
AFAIK t3g will present the results later on here in the thread.

In discussion with him a new idea was born. Best would be, if we could change the firmware of the ESP 8266 that it gets all necessary data and keeps the actual values in its flash. That you can only get it with a command via UART. This would save a lot of processing time.

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.

engolling

[t3gathome]

Over the weekend engolling and me made some tests, like he said in the previous post.
I am trying to simulate a WD right now: with 2 raspberry pis and one with an online subdomain of my website.
--> Than I have "4 wireless displays" --> 1real+3fakes. But I did not get the simulated ones to work until now.

Although I want to provide my results:
At first Werk_AG you did a very nice job! All functions are on a clever, cleaned up place and everything is working!

Here are some things in addition to engollings post, that came up:

• The port 80. Could we change that with another part in the WIFIunit_address variable, so for each IP/hostname, the port can be changed? This will affect: 
  
•    -->if (wifi.createTCP(mux_id, WIFIunit_address [0] [i], 80, 0)) 
  
•    -->const char* postfix =" host:80\r\nConnection: close\r\n\r\n";
  
• a very big disadvantage of all this solution is, if a (i call a WD a sensor) sensor does not respond --> then we have a lot of timeout
  
• another thing is misconfiguration: If a WD unit is configured in extra sensors, but has 0.0.0.0, than the routine times get worse also
  
• and having an empty string "" instead of "0.0.0.0" increases also routine time
  

I think at me hostnames are working because of my fritz box router has some dns and nameserver resolving services.

Here are some mean value figures of our tests:

• Wireless Display alone (24 data points):
  
• 603,667 ms
  
• Wireless Display + www Wireless Display of engolling over the web (121 data points)
  
• 1460,16 ms
  
• 1 time www (engollings Wireless Display) configured (30 data points):
  
• 855,967 ms
  
• 2 times www (engollings Wireless Display) configured (13 data points):
  
• 1561,54 ms
  
• 3 times www (engollings Wireless Display) configured (30 data points):
  
• 2188,8 ms
  
• 4 times www (engollings Wireless Display) configured (7 data points):
  
• 2753,14 ms
  

now we come to failures or a not responding WD:

• 1 time www (engollings Wireless Display) configured (65 data points):
  
• 8755,46 ms
  
• 3 times www (engollings Wireless Display) configured (167 data points):
  
• 26092,2 ms
  

and now some special ones:

• 1 configured as www sensor the other 3 sensors are configured with "" instead of "0.0.0.0" --> (3 data points) and 7186 ms
  
• 2 have correct IPs and altogether 3 extra WDs are configured --> (5 data points) and 1831,4 ms
  

So altogether this must become more robust and stable! We can play with timeout times and probably we need sth. like a ping, to detect if we could expect an answer?!?
I did not have a feeling for these bad times in the beginning... :/
I think engollings idea could be a nice thing to let the ESP do more data processing.
Probably we achieve the ESP to get, process and store the JSON data for the RX Mega to get the data later on with no (or a very little) loss of speed.

As an attachement I have a plot of routine times it takes to have 1...4 www sensors (like all the rest emprical data). --> routine ms over number of devices

best regards
t3gathome

[werk_ag]

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.

[werk_ag]

[*]1 configured as www sensor the other 3 sensors are configured with "" instead of "0.0.0.0" --> (3 data points) and 7186 ms
[*]2 have correct IPs and altogether 3 extra WDs are configured --> (5 data points) and 1831,4 ms

[*]

There is a quick and dirty routine that counts the number of configured sensors by checking the first char of IP address. If it is anything different from zero, the sensor exists, so "" counts as an existing sensor. This is the reason why execution time is greater when you used "" instead of "0.0.0.0"

[t3gathome]

Hi Werk,

thanks for your reply! I found this routine 10 minutes ago... Now I understand...!
I implemented my simulated sensors and improved reading the JSON data (depending on the payload/body being in the first message or not)
Now I have one Wireless Display, one Website on the www (thdata.heini.bayern) and two independent raspberry pis in my local network serving fixed data via php.
They all work and times are a bit better now... 1000ms-1500ms.
I am trying to improve the routine now. If I have any progress, I will report it ASAP.

regards t3g