#And while i have a listening ear on this
1 messages ยท Page 1 of 1 (latest)
It is possible, I did it too. But... there is no standard way to do it and it is hard. Since you say you're a dba, I assume you know your way around in sql. If you don't, you should really not even try this, as you will very likely corrupt your new HA installation....
If you still want to go ahead, I suggest you install the Terminal & SSH Add-on first, that will give you a terminal window from which you can run sqlite3 to execute your statements.
๐ after almost 3 decades working with SQL / data, i think i have a fairt chance ๐
In the configuration page for the Terminal & SSH add-on add sqlite to the Packages list so that you do not have to install the sqlite package every time.
SQLite web looks like it uses standard T-SQL 92 compatible code, nice !
It's over a year ago for me now, but I do have some of my notes and scripts I used still lying around. You can have those to get you started, but I will not be able to assist you a lot.
i would really appreciate any and all docs you can share
dont forget to create backups before modifying things ^^
(also keep in mind that you can use more powerful software to edit the db as you can copy it on and off system)
Half the fun is tinekering around and figuring out stuff
What I did was to attach a 2nd database in my domoticz machine, then select and insert all data I wanted to transfer into that transfer database. Copy the transfer database over into the home assistant machine, and from there do the inverse, copy the data from the transfer db into the HA database.
You did not export the data in CSV format ?
oh another thing, make sure ha doesnt actually run while modifying / changing out the db
Correct, I did not. I used a sqlite db to transfer the data. This 1st script contains the statements I used in the domoticz instance. As I said, use them as an example. DO NOT RUN THEM blindly, and do NOT RUN THE ENITRE SCRIPT IN ONE GO...
We're not going to change out HA's database or modify HA's database structures, we're only transferring data into and out of the database, so no worries about having HA running while you're doing this. It took me more than a few weeks to discover everything, so I would not have been able to it without having HA running during that time.
Making proper backups is very sound advice though ๐
Making backups is THE advice if you ask a DBA ๐
sqlite doesnt really work like a dedicated sql server. its simply a file thats being read and written to with possibly some in memory caching.
adding a second process to access it may be enough of a disturbance to kill it. at best ha notices and dumps it as corrupt and you can simply copy it back and its fine. at worst you may leave the file in a corrupt enough state for the data to be lost
Ahh... your just mounting a temp 2nd DB in HA for the transfer of the data
Nice.... looks like there is even code to correction of the datetime datatype
That 1st script contains statements I used in the domoticz machine to create the transfer database. You can try that multiple times.
Check !
Thanks for the warning, i'll be sure to make backups. And in the case the second DB file is problematic, i can allways convert the data to a (rather large) insert script
moving stuff around like that will be fine, id just turn off the ha core container for a moment while you do the moving
Use the domotics sqllite enginge to generate insert scripts you can run by using sqlite web on HA
ah.... ofcourse... (noob here)
HA assumes its the only process working in the DB
pretty much yes
What I'm doing is to insert the data from DZ before the data set already created in HA. Since HA stores the energy data in a cumulative format (Long Term Statistics or LTS), there will be a point between those two sets where the sequence is broken. I did not try to adjust this break myself. Instead I used the developer tool 'STATISTICS' to find the break and adjust only the 1st data point of the HA data to restore the sequence. You'll see what I mean once you've used the STATISTICS tool once.
so, its not just raw data that gets compressed to large timeslots when it gets older ?
Correct, HA doesn't play very nice when you run long running statements, but it still applies basic locking mechanisms, so as long as you keep the batches small, and possibly avoid running larger DDL around the :00 times, you'll have no issues at all.
ha stores both the change and an absolute value in the history
depending on what is being displayed that helps to keep processing times down
Indeed. statistics.state has the absolute value at the time of measurement, statistics.sum has a running total of the change between this and the last row.
im not quite sure how the technical side of the modify statistic works in regards to either field, but it effectively adds a static offset to all of the following sets of data
the adjustment will be dropped once it hits the long term side of things if i recall, not sure on that anymore
But only for those rows where the statistics_meta table has a has_sum = 1.
Thaty figures... i use techniques like that to keep the measurement DB's down to 60 TB'ish, if i would not compress older data to large timeslots i'd end up with some behemoth that would be a PB by now ๐
The Enegry dashboard (and other things using the LTS) only look at the statistics.sum column
so rows with has_sum = 1, describe a datetime range, and has_sum = 0 is absolute data?
ah, there is a page describing the DB https://www.home-assistant.io/docs/backend/database/
Almost. has_sum = 1 means state and sum columns are filled; these are created from entities that have a state_class = total_increasing or state_class = total attribute.
entities that have a state_class = measurement will result in a statistic_meta row that has has_mean = 1. The rows in statistics for these statistics will get their min, max and mean columns filled.
As every entity can have only 1 attribute called state_class, the has_sum = 1 and has_mean = 1 are mutually exclusive. i.e. rows in statistics will either get their state + sum columns populated or their min, max and mean columns.
hmmm... i think i'm beginning to understand he <says optimistically>
II see I did not keep a lot of the statements used in the HA database.
it takes some time to understand a new datamodel.
ow? its that simple to attach .db files to sqlite ?
The HA database model isn't overly complicated. It's just that it is not very well normalized and not all data is available in the database sadly. It's been designed apparently mostly by developers, not a dba ๐
the file is effectively the database. attach is just the command to open a "connection" to it (read the file)
Bwahahahaha.... thats my life in a nutshell
correct
are you familiar with sqlite or do you use another sql dialect normally?
its been far too long ago that i've played around with stuff like this ๐
I thank you guys for giving me a flying start, truly much apprecianted!
i.e. do you need hints on how to read and write dates/datetimes?
nah, i'm famliar with unix epoch to UTC conversions in my own projects
excellent. I normally work in T-SQL (MS SQL), so this was another big hurdle for me ๐
Same here, MSSQL DBA since version 6.5
same
wow... just read that HA even has support for Jupyter
I'm looking to see if I can find some more queries I used, because that last one falls a bit short...
i will report back if i can make it work, andwe can exchange notes ! ๐
Queries are pretty fast, considering it's only running on a RPI 5
One side note: HA keeps one row in the LTS for each hour. Domoticz however has one row per day. i.e. you best insert that at 00:00 each day, so that the energy dashboard has at least one row for each day. It will look at bit strange when you look on a per day view, but that's all the data we have, so nothing to do about that. I made an error somewhere when inserting the data, probably due to Daylight saving time, that makes mine show up as 02:00, but this still works.. ๐
For example
ey, thats a good tip....
And the reason why i always use UTC (because i have data coming in from all timezones)
Right, I love UTC too. But sadly I don't always get to have a say in this...
well... sometimes you must make space for dev's to fubar, and then swoop in to save the day.
๐
again, thanks for the tips.
I'm off to bed, need to work @ 10 tomorrow.
good night