OH3 Shelly Binding UoM Voltage vs Temperature - Explanation

Setup, Configuration and Use Items & Sitemaps
,
1
  • Platform information:
    • Hardware: amd64
    • OS: Windows 10/10.0
    • Java Runtime Environment: 11.0.9.1 (Zulu11.43+55-CA)
    • openHAB version: openHAB 3.1.0.M4

Hi All

I recently installed a Shelly UNI to Measure Voltage and Temperature.

I have however bumped my head on an apparent UoM inconsistency which I am not sure about.

The ITEMS are created using the UI and work fine for the most part:

UoM

The ITEMS have the correct Type (being Number:Electrical Potential and Number:Temperature)

The issue however is that the UoM for the Voltage is not displayed as can be seen above.

Also, when viewing the ITEM state using the UI, the state is displayed as Err.

ADC
ADC830×698 22.3 KB

This can be “corrected” by adding State Description Meta Data of %.2f V

ADC2
ADC2840×742 24.1 KB

What I am not clear about is why Temperature works “out the box” but Voltage does not? Is this something I am doing or something the Binding is not doing?

Took me a while of searching to find how to “fix” the Err for the Voltage. I also briefly tested a Door and Window 2 unit and had a similar issue?

Thanks
Mark

2

This looks like a bug. Please file an issue on openhab-core.

If this is not a bug, the only thing I can surmise is that some units don’t have a default and thus when a unit is not provided it can’t figure out what to do. But I don’t think that is the case for V so I still think it makes sense to file an issue.

3

That’s exactly it. I believe only Quantity Types that get changed by system Metric/Imperial selection get a default unit.
Temperature gets a default, C or F. If you post “just a number”, the default unit is assumed.
It follows that posting a number without any units to one of those other types just blows up, its meanngless.

Giving the Item a state description pattern also supplies that Item with an individual default unit, overcoming the problem.

The real fix here is -
If the binding ‘knows’ that chunk of data xx is always in some unit, like V, then it needs to append the unit itself
but only if
the binding is also providing a Quantity type channel,a Number:ElectricPotential in this case.

If the binding only provides an ordinary Number channel, you made your own pitfall by linking it to an inappropriate Item type.
So far as I know, Shelly binding provides no quantity channels.

It’s reasonable to hope for a binding enhancement to deal more gracefully with units.

4

But Volt is the only unit for ElectricPotential. There is no ambiguity here. It seems like if there is only one unit supported, it should be the default.

5

Sure, but the binding didn’t say it was ElectricPotential (I’m going off the docs here). And even if it did, it could express it in mV or kV if it wanted.

6

Thanks fort he responses, though I am now more at a loss.

I installed a new Shelly EM this morning and the Voltage on that is displayed correctly with no State Description Meta Data required.

Performed a REST API query on both using the defaults as they are created when linking (using defaults) in the UI:

Shelly UNI:

{
  "link": "http://localhost:8080/rest/items/ShellyUNIshellyunie8db84d6b3e510163199230_VoltageADC",
  "state": "27.83",
  "stateDescription": {
    "pattern": "%.0f %unit%",
    "readOnly": true,
    "options": []
  },
  "editable": true,
  "type": "Number:ElectricPotential",
  "name": "ShellyUNIshellyunie8db84d6b3e510163199230_VoltageADC",
  "label": "Shelly UNI Voltage ADC",
  "category": "",
  "tags": [
    "Point"
  ],
  "groupNames": []
}

Shelly EM:

{
  "link": "http://localhost:8080/rest/items/ShellyEMshellyemb04c0810163199229_Voltage",
  "state": "232.1 V",
  "stateDescription": {
    "pattern": "%.3f %unit%",
    "readOnly": true,
    "options": []
  },
  "editable": true,
  "type": "Number:ElectricPotential",
  "name": "ShellyEMshellyemb04c0810163199229_Voltage",
  "label": "Shelly EM UPS Voltage",
  "category": "",
  "tags": [
    "Point"
  ],
  "groupNames": []
}

Does this indicate that the state coming from the binding is incorrect because there is no “V” on the UNI device 27.83 vs 27.83 V ?

Does this still look like a core issue - or more like a binding issue?

Does the REST API result indicate what I think it does? That the UNIT is missing?

I just used the defaults when linking the channel - no changes other than the Label.

Not clear what you mean here? The binding does say it is electrical potential - that is the TYPE that is suggested when linking the ITEM. The docs don’t mention this explicitly however.

Thanks once again - hope not too long?

7

I do not know if the binding offers you a number type channel or a number:electricpotential channel.
Binding may not be offering the same type for different devices.
It makes all the difference in how it works.
I don’t think it’s easy to find out the channel type in MainUI, and I’m not enitirely sure I’d trust it anyway, if it intervenes with “semantics” based on labels.

I would check the Thing in API Explorer, which should list channels.

Either -
the channel type is a plain number (binding limitation, but no bug).
or
the channel type is a quantity, and the binding forgets units (which would be a binding bug).
Same effect on quantity Item, either case.

8

Do you mean the attached from REST API?

Shelly UNI Thing.txt (9.6 KB)

    {
      "linkedItems": [
        "ShellyUNIshellyunie8db84d6b3e510163199230_VoltageADC"
      ],
      "uid": "shelly:shellyuni:e8db84d6b3e5:sensors#voltage",
      "id": "sensors#voltage",
      "channelTypeUID": "shelly:sensorADC",
      "itemType": "Number:ElectricPotential",
      "kind": "STATE",
      "defaultTags": [],
      "properties": {},
      "configuration": {}
    },

Shelly EM Thing.txt (10.7 KB)

    {
      "linkedItems": [
        "ShellyEMshellyemb04c0810163199229_Voltage"
      ],
      "uid": "shelly:shellyem:b04c08:meter1#voltage",
      "id": "meter1#voltage",
      "channelTypeUID": "shelly:meterVoltage",
      "itemType": "Number:ElectricPotential",
      "kind": "STATE",
      "defaultTags": [],
      "properties": {},
      "configuration": {}
    },

Both seem to be Number: ElectricPoptential

9

Looks reasonable.
So it looks to be binding bug, specific to UNI perhaps.
Note UNI only recently supported, but current latest should be in M4 here.

1 Like
10

Thank you. I am using 3.1.0.M4.

Have logged an issue as follows: