Page 2 of 3

Re: WiFiLogger for Davis stations

Posted: Fri 06 Jul 2018 2:07 am
by PaulMy
Not totally reliable as yet. Sometimes it can run for a couple of days and then only for a few hours before CumulusMX crashes. Whenever there is some action with either the console or WiFiLogger settings, such as firmware update or console setting changes, then CumulusMX crashes pretty quick. I have tried to shut down CumulusMX before doing those things, but still some crashes at other times.

The Davis Envoy/USB logger and Cumulus1 is my main setup and that works flawless. The Vue console/WiFiLogger uploads and CumulusMX is still in trial.

Paul

Re: WiFiLogger for Davis stations

Posted: Sat 07 Jul 2018 3:04 am
by BCJKiwi
I Agree,
Having issues with CumulusMX shutting down - gone back to USB Logger for now.
In discussion with Developer.

Steve
Could you please provide a current clear description of;
Disconnect period (VP2PeriodicDisconnectInterval)=?
DavisIPResponseTime=1000
and
RestartIfDataStops=1

Are these now fully functional in CumulusMX?

It seems the correct settings in these parameters may help with WiFiLogger issues.

Am trying to get two copies of MX running in same Computer and have two consoles;
VP2 Console at C:\CumulusMX\ on a Davis USB logger on Com3
Envoy at C:\CumulusMXIP\ on the TCPIP WiFiLogger at port 22222.

Either will run but not both together.
Have turned off the Setting Stop Second Instance in both - Any suggestions?

Thanks

Re: WiFiLogger for Davis stations

Posted: Sat 07 Jul 2018 3:53 am
by PaulMy
Hi Brian,
I am running very similar to you BUT:
Envoy/USB and Cumulus 1
and Vue console/WiFiLogger and CumulusMX
both on the same computer.

I can run both Cumulus 1 and CumulusMX at the same time until CumulusMX crashes. Current CumulusMX running into 2nd day and Cumulus 1 does not fail at all.

My settings:
Cumulus 1
Davis type - tick Serial
Tick Confirm shutdown
Tick Close on suspend
Tick Stop second instance
Tick Restart if unplugged

CumulusMX
Davis Connection - TCP/IP TCP Port 22222
Disconnect period 20
Tick Stop second instance

CumulusMX does not have all the settings options that Cumulus 1 has and maybe the extra options on Cumulus 1 is why I can run both at the same time on the same computer.

Paul

Re: WiFiLogger for Davis stations

Posted: Sat 07 Jul 2018 4:44 am
by BCJKiwi
OK, If you are running different programs then there should not be a conflict.
I could run 2 MXs but in different PCs but my understanding is that I should be able to run 2 MXs at the same time but in different folders however that does not seem to be the case (Yet?).

Re: WiFiLogger for Davis stations

Posted: Sat 07 Jul 2018 6:59 am
by laulau
When Cumulus starts, it will display the URL of the user interface. It runs on port 8998 by default; if this is not suitable for some reason you can over-ride it using the '-port' parameter on the command line, e.g. to use port 9999 instead:

sudo mono CumulusMX.exe -port 9999
Perhaps this works also in windows :!:

Re: WiFiLogger for Davis stations

Posted: Sat 07 Jul 2018 8:24 am
by steve
BCJKiwi wrote:Disconnect period (VP2PeriodicDisconnectInterval)=?
DavisIPResponseTime=1000
and
RestartIfDataStops=1

Are these now fully functional in CumulusMX?
VP2PeriodicDisconnectInterval: When the clock minute changes, Cumulus stops the current stream of data from the console, disconnects, waits for the specified number of milliseconds, and then attempts to reconnect.

DavisIPResponseTime: The length of time in milliseconds which Cumulus waits to allow a response from the console to a command (i.e. a request for any kind of data)

RestartIfDataStops: Cumulus 1 attempts to restart itself if it has had no data from the station for 60 seconds. Currently no effect in MX.

MX will not currently work reliably in any situation where the connection to the console may be lost. Loss of the connection causes an exception when MX tries to talk to the station, and MX does not currently handle the exception, which is why it crashes. This is not an issue in Cumulus 1 because the Davis DLL handles the connection.

You should be able to run multiple instances of MX on the same machine as long as you do not try to use the same TCP port for user interface (you can change it in the way Laurent suggests).

Re: WiFiLogger for Davis stations

Posted: Sat 07 Jul 2018 11:49 pm
by BCJKiwi
Thanks Steve ( and Laurent ) 8-)
The explanation helps a lot.

CumulusMX's are running on win10 - one on USB and one on IP.

Second instance Administrator Cumulus.exe shortcut:-
Target: C:\CumulusMXIP\CumulusMX.exe -port 8997
Start in: C:\CumulusMXIP

Second instance CumulusMX.exe shortcut:-
URL: http://10.0.0.1:8997/

These work OK but there is an error on start up but this does not stop loading or running of .exe or User Interface websites.
Have attached a snippet from MXdiags which indicates both instances of web socket server are sharing port 8002 and .net is complaining.

Re: WiFiLogger for Davis stations

Posted: Sun 08 Jul 2018 9:46 am
by mcrossley
You need to use the -wsport parameter on the second instance to alter the web socket port as well as the http port

Re: WiFiLogger for Davis stations

Posted: Sun 08 Jul 2018 10:16 am
by steve
Oops, yes.

Re: WiFiLogger for Davis stations

Posted: Tue 10 Jul 2018 9:59 pm
by BCJKiwi
Well the issues I'm seeing are ongoing.
2 instances of MX will not play nicely even with -wsport setting.

So in an atempt to test the WiFiLogger I set up MX in another PC and copied in the data, .ini etc etc files and ran it.

It is still not stable and stops at interminate periods sometimes over a day and somtimes withing a few hours.

The MXdiags error listing is as follows:-

Code: Select all

2018-07-10 18:28:48.399 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
   at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at CumulusMX.DavisStation.SendLoopCommand(TcpClient tcpPort, String commandString) in C:\Users\steve\Documents\Visual Studio 2015\Projects\CumulusMX\CumulusMX\DavisStation.cs:line 766
   at CumulusMX.DavisStation.Start() in C:\Users\steve\Documents\Visual Studio 2015\Projects\CumulusMX\CumulusMX\DavisStation.cs:line 580
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()
Obvoiusly there is no C:\Users\steve\Documents\Visual Studio 2015\Projects\CumulusMX\CumulusMX\DavisStation.cs in the PC but assume this is just an internal error message listing in the code.

Have attached an edited version of the Cumulus.ini file in case there are settings missing/or should be changed.

Not sure what to try next - wondering if trying Cumulus1 with the Davis.dll or turning off loop2 might have any bearing on the issue.

Thanks

Re: WiFiLogger for Davis stations

Posted: Wed 11 Jul 2018 4:44 am
by steve
This is the issue I described above, the connection was closed and MX does not handle it. You are unlikely to get MX to play nicely in a situation where the connection can get closed while it is using it, regardless of settings.

Re: WiFiLogger for Davis stations

Posted: Wed 18 Jul 2018 7:56 am
by prodata
steve wrote:This is the issue I described above, the connection was closed and MX does not handle it. You are unlikely to get MX to play nicely in a situation where the connection can get closed while it is using it, regardless of settings.
Steve, I may be wrong but this sounds like it is an error that could (easily?) be handled, at least in principle with a tweak to CMX.

I'm aware of the situation with CMX development, but any chance that you could offer a pointer as to the likelihood of a fix happening in eg the next 6-12 months - I'm thinking along the lines of possible vs definitely not vs no idea!

Right now it looks like CMX is not really recommendable for use with the new generation of Davis-compatible loggers that may be configured to do other uploads while still feeding LOOP data to software like CMX and where, at least occasionally, a new LOOP packet may not be available within the required time window.

Re: WiFiLogger for Davis stations

Posted: Wed 18 Jul 2018 8:19 am
by steve
John, yes, it’s something that could (and should) be handled. Regarding a fix in the timescale you mention, I would think that at some point in the next few months I will either find the time to do a few enhancements, or I will finally decide to make the source code available.

I’m not sure I understand your description of the problem, though. I’m pretty sure MX already copes with LOOP packets not arriving. The diagnostics that have been presented suggest that the problem is that the connection is being disconnected (and not by MX). This is the same as happens sometimes with Davis IP loggers.

Re: WiFiLogger for Davis stations

Posted: Wed 18 Jul 2018 10:35 am
by prodata
[Not sure this is the right forum to continue this thread, but since it's started here...]

Thanks Steve, that's helpful.

I clearly don't understand enough about the detail of how the IP connection is made. I had imagined that this connection was, in a sense, always on, ie if a data packet arrived on a given port number then it would always be delivered to the relevant software (assuming that the software was loaded and active). So I'd imagined that the MX problem with the WiFi logger was simply a delayed next LOOP packet.

But it sounds like that's the wrong picture and there is actually an active connection established between WFL and MX. (Is there something akin to Redirector code delivering data to MX via a VCP for instance?) And what's causing the problem is that the connection is being taken down from the WFL end. So what's needed is - if possible - for the connection to stay up even if the next LOOP packet is delayed significantly (or even missed altogether), while the WFL is performing other tasks. Is that a more accurate statement of the problem?

Apologies if I'm fumbling with terminology here, but just trying to understand the issue better to see if there are alternative fixes possible.

Re: WiFiLogger for Davis stations

Posted: Wed 18 Jul 2018 11:21 am
by steve
MX has to first establish a TCP connection to the logger before it can begin exchanging data with it. It currently doesn’t allow for the possibility that the connection may no longer exist when it tries to send a command, and what happens then is that the system raises an exception, which MX doesn’t handle, and an unhandled exception results in a crash. I don’t know why the connection gets disconnected, but it doesn’t really matter - MX needs to handle the situation.

The other thing it needs to do is to re-establish the connection, but I think that there may already be code in there to do that, but it’s currently of no use in this situation as it’s already crashed.