Android App on Tablet as Home Lighting Control for Visitors

Apps & Services Android App
, ,
1

Hi:
Beginner here: OH4.1 on RPI and an android tablet client.

Am trying to set up my Android app on a spare tablet so that visitors/overnight guests can change lighting settings.

Fundamentally I want to make SOME of my Openhab home controls accessible, in my home, to a type of user who is not like the tech-savvy readers of this community site. These are users who will click things they shouldn’t. As such, it needs to be reasonably foolproof (perhaps not hackproof).

Has anyone perhaps developed a tutorial on the issues I am going to need to solve?

I have taken a look at this:

Problem 1)
Specifically, I find the Overview page which appears in (mainui as standard) to be a liability since it invites the (let’s assume unsophisticated) user to click on the “Sitemaps/exit” icon in the top right. This leads to an error page of “Openhab returned an empty Sitemap list” which is VERY user unfriendly - a user wouldn’t expect this from a high quality system , so as the admin, I want to get rid of it. Is there any way to remove this icon?

A workaround is to set a tab page in MainUI as a startup page. This does not have the sitemaps icon in the top right, but the problem is it does have a hamburger menu in the top left … clicking on this reveals a slideout menu with any other tabbed pages and also the Openhab logo… so far so good (from a user perspective since no ugly errors) but clicking on the logo unfortunately brings me back to the Overview page with the Sitemap link in the top right… Sitemap icon problem again.

Problem 2)
In the example above I am not using any authentication and just using the android app as is. It would be more elegant to define a specific user role - let’s say “guest” - logged in to the app on the tablet which is in any event, for guests’ use. In my case I have found that the app frequently asks for authentication - I would like to have a “remember me” option so that this does not happen for, say, 30 days. Also I would like to be able to prevent the guest from being able to change their own password (since I will have different guests - I don’t want to have to delete and recreate user roles each time someone changes the guest password and doesn’t tell me)… At present I don’t think this option is available.

Any guidance on elegant solutions I or even hacky workarounds would be appreciated.

Cheers!

2 Likes
2

I recommend to create a Sitemap for the guest. Set this sitemap as default and hide other Sitemaps from the side menu, as well as Main UI, NFC, etc. This can be set in the app settings.
You could also set the app as launcher, so the guest can’t exit openHAB easily.

3

Can’t the user go and change the settings?

4

Unfortunately sitemaps are not going to cut it. Functional but not visually appealing. : )

also seems I am not the only one trying to get rid of this link:

5

Whilst it’s not 100% tamper-proof, here’s what you can do:

  • Create a Layout Page
    In the Code, enter this:
config:
  layoutType: fixed
  fixedType: canvas
  gridEnable: false
  hideNavbar: true
  hideSidebarIcon: true
  scale: false
  screenHeight: 1080
  screenWidth: 1920
  sidebar: true

Adjust the screen resolution to suit.

I use a Raspberry Pi/Debian, and I have Chromium browser run full-screen on X startup directly to the page’s URL. This way you can configure specific tablet to load a specific page for that room.

I don’t know how to set this page to load by default on Android. If you could hide Android’s system navigation buttons (bottom of scrreen) so user can’t press “Back” or menu or something… it might work.

6

Works thanks.
This hides for all users, of course, including admin.
Was hoping to also implement something along the following lines to enable some differentiation among users:

"=(!user) ? true : false"

Have not been able to get it to work here, tho. Any help appreciated!

7

I suggest that if Openhab is to maintain its relevance, it does need a way to present simple, well-designed and problem-free pages to less-tech-savvy users - not just for members of this forum. “Well-designed” appears to be in hand - with fantastic progress on UI options. But “simple and problem-free” would appear to necessitate (among no doubt other things) a more systematic approach to providing a differentiated experience by user or user type. Perhaps for future releases…

Simply put - If my friends/guests can (from their perspective) break the Openhab interface (by landing on a page they don’t understand and can’t navigate back from) then they are not going to want to have it installed for them… and adoption rates will be slower than alternative home automation options; this would be a shame, given what has been achieved by Openhab’s mantainers so far.

8

Feel free to contribute.
Unfortunately, there are not enough users who want to spend their rare free time to develop/contribute what others put on the wish list.

9

Fair comment - and if I had the expertise I certainly would.

However my point is about prioritization of where to deploy scarce resources ; hopefully through this exchange we can make this issue part of the dialogue on what may be prioritized in future work. Perhaps other changes will help Openhab better maintain its competitive edge; but I suspect achieving broader adoption by the less tech savvy is key.

We may tend to assume this means making a product dummy-proof from “initial setup” through to to “use” - but this is especially hard/costly and may not be worth pursuing - since, honestly, Openhab setup for a non-tech-savvy person is very very hard and may be perhaps impossible to simplify. There is also the approach where “initial set-up” can be done by the more tech savvy - a long as “use” can be smooth for everyone. This means two types of users with different functionalities.

10

But thats another issue. As we all volunteer to contribute, you cannot tell somebody what has priority. Furthermore, there is no authority to set priorities.

Edit:
To go a bit further, when I started with openHAB, I had no development experience at all, did know nothing about Java. But I took the challenge as I needed a Binding for unsupported devices. In the meantime I contributed 4 Bindings. After that I started another challenge to create widgets. And last but not least I am now learning how to contribute directly into MainUI.
So yes, it takes time, but if one is willing to accept the challenge, it is worth the effort.

6 Likes
11

Agree - and wouldn’t want to be telling anyone anything. But at least we are now talking about it.
And fair point on learning - I am still working at that! Also zero tech background : )

1 Like
12
13

Uninstall BasicUI.

OH has two roles, user and admin. If he implicit user role is enabled, accessing OH without logging in assigns the user role. The user role can only access Pages, Sitemaps, and interact with Items. All the settings and other menus are not shown and access to the portions of the rest api to muck with those is locked down.

Furthermore, you can choose to show/hide widgets and even whole pages on a role basis or even in a user basis, but I don’t know if the later can be done when using the explicit user role (i.e. not logging in).

This is between you and the browser you are using. The browser is throwing away the cookies with the login credentials. OH doesn’t expire the credentials automatically. On my home machine I remain logged in pretty much until I clear the browser cache.

I actually don’t think there’s is a way to change the password at all except by ssh’ing to the machine and using the karaf console. But if you use the implicit user role your guests shouldn’t even need to log in at all.

Only if they are in the admin role.

The user role can’t access nor change those settings, even if they are knowledgeable enough to use the rest api directly.

14

Thanks Rich.

Let me clarify:
I am sure that we share the same goal to see the use of Openhab spread more broadly; this include non-tech savvy users.

To achieve this, we need to increase the number of folks who would be comfortable recommending OH to a less-tech-savvy friend or client - assuming install and setup were done for them upfront.

My focus is on ease of use at the UI level, assuming a less savvy user.

All my comments relate to the Android app (maybe same for iPhone - haven’t checked).
I believe that the app is the interface where most non-tech savvy users will interact with Openhab.

Such a user is unlikely to be typing an Openhab IP address into a browser.

My comments are therefore focussed on seeking to enhance the app experience.

Importantly, the app needs to be relatively foolproof (not hack proof), since users will tap where they shouldn’t etc.

Perhaps there are some easy fixes to the problems I am seeing?:

If we take an unauthenticated user, on the app, on reaching the Overview page they are presented with an Exit button. One would assume that clicking this button will exit the app…

image
image720×373 58.5 KB

However this does not appear to be the case - I get this:

WhatsApp Image 2025-01-02 at 16.20.05_0ab46a62
WhatsApp Image 2025-01-02 at 16.20.05_0ab46a62720×1520 25.1 KB

A non-savvy user would not know, and arguably should not need to know, what a “Sitemap” is.
It has been suggested that I could delete Sitemaps - but would that really remove this page such that an Exit Button really leads to an exit?

Instead, in the current form of the app and setup, the user is forced to click on the hamburger menu to get away from this screen and the following appears:

WhatsApp Image 2025-01-02 at 16.20.24_81d124a1
WhatsApp Image 2025-01-02 at 16.20.24_81d124a1720×1520 18.8 KB

A user also should not need to know what MainUI is. For a smooth user experience, this menu should not be appearing in its current form, and arguably should not need to appear at all.

One solution is to make the Overview page invisible to unauthenticated users (am aware of isVisibleTo); and have a preferred landing page (defined in the app) other than the Overview page. The problem is that when you do this, the Openhab logo in the sidebar menu is still clickable: it takes you to the (supposedly blocked) Overview page… and from here there is the problematic Exit button .

WhatsApp Image 2025-01-02 at 16.44.28_31d0d061
WhatsApp Image 2025-01-02 at 16.44.28_31d0d061720×1520 39.1 KB

I have tried hiding the sidebar, and hiding the navbar but these changes are hacky and frankly - make the experience less nice. The menu looks good and is useful for other pages. The Navbar looks good too as Maintainers designed it.

Part of the problem appears to be that we are trying to make a “Settings” button available (in the sidebar menu, after the exit button has been clicked), and to do this for all users whether authenticated or no. The pincode/biometric authenticator in the app provides some security that settings can’t be changed by just anyone.
So one solution is to accept that a Settings button is needed, simply and move it into the main pages sidebar of the app.

Another solution is to use some form of login. As pointed out, different user roles are already available to be defined.

However in the app this is more complex; the app appears to require you to log in repeatedly ( this is between me and the app, not me and the browser), so some kind of “remember me” function would be great. Bearing in mind that for an android tablet on a wall in a house, there will be multiple users perhaps sharing the same login (if we decide that logins are the way to go - not sure that they are), however the admin needs to be able to block the ability of a user to change the password. At present this is not possible - in the app the authenticated ‘guest’ user can change their ‘guest’ password to anything they like - and the other guests sharing the same login will no longer be able to access Openhab - this is a problem.

I hope this helps crystallize the problem that I am seeing. This is amazing software - I hope to see access to Openhab going beyond the tech savvy.

15

How do you suggest do reach app settings in that case? I don’t think the deep integration between app and web UI you’re suggesting is viable with the amount of man power we have. Don’t forget there’s also more features like NFC that could appear in that spot.
I’m not saying there’s nothing that can be improved (the exit button probably shouldn’t be shown if there are no sitemaps configured), but the general argument of any kind of complexity overwhelming any non tech savvy user seems a bit contrived to me.

@mueller-ma I guess we should have an interface for communicating to MainUI whether or not to show the button.

16

Open MainUI in the browser on the phone.
Tap the three dot menu
Tap “Add to Home Screen”

MainUI is a PWA so you can add it as an app to your phone independent of the Android app. Of course you lose out on all the features the Android app provides such as notifications, divice info sharing, etc unless you also install the app. But if BasicUI isn’t installed nothing should be shown as an option when tapping that exit icon.

17

Speaking only for myself, I couldn’t care less about adoption rates or spreading the use of openHAB (please note the capitalization). This matters for commercial products, not for free and open-source software.

That’s a pretty big assumption, and it’s the reason I wouldn’t personally recommend openHAB outside of hobby use. Actually, I don’t recommend openHAB to anyone–I just tell them that I use it, and if they’re interested in openHAB as a hobby then I’ll help them get started.

Open-source software comes with no technical support, so if I did recommend openHAB or set it up for friends/family, I’d feel the need to support them when something goes wrong. What starts out as a fun project eventually becomes an inconvenient responsibility, and I don’t want that for my hobby.

If openHAB’s existence depended on market share, then much of what you say would matter. But that’s not the case. As long as our developers enjoy working on openHAB, it makes no difference if we have 10 users or 10,000.

This is why we say that suggestions are always welcome, and it’s up to devs to decide what they’ll focus on. We need to remember that this is also their hobby. In the open-source volunteer world, happy and engaged devs are the most important factor in a project’s sustainability, not market share.

I get where you’re coming from on this, because I work at a university. Some university students make it their business to click on things that they shouldn’t (though most don’t).

However, I’m not sure the same thinking needs to be applied to your specific scenario.

  1. Your visitors are less likely to click on things they shouldn’t, because they are guests in your home.
  2. If your visitors accidentally click on something they shouldn’t, you are close by to help them.
  3. When you show your visitors the tablet, you can instruct them how to use it.

I’d think differently if you were building a system for short-term rentals who would never interact directly with you, but I don’t get the impression that’s what’s happening here. Based on everything you’ve written, I imagine you’d want to personally hand over the tablet and explain how it works, so that you can also talk about your openHAB system.

A sitemap is the clear and obvious solution, but…

This is perfectly valid, but keep in mind that it’s a subjective opinion. So, you can’t really say this:

A solution exists, and you just don’t like it. In contrast, many of us only use sitemaps due to their no-nonsense simplicity. Our opinions are different from yours due to differing preferences and priorities.

I hope you find a satisfying solution, but I encourage you to make it about your specific goals–not what openHAB needs for adoption rates and competition.

Think of it this way: commercial companies are generally criticized for caring more about profits and market share than serving current users and keeping employee happy. openHAB is the exact opposite. Personally, I’d like to see it remain as such. :wink:

4 Likes
18

The number and quality of contributors (developers) make a difference. So in that sense, attracting more developers, whatever that entails, would be beneficial to openhab’s future.

1 Like
19

Absolutely! But how to attract more devs. I have no idea. In the past, there was a bounty service which could be used for issues (also feature requests), but this has stopped and to be honest, it was rarely used for openHAB.
So if anyone has a good idea, apart from hiring devs, please speak up.

20

The only thing I can think of is to make openhab more “attractive” (which can mean different things to different people) to use, so suggestions about making it easier to build a “guest friendly”, both in terms foolproofness, and in terms of eye candy / “wow” factor are very on point, IMO.

IMO, openHAB is lagging behind HA in UI “wow” factor (or at least in how easy it is to create them) and in integrations, and perhaps a bit in ease of use.

Also the more “end users” (i.e. non developers) we have, and the more “demands” for something, could also be more incentive for developers to spend time on building it because they know that it will get used.

It’s all kinda related in a feedback loop somehow. More users → more devs → more features → more users, but which is the chicken and which is the egg?

IMO it starts with the product. A very enticing product even with rough edges would attract more developers to work on it more which in turn makes it even more enticing to attract even more developers. This is why I think HA has an astronomically higher user base, for better or worse.

Having too many developers (of different levels of competency) too will have its own and different sets of problems though. Quality and time to review will probably suffer in that case. so yeah… sorry for my ramblings