Meteohub Update 4.2d

[admin]

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?

Yes, can be done. Should it be restricted to sensors assigned to an id or for all that have been seen anyway?.

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?

Yes, that is already implemented. You can also apply Meteohub calibration to "data" sensors. HTML data logger will also support "data" sensors starting with version 4.2e.

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?

Yes, that was one of the reasons to introduce generic "data" sensors to Meteohub.

Maybe some changes do not need a recomputation.

4.2e does reduce recomputation to those interactions on weather station page that make it necessary.

[admin]

day/moth/year values for uptime don't have a meaningful implementation. At the moment the math applied to it is like for temperature. That is fine for just reporting the actual value but when considering values for time frames the cumulative nature of uptime has to be taken into account. Meteohub supports cumulative sensor types (like total rain). I will think how to adapt this. May be something like a duration measurement class has to be introduced... will take some time.

For the moment just the actual values are defined and meaningful.

[cbhiii]

Right. It would be great to see it record and accumulate like a rainfall sensor so that monthly "uptime" can be calculated as a percentage of total hours in the month.

I understand that it will take take to do it, but I and other would greatly appreciate that feature. Thanks!

[skyewright]

Does the Meteohub system 'know' the total number of 'live' sensors

Yes, can be done. Should it be restricted to sensors assigned to an id or for all that have been seen anyway?.

I was thinking of 'live assigned sensors' as a sort of quality control value to monitor.
'Total assigned sensors' might be handy for maths, but for most Meteohubs it would be a static figure for months or even years?

Could the "data" sensor type be made available for plug-ins?

Yes, that is already implemented.

I did wonder - but time constraints meant I opted to ask rather than just try it out. :)

4.2e does reduce recomputation to those interactions on weather station page that make it necessary.

Thank you. I'm sure that will be much appreciated, especially by NSLU2 users.

[skyewright]

day/moth/year values for uptime don't have a meaningful implementation. At the moment the math applied to it is like for temperature.

Uptime is maybe an odd one?
The more I think about it the more I think maybe the current implementation is right, i.e. without a midnight reset.
In my example day1_data1_valuemin_num was 3.00, but maybe the Meteohub had been running for days at that point? To show a minimum of 3.00 sort of implies that at some point there was 3 hours between reboots!
The current arrangement shows the average, minimum, and maximum of the values visible on the System page so far during the day, which arguably makes more sense.

Maybe that and a percentage uptime as mentioned by cbhiii?

Meteohub supports cumulative sensor types (like total rain). I will think how to adapt this. May be something like a duration measurement class has to be introduced... will take some time.

Yes, an 'accumulator' or 'counter' type would be nice (when you find the time).
Maybe 2 data values; a count and a rate?
Though maybe you'd rather keep these generic types to just one value which the implementor could then use in whatever combinations they wished (i.e. no reason why a plug-in might not populate both a data and a counter with values of different types based on readings from a single physical sensor, e.g. a lightning counter).