Best Practice for a Tablet UI

Add-ons UIs
1

Longer journey than I expected to get here. Basic implementation of OH running HVAC (that rippled back to replacing all my thermostats). I’ve customized widgets to represent zones and have a reasonable browser presentation.

Two questions: I want to present basic climate control on a Samsung tablet (A7 or A8). Preferably with no modes and not responsive. Is the best practice to build a grid Basic UI, HABPanel, Android App or something else?

Also looking for an easy way to propagate communication errors from bindings up to the UI. I’d like to gray out the widgets and maybe post a message rather than having widgets do nothing. Any suggestions on how to track status on THINGS and feed it into variables the UI can see?

2

I don’t know what you mean by this. You just want to display without having any controls?

This is two questions in one: what UI to use, and what app to use.

For the most flexibility and support in the community, use a Main UI page. I don’t recommend Basic UI, because the text is small and difficult to read from a distance. It’s basic. HABPanel works well enough, but if you’re starting fresh I don’t see a good reason to choose it over Main UI.

For a wall-mounted tablet, the general recommendation is to use the HABPanelViewer app (which works with any webpage, not just HABPanel) or FullyKioskBrowser app.

I use HABPanelViewer, because you can set up an item in openHAB and send commands to the tablet to turn the display on and off. So, my HPV tablet is only on when I’m home and awake, and otherwise turns itself off to conserve energy. You just have to set the default URL to whatever openHAB UI you’re using, and then create rules to send commands to the app.

Note that HPV is no longer in development, but the 0.9.27 version is very stable.

I don’t know much about FullyKioskBrowser, but you can find discussion about it in the community.

The openHAB app works too, but I don’t think you can use it to control the tablet. I could be wrong about that.

Search for “thing status”. There’s lots of discussion in the community and docs.

Easiest solution is to have a rule that triggers on thing status and updates another item. Beyond that, I don’t know how to accomplish what you want to do. If I were concerned about the status of a thing, I would have openHAB send me a notification whenever it goes offline, or solve the problem of why it goes offline in the first place.

2 Likes
3

Not much I can add to what @rpwong said except to emphasize that the only want for anything to influence the UI elements in any of the UIs is if the value is captured in an Item.

There is a rule template on the marketplace to monitor Thing status changes and do something, like set a Switch to OFF.

4

Thanks. My bad in calling the default UI the Basic UI.

“Responsive” is a style of web development that renders properly on different screen sizes and resolutions. I want a tablet UI that always renders the same and doesn’t have any user commanded modes. That’s much easier to explain and support for non-technical users. I’ll look at Habpanelviewer, but I’m a little hesitant to deploy on an unsupported app that has OH version dependencies.

As far as why stuff goes offline - there are millions of lines of code between OH and my devices. To see the thermostats I had to add a Remote OH instance on an RPi then troubleshoot an intermittent compatibility problem between RPi4 and Gen5 ZWave. I also have a 3rd party BACNet binding talking to a small PLC. Lots of opportunities for glitches and I can’t easily test every possible combination of events.

I saw the thing status state machine in the docs, and was hoping to find a variable exposed to the UI that maps an item back to the status of the underlying thing. Then the UI has a clue it shouldn’t let users try to change a value until the thing returns online. Sounds like there may be a workaround with a rule.

5

Well, I can only tell what my experiences are. I have a wall mounted android tablet and use a (default) Main UI in grid layout where I’ve added a set of widgets. You can choose the size, i.e. 1x1, 1x2, 2x2 squared etc. This works well. I’ve notices issues with the responsive behaviour.

I usually design the page on my laptop. If you show this on your tablet on chrome in desktop mode it’s exactly what you’ve made. Only remember to set the screensize on your grid slightly smaller than the actual screen (else you get scrollbars, the margin/border eat 10-20 pixels) .

If you use the openHAB app (or chrome in standard mobile mode) you will have little ugly shifts of 4-8 pixels. This can be solved, but takes effort. You have to add code like below to make it right on both.

left: "=(device.desktop ? 24: 28)+'px!important'"

Why take the effort you probably ask? Well, the openHAB app is far more stable than using the chrome browser. It will keep running and running for a long time. Chrome will not. Best result is when disabling updates on the tablet. Google updates it often, and after this your page will crash. With disabled updates I usually get one of two weeks running (the app runs for months, but also when disabling updates).

So, this is my experience. Hopefully it helps you to decide.

6

Gotcha. I read your original post as “put a UI on a single tablet”, so I didn’t see that sentence in the context of web design.

Good point. I don’t know what the version dependency was with OH2, or if the same issue will pop up with OH3 → OH4. I suspect that won’t be the case, since OH4 is not as big a leap.

openHAB UIs are meant to interact with items, so it always comes back to that. You can use expressions in Main UI pages to make widgets visible/invisible, so you could swap in a generic OFFLINE text widget whenever necessary. That might take quite a lot of work, though.

You can also make items visible/invisible in Basic UI sitemaps. So maybe that does make more sense for your use case.

7

I use HabPanel for a three month now. IMHO the problem of it is that you have very less control over widget colours. E.g it will show you item On or Off status, but you can‘ grey it out for example. So you will need to design your own custom widgets, which is a bit of work.
Also HabpanelViewer in my case crushed every day or two due to html frame widget(I used it to show current weather).

8

Thanks for the suggestions.

Understand the intent of the UI is to show what the Item values are. What’s a bit difficult is when a controlled device drops offline, pressing a UI button results in the button not reacting to the user command.

For example a radio button for selecting OFF/HEAT/COOL: if the device dropped offline in OFF mode and a user commands HEAT then the HEAT button flashes briefly and then reverts to OFF since that was the last known state. Technically correct, but I’d like to give the user a reason why the UI is ignoring commands and at least let the user know the problem is known.

As tech support for the house I prefer to get a call “The system says it can’t see XYZ” vs a call “Nothing happens when I press a button”. Because the cure for that could be simpler, like “reload the web page”.

Down the road I may write an Admin python script that monitors all the device status and can proactively try to reset unresponsive components, but that is a lot of work.

9

That is a lot of work, given that you can probably achieve this without any coding at all using the rule templates and UI widgets that are already out there.

Here is how I handle this use case.

I use (note, I’m linking to the 4.0+ versions of these rule templates but there are 3.0+ versions published as well) the following:

Feature Purpose
Thing Status Reporting [4.0.0.0;4.9.9.9] Calls a rule when a Thing changes state. The rule that gets called sees the old and new state and sets a status Switch to OFF or ON as appropriate.
Network Binding Linked to Switch Items to represent the online status of network devices
MQTT LWT Linked to Switch Items to represent the online status of MQTT devices (this is somewhat legacy as I could configure the LWT on MQTT Thing itself and use the Thing Status Rule template above for that instead.
Threshold Alert and Open Reminder [4.0.0.0;4.9.9.9] Monitors Items that report periodically and calls a rule when an Item doesn’t receive an update or change in a certain amount of time. The rule that gets called sets a status Switch to ON or OFF as appropriate.

Each of the Equipment in the semantic model (where I implement this) has a Status Switch Item. I use Service Status Standalone Widget to show only those devices that are OFFLINE based on the Status Switch’s state.

In a few rare cases, I have a rule that gets triggered when a command is sent, and if the device that command is destined for’s Status Switch is OFF send a broadcast notification saying the command likely will not succeed because the device is offline.

I haven’t used the status switch to hide or change the appearance of the widgets but because the status is represented as an Item it’s pretty straight forward to do that.

Another approach you could use on that front is to set all the Items that are members of an Equipment to UNDEF when the Thing goes OFFLINE (using the same stuff as above just change the rules called by the rule templates above). Then you can change the widgets to show something different when the state is UNDEF. That might be easier than dealing with the status Item depending on how you create/configure your widgets.

1 Like
10

Rich,

Thanks! I’ll take a look at the status reporting rule.

11

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.