OH Core: Sitemaps2

[davidgraeff]

Just a few quick question to know how android OH maintainers think about it.

1. Are you able to support a second openHAB core (Rest) API next to sitemaps or do you want to release a last app version for sitemaps and replace sitemaps with the new oh core concept in a refactored app?
2. What features of sitemaps are you using?
3. Do you prefer Websockets or server send events?
4. Any particular wishes for sitemaps2 or any disliked feature of sitemap that should peacefully die?

Cheers, David

[maniac103]

IMHO:

1. I think we should try hard to keep one app for all server versions, and I think this should be doable in any case, even if by completely replacing the list fragment + adapter.
2. What kinds of features do you think of? At the moment, I'd say 'whatever is needed to render the widgets' ;-)
3. Is this question about what we're using currently? If so: SSE.
4. More detailed documentation (both API and events) and more thought out event design ;-) Otherwise it seems fine to me.

In general it's a bit hard to properly answer to those questions though without knowing what the suggested alternative actually is...

[davidgraeff]

3. we're using currently?

It's more about what is preferred for Android development. SSE was chosen back then because Websockets were not widespread. But we have a choice now.

2. What kinds of features do you think of?

Sitemaps do a lot. "Interactively" hiding items. Computing states for child items. State dependent colors. State dependent icons. Push button switches (via "mappings"). The selection widget.

The thing is: openHAB supports all of the above also without Sitemaps (but you would use different REST API endpoints like /events, /things, /items).
The question is, do you use and support all of the sitemap features by purely relying on the sitemap API?

A future API might be more like this:

1. Request /about - openHAB version, and some general info
2. Request /sitelayouts - all sitelayouts
3. Request /sitelayout/{layout} - provides you with:

• the full layout, all pages
• Embedded item value and item name (i.e. item id).
• Each item also refers to its linked OH2 binding thing channel.

4. Request /channel-types - Provides you with detailed information about a channel (type, possible options if it is a String with options, possible commands if it is a state-less channel, min, max and so on)
5. No registration for events anymore if websockets are used. You establish a websocket connection and send a http header to limit the events to what can be found on your sitelayout.

That's one model. The point is, the API could be absolutely different to what is in place today.

[kaikreuzer]

I very much suggest to keep discussions about the evolution of sitemaps to the one existing issue at eclipse-archived/smarthome#5337. It makes no sense at all to start a dedicated discussion for every UI that might then make use of it.

[davidgraeff]

@kaikreuzer The design you mention is too complicated and it doesn't look like it will get finished ever or is maintainable by anyone else then the contributor. Why was there nobody actually talking to the consumers of such an API? I'm trying to gather use-cases first and then design an API. And that will probably be more like Yannicks Cards implementation. For obvious reasons I cannot hijack that thread, as I don't like the design at all.

[maniac103]

I'm trying to gather use-cases first and then design an API

This actually sounds like a great approach 👍

The question is, do you use and support all of the sitemap features by purely relying on the sitemap API?

Currently, that's the case, yes.

It's more about what is preferred for Android development. SSE was chosen back then because Websockets were not widespread. But we have a choice now.

For us it doesn't really matter. Websockets probably are a bit nicer since they're supported by OkHttp directly (one needs an additional library for SSE), but both do work for us.

That's one model. The point is, the API could be absolutely different to what is in place today.

That probably doesn't matter too much for us either. From the app point of view, I only have two wishes OTOH:

• No guesswork in meanings of API fields (bad example here is the UoM support, which introduced a widget state next to item state and it's a bit unclear when which fields are set and what format the item state commands do have to follow)
• Renderable by non-HTML renderers. I've skimmed over the PR linked by Kai and it looks like it wants to send layout components using CSS (or rather, allowing it to be declared using CSS) ... this is something that would be a nightmare to implement, as it, short of writing a CSS parser, would mean doing everything in a WebView.
• (Side point of the above): Please (try to) keep complexity in the server, just as current sitemap API does. Thinking about e.g. resolution of visibility or colors here. Re-implementing this in every client seems like overkill for not much gain. The linked PR seems to already do that/also suggest that.