I would love to see some Widget tutorials by @ JustinG . Either on the openHAB Youtube channel (which would be awesome because you could show something there step by step) or as pages in the openHAB documentation based on the ones that @rlkoshak did.
Justin, it is just amazing what you do with widgets and I would love to see some tutorials, so more people eventually are able to write custom widgets like you.
… which doesn’t mean that there aren’t also others here in the community who do amazing widgets stuff - so if anyone feels you could do that, please do.
Oh man, this, 1000x. More widget stuff. I’m not a creative guy, aside from being pretty dumb. All my dashboards look like a 5yo without imagination threw something at the wall. And the openHAB YouTube channel is still my go to place to review functionalities. Would be so cool to go through a bunch of the most used widgets. Maybe do a community poll to pick which widgets are more interesting??
There is a couple of options via paid third party services on iOS (not sure about Android) but for a number situations smart notifications built into OpenHAB make a lot of sense. E.G. my driveway gate, powered by a not inexpensive Doorbird solution, has a dumb energised relay. With a hidden contact sensor I can add in open/closed state to the equipment in the model. What I cannot currently do in OpenHAB is have it notify me if the gate is open with some smart options (close/check camera/snooze/ignore). This ‘semi-automation’ for some cases makes a lot more sense that fully automated rules, that would fail in real world situations.
There’s already some examples for those rules here in the forum and in the marketplace. Perhaps if you’ve already got some automated rules for that place them in the marketplace?
I won’t expect something different for “notification based on CONTACT/SWITCH items” if built in into OH4 - that’s certainly a task for rules, isn’t it?
Maybe I’m misunderstanding: could both of you provide examples which give openHAB the native ability to send ‘smart’ notifications, i.e. notifications which include a selection of actions which are then sent back to openHAB. I’m pretty sure this is what @f00b4r is after. (I’m aware of the Signal Binding, but nothing ‘native’, so am interested in these rules you mention…).
Third-Party Tools like
a) openHABIan
b) openHAB App (iOS, Android)
c) HabAPP
e) …
What I (and clinophobic) refered to was smart rules, which have little to do with the thread as it is about openHAB4 core functionality.
What I think, f00b4r and you are refering to is a combination of 5.b) and 4. A functionalilty within third-party tool (here openHAB App) to not only have messaging one-way, but bi-directional. That’s already possible with combination of 5.c) and 4. - as HabAPP allows you to interact with openHAB core via REST-API. So, HabAPP can do that already.
But: coming back to your question: “notification” with a back-channel or a bot-like behaviour is no task for OH4-core (it already offers all you need via API), but for the respective 3rd Party tool and must be implemented in the openHAB App.
Yes, Thomas, I agree, I would suggest to open a specific thread for that where @f00b4r can describe a specific usecase and we all can show what the right approach would be.
This was also requested by @clinophobic a few posts up, hence my confusion when you then both replied to @f00b4r that you can do this with rules and stuff from the marketplace - as you’ve mentioned, we could develop our own smart notifications
but this isn’t using rules, nor stuff from the marketplace.
We should split hairs about where these things should be implemented, but don’t forget the average user sees most of your numbered list as a single ‘openHAB’. My assumption is that this entire thread is for those users to suggest their wishes, and in the background we can work out what goes where (if ever).
Yes - and no.
As mentioned multiple times, this openHAB4 wishlist thread deals with core functionality. There’s different developers for the rest of my list as far as I know. So we shouldn’t mix requirements spread over multiple projects - and developers.
My pointing out was, that the raw given usecase from f00b4r is already possible with HabAPP. But of course implementing a bi-directional “messaging” of some kind would be nice to have in the openHAB App also. But that’s to be discussed in another thread dealing with the App.
I am really talking about bi-directional messaging (I have also seen it referred to as either actionable or smart notifications). I would argue that my use case of my driveway gate is not possible to deal with using smart rules as there are too many ways it can fall down e.g. the door is opening/closing and then someone hits the button again or it stops because someone steps in the way and the safety sensor kicks in. The door is then only partially open but there is no way to tell this.
Although I mention one specific use case clinophobic mentions another with the oven, it might be usual that the oven is left on accidentally but there again you could be deliberately using it. With bi-directional messaging it would open up a lot of options for users and allows a human to make a decision where it makes sense. I get that there is an argument whether this is done in the core or not but for me it is almost basic functionality that I would want from a smart home (e.g. I would expect automation, voice interaction, being able to react to my smart home). I know HA has added this but on the other hand Apple have not (yet - although I would be surprised to not see it coming in the next major iOS update).
Edit : re HABapp, I would want to be able to do this on my watch.
…and there we go!
It’s already possible in openHAB core - since OH1 - to achieve that. It is possible in BasicUI, as well as in OH3-GUI and of course with widgets in OH3!
But: and that’s my point (and what I wanted to point out along with others here), you’ll have to deal with that in every single touchpoint. And the Android/iOS App isn’t part of openHAB Core, there’s a whole different developers dealing with the App. So, if you will, that’s nothing openHAB4-specific, it can already be implemented in the App-Touchpoint.
Just a thought: You could use your Watch to
get notifications via openHAB App
use Alexa-App to tell Alexa what to do
=> and use the response for openHAB actions.
but again: If you would like to have that “smart messaging” in one touchpoint you’ll have to add that functionality to that specific touchpoint you’re using. In your use case it’s the App.
OK I understand what you are saying and why it would need work at the App-Touchpoint, although i would still respectfully argue that it then being “core functionality” of phone/watch apps would make for a much better experience. Also I would find it slightly jarring to get a visual notification but be expected to respond by voice, not dissimilar to having to navigate through nested menus to reply to something and not always that accurate/possible in a noisy environment (I know that was just a thought from you and it might be my personal bias).
It is a difficult one for developers / end users, the former having a full understanding of where things lie versus “I want it to just work” of the latter, especially since people are so used to being able to interact with things via their phone/watch. Relying on a third party for functionality that could be used across all bindings/rules etc and then it possibly disappearing is problematic for me.
I will try and step back from this now anyway unless you have any more questions, but I cannot wait to see what 4.0 bring.
In my chart, blue ones are 3rd Party “touchpoints”, which rely on the REST API, delivered by openHAB (reddish).
And there’s the “OH-WebUI”, which is part of the core as far as I understand it (and yes, the OH-WebUI also uses REST API, but for simplification I left it out). This UI is reachable via local network (or VPN).
From my understanding, what we’re (mostly) talking about in this thread is core-functionality (reddish colour). Sometimes there’s some wishes for the blue touchpoints. And again: most of the cases outside of core are already possible with OH3.x REST API - but have to be developed inside those touchpoints.
Isn’t that already possible? At the bottom you can add custom metadata (also I must admit that UI could be improved there. Anyway, I think this is not a core issue, as core already allows custom metadata.
(see my comment regarding that)
