Hm, 
I don’t like that. So far I had the same look and feel on all devices/plattforms (Android, iOS, Web).
Playing around today, I saw that in the iOS-App you can use BasicUI in the app. Would it vbe possible to add that to the Android app? Or is that already possible and I’m just too blind?
Edit: Oh,… the way the iOS app handles it is‘n helping as the use of BasicUI is not permanent.
I mainly like the new look, and it’s awesome to see the dev activity. I think that values should be moved back over to the right side though
It’s always possible to pin any web page as an app on either iOS or Android. Open the URL in the browser and in the menu somewhere there will be an option to “Add to the homescreen” or something like that and you’ll get the browser based BasicUI as an “app”. But you need the Android app to get notifications and some of the other more advanced features.
Right, and with the value to the right, it would be (and previously was) even more truncated.
In the case of the setpoint I was thinking already whether the middle button is needed at all (touching the row outside of the buttons does the same thing), but there are other cases (rollershutter, color chooser) where 3 buttons are definitely needed.
I like the setpoint. Up and down. And a slider for faster movement.
Yes, true. But then the password prompt pops up everytime. That’s never gonna get past the wife…
(it does too in the iOS app)
…but that’s probably a different topic.
It was only through this discussion and the fact that nothing has changed for me that I found out that the Openhab Beta App I used is no longer available in the Play Store. 
On the subject of accent color, I would like to note that it is not adjustable on the mobile phone, but on the tablet there is a button to set it. Although the red would not be my favorite color 
There’s two problems with adding an option for that:
But maybe we could get away without the option by applying some heuristics? Let me illustrate by a pet peeve of mine, the widget for Player items, which are rendered as buttons:
It’s ugly not (just) because of the needed amount of space, but also due to the ASCII button texts and the useless 4th button (play and pause can’t be active at the same time anyway).
Therefore I’m working on a patch that collapses them into a layout similar to roller shutters:
For implementing it, I look at the properties of the switch widget, so basically employ heuristics to recognize this case. I wonder whether the same thing would work for your use case as well, checking e.g. for button count <= some limit && labels of all mappings have only 1 character and if that’s the case, display in one line. The interesting part then becomes how to display the unicode glyphs as images…
Haven’t got the update yet, but does this mean that the design in the webbrowser won’t be the same anymore as in the app?
Correct.
Google removed the beta version, because it’s too similar to the stable version: Beta version has been removed by Google from Play Store · Issue #3012 · openhab/openhab-android · GitHub
Wouldn’t tags be a way to achieve that? Then you wouldn’t need a heuristics as there would be a definite way to determine this. Tags should be available inside the app, shouldn’t they? Also there would be no need for server side changes and other visualisations (iOS app, BasicUI web) would just ignore it.
It could also be sitemap-specific - in your case maybe something like “sitemap-player” and in my case like “sitemap-compact”.
You can’t assign tags to sitemaps, can you?
No, but to the items. That means, my rollershutter items get the tag “sitemap-compact” and the Android app then knows that they should be rendered in a single row.
I just tested it in the REST-API-Explorer with GET /items/{itemname}:
{
...
"tags": [
"custom-tag2",
"custom-tag1"
],
...
}
So I would expect the tags to be available in the app.
This way it would be possible to have both variants in one sitemap, for each item as it best fits.
I saw if I move the slider every value is sent…
Could it be changed that the value is sent if you set a value, not every step. Like the old slider.
@mueller-ma
What’s the problem with the new behavior?
There are so many commands in this short time…
Is this not to much for some devices like radiator valve?
I think he is talking about the count of changed values when sent to the device:
Number item, rendered as setpoint on the sitemap:
Setpoint item=Tuya1Bad_Setpoint minValue=5 maxValue=30 step=1
old behaviour:
there was a “set” button on the setpoint widget which you needed to press to send the changed value
events.log for old behaviour
2023-01-28 19:57:57.726 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Tuya1Bad_Setpoint' received command 12.0
2023-01-28 19:57:57.728 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Tuya1Bad_Setpoint' predicted to become 12.0
2023-01-28 19:57:57.731 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 8 to 12.0
new behaviour:
there is no “set” button anymore and if you change the temperature, every single changed value gets send to the device:
events.log for new behaviour:
2023-01-28 19:58:40.966 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Tuya1Bad_Setpoint' received command 13.0
2023-01-28 19:58:40.967 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Tuya1Bad_Setpoint' predicted to become 13.0
2023-01-28 19:58:40.969 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 12 to 13.0
2023-01-28 19:58:41.238 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Tuya1Bad_Setpoint' received command 14.0
2023-01-28 19:58:41.238 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Tuya1Bad_Setpoint' predicted to become 14.0
2023-01-28 19:58:41.241 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 13.0 to 14.0
2023-01-28 19:58:41.760 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 14.0 to 13
2023-01-28 19:58:42.441 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 13 to 14
2023-01-28 19:58:42.592 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Tuya1Bad_Setpoint' received command 15.0
2023-01-28 19:58:42.593 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Tuya1Bad_Setpoint' predicted to become 15.0
2023-01-28 19:58:42.594 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 14 to 15.0
2023-01-28 19:58:42.647 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 15.0 to 14
2023-01-28 19:58:42.673 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Tuya1Bad_Setpoint' received command 16.0
2023-01-28 19:58:42.674 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Tuya1Bad_Setpoint' predicted to become 16.0
2023-01-28 19:58:42.675 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 14 to 16.0
2023-01-28 19:58:43.041 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Tuya1Bad_Setpoint' received command 17.0
2023-01-28 19:58:43.042 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Tuya1Bad_Setpoint' predicted to become 17.0
2023-01-28 19:58:43.043 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Tuya1Bad_Setpoint' changed from 16.0 to 17.0
In both cases shown, the difference between old and new value is 4 degrees.
Aah, now I understand, thanks. I thought he’s talking about the ‘Slider’ widget, not the ‘Setpoint’ one. Yes, the slider bottom sheet should limit the number of sent values the same way as the Slider widget (only send if no change for at least 200ms). I’ll look into it.
Thx yes this is what I meant.
Maybe send command if ‘finger release slider’? 