if I had a wish it would be around extending the functionality of the openhab mobile app specifically in regards to notifications and adding the possibility to send the device position to the server. Let me explain:
Notifications
Currently there are a lot of bindings that can be used (Pushover, Telegram, etc.) which provide rich experience when sending notifications to mobile clients. I would love to see some of the functionality be moved into the native openhab app. I’m specifically thinking of ways to
a) send responses back to openhab (e.g. Doorbell rang, should the door be opened? - Yes; - No)
b) Send images as part of notifications. (e.g. a camera image or similar)
Device Position
Also for this scenario there are 3rd party bindings (e.g. gpstracker) which can do this. If it would be possible to integrate the the possibility to update an openhab item with the current position of the mobile phone in regular intervals (or if the position significantly changes) it would eleviate the necessity to use 3rd party apps and services.
I think both of these features would greately extend the featureset of the mobile integration of openhab.
While that is true, you need separate apps for it. It would greatly improve the user experience to have these two additions to the app.
And I don’t think the iCloud binding is a true replacement as it exposes a lot more to openHAB, all your data, pictures etc and the password is stored in plain text accessible from the UI.
Nah, I would never use the iCloud binding while Apple is not able to support granular rights management and/or openHAB doesn’t have a more secure key vault (not blaming anyone, just the way it is)
All of this can be implemented with widgets so no real point in implementing this again in the app.
Support of messengers like Telegram in turn is right for people that do NOT want to have another messenger app called openhab as they already have 3 or 4.
I’d rather vote for a mature signal binding and eventually a WhatsApp one if possible (dunno if they provide a spec, I guess no).
There is an open issue to add this to the Android app but there are a number of significant technical issues to overcome.
One of the advantages of a platform like OH is that instead of providing half-assed implementations of features trying to solve all problems for all users poorly, it integrates with third party tools and services which specialize in these features, giving a complete and well rounded experience. Relying on third party apps and services is not a weakness when looked at from that perspective.
But this too is asked for above and I believe there is an issue open for this as well.
There are some open PRs working on this. I’m not sure the extent of what’s being worked and whether it will address your concerns but it’s at least a start.
Android App has tasker integration built in, so what are your concerns ?
Password is only accesible for admin, but it should be possible to store it encrypted. Without admin rights, you will not be able to get the account details and therefore have no access to the account. The binding itself doe not provide more information than given in the available channels.
In that case my wish is only regarding the iOS app, as that does not have notifications or geolocation.
Regarding the password security I‘m not talking about channels and the binding itself, I’m talking about storing a iCloud password that gives access to a lot of personal information, from pictures, billing to all kinds of data. on a not so secure openHAB in a plain text way.
This breaches like so many security best practices, saying it is only available to admin account is ignorant (sorry for the tone, nothing personally).
I am completely with you, that’s why I wrote about storing it encrypted.
Having a general solution for secure storage of credentials would be the best way to go.
I would encourage anyone who has opinions on the storage of keys to comment on the issue above. We were discussing a few weeks ago different ways/levels of security that could be implemented. The proposed suggestion is to let the user decide between a few options on how to unlock the keystore. In all cases the keys are stored encrypted. The question is how to unlock.
In the code submitted, the binding stores an AES key as a private variable that it’s required to pass to the library to gain access to the keys.
I have no technical knowledge about the topic but isn’t there a standard for us to follow instead of reinventing the wheel? Or is the question “which standard to follow?”
It’s more of options yes. We’re absolutely not going to write our own crypto libraries, thats a big no no. It’s a matter of how to best implement it based on the needs of the platform while taking into account the different use cases of deployment. For example, some OH instances exist in remote homes where the system needs to come up with no user interaction. The system basically needs to unlock itself. In other cases, a user may want the option to enter a secret into the web UI or CLI to unlock the warehouse. It’s a matter of providing options to the user community so they can best choose whats right.
This cuts both ways though. How many end users would have to install the Signal app to get this functionality?
I also think most end users would not perceive interacting with their smart home as interacting with a separate messaging app but actually interacting with OpenHAB itself, especially as there would be noise from other contacts in the app and granular control of notifications would be more difficult.
None. As I said if you want the functionality it can be implemented in widgets (& rules, eventually) already today.
Receiving notifications requires a client such as the openhab app, but for the rest such as dialogues, no clients are needed (well other than a web browser).
If you deliberately choose that for receiving notifications you want to use Telegram or Signal instead of openhab as the client it’s because it is already your messaging central on your client device.
But nobody would need to install it just to get the notifications and interaction functionality.
And that’s my point how any volunteer developer would look at this, too: why should he spend his time on building such a thingy when any user can already accomplish the same in current OH3 ?
His talent is better spent on other todos.
What is actually the main purpose of OH4? Is it more like update everything to the latest version? At the moment I do not really see much additional features or are the developed in the background.
I hope that there will be some improvements for energy visualisation
There’s always various different aspects to version management, new features just being one of them but a new major version does not necessarily mean there’s new major features.
Another aspect is about what’s happening under the hood such as to refactor and align architecture with other components.
This usually results in breaking changes so those we try to avoid doing inside a single major version.
OH4 will be Java 17 based and there’ll be mostly internal changes to JS and rules DSL handling.
Some structural stuff about channel, metadata and UoM handling, too.
There is no official roadmap. Work is done by individuals (volunteers) and not organizations.
The purpose of 4.0 is to introduce breaking changes which were reverted or on hold for 3.x line.
One more wish for the list: a “Startup complete” trigger when the startup is really complete from a user point of view.
With really complete I mean that all the rules (including JS scripting) have been loaded and are usable, that the cloud service has connected and that it’s therefore possible to send notifications, and of course that the persistence service had time to restore the necessary values on startup. In short, when the system has become fully functional and you can reasonably expect to find all the devices online that should be online…
Right now on my PI 4, the UI Startlevel 100 trigger and the DSL System started trigger both fire around 30-40 sec before MapDB restores the settings, about 1 min before the cloud service connects and around 3 minutes before my last JS scripting rule is loaded, so long before the system is actually ready for use.
I know it’s possible to work around this with a timer set so long that you’re sure that everything must be finished, but there should be a more elegant way to do this
And what should be done if it never reaches that? Let’s say one of your devices is broken and never comes online or there is something wrong with the Cloud Service. The most important part when pondering things like this are not the happy path, but what to do when things go wrong.
Also note, adding a new start level won’t prevent rules that are not triggered by a start level to not fire.
I would probably be worth while addressing the root of your troubles. It should not take that long for these things to occur on an RPi 4. That’s a problem for another thread though.
A nice idea would be a per thing/service timeout. The binding could make a suggestion for the timeout since the binding often knows if it’s e.g. a virtual thing, a wired device or a battery device.
In case the binding is wrong the user can always override the timeout.
After the timeout the thing e.g. switches to Timeout and from there the binding tries again to bring it online.
That way the longest timeout is the time after which openHAB is guaranteed to be online.
