Meteohub Update 4.2d

[admin]

DEUTSCH:

Update V4.2d (NSLU2 und x86) enthält die folgenden Änderungen:

* Fügt als auswählbare Station "System Data" hinzu, deren Sensoren Informationen über den Systemzustand geben: Uptime, Systemlast, Speichernutzung, Anzahl Prozesse, Signalpause. Diese Daten können den IDs data0 - data39 zugeordnet werden und in Grafiken oder als Variable für HTML-Templates verwendet werden. Die Implementierung ist noch experimentell.
* Fügt Unterstützung für die Wetterstation RainWise MkIII hinzu. Die Implementierung ist noch experimentell.
* Verbessert das Wiederaufsetzverhalten des USB HID Datenerfassungsprozesses.
* Erweitert die "dmesg" Protokolldatenanzeige um eine Listung der verfügbaren PCI und USB Geräte.
* Beseitigt einen Fehler bei der Berechnung der textuellen Windrichtung aus der Windrichtung in Grad.
* Beseitigt einen Fehler in den monatlichen Zeitplänen, der zum täglichen Upload führte.
* Um Probleme mit unvollständigen Daten beim Speisen der Wetternetzwerke zu vermeiden, werden nur Datensätze gesendet, die mindestens eine Außentemperatur und -feuchte enthalten.
* Schaltet die akustische Signalisierung der IP auf den Plattformen VMware und Virtualbox ab.
* Beseitigt einen Fehler bei der Spezifikation von mehr als 64 Grafiken zum Hochladen auftreten kann.

----------------------------------
ENGLISH:

Update to Meteohub V4.2d (NSLU2 and x86) brings these features:

* Adds station "System Data" that reports system information by it's sensors: uptime, system load, percentage of storage usage, number of processes, signal pause. This data can be used for graphing and HTML template replacements. The implementation is still experimental.
* Adds support for weather station RainWise MkIII. Implementation is still experimental.
* Improves restart behavior of USB HID data logging process.
* Adds a list of available USB and PCI devices to "dmesg" log file.
* Fixes a bug that computes slightly wrong textual wind direction from wind direction in degrees.
* Fixes a bug in monthly time schedules for graph uploads that resulted in daily uploads instead of monthly ones.
* To avoid trouble with incomplete data sets for weather networks, a data set must at least have outdoor temperature and humidity to be sent.
* Disables acoustic signaling of IP when on platforms VMware or VirtualPC.
* Fixes a bug that can occur when specifying more than 64 graphs for upload.

----------------------------------

Remark: When you have Meteohub 4.2c or newer installed, easiest way to get this Update is by use of "auto update" feature on "maintenance" page.

Download link: http://www.meteohub.de/joomla/index.php ... &Itemid=29

[admin]

Here you find an example for display of system load (left) and number of running processes (right).



This needs the station "system data" activated and it's sensors mapped to data ids. These data ids are then used for graphing.

[admin]

here is the graph definition:

[admin]

... and sensors page

[wfpost]

nice feature:
how do I interpret Signal gap? 3.00 stands for?

danke

[admin]

It is the time in secs that has passed since the last sensor reading has been received. When no sensors are recorded this number goes up. It does not reflect on a particular sensor but notices when the stations gets completely silent.

[admin]

I just realize, that "auto update" feature might not work (gets stuck at checking md5sum)... so please use traditional update path. This will be fixed with next update.

[skyewright]

* Adds station "System Data" that reports system information by it's sensors: uptime, system load, percentage of storage usage, number of processes, signal pause. This data can be used for graphing and HTML template replacements. The implementation is still experimental.

A small point. First some history...

In the early days of the multi-station feature my 'spare' Meteohub had 4 stations set up@
0: RFXCOM TCP/IP
1: RFXCOM USB via TCP/IP from another Meteohub
2: WMR200 USB

After a while I deleted station 1 and stopped station 2.

Later I added
3: Plug-in

I just went to add a 'System' station. After selecting the Add option there was a new entry
4: System Data

but (though I didn't notice it at first) there was also a
1: System Data

Maybe Meteohub doesn't like "holes" in the sequence?

I've now deleted 4:, so there is just one System data and no 'hole'. ;)

PS. I noticed that the action of adding a Weather Station seems to provoke a reclaculation of data.
Is that really necessary - since, so far as I'm aware, at that point the new weather station (of any type) does not have any sensors associated with it, so there is nothing to affect any calculations?
When sensors are assigned on the Sensors page for the new station another recalculation will be provoked - wouldn't that be enough on its own?
Just a thought...

[skyewright]

You may have already noticed this but the Data used and System used figures seem to be cross connected, i.e. compared to the System Info page Data used is the System figure, and vice versa.

[admin]

Yes, I swapped this. Any additional info you might find useful in system data section?

According to recomputation, I will have a look at this. Maybe some changes do not need a recomputation.

[cbhiii]

Boris,

Very nicely done! These system loading and status features are just the kind of things I was looking for! (especially signal gap)

I also like the autoupdate feature and the data check before sending to weather networks.

Great job!

[cbhiii]

I found a bug when deleting graphs in the "manage graphs" section.

When you click on a graph and hit DELETE it will delete the wrong one in most cases. Especially if you've used one graph to make others out of.

Can you try and duplicate this?

[skyewright]

Any additional info you might find useful in system data section?

Does the Meteohub system 'know' the total number of 'live' sensors, i.e. the number that are currently sending data at least as frequently as each station's "Hold time for live data" time?

Also, I imagine that a "data" value is just a 2 decimal place number?
Could the "data" sensor type be made available for plug-ins?
e.g. the plug-in provides
data9 123
to indicate a value of 1.23?

This could allow recording for non-standard sensors such as a lightning counter, a moisture meter or something measuring Amps or Volts, without resorting to 'misusing' standard sensor types?

Maybe some changes do not need a recomputation.

I think some could manage without.

A nice 'expert' option on the Maintenance page might one to disable automatic recomputation? Sometimes if there are a number of changes to be made each of which would provoke an auto recomputation it would nice to be able to "turn off" the automatics, make all the changes, then re-enable automatics, and set off a manual recompute.
Just an idea...

[cbhiii]

Uptime bug (maybe)?

I found an issue with the data1 sensor (uptime).

(1)
When using the variable [day1_data1_valuemax_num] I would expect it to say only 9.5 hours if it is 9:30am local time, yet it says 23.59 because I rebooted it yesterday at almost this time. I think this variable should clear every night so that an uptime percentage can be calculated out of 100%. The same is true for the month and year variables. In the future I want to have a percentage on my web page showing my server uptime as a percent for the day, month and year. So it would be like 99.99%, 99.87%, 99.76% for example. Unless you can tell me how to calculate that.

(2)
How should I interpret the 3 variables below? How can there be a minimum uptime, and average, and a maximum? Wouldn't there be just 'max'?

day1_data1_value_num 18.92
day1_data1_valuemin_num 14.25
day1_data1_valuemax_num 23.59

Thank you.

[skyewright]

How should I interpret the 3 variables below? How can there be a minimum uptime, and average, and a maximum? Wouldn't there be just 'max'?
day1_data1_value_num 18.92
day1_data1_valuemin_num 14.25
day1_data1_valuemax_num 23.59

If, as you suggest and I agree, the day1 reset for these was at midnight (i.e. was a "Today" figure like the other day1 values) all the above figures would presumably be around 9.50 for your example, but minimum and average could have different values to maximum if there were reboots during the day.

e.g. with reboots at 3am and 8am then at 12 noon, I think the figures would be:

day1_data1_value_num 4.00
day1_data1_valuemin_num 3.00
day1_data1_valuemax_num 5.00

Does that make sense?