Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setpoint/Control items used in sitemaps as default or in groups should generate slider/stepper widget #1697

Closed
mkrathome opened this issue Feb 10, 2023 · 22 comments · Fixed by openhab/openhab-core#3364
Labels
basic ui Basic UI enhancement New feature or request

Comments

@mkrathome
Copy link

mkrathome commented Feb 10, 2023

The problem

As mentioned here https://github.com//issues/1494#issuecomment-1412629299

There is no possibility for me to control a setpoint or control item in a sitemap which is designed in the Main-UI directly out of the semantic model
I tried a lot of things and thought it will be fixed e.g. the same problem was in the hab panel and overview (there I was able to make working widgets in the Metadata before the "fix")
But unfortunately the behavior in sitemaps is the same:

Screenshot_2023-02-10-09-49-43-635-edit_com android chrome
Screenshot_2023-02-10-09-50-13-408-edit_com android chrome
Screenshot_2023-02-10-09-50-49-770-edit_com android chrome

Expected behavior

I would prefer to have the possibility to control setpoints via e.g. stepper-widget in sitemaps.
In the end I'm able to create my own sitemap with designer/code out of a lot of single enteries but i thought, that especially for beginners it should be work to create a working sitemap out of the semantic model where the whole equipment was build.

Steps to reproduce

Your environment

Browser console

Browser network traffic

Additional information

@mkrathome mkrathome added bug Something isn't working main ui Main UI labels Feb 10, 2023
@rkoshak
Copy link

rkoshak commented Feb 10, 2023

for beginners it should be work to create a working sitemap out of the semantic model where the whole equipment was build.

We need to be careful with the terminology here. Sitemaps are separately definable and displayed by BasicUI. Sitemaps know nothing of the semantic model. Similarly, HABPanel is a wholly separate UI which also knows nothing about the semantic model.

Given these, what is it exactly that we are looking at? Just from how it appears I think we can exclude HABPanel. So is this BasicUI or is it a Location card in the overview page of MainUI?

If we are looking at an actual sitemap, well, as I said, sitemaps know nothing of the semantic model. When you use the Default element or the Group element to put Items on your sitemap, the element is going to be based on the Item type. A Text element is always chosen for a Number Item by default. If you don't want that, you have to create the sitemap yourself and tell it which element to use instead of using Group or Default.

This is how sitemaps have always worked so at best this is a feature request. It is not a bug.

However, if you are talking about the overview tabs on MainUI, my understanding is an Item tagged with Setpoint should show a slider by default.

@mkrathome
Copy link
Author

This is how sitemaps have always worked so at best this is a feature request. It is not a bug.

Yes, this is a sitemap but buildet only out of the Model...

Ok, then I'm wrong because I started 9Month ago and was very impressed by the magic ✨ magic ✨ of openHAB. I thought it makes a lot of sense, to be able to let "non engineers" model their Home in the semantic model and with only putting one main-group in a sitemap, will have a first full functional UI to start with.

In the meantime I learned a lot and yes I design my sitemaps with all of the item types and wraps and and and.

But i was trying to give a how to here:
https://community.livisi.de/forum/thread/4480-oh-lokales-smarthome-auf-himbeere-f%C3%BCr-anf%C3%A4nger-ein-reisebericht/?postID=38018#post38018
Because the most people of that community are not so experienced with let me say programming. But a lot of them will need a system like openHAB in the future for running their equipment e.g. with Alexa or push notifications because the cloud service of Livisi ends in 02/24.

Would it not be great, if the setpoints would displayed as a slider in BasicUI too if It is included in a group or defined as default?

So please take it as a wish or as "the best case":
a feature request.

I'm not experienced in handle labelling here could you please be so kind and change the label to feature request🖖🏻

All the best and many thanks for all of what you are all doing here👍🏻

Manuel

@rkoshak
Copy link

rkoshak commented Feb 10, 2023

I thought it makes a lot of sense, to be able to let "non engineers" model their Home in the semantic model and with only putting one main-group in a sitemap, will have a first full functional UI to start with.

That's the intent but OH is over a decade old now. The semantic model and anything that uses it was only recently introduced. There is a lot of legacy stuff that remains that either is carried along for backwards compatibility or because they haven't been upgraded yet (e.g. sitemaps).

If you set up the semantic model, the Overview tabs of MainUI will be populated from that (because MainUI was introduced about the same time that the semantic model was). That's really intended to be the "OH builds it for you UI" part of OH right now.

Would it not be great, if the setpoints would displayed as a slider in BasicUI too if It is included in a group or defined as default?

Sure, which is why I'm not recommending closing this (though you might want to search to make sure there isn't an issue open for that already), but be aware that the phone apps implement their rendering of sitemaps independently. The issue here would only address BasciUI. That's one of the things that makes enhancing sitemaps a challenge.

But I think the API stuff necessary to make this work is already there so at least it doesn't require changes to core.

I'm not experienced in handle labelling here could you please be so kind and change the label to feature request🖖🏻

This isn't my repo and I've no more rights than you do. We'll have to wait for a maintainer to help with that. But you can change the title to something that better reflects the issue.

@lolodomo lolodomo added enhancement New feature or request basic ui Basic UI and removed bug Something isn't working main ui Main UI labels Feb 10, 2023
@lolodomo
Copy link
Contributor

lolodomo commented Feb 10, 2023

The default sitemap element associated to an item is hardcoded in the core framework. And it is not linked to the semantic tags.
And it is applicable to any sitemap UI, not only BasicUI.

https://github.com/openhab/openhab-core/blob/main/bundles/org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/items/ItemUIRegistryImpl.java#L242

@lolodomo
Copy link
Contributor

lolodomo commented Feb 10, 2023

It could be probably enhanced but what would be all the rules to apply?
Just one for setpoint tag?

@lolodomo
Copy link
Contributor

lolodomo commented Feb 10, 2023

Building a new default sitemap based on the semantic model could be an idea.
The current default sitemap is listing all the things in its home page IIRC.

@rkoshak
Copy link

rkoshak commented Feb 10, 2023

I would expect there to be more rules than just for Setpoint and there is more in the State Description metadata that could be used too (e.g. min, max, read only, etc.). For example, a read-only Switch could use a Text element whereas a non-read-only Switch would use a Switch. A Switch with "options" can use those to crate mappings, or have it use a Selection element.

That's at least three rules just for Switch. Number is going to include a whole lot more.

@mkrathome mkrathome changed the title Setpoint items in sitemaps, designed in Main UI out of the sematic models are useless Setpoint/Control items used in sitemaps as default or in groups should generate slider/stepper widget Feb 10, 2023
@mkrathome
Copy link
Author

mkrathome commented Feb 10, 2023

The default sitemap element associated to an item is hardcoded in the core framework. And it is not linked to the semantic tags.
And it is applicable to any sitemap UI, not only BasicUI.

Ahhh that is the reason that this

I would expect there to be more rules than just for Setpoint and there is more in the State Description metadata that could be used too (e.g. min, max, read only, etc.). For example, a read-only Switch could use a Text element whereas a non-read-only Switch would use a Switch. A Switch with "options" can use those to crate mappings, or have it use a Selection element.

Hasen't had an effect🙈 you see I tried and decided for my own, in the end to use sitemap as it was designed for with all that text, wrap and frames....
Because I started with all that fancy stuff with OH 3.2 and was very happy, that all that "low-tech level" works (model/page-designer-mode/...) so I haven't had to learn an extra programming language. Yes I know, sitemap are the "old stuff" and overview/panel is the more "easy-way" but in real for me this is the perfect UI because I don't want to "have a god time" (waste tons of hours in watching cameras or robo-mover and such things) with my smarthome on my tablet/phone. Just check or control If needed and all the other time it can just work😉 for me the best smarthome is the one, you don't need take care about and you don't see it🙈

So in the end maybe there is another fancy way to get newbies fast involved but i think, only because it's "old" sitemaps should also included in the ✨magic ✨ of openHAB like MainUi stuff.

All the Best 🖖🏻

@lolodomo
Copy link
Contributor

lolodomo commented Feb 10, 2023

For example, a read-only Switch could use a Text element whereas a non-read-only Switch would use a Switch. A Switch with "options" can use those to crate mappings, or have it use a Selection element.

Such kind of rules are already implemented.
But if for example we change the default rendering of a read-only switch item to a text, you can be certain to have some of the users complaining about this change!

@mkrathome
Copy link
Author

Such kind of rules are already implemented.
But if for example we change the default rendering of a read-only switch item to a text, you can be certain to have some of the users complaining about this change!

Ok this might be right, but didn't make it sense, that a item which is declared as setpoint is able to be used as an input?

🖖🏻

@rkoshak
Copy link

rkoshak commented Feb 10, 2023

you can be certain to have some of the users complaining about this change!

We have users complaining about the lack of this. You can't make everyone happy.

The same advice would apply though. If Default doesn't give you what you want, define the sitemap how you want it. So that doesn't concern me too much.

I'm more concerned that the scale of the work involved to make this work for sitemaps is going to be huge.

but in real for me this is the perfect UI because I don't want to "have a god time" (waste tons of hours in watching cameras or robo-mover and such things) with my smarthome on my tablet/phone. Just check or control If needed and all the other time it can just work😉 for me the best smarthome is the one, you don't need take care about and you don't see it🙈

This belies a misuse of the semantic model. You should not have all your items in the model. Every item that you put into the model should have a reason for being there (e.g you want to expose it to your end users). If you don't want to see your robomower, don't put it into the model. Or if you have other reasons to have it part of the model (rare), set the visibility to false.

It's more work to build a sitemaps than it is to just leave stuff out of the semantic model.

@lolodomo
Copy link
Contributor

but didn't make it sense, that a item which is declared as setpoint is able to be used as an input?

Yes, makes sense to me.

@lolodomo
Copy link
Contributor

I'm more concerned that the scale of the work involved to make this work for sitemaps is going to be huge.

This would be retrieving the tags attached to an item to add a new criteria to decide what should be the default sitemap element. I am not sure this is so huge, or I am missing something.

@mkrathome
Copy link
Author

This belies a misuse of the semantic model. You should not have all your items in the model. Every item that you put into the model should have a reason for being there (e.g you want to expose it to your end users). If you don't want to see your robomower, don't put it into the model. Or if you have other reasons to have it part of the model (rare), set the visibility to false.

🙈 I have to learn to point out my intension better in Englisch🙈

Indeed I want to check from time to time status of e.g. the mower ... And I'm very excited about the semantic model, because it's a very good tool for create and organize all the needed items directly with or without linking to chanel's, aggregate Funktion...

So I'm happy, that I joined all that fancy stuff with OH3.2 and all the development was ready to use for a "low-tech-sartup"

What I wanted to say was: " I don't need to have a panel on the wall where I can see a lot of nice Widgets or Camara views or the ways the robomower has taken last 2h.... "
I really like, that visitors of us don't have to see all that stuff or somebody is wasting time in watching minutes or hours every day at "the own home". it's enough, when it works as it should. AND if it not work as expected I can quick check what went wrong. For that the Sitemap looks like the perfekt tool for me valso to overwatch from distance when traveling.

Sure, everybody has different preference and I'm not judging Users which happy with all the fancy MainUI stuff and want to have all such things and the total flexibility and I'm very impressed by all that ✨ magic ✨ of openHAB ..

🖖🏻

@mkrathome
Copy link
Author

This would be retrieving the tags attached to an item to add a new criteria to decide what should be the default sitemap element. I am not sure this is so huge, or I am missing something.

Maybe it is a good idea, to synchronize withe the latest updates of the widget-cards for overview and panel or let me say MainUI.
Before the last update there where similar behavior (but fixable with adding defaults widgets in metadata). Now a "standard widget-card" is automatically choose.
Before the update,
I tried out all of the default widgets (stand alone, list, cell) and recognized, that it has only affect at MainUI

Maybe it is also worth to think about taking this out of hard coded and give also the opportunity to have a "Default Sitemap Widget"?

All the Best Manuel 🖖🏻

@lolodomo
Copy link
Contributor

Maybe it is a good idea, to synchronize withe the latest updates of the widget-cards for overview and panel or let me say MainUI.

Creating in sitemap UIs a dependency on MainUI is IMHO a very bad idea.

Maybe it is also worth to think about taking this out of hard coded and give also the opportunity to have a "Default Sitemap Widget"?

Yes, at least for what is not obvious.
For your wish with setpoint, I do not think there is the need of a setting for example.

I will study this enhancement (default setpoint "widget" for Number item with a setpoint tag), I hope I am not missing something because I have the feeling it should be relatively easy to implement.

@mkrathome
Copy link
Author

Thanks for your work and time you spending at that point👍🏻

All the Best 🖖🏻

@rkoshak
Copy link

rkoshak commented Feb 11, 2023

This would be retrieving the tags attached to an item to add a new criteria to decide what should be the default sitemap element. I am not sure this is so huge, or I am missing something.

I'm assuming that BasicUI, the Android app, and the iOS app will all need modifications to support this. But if it's all handled in core, so much the better (though this issue would need to be moved to the core repo, right?).

What I wanted to say was: " I don't need to have a panel on the wall where I can see a lot of nice Widgets or Camara views or the ways the robomower has taken last 2h.... "
I really like, that visitors of us don't have to see all that stuff or somebody is wasting time in watching minutes or hours every day at "the own home". it's enough, when it works as it should. AND if it not work as expected I can quick check what went wrong. For that the Sitemap looks like the perfekt tool for me valso to overwatch from distance when traveling.

Maybe I'm still not understanding. And I'm not trying to argue that one should not use Sitemaps. But on the one hand you are saying that you don't want a panel on the wall for control but at the same time you want to provide a UI for control? Whether the widgets are fancy or not is irrelevant.

I too have a very simple UI that the home's end users use (in those rare cases where they have to use it at all, I aim for automation, not manual control). So the page they see when they pull up MainUI is this:

image

They can open the garage (and see what the garage doors are doing, control the lights, temporarily turn off the network wide ad blocking and see the status of batteries that may need changing or devices that may be offline (to explain why something didn't work). That's it. That's all they see. When logged in as a "user", I even hide the Locations, Equipment, and Properties tabs.

Note, all of these widgets are either built in or installable from the marketplace and we show how to build the Garage widget in the Getting Started Tutorial. You don't have to show everything to the end users and you don't have to spend much if any complicated work most of the time to create a simple UI for the end users .

I'm not saying that sitemaps don't have a place nor am I saying no one should prefer them over MainUI. But I do push back against the notion that what you describe (as best as I can understand it) cannot be achieved through MainUI with minimal work too.

@mkrathome
Copy link
Author

@rkoshak

Sorry but i think I'm not able to describe my point of view in English clearly.

Yes everything is very simple to implement via MainUI.
This is not the point. I just personally prefer sitemap.
And if I want to describe beginners (with less English experience's than me🙈) how to setup all that I can only talk about sitemaps.
And yes there are some people, which want to use openHAB but get in struggle with language and/or with the way of documentation.

But please forgive me, if the things I write here sounds not politely for you because that is not my intention.

You all have my deepest respect and I don't want to make trouble 🙈

All the Best 🖖🏻

@lolodomo
Copy link
Contributor

@mkrathome : it is implemented. Look at the PR for screenshots.

@mkrathome
Copy link
Author

@mkrathome : it is implemented. Look at the PR for screenshots.

Thank you, that looks great👍🏻

All the Best Manuel 🖖🏻

J-N-K pushed a commit to openhab/openhab-core that referenced this issue Feb 12, 2023
…3364)

* Use setpoint as default sitemap element for item with tag "Setpoint"

Fix openhab/openhab-webui#1697

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
@mkrathome
Copy link
Author

Thx a lot🖖🏻

splatch pushed a commit to ConnectorIO/copybara-hab-core that referenced this issue Jul 12, 2023
…penhab#3364)

* Use setpoint as default sitemap element for item with tag "Setpoint"

Fix openhab/openhab-webui#1697

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
GitOrigin-RevId: fd6e161
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
basic ui Basic UI enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants