Q re dev_state in device_history_basic

Hi Matt,

I'm having a dense moment, can't figure out what f and t stand for, other than f = off, t = on ? Or is it intended to be something else?

Any plans to add a device_status table yet?
In the process of building a device_status table from sql history instead of using events log. Thought I'd ask in case it's coming

Heinz

[matt (support)]

Hi Heinz,

I'm having a dense moment, can't figure out what f and t stand for, other than f = off, t = on ? Or is it intended to be something else?

You are correct -- is is a boolean that represents the ON/OFF state of the device (ON is true).

No plans yet for a device_status table, but maybe after 2.5 ships. The next beta will be more intelligent about writing entries out to the device_history tables. It will only add a new row to the table if it is different from the previous row (the device state really changed).

Regards,
Matt

Duh, of course true and false.

Told you I was having a dense moment. Hadn't realized just how dense though

Thanks for the straightening.

The next beta will be more intelligent about writing entries out to the device_history tables. It will only add a new row to the table if it is different from the previous row (the device state really changed).

Regards,
Matt

As I'm redoing collection of status to PostgreSQL from event log I twigged on to the fact that I use time-stamp to confirm that security sensors are actually online, I.e. they call home occasionally without changing status.

Please take that into consideration when re-thinking history tables. I for one would rather have too much info than too little. No problem to purge out the db tables occasionally.

Heinz

[matt (support)]

Hi Heinz,

I'm really liking the new optimization that only writes changed states to the database. It is faster and keeps the database from getting huge from my devices that require polling (like the thermostat).

The next build of Indigo will include the new security attachment script (thanks bschollnick2!), and it includes an automatic heartbeat monitor for the security modules. Take a look at it after I post it.

If you really need the extra data in the database, then I can add it as an option to a future build (or you can comment out the line in indigohooks.py that tests the device states and var values for changes).

Regards,
Matt

Don't know how, but I managed to miss this post earlier

The new security script should do what I need, I.e. it was only the heartbeat I was missing. I'm currently getting that out of the eventlog.

I'm certainly in favor or smaller files as in reality one seems to forget to trim them