openHAB 4.0 wishlist

in Main UI, in the page editor, when you add a list item to a list and you click to Configure Item and it says Move up or Move down, how about Move to top?
Use case: you have a list with a bunch of list items, when you add another list item it gets added at the bottom and if you want it all the way at the top it is a lot of clicking

Can you please open a feature request/enhancement issue at the openhab-webui repo? Thanks.

1 Like

I wish for better error messages…

2023-03-05 09:46:55.995 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined

How can i find out where it wants to send it to, so that I can either create the item or delete the command that wants to update it?

There are others I came across, but can’t remember.

The message above could say: Attempting to send a state update of item <name> which doesn't exist:

undefined is already the item name. Probably there is an issue when serializing the event before. Can you have a look in the browser at the web information(network information of the requests? My guess would be a request to /events/states/... causes these issues.

Didn’t want to open a normal (support) query; just sayin’ that such messages could be improved on.
BTW: I do not understand how to provide the information you are asking for. Maybe I open a new post… OH3: update of an item which doesn't exist?

These type of messages mostly appear if you are opening a custom widget (in editor mode) and this widget tries to get a state of an item which hasn’t been defined yet.

Error messages are indeed something that can be improved in a number of places and they do continue to be improved over time. However, in this particular case I’m not sure the information exists to provide a better message.

It does. Unfortunately in this case the Item name is undefined. The error message really is

Attempting to send a state update of an item which doesn't exist: <name>

It’s just in this case, whatever is defining the name of the Item for what ever widget is asking for it is failing or was never defined in the first place. And because the Item name is being created on the web page side, all the openHAB server knows is that something requested the state of an Item that doesn’t exist.

You can experiment to see this for yourself. Open a custom widget that takes at least one Item as a property in the Developer Tools → Widgets. When you first open it you’ll see

2023-03-06 07:27:17.153 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined

For some real fun, define a new custom widget with:

uid: test
props:
  parameters: []
  parameterGroups: []
component: oh-label-item
config:
  icon: iconify:carbon:pressure
  iconColor: blue
  item: 

You’ll see it complain about the Item being null. Then you’ll see each letter you type for the item property until you get to the Item’s name.

2023-03-06 07:34:01.197 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: null
2023-03-06 07:34:01.198 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: v
2023-03-06 07:34:01.198 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vW
2023-03-06 07:34:01.198 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWe
2023-03-06 07:34:01.199 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWea
2023-03-06 07:34:01.199 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeat
2023-03-06 07:34:01.199 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeath
2023-03-06 07:34:01.200 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeathe
2023-03-06 07:34:01.200 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeather
2023-03-06 07:34:01.200 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeather_
2023-03-06 07:34:01.200 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeather_T
2023-03-06 07:34:01.201 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeather_Te
2023-03-06 07:34:01.201 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: vWeather_Tem
1 Like

Hi,
I think it’s too late for 4.0, but here’s my list (maybe for 4.1?):

  • OH UI: Access to items icons (category) and labels from MainUI. What’s the point of defining them with the item definition and then having to re-enter them again when using the item in MainUI (except in oh-repeaters)?

  • OH UI: More documentation and examples. I’m finding it very difficult to tweak or create elements of the UI. Mostly with CSS styling.

  • OH UI Widgets: Beginner friendly use cases. Lots of people must have the same use cases, make it easier for beginners to have a nicer UI. Something like the Main Widget by @hmerk.

  • OH Core: Extendable semantic model and badges. It is very very limited. I know that it adheres to a standard ontology, but it should be extendable at your own risk. And also the badges.

  • Bindings: Google Assistant SDK. Be able to send commands to GA, broadcast messages, and control devices that are supported by GA but not by OH. Just like this: Google Assistant SDK - Home Assistant

  • Bindings: Xbox Xbox - Home Assistant

  • Bindings: +1 for Matter/Thread. I think this should be a top priority for OH.

  • Bindings: Home Assistant integration. HA moves faster than OH and sometimes (like Xbox and GA SDK) there’s already a solution in HA but not still in OH. It would be nice to integrate OH and HA (synchronize items, for example) so you can run both alongside. Home Assistant has a REST API that could be used for this: REST API | Home Assistant Developer Docs

Regards.

1 Like

main_widget is not made by me, I am just supporting the project. When you talk about beginner friendly use cases for UI widget, wht do you have in mind. There are loads of widgets in the marketplace, that’s community work. openHAB itself has just standard widgets and this is unlikely to change.

There are different topics which describe the state and future.

If there is a usable REST API, why not use it with the HTTP Binding ? Our you could link both via MQTT. You see, there are existing solutions…

Thanks for your effort!
When I migrated from OH2.5 to OH3 not long ago I found it very hard to get a nice UI, I had to tweak/create many things. Then I discovered the Main Widget (it isn’t in the marketplace), which looks much nicer than most widgets there, but still had no idea how to get it to work. I’ve used OH form many years, but the change from OH2.5 to OH3 has been very hard. For an OH newcomer this must be impossible.
This is what I had in mind. A beginner will have the typical needs and will want a nice UI. Main Widget is trying to address this, I believe something similar should be part of openHAB.

Happy to hear that. I haven’t seen those topics, I’ll read them.

That’s exactly what I was planning to do, but if there was a binding it would save me (and I suppose many people) a lot of work.

2 Likes

It is in the Marketplace and there are docs in the according topics and in the dev topic.

Ok, than you have to find a volunteer who is going to write that binding, or do it yourself :wink:

It isn’t published, so to find it you have to know that the marketplace is based on this forum, copy and paste the code of all the required widgets and then configure them. I think it’s still too difficult for a beginner, but you are going in the right direction. Keep up the hard work!

Let’s hope a Java dev believes it’s a good idea (it’s what wishlists are for, isn’t it? :wink:). Unfortunately I don’t have enough Java knowledge or time.

1 Like

Yes, this is a wishlist, but i don’t see it as a list for binding demands. This has nothing to do with the openHAB 4 realease.

In the OP there is a section for bindings. Aren’t bindings a part of OH? With every version there are new ones.

Your request is sorta X-Y problem request type of: if you have a specific device you want to get supported in OH then tell us here.
If there isn’t any then there’s actually no problem and you don’t need what you’re currently asking for.
A generic interface to another home automation system isn’t a value in itself (particularly as that’s already available in HTTP and MQTT) so you’re unlikely to find any dev to be convinced of that idea, capable of and willing to implement it for you.

No, don’t get me wrong. It is a way of taking advantage of HA faster development and wider device support.
I believe that as it is of use for me it would be for more people, that’s why I posted here. But if nobody believes the same it’s ok, there’s always another way to do it.

Have you looked at the many examples posted to the Marketplace? That’s a great source for examples and you might find what you need is already done and you can just install and use it.

Beyond that, CSS is a huge topic. I don’t think we have the man power to duplicate documentation for all of CSS. But with specific suggestions what we have could be improved. Though for the most part, if you are modifying CSS or messing around with raw F7 components, you’re an advanced user almost by definition.

To make things easier for beginners we have the Locations, Equipment, and Properties tabs. What’s easier than not needing to do anything at all? Next in complexity is finding and installing widgets from the Marketplace. Beyond that we also have examples for building custom widgets and the layout for the Overview tab in the Getting Started Tutorial.

Many use cases are represented in the Marketplace with more being added all the time.

There are significant technical challenges here that make that hard to achieve.

You should file a feature request issue on the Google Assistant Integration repo: Issues · openhab/openhab-google-assistant · GitHub

There used to be an Xbox binding IIRC but no one volunteered to migrate it from OH 1 to OH 2.

OH has no priorities. Each individual contributor has their own set of priorities. Unless and until someone volunteers to write a binding for this :shrug. No one can tell anyone else what to work on. Unlike Home Assistant, we have no employees.

Even so, this has been a priority for a number of contributors with many thousands of words having been exchanged discussing approach, feasibility, etc both here on the forum and on GitHub and as I understand it on Discourd as well…

There are several threads with tutorials showing how to do exactly that on this forum. MQTT is generally the technology used to achieve that integration instead of REST API (note OH has a REST API too). OH provides an MQTT Event Bus rule template to make it easier, at least from the OH side of things. But again, if someone were to volunteer to create such an integration it would not be refused.

I find through the extensive support I provide on the forum (which is my primary contribution to the project) that it’s those OH 2.5 users who neglect to read the Getting Started Tutorial are the ones who have the most trouble over all. Next come those users (experienced or not) for whom text based documentation isn’t the best for their learning style (we do our best to help those users). Finally it’s a tie between those who simply don’t want to learn anything and just want a big red easy button and those who are OK with some learning but they want infinite control (usually over the workings and appearance of the UI) with supreme simplicity. Unfortunately, TANTAFL. The more control you want the more complicated and the more work it’s going to be. MainUI tries to find a happy medium. You can get to a pretty usable and good looking UI with minimal work. And there are lots of room for configuration and customization where needed. The Marketplace fills in a lot of gaps as well and gets better with every post. But ultimately, if you want something different or want to tweak everything, it’s going to require a lot of learning and work.

Note, the Marketplace is part of openHAB in every meaningful way.

It’s also still under development. I’m pretty certain that it will become published when it’s ready.

No, there is a flag in Settings → Community Marketplace to show unpublished entries. Toggle that and they will show up and you can install it just like the published ones. But given that it’s still under development and not tagged as published indicates beginners shouldn’t be using this widget yet anyway. So these small hurdles are like speed bumps, deliberate safety features. Eventually though that “published” tag will be added and it will show up in the list automatically.

1 Like

Indeed Rich, there is massive work going on under the hood, especially as we are seeing performance issues on bigger installations.
Our aim is to provide a stable and really usable solution by the time openHAB 4 will be released.

2 Likes
  1. Support for homekit devices connected directly to openhab.
  2. an easy “remap” for icons animations in sitemap. For example my heater drain 1200 watt so when watt is 0 should shown icon 0 and when is 1200 should be shown icon 100.
  3. A binding for BTicino Living Now. (also if the point 1 should be enough to use living now.)
2 Likes

Of course, and also here. But I rarely found just what I was looking for.

:smiley: Thanks, but detail oriented, I would say.
I completely understand the complexity of CSS and wasn’t asking for that. Most of the times it’s little things I’d like to tweak and I find it very difficult. For example, here I learned that oh-list is a special case:

I totally agree. The semantic model is great, but the next thing is to get a nicer UI and there it gets more complicated.

I didn’t know that. Let’s hope the Brick schema gets extended…

I’ll look into that, but I believe they are different.

I know. Maybe I didn’t choose the right word.

I’ve read a lot, before and after the migration. Much of it was yours :wink:

Yes, I know than option, but I didn’t know it then. And I understand why it’s there.

Thank you all for your help, and especially you, @rlkoshak!