IMPORTANT! The server may go down soon - possibly permanently. Please read the latest post in Announcements and News

FTP is broken. I advise all users using my server for their web site to make alternative arrangements.

Please read the posts in the Announcements section about the current status of Cumulus development now that I have retired

Please read this post before posting

Latest Cumulus release v1.9.4 (build 1099) - Nov 28 2014
Latest Cumulus MX release - v3.0.0 build 3043 Jan 20 2017. See this post for download

WiFiLogger for Davis stations

For discussion of DIY weather equipment - sensors, accessories, improvements to existing kit etc
prodata
Posts: 197
Joined: Sat Feb 05, 2011 7:13 pm
Weather Station: VP2
Operating System: Windows - all flavours
Location: Littleport, East Cambs, UK

Re: WiFiLogger for Davis stations

Postby prodata » Wed Jul 18, 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: 26688
Joined: Mon Jun 02, 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: WiFiLogger for Davis stations

Postby steve » Wed Jul 18, 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
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876

Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job

BCJKiwi
Posts: 862
Joined: Mon Jul 09, 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

Postby BCJKiwi » Wed Jul 18, 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.


Return to “Homebuilt”

Who is online

Users browsing this forum: No registered users and 2 guests