HE Features and Requests for 2023?

What are some of the new enhancements, features or bug fixes you are looking for from HE in 2023?

Some of mine:

UI Updates:
I still find the UI really difficult to use both on the website and the mobile (Android in my case) apps.

  • Some features on mobile just don't render in a viewable manner at all. Especially wider tables of data.
  • The "Done" button usage is confusing.
  • Device functions are segregated between the Devices and Settings menu functions in seemly odd ways sometimes. You add devices under Devices->Add device, but you can also see device states/data inside Devices. But if you want to look at futher details about a device (such as its zwave details like routing or security) you have to know to go into Settings->Zwave details. Why aren't all the details about a device (regardless of type) available from both places? Looking at the routing table is not a Setting, I'm not sure why its there.

Developer Documentation
Developer documentation still contains large sections of undocumented "TODOs". It would be nice if just 1 function a day could be documented, eventually they would all get completed.

Developer tools

  • Some enhancements to the editor would be nice. For instance, you can't select text and use tab/shift-tab to change indentation enmasse. The editor component being used is from 2018, updating to the latest may provide some nice enhancements/fixes.
  • Github integration for drivers/apps. Having to cut/paste from github for your own drivers are extra steps. Closing that loop would make development/updates easier.

Dashboard Enhancements
The built in dashboards aren't usable at all for me. How do you show a single tile with humidity and temperature from a combo humidity and temperature device? I have no idea. The UI of setting up titles (especially on mobile) is really confusing. The third party dashboard app is much easier to figure out.

Maker API cleanup
Maker API isn't always consistent with what JSON datatypes it uses and when units are passed along. Would love to see some of these issues addressed.

Device Firmware Updater app breakage
Anytime you remove a device the app had previously upgraded, you can't open it again without deleting and re-adding the app. Confusing and likely an easy fix. java.lang.NullPointerException: Cannot invoke method getDataValue() on null object on line 111 (method firmwareSelectorZW)

I look forward to seeing what exciting new features and enhancements HE has for us in 2023! All the best to the community and the Hubitat Team!


Better Dashboard tooling:
One of my top requests could be to have a better overall dashboarding solution, as of today we have to mix and match custom solutions to get something that is really nice looking and useful.

I would even be ready to pay some extra $$ for something OOTB and not have to mess with external solutions / apps.


I agree with with you on the UI of the Rule Machine. I get confused because the first thing I think of when making a rule is "if this happens then..." but IF is not done in the trigger section.

There have been some strides in the last few months to improve things and it did get easier. But I think it has a ways to go.


I'd think of that more as "when this happens, then," and that's basically the RM UI: the trigger is the "when this happens," and the actions are the "then." :slight_smile: Of course, you can get more complicated with additional logic, either in the actions (where it is phrased as IF -- but keep in mind, something needs to get the actions going in the first place) or with an advanced feature like required expression, but that's the basics. (I'm saying "when" here to emphasize the importance of triggers representing events, not state/conditions, though there is often a cause/effect relationship.)

But I think you're onto something: Basic Rule was created with the goal of flowing more like users think when creating automations. It has no discrete separation between "triggers" and "actions" -- though the first thing you create is effectively the "when this happens" that acts like an RM trigger. Of course, it's also a less powerful too, though despite its name, it can still do quite a bit. Many other apps have also been reworked or created with similar improved UIs in mind, and it's possible we'll get more in the coming months/year.


Rule Machine is the advanced version, and there are simpler ways to create automations like Basic Rule and Simple Automation Rules.

Room Lighting is the advanced version. Try as I might, I have a really hard time creating RL automations that do what I want them to do. I admit it's user error. I've ended up having to do my lighting automations in RM using RL scenes.

I know that Groups And Scenes has been, more or less, deprecated. (Yes, I know it's still available. But has always in my experience been... quirky.)

I'd really like to see a simpler version of Room Lighting that's more like a "basic rule for lighting automations."

1 Like

I do use Room Lighting, and it works well for what I use it for. But some of the esoteric settings add to my confusion and limit how much I use it. The trouble seems to be feature creep for this and many other apps. I agree with Bruce wholeheartedly that adding things for edge-cases leads to statements like yours. I do think that there have been almost too many things added here, and unless there is some way to simplify things, adoption of RL will suffer.

The documentation for apps is good, but when you have to look up what every option does every time you change or create something, it is getting too complex. I think we are either approaching that point or at it now. I do think there is an issue of grammar and word choices in some apps or names of settings, but on the other hand I am not sure what (or if) is a better descriptor in many cases. There simply aren't words for things that fit better than (for example in RL) activate. Same with what Corey said about "Done", like what synonym works better here?


Web UI

The first feature is an easy to implement one: make search filter out child apps/devices. In my case, my rule machine has over 100 apps and my HASS bridge device has 20 children, so its annoying to find the child I want (its as if search isn't there). To avoid annoying others, make it a togglable feature with it off by default

My second feature is probably not too difficult either, maybe some new CSS. I use the free open-source chrome/firefox extension called dark reader to make websites dark. When hubitat goes through this, it creates a very nice-looking dark mode. A built-in dark mode would help a lot on devices that don't support extensions, like mobile web browsers.

Attached are some screenshots of the nice dark UI.


This would also break a lot of existing functionality such as the home assistant integration, the pyHubitat library, and other projects. Instead the current API should be renamed legacy and the new API has to be installed new.


A more user friendley UI is one of my top wishes. Also a more graphic way of creating rules like a simpliefied version of Node Red a.k.a like Homeys Advanced Flow would be wonderfull.

Integration of more brands and products found here in Europe is my next big wish. I’ve asked Hubitat staff for Gardenas sprinkler system and provided info about where to find ther open API so hopefully they’ll be able to make that brand an integrated product in the near future.


Obviously you would version the API. Either by selecting which version on the Maker API control panel and/or by passing a version in the URL. I would never recommend anything that would break any existing behaviour.

1 Like

And, unfortunately, the documentation does not seem to keep up with all of the changes, and that makes it even harder. What does this switch mean? look in documentation Not there. ¯_(ツ)_/¯ That's not a slam on the team trying to keep the documentation updated. It can be a thankless task that's never done. It just makes it tough in a really complex app to figure out what's going on.

Agreed.. Sometimes there are no good choices. Whatever is selected is going to be confusing to someone.

The only thing I've thought of for activate is... maybe if the Activate column was in the same group as the Activation Settings... or off to the far left by itself... and if there was an "On" column to match the "Off" column, then it would be more clear that "Activate" was something else. I don't know. I had a hard time wrapping my head around "Activate" meaning the state when so much of RL has to do with automation. I probably still don't really have it right.


This so much! I do a lot of app editing in Chrome on my Android tablet and it's so painful! Editing is completely broken when you have tabs selected for indentation. I literally can't add new lines of code, anything that gets typed at the beginning of a line gets deleted right away. I have to work around the issue by starting new lines at the end of the preceding line and then adding a new line in front of it.

1 Like

If you can point to specific examples of this, the documentation can be updated accordingly. It is indeed difficult to track all changes, but there have been a lot of updates done this year (not just moving to a new platform).

It is possible some self-evident features will intentionally not be documented (e.g., choosing "Motion becomes active" as a means to activate in Room Lighting will need a "motion: active" event from a motion sensor). It is possible different people may have different ideas about what "self-evident" means, which can also be good to know. :smiley:


Absolutely. They must not mess with the current MakerAPI otherwise all my custom dashboards will stop working.


Hey @coreystup, I wonder if I might have a solution for you so you don't have to wait around. If you write .NET code, I've written several JSON converters to handle exactly this. If you don't write .NET code, maybe I can work this into something usable on your preferred platform.

These converters help a lot because you don't need a bunch of if/else statements in your code, you don't need to handle parsing within your business logic, and most importantly - they are type safe, which offers quite a bit of safety in this strange environment. Here are some examples:

Here is a location where the converters are used. This takes the output from the Maker API "all" endpoint and returns a type-safe object. These objects then make use of the OneOf<T> library to tease out the data in a type-safe way. The pattern I'm using here is "pattern matching" and allows simple dispatch to specific methods to get at the data I want. Here's the main object that holds onto the converted data. There's room for improvement (I'm refactoring the main branch), but it works quite well for my use case.

If you'd like to follow a test case, this is a short one that consumes this data to verify the data has been populated correctly.

It seems we are talking about different things (my comment was on documentation in general).

All changes are documented in the release notes, which are also linked to on the Check for Updates page on the hub.

1 Like

The one area I would really like to see improved is the device table display. If we could have at least an option to split the "Name/Label" field into two columns, and to replace the newline character between the two zigbee ID and network ID, then I could select the table and paste it into a spreadsheet. As it is, the above problems make this process such a mess that it's unusable.

If it's practical, it would also be a HUGE help to have an option to open those links in a new tab, rather than the current one. That way I can just close the device tab and get right back to where I was in the table, rather than having it re-display itself without any of the settings or sort options I'd made. This might all sound nit-picky but I have over 150 devices and it's REALLY annoying to have to page through this to find the device I was just looking at to find the next one, especially when they're close to the end of the list.

1 Like

There is a user app that can export to CSV. I used it to dump out the device and firmware version. [Release] Device Data Item Display

Normally for this I CTRL-Click but for some reason this wont work on the device page, but you can right click and open in new tab which is what I normally do. If the CTRL-Click could be fixed that would be nice.

1 Like

Wow, a lot of good stuff happened in 2022. Good work Hubitat team!

My 2023 list:

  1. Add the table format to RM triggers like the actions have so can edit a piece, not redo the whole thing. Otherwise RM is awesome given the UI interface its using.
  2. IOS mobile app needs some help, specifically geofence for presence which I gave up on. Multiple hubs at different locations cant have different geofence location, they linked, Battery hog, maybe have a polling interval, and make more reliable.
  3. Implement some of the proven solid community Apps and DH's as "built in".
  4. A legend for the Z-wave topology map so I know what the colors mean.

Not gonna push the dashboard short comings, im using sharptools.


Yeah, but it's easy to forget, and the phone version is worse - press and hold, select "open new tab in group" and then deal with the tab group is a pain. I'd be fine letting it open in the same tab if hitting Back would return to where it left off. That would be better yet.