This is a little bit of a mix of both command and automation.
Fully automated would be if it knew when you wanted to watch Apple TV without you needing to do anything at all. That’s not always feasible but where it is it’s so much better. In my home, the only time that most of the family notices that something even is automated most of the time is when it fails to work. Then all of a sudden it’s “why aren’t the lights on?”
Unless there’s something going on like you’ve installed a bitcoin miner on your RPi 4 or loaded it up with so many services you’ve run out of RAM, any problems with responsiveness lies outside of OH 3 and the RPi 4. Some technologies can become overwhelmed if they receive too many commands too quickly, for example, Some cloud API calls could add significant latency.
But on a local network OH 3 and MQTT should be plenty fast enough, especially with QOS 0.
You might consider what is it you are hitting pause with in the first place. If you need to bring out your phone, open an app and start tapping on the screen to do common every day stuff like watching TV or turning on the lights, you will be getting the eye rolls. “How is this easier than just using the remote?”
Just because you can integrate it into OH doesn’t mean you must. Perhaps it makes more sense to kick off a TV watching session through OH (perhaps using a physical button or the like) but actually manually controlling the volume and pause and the like is managed through the Apple TV remote.
If OH touches it does not mean that OH is the only way to use that device. In fact, it’s better (IMO) when there are other ways to control a device. The system is more robust that way (escalators verses elevators).
I think most in OH 3 are using MainUI. BasicUI is, as the name implies, basic. There’s not a lot of capability or customization available there. HABPanel is much more flexible but also requires a ton more work to build a panal. HABPanels are also not dynamic. If you have a tablet and a phone, you’ll have to build separate panels for each. They don’t handle scaling based on screen size very well. MainUI provides a medium point where you can get the basics with very little work but you have a high degree of customization available.
I’ve a similar simple widget for my single thermostat (I’ve not put it on the marketplace but can if someone wants it). It combines three Items actually letting me set the mode of the HVAC between heat, cooling, and off, set the target temp and is shows the current temp.
This could be expanded to apply an Action to one of these subwidgets to open a panel to show additional widgets.
But, you also might get everything you need through the semantic model. There are three tabs in MainUI that automatically get populated based on the semantic model: Locations which shows all your devices and Items based on where they are physically located, Equipment which groups all your Equipment of the same type together, and Properties which group all your Items based on what property they represent (e.g. Temperature).
Maybe you don’t need to do much of anything to get a UI that works close to what you want.
“Behavior” is going to be handled by rules (see the Getting Started Pages on Rules).
“Configuration” is going to be stored in Items (see the Getting Started Page on the Semantic Model).
“Zones” will usually be represented through the Semantic Model (see the Getting Started Page on the Semantic Model).
Don’t do that. Write one rule that handles all your thermostats. There are lots of techniques but in general it involves:
- Putting the triggering Items into a Group
- Naming your Items so when you have the name of one Item, you can build the names off all the other associated Items (see Design Pattern: Associated Items)
- Once you have the names of the Items, the rule can run through its logic for that thermostat.
Another option is to use one of the rules languages that support libraries and put the logic into a personal library function called by multiple rules.
Rules can call each other and pass “arguments” so you can achieve some reuse like that.
Finally, you can create a rule template and instantiate multiple rules based on that one template. But there really isn’t a way to install a template unless it’s published to the Marketplace.
It’s all YAML. It’s built on the F7 framework and there is some ability to do some CSS. But for the most part you are configuring and combining custom OH and/or F7 building blocks.
There is a webview widget but there really isn’t much that you can’t get with the build in blocks. But you don’t need to write a custom HTML page to do this in MainUI.
See Pages - Custom Widgets | openHAB.
In fact, please review/rereview all of the Getting Started Tutorial as most of the answers to these questions should become answered there.