Ecowitt HTTP forward

[forestedge]

[attachment=0]
Gone back to the latest build and ignoring 524 errors in the MXDiags.

I use an Ecowitt station for extra sensors but cannot find the option to forward the data mentioned in the "whats new" for b3241?

[mcrossley]

It only works for primary HTTP (Ecowitt) stations at present. If you are using Ecowitt just for secondary sensors, I plan to add that in a future release.

[forestedge]

Thanks for clarifying that, in the meantime I have had to revert again as the latest build only lasted a few hours up. Had no problems before this though with uptime.

[SamiS]

If you are having problems with the php uploads crashing whole CMX, there is no reason why you couldn’t keep running the newest build using ftp/ftps/sftp with it just as with earlier releases. The php upload is just an additional method that gives some advantages, but is not mandatory.

[mcrossley]

Thanks for clarifying that, in the meantime I have had to revert again as the latest build only lasted a few hours up.

It looks like you terminated CMX rather than it stopping.

You are getting HTTP error 524 (timeout) to every PHP upload request. Most times I have heard of that it is because the web site is fronted by CloudFlare. I do not know what the answer to that is.

But as stated, there is no need to revert the MX version, just switch back to whatever FTP upload process you were using before.

[freddie]

You are getting HTTP error 524 (timeout) to every PHP upload request. Most times I have heard of that it is because the web site is fronted by CloudFlare. I do not know what the answer to that is.

Sometimes when you visit a site fronted by CloudFlare you get an interstitial page that says words to the effect of "checking your browser", so perhaps there is some pre-emptive filtering of bad actors. I don't know if it is possible to configure individual URLs to not be subject to this - I really don't know the first thing about CloudFlare apart from this observation of behaviour.

[SamiS]

@mark did you spot these from the log? They seem to occur quite a less frequently than upload errors.

Code: Select all

2023-05-04 18:41:31.271 !!! Unhandled Exception !!!
System.ArgumentException: The tasks array included at least one null element.
Parameter name: tasks
   at System.Threading.Tasks.Task.WaitAll(Task[] tasks, Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at CumulusMX.Cumulus.<RealtimeUpload>d__306.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   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.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
 

[mcrossley]

Yes, I did. Under investigation...

[mcrossley]

I think it occurs because the upload tasks are erroring before they are added to the list of tasks I keep, then I wait on the all the tasks in the list to complete which is then null. I'll add a check to make sure the task list has a Count > 0 before attempting to wait on them.

(It could also do with a try-catch as well!)