I had a few other things going on over the last couple months so I’m a little late to the OH3 party, but I’ve finally had a chance to sit down and kick the tires and thought I’d share some of the things I’ve seen and the thoughts I’ve had.
My OH2 was a native install on my linux server and grew up quite haphazardly over the years. There’s a lot to like about the native install once it’s up and running, but, I took the upgrade to OH3 as a good chance to modernize. I switched the OH install over to docker. Spinning up the OH container and getting it running was, of course, trivial and my few very minor issues are not OH related but issues with mDNS on docker (I’ll figure it out eventually, I’m sure).
I then undertook the largish task of eliminating years of cruft by rebuilding my config from the ground up. Because I started from scratch, in some ways my experience parallels a beginners experience and some of the following comments come from that perspective.
Main UI
Bravo devs! 
There are of course any number of minor decisions that I personally wouldn’t have made (but that’s understandable and possibly even for the better overall; in the immortal words of Neal Stephenson, “I am a market segment of one”). Previously, my configuration was 98% in text files, but to put the UI through it’s paces I wanted to try, at least initially, to do the majority of the item building with the interface. After a few starts and stops (see Semantic Model below), I was very impressed and decided to follow all the way through, completing all item (and a large chunk of the rule/script) config with the UI. The giant leap in administration and usability is, I suspect, the reason that my rebuild took me a few days and not a few weeks or more.
One question I would have for any dev on the UI is about custom metadata on items. If you add data to one of the built-in metadata namespaces (an awesome feature!), then that namespace is actually listed
in the metadata box on the item page. If, however, you create a custom namespace for an item, that namespace is not listed and you have to go through typing the namespace into the Add Custom Metadata dialog every time. Was there a specific reason behind this choice? I certainly can’t say for sure, but I would think if the metadata box can be populated by the built-in type then it shouldn’t be difficult to have it also populated by the custom type as well. This would be enormously helpful for people who use custom metadata both to control rule function and as a result of rules. Then, at a glance. it would be possible to see if metadata had been properly created by a rule or if that item is one you’ve already set the metadata up for without opening up the json file and searching or painstakingly entering each namespace into the dialog one at a time. If there is some reason this is prohibitively difficult or has been considered and rejected then I won’t worry about it, but if it’s feasible, then I’d be happy to put in a request for it.
Semantic Model
Much of the cruft in my original config came from several different attempts I made over the years to manually implement something similar to the semantic model. In the end, I only ever maintained this for lights because I found that the effort wasn’t worth the meager or non-existent benefits for most other object types.
It actually took me a few tries to find the right fit between my digital layout, smarthome pieces, and actual house. But, in 3.0 the full semantic model is not only worth the effort, it’s not really much effort at all with the clever interface. I have enthusiastically embraced incorporating all but a very select few of my items into the model.
I did run into a few places where I’m still not satisfied with the mapping of the model. For example, all my z-wave wall switches that are connected to lights are taqgged with wallswitch and the points that control the brightness or toggle all have the light property. But what about the switches connected to my ceiling fans? Ceiling fan is an equipment type, not a property, so I am forced to choose between staying consistent with the rest of my model and leave them as wallswitch or setting them as ceiling fan to get them appropriately isolated in the equipment tab on the over view. In an extreme example, my son’s ceiling fan has never been directly wired to a wall switch, so now I’ve got it connected to an embedded z-wave switch and that switch is controlled by a separate z-wave wall switch so from an equipment standpoint it goes wallswitch -> switch -> ceiling fan for a single control point. These are the exceptions and not the rule, the model is still a huge boon both for beginners and at least in my case, slightly more advanced users.
I do have a few thoughts on the model that I feel it’s worth putting out to the community. I know Yannick has clearly outlined why the model should remain general and there’s not a lot of push to add extra locations, and I agree with all of his points. There are, however, a handful of important concepts that I feel are worth at least some consideration as candidates for adding to the model. I realize that the model is simply groups and tags and that most of the functions can be replicated by manually setting these for items, but each of the following, in my opinion, would see wide enough use and be common enough for beginner users to warrant being added formally to model:
Locations
-
Pool - There are a few specific outdoor locations in the model (e.g.,
garden) but a pool area is one that many users have automation or sensors for and is rather distinct from both a general outdoor space and the other specific outdoor tags. -
Suite - The only “collection of rooms” level in the model is really the
floor(you could argueapartmentas well, but, to me at least, that implies a fairly separate isolated area), but I think one more level available between floor and room is very useful. In my specific case I have many items and rules that are not just for the master bedroom but the master bedroom + walk-in closet + master bath. Right now my master suite is just a genericroomwith sub-rooms, but that doesn’t really feel very satisfactory. Yannick’s argument, if I recall, for the specific locations that have already been included in the model is that these are room types that tend to have distinct functions and that multi- or general-purpose rooms didn’t need to all be represented by specific tags. I would argue that a suite of rooms, from an automation standpoint, has a pretty distinct set of functions: averaging temps in the different sub-spaces, aggregating light and presence data, etc. -
Individual/Person - I think it would make quite bit of sense to extend the concept of “location” in the model to include the inhabitants. Many if not most of us have equipment, items, and rules specific to distinct people in our schemes.
Smartphoneis even already an equipment type, but it doesn’t really make sense to anchor that equipment to a physical location in the model. This idea, however, extends beyond just personal electronics to items that hold preferences and settings for individuals in a home or even beyond. For example, a few years ago, I had a full digital sticker reward chart for my younger son built-in that would fit quite naturally into a person level category but not really any “location” within the house.
Properties
- OnlineStatus - One of my primary use cases for OH is a centralized location for tracking the connectivity of not only the smarthome equipment but various other devices in and around the house. From the forums it seems that this is fairly common; Rich has certainly put up several wonderful posts about the various rules and widgets he uses for tracking all of his components and many commenters have asked about linking to OH instances at remotes site for this very purpose. I think Online or Connectivity status property would be very useful both for beginners to be able to see such aggregate data in a properties card and for advanced users for to create general rules for handling offline alerts.
Other
- Multi-location equipment - The way the model page and the auto-populated cards work, equipment cannot be anchored to two different locations. There are, however, some fairly basic and common reasons why someone might need to be able to do. 3-ways lights are the most obvious. I have a 3-way switch circuit (as most of do, or at least should) that controls the light on my stairs. One of those is a z-wave
wallswitchregistered in my model, but now it would be sensible to say thatwallswitchequipment is both in the main floor hallway and in the upstairs hallway. I can, as I said, manually add the equipment to that second group and that will be effective for any rules or other such things that I custom build, but that secondary location is not reflected on the model page or the location cards. It is a minor point, but again, I’d be interested in the devs’ opinion on how much that would wreck vs the sensible benefits of it.
Rules
Back somewhere in the 2.5’s I converted all my critical rules from DSL to jython. I saw the various discussions and solutions for updating to 3.0 with jython rules, but decided instead to switch them all over to js because…well, mostly because I don’t know js nearly as well as python and I like learning new things (I obviously used the js helper libraries for this as I’m not a masochist). I also spent a little time playing with the blocky option primarily just to play but also to occasionally get an autogenerated hint about how to do something new in js. Also, yet another huge shoutout to @rlkoshak (Is there a “Shoutout to Rich” tag for posts? There should be.). Although I didn’t actually use any of the helper scripts he’s made available, I did peruse them early and often in my learning process for js timers, and his posts on context and the this object are invaluable.
The rules interface is also really well done and added exactly 0 difficulty to my process of working up my rules from scratch. The ease of moving between, or combining different actions is incredible. The linking up of the item triggers and condition to the state description metadata is a fabulous touch.
Amusingly enough, the one thing I couldn’t figure out was in blocky. Maybe it’s there and I just didn’t poke around enough, but I couldn’t figure out how to compare a number item state to a number. There doesn’t appear to be anyway to cast item states in blocky and the if block’s type checking won’t accept an item state block if the other block in it is a number. If this is actually an omission then it should probably get a request as I can see this being fairly important from a beginner user-friendliness perspective.
Controversial Opinion
I am assuming that none of my other musings are going to set off any significant issues. I do, however, have one opinion that might be polarizing. I think item uids should be mutable (this does not apply nearly as much to thing or rule uids). I know the arguments against it; I’ve even seen a few very recent posts going over them, and I understand the potential for downstream breaking changes in a config if an item uid is changed. For those reasons I don’t think it should be as easy as any of the other item editing that can be done in the UI, but protected behind a few extra clicks and confirmations or even only enabled as an advanced option in the system settings. Nonetheless, I think it’s a good idea specifically for those users who have gotten past the very most beginning steps and are on their way to becoming more advanced users (i.e., users who also likely understand the potential consequences of changing a uid but can see the utility behind improving the readability of their config).
It seems with the changes to 3.0 that OH development is emphasizing attracting new users with less experience and coding know-how/desire. But part of the growth that those users need to eventually be able to have is to build a config that is structured in a usable and sensible manner. One of the most key components to that, in my experience and opinion, is a consistent and understandable item naming convention. Some of the requirement for this had been removed because Main UI, in all its item dialogs, shows the human readable name as well as the the item uid. That doesn’t hold, however, the moment the user begins to explore scripting and rules writing.
As I was initially re-building my config in the semantic model, I actually hit a few dead-ends and restarts in terms of developing a naming convention that was sufficiently global, useful, and sensible with the model’s location->equipment->point structure. I’m comfortable enough to dig into the jsondb files and reconfig that way but I don’t think that’s something that newer users should be encouraged to do and the process of deleting, recreating, and re-linking items just to rename them is simply not a bulk solution.
