HouseBot

Richard Naninck wrote:Hypothetically speaking: shouldn't the database just keep it's original size or even fluctuate a bit in getting larger and smaller again depending upon the size of property data?

You would think, but that's not the way access works. It's probably due to the way it creates records for transactions and the possibility of rollback. Not really sure.

If I understand this correctly, it grows because Access creates a new entry for each update. Do other dbase programs like mysql or sqlite do the same thing? Just interested in the matter. I don't think changing from Access to something else is going to be easy and since nobody else is having issues with this it doesn't make sense to change it at all. Time will tell..

I would hope that other DB's handle it better, but I'm sure there are new issues that they bring. I'm not a sworn supporter of access and would switch if needed. But switching out such a critical component is a risky task and since I don't really know what the issue is for sure, I'm leaning towards fixing what we have.

I can imagine the impact of changing the root of your software and therefore would stick to Access as well.

One thing is for sure, your fix does work. Yesterday I zeroized just about all properties that didn't need to be remebered and after 20 hours of uptime my dbase grew from 2MB to 14MB whereas it should have been around 100MB already before setting the values to zero.

So making this a feature in the GUI makes sense! Maybe a second option should be available too then: Don't remeber (or clear) the CurrentValue.

I could imagine the following scenario: the server releases the database at a particular time, at night may be. It comprimates the database and attaches it again. I think this can be acceptable as a compromise. The server is down for just a couple of seconds for database maintenance. So you don't need to look after the server. I have a half gig every 14 days. It's not a big deal but.....

peter

Good to hear I am not the only one. However implementing Scott's suggestions decreased the growth by 80% or so. I had to look carefully which properties I had to release but after some time I got it right. I am not sure if the database can be released at any point in time since you may miss events triggered by tasks, scripts or what have you. My scripts are constantly running and updating properties... and I mean constant! My FS20 HVAC stuff just crancs out insane amounts of serial data which is stored in properties. Releasing the dbase may have surprising effects.

All the more reason to support a "real" database IMO. Leave the Access DB in for those with simple needs, but have the option to connect through MSSQL (Full or Express Edition), MYSQL, PostgreSQL, or something similar for the power-hungry... I would imagine the MS route would be the easiest for Scott, and the Express edition is free and works great.

Terry

All nice thoughts of course, but if changing the dbase structure seems as hard as it is, it sounds strange to create different HB versions with different dbase handlers. Future updates would need multiple test platforms etc.

Agreed, I don't foresee different versions however. Just an option to select during setup, or maybe just another tab in the Settings --> Program Options Window. The way it is now could be the default, and a radio button, drop down selection, etc. would allow the user to select an alternate db. In speaking to my developers at work about this type of selection, they say that it's trivial in the .NET world to move between properly setup Access and MS-SQL DBs, but I know we're not talking .NET here.

IMHO, I think ultimately it's a "really nice to have" option, but I personally wouldn't want Scott to devote "Scottbott cycles" to it just yet when there are other more important goodies to create. (like an iSWRemote, or an all-out OSX/Linux version of HB just kidding Scott...not really... )

Terry

Of course you are kidding... it's april fools

Hi folks,
Were there any updates on troubleshooting this issue with hbdata growth?

My Housebot setup has been relatively unstable for about a year now due to the growth issue of hbdata. My system has a very low tolerance to db growth since I am running on diskless/fanless thin-PC. I can get up to about 75Mb before my system crashes out. I grow about 5 megs a day, so that gives me 2-3 weeks of runtime before failing.

Is the best way to troubleshoot this to disable one device at a time until the growth stops? Will Housebot still try to do db entries for the properties of the device even if it's disabled?

Any other thoughts would be appreciated.

Thanks
Tim

Folks,
I've done some more digging today an determined my worst offenders are the sleep timers. This makes sense, as every second it's going to update it's remaining time property.

I've implemented the db fix on my sleep timers by setting the persistentvlaue to 0. But I would welcome an easier way to do it in the future (checkbox?). I don't have Access on my Housebot PC, so I need to actually access my hbdata file from another PC to perform the change.

Tim

Not exactly sure what you want but if you want a checkbox to null a sleeptimer, you can use a theme button for that. Have the button null the sleep timer property. If you want multiple nulls from one button, you can use a task or script. Anyways, sleeptimers can be automated. I have sliders in my theme to set the actual sleeptime for photo slideshow timers, randow display of news etc.

No... Not to null a sleeptimer.

A checkbox to disable it being a persistant value in the database. It was spoken about further up the thread. Turning off/setting to 0, the persistantvalue flag directly in the hbdata database for a property, changes the behaviour of the record in ms database. For properties that update often, such as a timer, turning off persistance stops hbdata growing as fast.

Another alternative would be to always set the persistant value flag to zero for sleep timer devices in the next release.

Tim

Ah, now I am with you again. It has been a while since I scanned my dbase for the persistent flag. I nulled lots of them and in some cases I had to undo it again because important (last current) startup data was lost. That helped me a lot and yes, it would make sense to have a checkbox for that in the theme editer.