Control precision of number values passed to Alexa TTS service

[andyzlen]

Number values like temperature provided by thing channels are directly passed to TTS service of Amazon Alexa engine ignoring item configurations like [%.1f %unit%]. Depending on the precision with which the value was passed number values with high precision could end in an output like “The temperature in the children’s room is twenty-three-point-eight-nine-nine-nine-nine-six-one-eight-five-three-zero-two-seven-three-four-three-seven-five degree”. Of course you can try to manipulate number values as desired but especially when dealing with Quantitype values this ends in a nasty task for OH users to manipulate values in rules, please see also my explanation here: Openhab issue #4054: [Netatmo] Temperature values with many digits after decimal point. Therefore I suggest to apply the formatting pattern which allows users to get exactly the precision they desire. As @wborn explained here, not all item states are expected to have the same precision. E.g. for Energy (kWh) it's sometimes more desirable to have a higher precision.

[jsetton]

So it looks like the state value coming from the OH Rest API is raw. However, the formatting pattern is available in the API response. So that should be an easy change by normalizing an item state returned by the OH Rest API, if a formatting pattern is provided, using the sprintf.js module.

{
  "link": "http://localhost:8080/rest/items/TestNumber",
  "state": "1.23456789",
  "stateDescription": {
    "pattern": "%.5f",
    "readOnly": false,
    "options": []
  },
  "editable": false,
  "type": "Number",
  "name": "TestNumber",
  "label": "Test Number",
  "tags": [],
  "groupNames": []
}

[digitaldan]

Sounds reasonable to me, I am hoping to restart development this weekend and get a v3 beta out ASAP, I’ll take a look at this as well unless someone beats me too it.

[jsetton]

I just submitted a PR implementing this feature based on the item state presentation format.