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.
I’m not following how this addresses my concern (if you could call it that).
Let’s say we have the Timeout you describe implemented. We still can’t guarantee and Thing ever comes ONLINE. And if the Thing never comes ONLINE, can we claim that OH is fully online?
If not, then there are cases where OH could never reach this new run level state. What does that mean? Is it any better if those runlevel triggered rules never fire as opposed to firing too soon?
If so we count OH as ONLINE even if some of the Things or other OH subsystems TIMEOUT, then I’m not sure we’ve added much. All we’ve done is add a state that means “as best as we can tell OH should be online, but something could be broken so .” We really haven’t bought anything because even after the timeouts we cannot guarantee anything. All the same things that are a problem now remain a problem. The same checks need to be done.
And this only addresses Things. It doesn’t address Items, restoreOnStartup, the rule engine, UI, etc., all of which were mentioned by @Elgin as a concern too.
I want to be clear, I’m not arguing against any of this. I just want to think seriously about what it means and what should happen when things go wrong. When OH can’t ever become ONLINE because something (e.g. a Thing) is broken.
To clarify things a bit from my side, my use case here is as follows.
After startup I run a rule once that:
checks if certain settings have been restored to their items by the persistence and if not (e. g. in case of a clean installation or a failure) restores them to their default values
checks if a number of things have come online as expected and if not notifies me about it and if needed even triggers a reboot
sets some slow sensor readings that I don’t want to have restored to (possibly too old) values to values that don’t produce wrong reactions in other rules, e. g. luminance values to 0
start a time-triggered Javascript rule that deals with a pesky device that doesn’t run smoothly on the http binding.
So in my case the “startup complete”-point is when all the rule engines are up, the bindings are loaded and started and persistence has finished its restore on startup. The cloud is a bonus if it works, so it should at least be at the point where OH has attempted to connect and either succeeded or failed (as this appears in the logs right now, this should be possible to monitor).
A particular thing being online is not my requirement here, just a reasonable chance for it to be so (binding loaded etc.), from where I can determine myself what to do if it’s not as expected.
I’m not asking for a trigger that may possibly never be reached (unless something went horribly wrong in the first place and OH never started at all, which is an entirely different issue).
.” We really haven’t bought anything because even after the timeouts we cannot guarantee anything. All the same things that are a problem now remain a problem. The same checks need to be done.