Sorry Steve, I know you don't want to spend too much time here, but I still don't feel like I understand the complete picture. Could I have one more go:
In the normal course of events, does the connection between logger and MX stay up? Or is every request for a new LOOP packet always bracketed by open and close connection commands? I'm guessing it's the former, ie the connection is usually up (BICBW I know).
I can certainly see that if MX were to handle any error resulting from the connection not being open then that would be an excellent step forwards because it could handle a number of potential fault states.
But the bit I'm not clear about right now is what caused the connection to drop where there is a connection error betwen MX and the logger with the present MX version?
I think the answer is that it was dropped either explicitly or 'inadvertently' by the logger (ie rather than by MX). So my point - and apologies for labouring this - is that if the logger could be configured when busy not to drop the connection but simply to delay sending the next LOOP packet then it wouldn't send MX off in a huff as happens at present. I'm not sure whether or not this is possible, but I can investigate further if it might provide an interim solution to the problem.
Welcome to the Cumulus Support forum.
Latest Cumulus MX V4 release 4.0.0 (build 4022) - 11 May 2024
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
Latest Cumulus MX V4 release 4.0.0 (build 4022) - 11 May 2024
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
WiFiLogger for Davis stations
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: WiFiLogger for Davis stations
Yes, MX opens the connection when it starts up, and doesn’t close it until you close MX. There is the option to make it close the connection once a minute for a few seconds, and then re-open it, this is intended to allow a WLIP to upload to weatherlink.com.
I don’t know what causes the connection to be closed. But yes, if that could be discovered and somehow prevented, it should improve things until a version of MX is available which handles the disconnection.
I don’t know what causes the connection to be closed. But yes, if that could be discovered and somehow prevented, it should improve things until a version of MX is available which handles the disconnection.
Steve
-
- Posts: 1256
- Joined: Mon 09 Jul 2012 8:40 pm
- Weather Station: Davis VP2 Cabled
- Operating System: Windows 10 Pro
- Location: Auckland, New Zealand
- Contact:
Re: WiFiLogger for Davis stations
Have been testing the WiFiLogger with both CumulusMX and Cumulus1.
WiFiLogger configured as closely as possible to a stadard USB logger - i.e. No uploading or any other tasks being carried out by WiFiLogger other than those a standard Davis USB logger would perform.
In both cases there have been disconnects.
MX and 1 handle the issue differently but it does appear that the connection is closed at random intervals at the logger end.
Cumulus1 shows two different responses
1. one is:-
*** Data input appears to have stopped, restarting
2. the other is:-
VP2: LoadCurrentVantageData_V, error = -32701
VP2: Closing connection, result = 1
VP2: OpenTCPIPPort_V, res = -32701
VP2: OpenTCPIPPort_V, res = -32701
VP2: OpenTCPIPPort_V, res = 0
VP2: LoadCurrentVantageData_V, error = -32701 (repeats for any number of times)
VP2: Closing connection, result = 1
VP2: OpenTCPIPPort_V, res = 0
after which C1 continues OK without having restarted.
MX response is different.
1. sometimes the log reports:-
VP2: OpenTCPIPPort_V, res = 0 and closes
2. other times it just stops with no detail in the log
3. then we get this on occasions:-
!!! loop data not received
!!! loop data not received
System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
*** Data input appears to have stopped
Exiting system due to external CTRL-C, or process kill, or shutdown
For MX I have implemented an external shutdown/restart utilising #DataStopped tag and returned to USB logger.
WiFiLogger configured as closely as possible to a stadard USB logger - i.e. No uploading or any other tasks being carried out by WiFiLogger other than those a standard Davis USB logger would perform.
In both cases there have been disconnects.
MX and 1 handle the issue differently but it does appear that the connection is closed at random intervals at the logger end.
Cumulus1 shows two different responses
1. one is:-
*** Data input appears to have stopped, restarting
2. the other is:-
VP2: LoadCurrentVantageData_V, error = -32701
VP2: Closing connection, result = 1
VP2: OpenTCPIPPort_V, res = -32701
VP2: OpenTCPIPPort_V, res = -32701
VP2: OpenTCPIPPort_V, res = 0
VP2: LoadCurrentVantageData_V, error = -32701 (repeats for any number of times)
VP2: Closing connection, result = 1
VP2: OpenTCPIPPort_V, res = 0
after which C1 continues OK without having restarted.
MX response is different.
1. sometimes the log reports:-
VP2: OpenTCPIPPort_V, res = 0 and closes
2. other times it just stops with no detail in the log
3. then we get this on occasions:-
!!! loop data not received
!!! loop data not received
System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
*** Data input appears to have stopped
Exiting system due to external CTRL-C, or process kill, or shutdown
For MX I have implemented an external shutdown/restart utilising #DataStopped tag and returned to USB logger.
-
- Posts: 2
- Joined: Sun 20 Oct 2019 12:17 pm
- Weather Station: Davis VP2
- Operating System: Linux (Ubuntu)
Re: WiFiLogger for Davis stations
Hi everyone,
I have just installed WiFiLogger in my VP2. Very easy to install and configure.
Now as part of a project to develop a LAMP application to collect and display weather data from the VP2, I need to access it across the WiFi link using TCP.
Is anyone aware of any example code that would demonstrate, opening the port, sending a request and receiving data back ?
I'm fine with the LAMP and TCP, ports etc I just thought someone might alrteady have been playing with this.
If not, I guess I'll probably set up CumulusMX and sniff the network traffic.
Cheers,
Geoff.
I have just installed WiFiLogger in my VP2. Very easy to install and configure.
Now as part of a project to develop a LAMP application to collect and display weather data from the VP2, I need to access it across the WiFi link using TCP.
Is anyone aware of any example code that would demonstrate, opening the port, sending a request and receiving data back ?
I'm fine with the LAMP and TCP, ports etc I just thought someone might alrteady have been playing with this.
If not, I guess I'll probably set up CumulusMX and sniff the network traffic.
Cheers,
Geoff.
-
- Posts: 317
- Joined: Sat 05 Feb 2011 7:13 pm
- Weather Station: VP2
- Operating System: Windows - all flavours
- Location: Littleport, East Cambs, UK
Re: WiFiLogger for Davis stations
The actual API for requesting data from the WiFi logger is just the standard Davis one, ie as per the SerialTechRef document - see:
https://support.davisinstruments.com/ar ... 6-1-any-os
From memory, the logger can be accessed on default port 22222
I'm slightly more hazy about precisely how you send requests to the logger in a Linux environment. It's effectively serial over TCP/IP and I'm guessing that some generic type of Redirector library is a default component of Linux, but someone else will need to help with the precise command/syntax.
https://support.davisinstruments.com/ar ... 6-1-any-os
From memory, the logger can be accessed on default port 22222
I'm slightly more hazy about precisely how you send requests to the logger in a Linux environment. It's effectively serial over TCP/IP and I'm guessing that some generic type of Redirector library is a default component of Linux, but someone else will need to help with the precise command/syntax.
-
- Posts: 2
- Joined: Sun 20 Oct 2019 12:17 pm
- Weather Station: Davis VP2
- Operating System: Linux (Ubuntu)
Re: WiFiLogger for Davis stations
Thanks John.
G.
G.