Please do so! Thx a lot!!
-
Device attributes of 'boolean' should not be avaraged in graph
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebookmake it so !
-
@Heizelmann you please give an example of a device type where boolean values are averaged?
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
The first graph is from online watching. Two short pulses had happend
present:13:12:48 absent: 13:13:03 and
present:13:15:19 absent:13:15:25
This is correct in view. Then closing graph and reopening shows this
-
@Heizelmann said in Device attributes of 'boolean' should not be avaraged in graph:
The first graph is from online watching. Two short pulses had happend
Well, this does not happen for switch state and presence attributes in my test setup!
- Which presence device type are you using?
- Did you change the database settings in your setup?
Normally, averaging should only happen for “continuous” attributes. These are "number " type attributes by default, if not specified otherwise in the device schema. Attribute types of type “boolean” and “string” are “discrete” attributes by default where no averaging takes place. The following setup is the shoing the default configuration pimatic is using:
"database": { "deviceAttributeLogging": [ { "deviceId": "*", "attributeName": "*", "type": "*", "interval": "0", "expire": "7d" }, { "deviceId": "*", "attributeName": "*", "type": "continuous", "interval": "5min", "expire": "7d" }, ...
EDIT: The following example from my test setup is showing history data from the 15th of March. You see nice how responseTime (number) is average to the 5min while the presence state (boolean ) is not averaged:
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
@mwittig Sorry, I have forgotten this: It is a MySensorsPIR
-
@Heizelmann said in Device attributes of 'boolean' should not be avaraged in graph:
It is a MySensorsPIR
Thanks. I had quick look at MySensorsPIR which does not override the default behaviour of the “presence” attribute inherited from “env.devices.PresenceSensor”. So, may be it is the database configuration in your case?! Please review.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Thanks. May be I did something wrong in database setup.
This is the actual setup:{ "deviceId": "sickerschacht-pumpe-sensor", "attributeName": "*", "type": "*", "interval": "1min", "expire": "1y" },
is it possible to ignore the interval for discrete types and store the values only on change events?
-
Ah, I understood. “interval”: “0” means not deactivating database storage, but instead stands for storing on demand. Is this right? In my case an interval of 1 min was still too long. Setting it to 0 and the graph will stay OK. Is this “interval”: “0” feature somewhere documented?
-
@Heizelmann said in Device attributes of 'boolean' should not be avaraged in graph:
Is this “interval”: “0” feature somewhere documented?
Not as far as I know. I did some guess work from code reading. I think we need to add this to the config schema to be part of https://pimatic.org/pages/config/
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
sweetpi did some documentation a while ago at the howto category
https://forum.pimatic.org/topic/44/database-configuration-howtopimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebookmake it so !
-
OK, many thanks for helping. I think the issue is mainly solved with this but what is left is the in the lower section of the graph the selection area where the graph still shows interpolation.