Smarthome: [Basic UI] Element Type `Default` for item of type `Location` or "How to render a `PointType` in a sitemap"

Created on 24 Aug 2018  路  19Comments  路  Source: eclipse-archived/smarthome

How does it work? Element Type Default for item of type Location: "How to render a PointType in a sitemap" for Basic UI. This is what I have set up.

demo.items:

Location owmCurrentStationLocation { channel="openweathermap:weather:api:local:station#location" }

demo.sitemap:

sitemap test label="Local weather" {
    Frame label="OpenWeatherMap - Station" {
        Default item=owmCurrentStationLocation
        Text item=owmCurrentStationLocation
        Text item=owmCurrentStationLocation label="Location [%s]"
        Mapview item=owmCurrentStationLocation height=5
    }
}

What is working - the Mapview - but nothing else (state is 49.26,-123.19):

wetter

{
  "link": "http://localhost:8080/rest/items/owmCurrentStationLocation",
  "state": "49.26,-123.19",
  "stateDescription": {
    "readOnly": true,
    "options": []
  },
  "editable": false,
  "type": "Location",
  "name": "owmCurrentStationLocation",
  "tags": [],
  "groupNames": []
}

Most helpful comment

By the way, you show another problem because when you use a label with %s, the value is not correctly displayed. Maybe a problem with an unexpected character in the value that breaks the Basic UI code ?

What do you mean exactly? I am afraid I did a mistake in the first post. My original sitemap contains label="Ort [%s]" instead of label="Location [%s]". I translated it while typing.

Maybe the channel should have a pattern with %s.

The result of a new test is not better. But I figured a pattern for the label which seems to work: label="Ort [%2$s掳N,%3$s掳W, %1$sm]". A quick Google search results in an interesting link to a international standard (ISO 6709) for a representation of latitude, longitude and altitude for geographic point locations.

demo.items:

Location owmCurrentStationLocation "Ort [%s]" { channel="openweathermap:weather:api:local:station#location" }

weather

All 19 comments

Maybe the channel should have a pattern with %s.

By the way, you show another problem because when you use a label with %s, the value is not correctly displayed. Maybe a problem with an unexpected character in the value that breaks the Basic UI code ?

By the way, you show another problem because when you use a label with %s, the value is not correctly displayed. Maybe a problem with an unexpected character in the value that breaks the Basic UI code ?

What do you mean exactly? I am afraid I did a mistake in the first post. My original sitemap contains label="Ort [%s]" instead of label="Location [%s]". I translated it while typing.

Maybe the channel should have a pattern with %s.

The result of a new test is not better. But I figured a pattern for the label which seems to work: label="Ort [%2$s掳N,%3$s掳W, %1$sm]". A quick Google search results in an interesting link to a international standard (ISO 6709) for a representation of latitude, longitude and altitude for geographic point locations.

demo.items:

Location owmCurrentStationLocation "Ort [%s]" { channel="openweathermap:weather:api:local:station#location" }

weather

So it could be solved bu adding the right pattern definition to all channels associated to a Location item ?

In general, yes. But from my point of view we should reach an agreement on the "%s" pattern for Text elements. Resulting in an "0" is not an option. Is it?

And lets add some documentation about this specific pattern somewhere in the docs.

You're right. There is a place where a default pattern is set if not defined. I did that for String and Number items if I correctly remember. We should add one for Location item.
I will search where it is defined...

The PR that introduced these default patterns is #3822.

Note that it could make sense to replace the "Default" element from a Text widget to a Mapview widget in case of a Location item ?

I am not sure if we should define a global default pattern. I just want to make sure that we get a valid result for the pattern "%s". May both.

Does every available UI support the Mapview element? If so replacing the Default could be an option.

I use the system.location channel type in the OWM binding. A default pattern should be added to it.

https://github.com/eclipse/smarthome/blob/5ef015187d8c768312124d418e74feb282e9b69d/bundles/core/org.eclipse.smarthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/DefaultSystemChannelTypeProvider.java#L139-L146

Ok, you're right, maybe not all UIs are already supporting mapview. So Default = Text looks reasonable.
Adding a pattern to the system channel is a good idea.
We should not have a lot of existing bindings defining channels loked to Location item.

I found 7 OH2 bindings defining such channels. Only 3 of them are defining a pattern (air quality, sensebox and netatmo). Others are defining no pattern.

I created PR #6123 to address the pattern.

I think we could define the same default pattern for the bindings that have not set a pattern in their Location channels, the same way we already have for String and Number channels.

Why not change the bindings to use the default system channel type for location instead?

I guess I have spotted why we see a "0" for the pattern "%s". Have a look at these lines of code:
https://github.com/eclipse/smarthome/blob/79d5ec5cebadafbdbe0fa2b76d7f3986116a96c9/bundles/core/org.eclipse.smarthome.core/src/main/java/org/eclipse/smarthome/core/library/types/PointType.java#L146-L158

We pass an array to the String.format() method which contains a sorted list of the constituents - first one is the altitude. The altitude in my example is zero.

If we want to have a framework-wide default pattern for the PointType we should implement it here - similar to the DateTimeType.

Just as a side not: The pattern parameter could be null. We have a missing Nullable annotation there.

In the code listed by @cweitkamp above we should fall back to the default pattern of the system channel in case the given pattern is null.
For %s as a pattern there are two valid options:

  1. Leave it as it is right now, only addressing the first element in the array. Users then have to know about the data format and provide the correct pattern by themselves.
  2. Replace %s with the default pattern because we think the user wanted to format the whole PointType. As a result users would have to use %1$s to address the altitude.

Nr 2 is my preference. Its the least surprising output to the user.

wdyt?

Sounds good. I prefer No. 2 as well.

Just as a side not: The pattern parameter could be null. We have a missing Nullable annotation there.

I have to revoke this: as mentioned in https://github.com/eclipse/smarthome/pull/5901#discussion_r213958724 there is no specific reason for the annotation in this case and we should either remove it or add it on interface level -
combined with NPE safe-guard.

I submitted a PR #6190.

Was this page helpful?
0 / 5 - 0 ratings