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: 26620
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: 859
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 1 guest