Improvement suggestions

After heaving a really good time using Hubitat, I have gathered some ideas that could improove user expirience of the platfrom for advanced users (driver authors and DIY-enthusiasts). I think other people could share their ideas here too (to not to duplicate threads). I'd like to keep this thread agnostic from specific vendors/devices (avoid requesting specific apps and drivers) and focus on the platform itself.

Hardware related suggestions:

  • The hub has built-in USB OTG port that is unfortunately used only for limited set of Wi-Fi (and maybe cell phone) adapters. Capabilities can be extended greatly by adding support of USB-hubs, COM-port adapters and USB-SATA adapters.
  1. USB-hubs. This one is self explanatory. New feature simply might need some more ports.

  2. COM-port (with some API interface). DIY users will get quite broad access to connect their AVR/PIC/STM/etc controllers without any complications like using custom Zigbee or Wi-Fi controllers. Quite a lot of ideas requires only basic simple solutions.

  3. USB-SATA adapter support. Many times I saw on the form requests to support statistical data. And I found myself not so user friendly to use additional external platform (RaspberryPi or PC solutions). Using internal FLASH memory has a serious risk of HUB deterioration. But simply connecting external industry standard drive (SSD) with external supply opens an oportunity to add such functionality (it also needs some DB service installed; SQL API can handle all the needed to access this DB). Also it could store some video content from cameras. But I'm not so sure if the last point can be standardized.

  • PoE is another interesting feature for some use cases

  • UPS. It would be cool to have ability to connect external 18650 cell to some built-in circuit (as an option) to get atleast basic UPS support. If HUB will be able to self-shutdown gracefully after some timeout it would be just awesome. This topic actually can have many different ways to improve. But the lack of wide spread solutions of such low voltage DC UPS is obvious. And it needs some smart connection with the HUB anyway to take RM based decisions (beforementioned COM-port can help here)

Platform environment related:

  • I found some not so user frendly behavior during drive implementation related to multi-threading. Multi-threading itself is really good in squizing performance out of the hub CPU. But I find all the drivers and apps being directly exposed to multithreading with using limited JAVA/Groovy language feature set.
    Let's think of it from user point: Do I need access to the multi-threading when implementing app/driver? What for? Basically when accessing some internal state I need to protect this state from corruption. And it happens because event functions might get called from some different thread. And that's it. That is all the interaction with multithreaded execution here. So my answer is 'I don't need it. I don't get any benefit of it'.
    So what would I do to improve it: I would make an per-instance (either driver or app) event queue and call all the events in the loop from a single thread to trigger callbacks. This way add/driver interface becomes single-threaded removing the need of user-side synchronization (strongly improoving stability and making user code less error prone). Instances (apps/drivers) in turn can be updated in parallel threads still getting all the performance.

  • Z-Wave Application status: It would be nice to have hub handling (in configurable way) CMD re-try when device is asking for it. Some slow devices ask to retry after certain amount of time or simply 'later'. Handling this feature inside drivers is quite unfriendly. On the other hand slow devices could really benefit from this feature (locks, FLiRS, some others)

  • Z-Wave hot reboot. I had some Z-Wave issues few time that required to fully power-off my hub. It sound like hub is capable to reboot the module. For me it was a headache because it's sometime hard to get to hub. But I have constant acceess remotely.

SDK related suggestions (capabilities):
After adding child device interface it feels to me some capabilities need a bit of cleanup. Some of them are:

  • Battery. Aside from charge level battery (battery controller actually) can be in difefrent states like charging, discharging, off, on. Some 'batteryState' attribute sounds logical to add.

  • Thermostat. I would prefer to remove temperature measurement and fan control out of it. The motivation is simple: not all thermostats do report measured temperature, some have few temperature sensors; not all thermostats have built-in fan, some have few fans. Unfortunately it pops up backward compatibility problem.

I guess that's it for now from my side))
If you have any other ideas, please join me :wink: I believe guys from Hubitat could find something worthy here.

Lets start with the hardware stuff. That would require a redesign of the hardware. Which in turn would force another FCC certification as well as another SiLabs certification. That would get expensive real quick.

POE? This can be accomplished with a splitter.

Ups? Can be accomplished in a few ways. In my case I have a Ring v2 extender that is on the same circuit as the ups that the hub is connected to. If the ring extender switches to battery for more than 15 mins, Hubitat does a graceful shutdown. A bit cumbersome because you need the ups as well as the extender (or any battery backed up device)

The multi threading? I'll let others answer that one. I mean if everything is working as it should, it really doesn't matter to me as an end user.

Hot reboot? SDK issue.

SDK related issues: 100% SiLabs. All hubitat can do is follow them with very little finagling. Finagle it too much and they lose their certification regardless of how well the adjustment works.

Battery? The attributes like that I'm not even sure are availble... My own look at the z-wave sdk doesn't show those.

Thermostat? I'm not sure why that's a big deal. Aesthetics?

Not knocking any of your suggestions. A lot of this has been discussed to death and explained by Bruce & Mike as to why it won't or can't happen.

Just don't get my suggestions as complaints) It's just subjective thoughts on making platform better)

By USB suggestions I didn't meant any actual hardware changes. I thought adding a driver doesn't require FCC. But I'm not familiar with full production cycle in details.

Battery? This is not about Z-Wave specifically (not command classes but capabilities). Rather broader view over the API interface. Btw some devices can send extra notifications with such info even over z-wave.

Thermostat? Aesthetics? I would say yes. I can't call it an issue in any way. it's mainly about API interface cleanup (and it's purely subjective). Dashbords and rules rely on attributes and commands. Having unused attributes/commands just adds some mess.

1 Like

The attribute mess though would have to be cleaned up by the device manufacturer though I would think.