Problems with UnitOfMeasurement DataAmount Byte

Hi everybody,

I’m facing a problem while using UnitsOfMeasurement of type DataAmount with unit Byte.

Item file looks like this:

Number:DataAmount InternetDataTodayDown “Data volume Today (Downstream) [%.1f GiB]”

When I’m updating via a external script or via OH2 rest interface (with message/body/value = 16288.735 MiB) I get the following error message and the value is not updated:

[WARN ] [rest.core.internal.item.ItemResource] - Received HTTP POST request at ‘items/InternetDataTodayDown’ with an invalid status value ‘16288.735 MiB’.

I don’t see the failure in my configuration - does anybody from your side?
Or might there be a failure in the software (because with other UoM of type power everything works fine…

P.S. I also tried to use prefix G instead of Gi, but didn’t work as well.

Thanks in advance for your support

  • Platform information:
    • OS: Ubuntu 20.04 LTS
    • Java Runtime Environment: OpenJDK Runtime Environment (Zulu (build 1.8.0_252-b14)
    • openHAB version: 2.5.10

That is because OH has no such unit of measurement. Please refer to the official documentation.


Of course this unit is included in the list of supported units (there are several more tables inside the official documentation you referred to):

1 Like

OK I stand corrected. I missed that.
I wonder if they classed byte as metric or binary. Does the G prefix work?

I was not sure as well - so I tried both, and both variants (prefix Gi and prefix G) don’t work.

Created an issue - we’ll see:

1 Like

Pay attention to the Symbol column in that table.

DataAmount Bit bit
DataAmount Megabit Mbit
DataAmount Kilobit kbit
DataAmount Gigabit Gbit
DataAmount Terabit Tbit
DataAmount Byte B
DataAmount Octet o
DataAmount Kibioctet Kio
DataAmount Mebioctet Mio
DataAmount Gibioctet Gio

Megabit has to be Mbit. Gigabit has to be Gbit.

Notice these are bit measurements, not byte measurements which appear not to be supported outside of B. Though given that a byte is 8 bits, perhaps that is what they intend the octet measurements to represent. In that case you would use Mio for megabytes and Gio for gigabytes.

Thanks for your reply and the information included… Where did you find this table because it’s a different one as shown in the documentation

It really seems that only units mentioned in your list are realized, but this doesn’t make sense from my perspective as Byte with all prefixes KiloByte, MegaByte, GigaByte, TeraByte, etc. are very common units and should be available as UoM as well.

He took the DataAmount part of the SI table.

If only certain metric prefix / SI unit combinations are supported the Prefix table needs to disappear IMO

1 Like

Fully agree with @Bruce_Osborne - from my point of view there are two ways which make sense:
a) all SI units can be combined with all metric prefixes without further notice (this is the way the documentation is written now)
b) only certain combinations are valid, then all possible combinations have to be listed separately and the prefix table should be removed.

I strongly hope that implementation goes into direction of item a) and the observed behaviour in my case is just a bug.

1 Like

I copied it straight from that very link.

@rossko57 is our resident UoM expert. Any ideas why GiB didn’t work?

expert?! Nah mate not me … I do think there is no actual Byte implementation, and its in o for Octet, e.g. “3.87 Gio”

the odd Gi/Mi stiff is to distinguish from standard ISO prefixes, because standard k = 1000 as in 2 km, data k = 1024 as in 2 Kilobytes.

What’s need here is an umm language converter. You don’t really care what openHAB calls the units internally, Gio is fine. But you’d like to “translate” for display purposes to a more conventional looking Gb or Gbyte perhaps.

1 Like

From reading the docs, GiB should work though. There is a bytes measure B and the docs say

To use the prefixes simply add the prefix to the unit symbol - for example:

and it even gives an example with bytes

KibiByte - KiB

@schmidmuc, I think you have two paths. See if you can make it work with octets or try it again with OH 3 (there have been UoM changes in OH 3 which might impact this) and if it still doesn’t work file an issue.

When I’m updating via OH3 rest interface (with message/body/value = 16288.735 MiB) I get the following error message in rest interface and the value is not updated:

Code 400 | Error: Bad RequestResponse headers connection: close content-length: 0 date: Sun08 Nov 2020 23:25:44 GMT server: Jetty(9.4.20.v20190813)

As a workaround I changed to octets, but this should be implemented as well… I already created an issue - link mentioned above.

I looked in some code, without much idea of what I was looking at, and B/bytes do not feature.

If we can can figure out units language i.e. “my local text for this unit” then that doesn’t matter at all.

I could also give it a try to find the problematic code…

Could someone help me to find where in the code the UoM are implemented?