It is a cross-cutting concern since expire metadata handling is located in core without defined config descriptor. Thus this feature request affects core, ui and documentation for both user and developer.
You are correct about the title of this post and I referenced this in my original post. I included it in this thread as there are all sorts of requests being made about, hardware, documenting and bindings which can be added or changed before 4.0
Apologies @hafniumzinc @f00b4r I read you original message as a request for a notification based on a change in OpenHAB which would be a outgoing notification.
@binderth is correct that there are various options to do this at present but my request was to do it through the openhab remote cloud and receive through the OpenHAB app.
Something that I thought was quite useful that Home Assistant had in their equivalent of bindings documentation:
I don’t know what metrics Openhab collects behind the scenes but I would have thought it quite useful for both developers and end users to understand how mature a plug-in is and how widely used it is.
The OpenHAB bindings documentation seems to be getting better and better in the year or so I have been using it, given the sheer quantity of plug-ins that is quite impressive.
I’m not going to ask Santa for any more wishes. 
What type of config description would you expect? I also see that this is an issue as the missing config description requires UI hard-coding for a proper editor, but I also see that not may be very difficult to find a way to describe it.
For the state description it’s easy, also I think for Alexa or HomeKit, but how would you correctly describe expire in a re-usable way?
This will not happen. openHAB does not a will not introduce data collection. Better metadata (like connection type “Local Push”) is already on the way.
4 Likes
I would say that in many cases values written in metadata are made as glued text because its easiest to write such things, but not actually easiest to handle it. For example expire="4h,command=NORMAL" is glued value. For config descriptor I would expect three atomic values:
period(number)quantity(options second/minute/hour)command(text)
For Alexa or Homekit I do not have enough of knowledge to comment on these. It could be that these elements require some conditional elements which are not currently supported by core (doubt if its reasonable to go that path).
Looking ie. at some homekit posts, it looks again as issue related to how to specify textual part of metadata entry which is constrained by homekit itself.
I don’t think it should be strictly limited to just core. It should be limited to things that the openHAB project itself has power to achieve (i.e. changes to the OS, Java, or major upstream libraries is probably out of scope) but I think anything else can be fair game.
This is after all a brain storming thread. We don’t need to super strict about limiting its scope. But I do want to be sure we continue to point out where a wish can already be achieved, even if just in part, today.
If you get an event indicating when the door stated opening/closing then you can set a timer. If the open/closed sensor doesn’t report the door closed after a reasonable amount of time you know it’s partially open. I don’t think it’s as unachievable as you may think.
But that’s not an argument against your original idea, just showing that you should be able to achieve a lot more than you might think you can if you break the problem down.
Yes. I’m hoping the “complete” version gets addressed in 4.
As a very deliberate choice, OH collects no metrics about users systems. I think we could back into a number of downloads per add-on maybe, assuming the artifact sites collect even that much. But many of the people who use openHAB do so for the express reason that they don’t want some third party collecting all sorts of metrics about their home and home automation.
It’s that way for historic reasons and comes from the Expire 1.x binding. Were it to be rewritten using standard metadata it would look like:
`expire="4h"[command="NORMAL"]`
A deliberate decision to keep to the legacy style for this one case to avoid breaking changes (maybe it makes sense to revisit that decision in OH 4?). I believe in all other cases of well known metadata it follows the standard.
The current standard is just short of ISO8601 duration format (it’d need to become PT4H). This is a well known and well documented way to represent durations as a String. It’d probably be less work to just move to supporting that than to create a brand new definition of our own.
1 Like
While it is a standard outside, AFAIK it is not supported kind of config entry. If OH 4.0 brings such concept then we shall consider alignment across bindings as it such values are fairly common used for polling intervals.
I would love (more advanced) options for averages and trend lines in the charts. Now there’s only a basic option for 1 hour and 1 day averages.
1 Like
Right, but what @f00b4r wants clearly falls into the red category: he wants to be able to specify a feedback channel when emitting a notification (via sendNotification from a rule). That kind of feedback API currently simply does not exist, and IMHO solely implementing such kind of logic only in the client apps doesn’t make sense, since it splits configuration for single notifications to 2 or more places (the respective rule, Android app, iOS app, maybe more?), which creates a horrible UX. We’d need a way to specify the actions to be shown in the notification and a REST endpoint for the apps to submit the feedback, which then triggers a rule or something.
Speaking of wishes: my wish would be a vastly improved notification API in openhab-cloud, with ways to filter the fetched notifications (e.g. by date (span) or by severity, or even a full-text search) and to clear old notifications (again, e.g. by date) … for the latter, I’ve created a feature request almost 5 years ago 
and for the former, @mueller-ma also created one already.
2 Likes
no!
We’re mixing technical and business requirements… don’t do that! That’s usually the fastest way into dead-ends! We’re not talking “I need a notification, that opens a socket and awaits an answer” or something like that! Please avoid speaking in technical requirements unless the business usecase is clear and understood.
The use case is simple:
- get notification
- react to notification
ad 1: that’s already implemented. currently solely a openHAB Cloud Action and IMHO it should stay there. I don’t see a need to introduce a completely new entity like “smart notification”, which just adds another complex thing, which emulates a notification and reacting to it using REST API.
ad 2: that’s also already possible via API. You can easily trigger an item update or a rule or whatever you like with the API. And frankly speaking: that’s the way openHAB deals with user interaction. Via API. see above, a “notification-only” reaction would open a completely indepenent (and superflous) touchpoint, which adds nothing new to the ones, we already have.
What’s tbd is how to connect a notification with a possible reaction. You cannot send out notifications and connect those with any kind of action/rule triggering without context. So you either have to add a new parameter for the current sendNotification(emailAddress, message, icon, severity) or just add some trigger in existing parameters.
Using message would be something what iCalendar - Bindings | openHAB already does with “Command Tags”. So you could add some placeholders in the message for the item and/or rule, which then again triggeres the REST API. Simply by placing some kind of code within your message. That way, you could easily trigger a new value for an item or a rule or even more than one trigger in the process. You have to built a message text either way, so why not include the type of trigger you expect from an answer within the message?
sendNotification(my@email.tld, "That's a text asking for a feedback: leave door open or close it? FEEDBACK:ITEM:MyDoor:OPEN/CLOSED, lightbulb, minor)
This would then be sent to the App, which then shows the notification as it does already. But now the App knows, you like to have as an answer (leave Door open or close it?). Each notification now allows the user within the App to chose OPEN or CLOSED on the item “MyDoor”. The App could render the message in a UX-friendly way and give you two buttons to chose from. And send the answer back to the REST API.
For the sake of starting simple, I’d suggest starting with Switch or Contact items. Later on we can elaborate how to add more complex item types like number-sliders or others…
That’s how I would approach this, if we need feedback to a notification.
That would be nice - but again, that’s notifications already in the openHAB Cloud and persisted there. And the App uses that. Nothing OH-core would or can do.
2 Likes
Thanks for summing up the problem again … that’s exactly what the wish/feature request is about
As for your proposal, we need to keep in mind that we have only limited control over the notification content (as in: the OS notification ‘bubble’). I’d start with just a way to display one or two additional button(s) and a way to signal them being used back to a rule. This should work for both Android and iOS.
Of course. As @rlkoshak already mentioned, though, this thread is not only about -core. In my POV, it’s about general feature request brainstorming for the complete OH ecosystem (basically all projects in the openhab GH org).
2 Likes
Thing is: how do we channel the different requirements to the right “project teams”? There was not only me wanting to keep this thread on OH4-core. I’m totally fine with mixing different aspects and 3rd party tools together - but who’s gonna split it up again and delivers it to the respective dev teams?
The OH client apps definitely are not 3rd party tools.
Personally I read this thread also as Android app comaintainer I guess other maintainers will also read it with the idea of taking the good ideas for implementation in mind.
4 Likes
I think, we once again have to point out, that openHAB ist not structured in such a way.
We do not have respective dev teams, everything developed is community work.
What we do have is some “specialised” mainainter groups (core, add-ons, web-ui, etc), but it is not their job to develop what users or the community demands. They sometimes do, but this is out of personal interest.
I know, that’s all spare time activities and that’s great! I appreciate every single one of them!
I know not much about internal structures, but what I see is, that most devs don’t do all the parts and bits at once, but specialise in some kind of work. That’s what i mean with “team”. There’s some kind of communication going on (on github I guess), to coordinate work, which I don’t follow…
If that’s OK for all the contributors and maintainers - I’m A OK with throwing all into one pot. Just saying it’ll be a bit of work to pick the work packages out of one long thread!
No, there are no work packages. Every contributor works on what he/she likes to work on. Same applies to the maintainers. They review the code they are interested in. There is nobody with powers to tell anybody to do something.
I think it’s best to throw it all in one pot. You get more eyeballs on it and hope that one of the devs thinks its something they would like to work on.
I just added it to the wishlist as it seemed to be getting a lot of views. I am not even sure if it is possible to do in FCM or given that myOpenHAB cloud is free so it may only work if you host your own openHAB Cloud like IFTTT.
Also happy to be told it’s not possible or it’s not of interest because the devs choices on what to develop seems to be working good for us all as we are still here
That’s why I said way up in post 27 I recommended having some sort of strategy to organize the wishes.
But beyond that, unless individuals are filing issues on github to go with these wishes, or developers/maintainers are reading this thread for ideas and general awareness that’s as far as it goes. No one is going to package this all up and deliver them to the proper repo and shepherd them through development. No one is going to prioritize this or direct someone to work on a specific idea. Those ideas that a dev/maintainer sees they think they are willing to work on will get picked up, the rest no so much.
1 Like
-
I wish the java 17 requirement will not be enforced on the addons so they can be used in the 3.4 stable release at least until there is a stable 4.0 (unless the J17 functionality is required for that addon). Using zwave as an example, there are many beginning and intermediate users (usually on Rpi’s) that go from stable release to stable release. However, the Zwave DB of devices (and thus the binding) is updated weekly with new and modified devices. From a support perspective I would not like to advise that the only way to get your brand new shiny zwave device working is to a) wait 6 months for a stable release or b) upgrade your Pi O/S to bullseye, upgrade to J17 and then upgrade to an OH snapshot (unstable). Although I haven’t tried (just back from holiday), I believe the latest Zwave binding DB update is working in a 4.0 snapshot and will still work in 3.4 stable.
-
Rethink the massive .kar file approach, I’m thinking along the lines of the Apple/Google/Microsoft store During an OH upgrade my Rpi3 (on wifi) struggles with a 370 meg file of almost 350 bindings of which I use 4. Multiplying this extra burden by every OH upgrade and hundreds of users makes me question the German stereotype of efficiency and engineering
I’d add that with about the half of the items in this wishlist the kar file will be 500 megs by the end of the year.
The ultimate would be that only the bindings that changed would be upgraded (like how the apt update works), but I see the kar files are distributed to tmp and that is cleared every upgrade. Anyhow redownloading 4 jars is far better than 350. I also think this would help reduce the “Kar loading 15 sec message” and the activity related messages at startup when installing a new OH version.