performance q update one state or put info into props

question:
with sqllogger on:

what is less taxing on the indigo server+sqllogger..:

Code: Select all

1.
dev.updateStateOnServer(key, newValue)
2.
props = dev.pluginProps
props[key] = newValue
dev.replacePluginPropsOnServer(props)


Karl
ps.
and I guess
dev.replaceOnServer()
is only needed if dev.description ="new text"
is changed?

[matt (support)]

My initial thought would be updating states (versus properties) might be a bit more efficient, although it does trigger Indigo's Trigger processing (to check for device state changed triggers) so I might be wrong on that. State updating will trigger the SQL Logger plugin as well. Properties changes do to, but that bails out pretty quickly since the states aren't different (just the properties).

Replacing the entire element on the server would be the slowest, and you are correct that is only needed in a few cases like when changing the device's name, description, etc.

It would be nice to have an option to save some permanent variables that indigo does not need to manage (flags etc) — or is better to just save these things to a file to have them back after plugin restart.


Sent from my iPhone using Tapatalk

[matt (support)]

Device specific properties? dev.pluginProps would definitely the place for that. How frequently do you need to update the data (and are you running into high CPU usage because of it)?

just asking in general going forward about how to manage info

I currently have 400k dev.updateStatesOnserver(changeList) per day.

The Mac Pro2008/2012 run fine with it, but when some folks w older mac minis try to use my plugins I want to make sure it works fine too.


Karl

I currently have 400k dev.updateStatesOnserver(changeList) per day.

Good lord, man, that is a LOT of updates. Not sure if this would help or even be applicable, but I update the local copy of my states along with the server's copy. Thus, I can do a quick compare when a value is read/received and only update on a true change. It may not be applicable for you (or you may already be doing it) but thought that I would mention it...

These ARE changed state values
And yes, I believe I went overboard with sensors and beacons etc in my house
it’s about 5 changes per second

One of the suspects I like to change is Fingscan. It updates a state lastUp with the current date stamp every minute for each up device. And I have ~ 80
It should not need that state at all as it has lastStatusChange date stamp.
A left over from my early days.

Karl


Sent from my iPhone using Tapatalk

[matt (support)]

Can you queue up changes in the plugin based on a threshold percentage? Strictly as an example, say you had the following analog value state updates at the following intervals:

Code: Select all

0.10s    5.123
0.20s    5.120
0.30s    5.190
0.40s   11.120
0.50s   11.093
...

In this case the only really useful transition is 5.190 -> 11.12. The other ones could be ignored, or at least throttled so that they are updated less frequently.

For my pi sensors i have
Send to indigo if deltavaluelast-current > x or lastupdate- time.time() > 90 secs

Karl




Sent from my iPhone using Tapatalk