Original release topic

[HansR]

Sorry I use PHP a lot to run my whole website, so I use that as as solution to a problem that requires a program at the server level.

OK, but I am talking about a completely client based issue. My program is browser based for this point.

I cannot see why you are reluctant to use it as you are reliant on Server side JS scripts to produce the gauges, so why not add the PHP to the CumulusUtils pages that produce the output on the server?

Sorry for that, but it's my design and a somewhat fundamental way of looking at how I want to do it. And it is not server side javascript as I said above, it is browser based. I wrote a blog about it but my Wordpress for some reason fails editing. Some plugin. So you have to wait for it.

That was quicker than I thought, apparently an issue with the new 5.4 WP release. Here is the blog.

[sfws]

We are not talking about a global, but about the path to realtimegauges.txt which is defined in gauges.txt

I understand you perfectly, and I recall all you have said previously about having settings in one place, but you appear to misunderstand me.

I (and I think Water01) was talking about a change that let the definition of the path in gauges.js be defined outside that script. You (and nobody else) change that script to check if a variable (what I call global, i.e. shared across more than one script) has been set. You can then have another script (your setting script) set that variable and the changed gauges.js will read that without the end-user having to do any more editing of gauges.js to suit whatever path they use.

Oh and I also understand you wanted your creation to sit alongside Cumulus without tinkering with Cumulus files, but I am suggesting that you change one Cumulus file in a way that the developer could adopt into future MX releases, it has no effect on MX functionality, it does offer the possibility that an extra setting could be added to the MX settings to adjust the path without anyone ever needing to edit this file in the future. Maybe that is something Mark might have thought good to do in future anyway.

Now I hope you understand what I was saying in my previous post, I often feel my written work is not concise enough, it appears it was too concise that time for you.

[HansR]

I am not sure it is misunderstanding. Sure I can change gauges.js, and sure it can be done in the indirect way with intermediate global variables and there is more than one way to do so. But that is not the way to go if you want to work modular. I know configuration is done by editing mostly in the world of meteo websites/PHP. And that is exactly the choice I try to avoid. If there is configuration in a module (in this case gauges which is a layer upon Steelseries) the module should offer ways to configure. Either through file settings or with an api accessible for other programs, by change through calls or whatever. Not by manual interference or complex interaction with intermediate globals.

And I think we do not need to discuss it further. It is possible, as kocher showed with his slink - to change settings in the Steelseries by software (the attributes are public as far as I can see), I don't see why important attributes of the gauges can't be public and changeable at runtime. For the cumulus community it actually is more important. It leads to messy solutions as described.

If you don't agree, that's OK. My way of thinking, but that's life.

[HansR]

Version 3.0.1 is online

As you all appear to have more than one cumulus site running on the same real-time files, at least for test situations, I added the ini parameter CumulusRealTimeLocation to provide for a user who uses more than one website. See my notes in the README!

Known issues:

• the times are wrong in another timezone (with an offset of that timezone to my location )
• The moonphases do not show correct.
• Cumuluscharts needs to be rewritten because of the hardcoded location of the json data files (a problem similar to realtimegauges.txt).

Make the list with known issues as long as you can

[laulau]

It's a good idea to make the user define the path of the realtime files!

I guess we all agree but the path is hardcode in gauges.js
I already send a mail to @mcrossley on how to change the gauges config in software. I am awaiting his reply.

With respect to your sysinfo module failure (Méthode introuvable : '!!0[] System.Array.Empty()' which effectively breaks off the whole program because of a stack dump) seems to have to do with the version of .NET you are running. As Win7 is no longer maintained, upgrading probably is not possible.

That dump is caused by a lesser version of Windows and .NET . You need at least .NET 4, I believe even > 4.5. I am not a 100% sure in what version that call is introduced. But an upgrade is required or you can't use CumulusUtils (because the version call is everywhere). It is also an investment into the future (I don't economise on versions , I always ugrade pretty soon and operate currently on 4.7.2 works on normal up to date and maintained Windows.

Best, Hans

Have upgraded .NET framework

Last version here : http://laurentmey.fr/davis/utils/index.html

[HansR]

Have upgraded .NET framework

Good for you!

Last version here : http://laurentmey.fr/davis/utils/index.html

Wow, that actually looks pretty impressive if can say that myself
And btw: you have very much a variable wind today!

It really looks good. Works easy doesn't it?

[laulau]

Yes it works quite well!
I've to look at the user menu and the French translation at some point.

[HansR]

Yes it works quite well!
I've to look at the user menu and the French translation at some point.

Yes, but translation has to wait until I created all string entries.
First it must run correctly

[meteo19]

Bonsoir Hans
Fonctionne ici:
http://www.meteosegur.fr/CU_MX/utils/index.html
Comment adapter le site à la taille des écrans.Super travail Hans.

Pats

[HansR]

@meteo19: bonsoir Patrick, Je suis de retour à vendredi. La adaptation sera fait...
Merci pour l'installation. Maintenant... Break

[PaulMy]

@meteo19
From my experience you likely need to edit \CumulusMX\utils\cumuluscharts.js
and replace $.ajax({url: "../graphconfig.json", dataType:"json", success: function (result) {
with $.ajax({url: "graphconfig.json", dataType:"json", success: function (result) {

and then remove all the other leading ../ in that file as well and then re-run. Make a copy before you begin editing.

Enjoy,
Paul

[meteo19]

Merci Paul

[PaulMy]

Hi Pats,
I had to make those changes for the charts to work http://www.komokaweather.com/cumulusutils/index.html
But your changes may need to be somewhat different depending on where your files are located.

p.s. the version of CumulusMX where cumulusutils is located is a separate Cumulus install and shares the Davis console with another CumulusMX version install http://www.komokaweather.com/cumulusmx/ so have to stop one to run the other so current data is not always current.

Enjoy,
Paul

[meteo19]

Merci Paul les graphiques fonctionnent.

[HansR]

OK, good to hear.
The resizing of the screen is another issue, will work on it.

There is quite a bit more detail to do now than expected
Maybe i'll publish another intermediate beta soon.