Page 2 of 2

Re: Another post about error 103 and 32

Posted: Mon 24 Nov 2014 8:19 am
by steve
Brandon wrote:I'm not sure how to answer the question exactly because I'm not sure. So I will just mention how I have it set up. Under configuration there is an option for FTP logging I have check this a few times, but it seems to uncheck itself (or possibly gets uncheck when closing and opening cumulus?). Anyway, I have not noticed a difference in any uploads or errors whether it is checked or not so I am not sure what it does.
There is brief help for the menu items under "The Displays" - "Menus". FTP logging causes diagnostic logs of the ftp uploads to be created.
Under web settings in the internet configuration site/option tab I have the following boxes checked: Auto Update, Use FTP Rename, UTF-8 encode, Interval 3 minutes, Enable Realtime, Enable Realtime FTP, Realtime Interval 240 seconds. Then under the internet configuration files tab, it is set to sent the month file, the day file, and the extra log file. For each of those the Realtime, FTP, and UTF-8 boxes are checked.
It's a bit unusual to have 'realtime' at a longer interval than the normal uploads (hence the name), but it doesn't really make any difference to anything. So you are uploading the files at the realtime interval of four minutes, and the uploads will not be in sync with the writing of the log files. Again, not that it makes a great deal of difference. In my opinion, the only safe way to do this is to allow enough time between each log entry and upload such that it will always have completed before the next update is due.

Re: Another post about error 103 and 32

Posted: Mon 24 Nov 2014 10:38 am
by SpaceWalker
Brandon, for quite a few years now, I have been using an external very powerful and very reliable software (than the limited FTP functions usually built into the weather software) - it is called Syncovery.

That external software has been used to upload almost all of the data files created by both my weather software - the data files are uploaded to four different locations - some of those files are even uploaded in near-real time (as they are updated on the computer, they are also immediately updated onto the server). The software is well worth the money I paid for it years ago...

Re: Another post about error 103 and 32

Posted: Wed 26 Nov 2014 12:08 am
by steve
Brandon, see the post I've just made in this thread - https://cumulus.hosiene.co.uk/viewtopic.p ... 793#p99793 - for a possible way to get Cumulus to copy the log file before uploading it. You could use the same technique for the extra log file.

Re: Another post about error 103 and 32

Posted: Wed 26 Nov 2014 12:22 am
by Brandon
steve wrote:Brandon, see the post I've just made in this thread - https://cumulus.hosiene.co.uk/viewtopic.p ... 793#p99793 - for a possible way to get Cumulus to copy the log file before uploading it. You could use the same technique for the extra log file.
That is actually a really great idea! That said, I think I may not need it. Earlier today I went in and made sure that the logs were only FTP and not realtime because of your comment about the logging and normal uploads being synced with the log first then upload. Once I removed all of the realtime stuff, and set both the uploads and the logging to the same 5 min interval, I have had no problem. Im not likely to have a problem with the log taking longer than 5 minutes, even so once I get done testing this I plan to only save every hour to the log and database, so that will be ample time.

In other words, it seems that you solved my problem. Thank you for your diligence!

Two other quick questions is there a setting for making the FTP time out? If I wanted to keep it 5 minutes for example it would be nice to be able to timeout the FTP at 4 min so that if there was an atypically long upload it would err on the upload rather than erring on the logging which is so much more important.

Second (I think I know the answer to this as I haven't seen any links anywhere for the source) do you make the source available at all for customization?

Thanks again for all of your help!

Re: Another post about error 103 and 32

Posted: Wed 26 Nov 2014 8:21 am
by steve
Brandon wrote:Two other quick questions is there a setting for making the FTP time out? If I wanted to keep it 5 minutes for example it would be nice to be able to timeout the FTP at 4 min so that if there was an atypically long upload it would err on the upload rather than erring on the logging which is so much more important.
No, it will only time out if there is problem - the server not responding.
do you make the source available at all
No. I am asked this from time to time, and I'm not sure people who ask have really thought it through. You would need licences for the development environment and the commercial components which I use, which would cost you around $3500 in total. Unless you are already a Delphi developer and have a recent version of Rad Studio?

If I made the source available, there would then be modified versions of Cumulus in use, which I would be unable to support. I'm always open to offers, though. I'm not about to give away the source code after the thousands of hours of effort I've put into it over the last ten years.

Re: Another post about error 103 and 32

Posted: Wed 26 Nov 2014 2:27 pm
by Brandon
Brandon wrote:No. I am asked this from time to time, and I'm not sure people who ask have really thought it through. You would need licences for the development environment and the commercial components which I use, which would cost you around $3500 in total. Unless you are already a Delphi developer and have a recent version of Rad Studio?

If I made the source available, there would then be modified versions of Cumulus in use, which I would be unable to support. I'm always open to offers, though. I'm not about to give away the source code after the thousands of hours of effort I've put into it over the last ten years.
You are right, I have not really thought it through. I was actually curious about licensing. I know that Davis proprietary files can be access using a free .dll that they provide, but I was not sure if you were using that or what the licensing restrictions were. As for the Delphi, I don't currently develop in it but I am open to it and I'm sure sooner or later I will end up doing so (if I end up working on a project that justifies it).

I do agree that there can certainly be issues with opening the source including the lack of ability to support many tangential versions. I am not opposed to the fact that the source is not available, I only asked because I was not sure if it was or not. I think you do an excellent job of supporting Cumulus and from what I have seen your are very responsive to feature requests when they make sense for a large number of user. I really hope that my question was not offensive, and it was not my intention to make light of all of your great work.

As far as what customization I had in mind, I didn't have grand plans. The big thing is that I was wondering how involved it would be to add an option to accept no input as null (for the database) rather than 0 or the last recorded value. From what I read on the forums, it seems that the way Cumulus currently handles it is best for the majority of users. So, I wasn't sure it would be a good feature request.

That said, Cumulus has done a lot for me that I would not have been able to do with Davis (or at least not as quickly and with as little effort). I am very satisfied with Cumulus, your support, the wiki, the whole shebang!

Thanks!

Re: Another post about error 103 and 32

Posted: Wed 26 Nov 2014 2:48 pm
by steve
Brandon wrote:I was actually curious about licensing. I know that Davis proprietary files can be access using a free .dll that they provide, but I was not sure if you were using that or what the licensing restrictions were.
Yes, the current version of Cumulus uses the Davis DLL. The licence that comes with the DLL is the same licence that comes with Weatherlink, and it doesn't actually make sense in the context of the DLL. I have assumed that as Davis supply the DLL free of charge explicitly for "third party developers", then they have no issue with the DLL being distributed with third party software.

The version of Cumulus currently in development doesn't use the DLL.
The big thing is that I was wondering how involved it would be to add an option to accept no input as null (for the database) rather than 0 or the last recorded value. From what I read on the forums, it seems that the way Cumulus currently handles it is best for the majority of users. So, I wasn't sure it would be a good feature request.
It would be a huge change, it's fundamental to the way Cumulus works. When I wrote Cumulus, I wanted to be able to load the log files into a spreadsheet so that I could do analysis on them. Having 'null' values would have made that much harder (for me, anyway). I decided that if the situation arose that there were significant periods without any new data, then the problem was with the station or my siting of it, and I would need to take remedial action, rather than it being something that I should cater for explicitly in Cumulus.