I wanted to raise a topic to see if anyone has advise on a good external database to use with Hubitat. The reason i am specifically asking is about collecting data for my integration to help users, but even a general idea of what external databases works well with Hubitat would be nice.
I have only come up with 2 options that natively support rest API's
InfluxDB which seems fantastic for Time based data like for graphing and such. It pairs well with Hubitat.
CouchDB which it seems to be completely based on rest API's which is a NoSQL type database. Because of it's nature it seems to be a potential option under certain cirumstances, but i don't think it fits what i need very well.
That is it though. Everything else i have found needs a DB driver to connect, or uses a intermediate server to create rest api's for the database tables. Does anyone have any suggestions.
What type of data do you want to collect in the database? How do you plan on using that data after it is collected?
Understanding a little bit more of the actual use-case might help the community provide some new ideas.
One fairly simple option is to stand up a Node-RED server. NR has lots of options to integrate with a variety of database backends, that can also be hosted on the same external server. I have used NR to collect data into InfluxDB for years. I run Node-RED, InfluxDB, and Grafana on my always-on home server. That server also handles Plex Server duties for the house, shared folders for files, backups, etc...
Honestly I was kind of trying to keep it generic as to see what database folks use directly with Hubitat. That is why I didn't go into exactly what I was trying to do
That said what got me thinking down this path was the Govee stuff I have been taking care now. Simply put the drivers right now are split up not by the exact device, but by the device abilities. Since most of the Govee devices out there are RGB type devices the standard driver really does serve almost everything from Govee with the extra drivers covering some fring use cases that have feature subsets of the main driver.
Recently scenes were added which has made this a bit more complicated. The scenes can have drastically different commands depending on the model number. If i am able to decipher a way to send the commands to the AWS IOT cloud(not Govee Developer Cloud API) we will have over 144 devices that can use the driver with a range of 30-70 different scenes. Right now with LAN API only devices i still have over 50. I already have a map in the driver that contains entries for a variety of devices i own with a select list of scenes. If i ever managed to have commands for all 50 devices even a reasonable number of scene details would end up with hundreds of lines for them.
My thought is that if i could store this data in a small database that i could expose to Hubitat then i could create a method to retrieve this information. That would save me from either having to create a separate driver for each device model, or have a massive amount of data in the driver dedicated just to storing scene commands for everything. I also want to create a method for users to upload their scenes as well since i don't have every device to do the retrieval. I kind of have something already with CouchDB created for testing, but there is one aspect i am not really happy with. I think I can code around my issue though. I also really doubt this is the kind of data CouchDB is intended to do.
Ultimately what I want to do is have all of this data stored externally to Hubitat but readily available for 2 functions. The first function would be for a user to click on a button on the driver and it would retrieve all of the valid scenes for the device using the model that is stored in a data value on the device. The second function would be for the user to setup the scene in Govee Home app and then using the Govee Integration app capture the data and upload it to the database so that others can use the command on their device of the same model.
