Welcome to the new home of the Cumulus Support forum.

Latest Cumulus release v1.9.4 (build 1099) - Nov 28 2014
Latest Cumulus MX release - v3.0.0 build 3044 7 December 2018. See the Wiki for download

WiFiLogger for Davis stations

For discussion of DIY weather equipment - sensors, accessories, improvements to existing kit etc
prodata
Posts: 197
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

Post by prodata » Wed 18 Jul 2018 1:00 pm

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.
John Dann
Prodata Weather Systems
Littleport, East Cambs, UK
http://www.weatherstations.co.uk

User avatar
steve
Cumulus Author
Posts: 26714
Joined: Mon 02 Jun 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: WiFiLogger for Davis stations

Post by steve » Wed 18 Jul 2018 3:53 pm

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.
Steve

BCJKiwi
Posts: 874
Joined: Mon 09 Jul 2012 8:40 pm
Weather Station: Davis VP2 Cabled with Solar
Operating System: Windows 10 Pro
Location: Auckland, New Zealand
Contact:

Re: WiFiLogger for Davis stations

Post by BCJKiwi » Wed 18 Jul 2018 9:20 pm

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.

Post Reply