Metrics and imperials, I18N

5 posts / 0 new
Last post
Esa's picture
Metrics and imperials, I18N


have you discusses the need to be able to show metric values in addition to imperial/Us ones ?

I feel this should be made optional to the user to select which system to see the values in, the data seems to be metric tough but the UI
shows only imperials. I glimpsed through the scripts and seems that these are hardcoded, could easily add 1 config item for user to
select which one to show, and the scritps to provide either one.

Also could be considered for future development to take I18N, i.e internationalization requirements into consideration at least with
the UI elements... make them e.g configurable with preferred languages...

Nate's picture
Data conversions

Converting at the device may be problematic - I work with a data historian, and it's an extremely common problem, where to convert, and how to handle?

If there is multi unit of measure support, you would need to really think about the data flow and ensure it remains usable as additional features are added. How about a university gathering data from multiple hives? they need units of measure aligned so calculations line up - Adding a unit of measure field, and a table for driving the unit conversion in the end database would give a structure to allow common analytics, or alarm algorithms to be deployed.

I'd want to be able to benefit from some fancy new alarm logic someone else thinks up regardless of the UOM they use.

Paul's picture
Database schema


Have you looked at the database layout and the HIVE_DATA table?

Perhaps the raw database should have just one column for weight and one for units and then the other unit columns (or tables) in the converted database be populated from it?

This is a good time to figure this out as we are working on the data warehouse and would like to take lessons learned there and redesign the raw database.

I think you have seen this but maybe others haven't:

Can we take this design to the next level?

Esa's picture
I agree not to mix units that

I agree not to mix units that are used in the database, processing etc.- but the User Interface to be built so that the user can
select preferred units to show or automatically from users locale settings. E.g so that you guys in US can use old imperials and us in old continent modern metrics :)

Paul's picture
The current "Plan"

I do not have much expertise in large scale implementation of sensors but these are my thoughts:

1. Most certainly the user should be able to select units. On, your preferences should be stored and used when you login or based on cookies. (Also, pen and background colors, my favorites hives list, etc.)

2. KISS on the input side. Upload the data in the native units of the sensor or in units that the local beekeeper uses.

3. Convert the incoming data at the server to fill in the missing values for different units. The data base table has columns for different units. The conversion could be done on the fly each time the data is loaded but some of the data is loaded many time so it make sense to do the conversion once. It can be converted at the hive when it is inserted into the local database. One reason I want to convert at the server is to be able to insure that it is done correctly. Not all hives will necessarily run hivetool, but that is another problem.

Log in to post comments