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.
-
USB-hubs. This one is self explanatory. New feature simply might need some more ports.
-
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.
-
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 
I believe guys from Hubitat could find something worthy here.
