Feature Request

I'm really looking forward to trying this out--iIt'll save me the work of having to gin something up on my own and will fill a need I've been meaning to get to (cobbler's shoes and all that). But why not look the gift horse directly in the mouth?

This request is not fully baked, but I'm sure you'll get the idea. As an example, I'd be interested in tracking the number of times my sump pump cycles per day. This plugin will do that perfectly well no doubt. But I'd also like to know if the number of pulses is "a lot". In other words, is it more or less than yesterday? More or less than average? I don't need the plugin to track "all time" but it would be super if it would provide a bit of extra insight into the tracked thing. Perhaps the plugin device, rather than being an either/or (either 1 day or 1 month or...) will have all of those things? In other words, I'd select the sump pump as the thing to track and the states would have:

• Cycles today
• Cycles yesterday
• Cycles this month
• Cycles last month
• Cycles this year
• Etc.

In any event, thanks for doing this! Let me know if you'd like a beta tester.

I was just about to do a "feature request" and was wondering if it's too early in the plugin's life for that.

This is an example of how I did pulse counting with triggers and schedules. https://forums.indigodomo.com/viewtopic.php?f=104&t=23670#p190968. I basically used the Timed Devices Plugin "Running Timer" device and the available states as a template for the pulses I wanted to track, current and historical (Last year, last month, last week, today, this week, this month, this year). The Running Timer has a lot more states than that... those were the ones I used.

Also +1 on Dave's request to add some math states : averages, delta between states, max, low... that could be a lot of fun to track/see.

(Sorry Dave for jumping on your Feature request)

~Bill

The device certainly does the long term - it’s currently one device with at least 100 states but I’m thinking of splitting it so if you only want daily by hour you don’t need the rest.

More than yesterday should be simple enough.

Average I’ll have to look at.


Sent from my iPhone using Tapatalk Pro

Many thanks!

General question for you.

I currently have two sets of hourly states.

Code: Select all

hour00 #00:00-00:59am
hour01 #01:00-01:59am
hour02 #02:00-02:59am
hour03 #etc
...
hour23

and

Code: Select all

currentHour #60 minutes since device start, or reset action
hourMinus01 #The previous 60 minutes
hourMinus02 #The previous 60 minutes
hourMinus03 #etc


Do I need the hourMinus states (ie "2 hours ago, there were x pulses") or do folk just use "between 9am and 10am there were x pulses"?

Problem is at the moment (how it's coded) the minus hours are relative to device start, not the clock, so might be confusing?

I keep changing my mind, because when we get to Days, we need "Yesterday" and "Last week", not just "27th of the month" and "20th-26th of the month")

I think it's best to leave it in then folk can use it if they wish and ignore it if they don't.

Discuss...

I think I'd use the minus states most. For example, how does yesterday compare to the day before that? Although it would be good to fire a trigger if I reach a certain time of day and my sump pump has run zero times, too. I think I want it all.

Calling @Matt @Jay or anyone qualified to answer...

Code: Select all

key_value_list = [
{"key":"hourMinus24","value":d.states["hourMinus23"]},
{"key":"hourMinus23","value":d.states["hourMinus22"]},
{"key":"hourMinus22","value":d.states["hourMinus21"]},
{"key":"hourMinus21","value":d.states["hourMinus20"]},
{"key":"hourMinus20","value":d.states["hourMinus19"]},
{"key":"hourMinus19","value":d.states["hourMinus18"]},
{"key":"hourMinus18","value":d.states["hourMinus17"]},
{"key":"hourMinus17","value":d.states["hourMinus16"]},
{"key":"hourMinus16","value":d.states["hourMinus15"]},
{"key":"hourMinus15","value":d.states["hourMinus14"]},
{"key":"hourMinus14","value":d.states["hourMinus13"]},
{"key":"hourMinus13","value":d.states["hourMinus12"]},
{"key":"hourMinus12","value":d.states["hourMinus11"]},
{"key":"hourMinus11","value":d.states["hourMinus10"]},
{"key":"hourMinus10","value":d.states["hourMinus09"]},
{"key":"hourMinus09","value":d.states["hourMinus08"]},
{"key":"hourMinus08","value":d.states["hourMinus07"]},
{"key":"hourMinus07","value":d.states["hourMinus06"]},
{"key":"hourMinus06","value":d.states["hourMinus05"]},
{"key":"hourMinus05","value":d.states["hourMinus04"]},
{"key":"hourMinus04","value":d.states["hourMinus03"]},
{"key":"hourMinus03","value":d.states["hourMinus02"]},
{"key":"hourMinus02","value":d.states["hourMinus01"]},
{"key":"hourMinus01","value":d.states["hourCurrent"]},
{"key":"hourCurrent","value":self.curPulses[d.id]}
]
d.updateStatesOnServer(key_value_list)

I know that's the correct way to only submit the state data once, instead of several updateStateOnServer(state,value) calls.

But, does referencing d.states[] multiple times call to the server multiple times? Do I need to take a copy of d.states and ref that for each line of the above eg:

Code: Select all

x = d.states
key_value_list = [
{"key":"hourMinus24","value":x["hourMinus23"]},
{"key":"hourMinus23","value":x["hourMinus22"]},
{"key":"hourMinus22","value":x["hourMinus21"]},
{"key":"hourMinus21","value":x["hourMinus20"]},
{"key":"hourMinus20","value":x["hourMinus19"]},
{"key":"hourMinus19","value":x["hourMinus18"]},
{"key":"hourMinus18","value":x["hourMinus17"]},
{"key":"hourMinus17","value":x["hourMinus16"]},
{"key":"hourMinus16","value":x["hourMinus15"]},
{"key":"hourMinus15","value":x["hourMinus14"]},
{"key":"hourMinus14","value":x["hourMinus13"]},
{"key":"hourMinus13","value":x["hourMinus12"]},
{"key":"hourMinus12","value":x["hourMinus11"]},
{"key":"hourMinus11","value":x["hourMinus10"]},
{"key":"hourMinus10","value":x["hourMinus09"]},
{"key":"hourMinus09","value":x["hourMinus08"]},
{"key":"hourMinus08","value":x["hourMinus07"]},
{"key":"hourMinus07","value":x["hourMinus06"]},
{"key":"hourMinus06","value":x["hourMinus05"]},
{"key":"hourMinus05","value":x["hourMinus04"]},
{"key":"hourMinus04","value":x["hourMinus03"]},
{"key":"hourMinus03","value":x["hourMinus02"]},
{"key":"hourMinus02","value":x["hourMinus01"]},
{"key":"hourMinus01","value":x["hourCurrent"]},
{"key":"hourCurrent","value":self.curPulses[d.id]}
]
d.updateStatesOnServer(key_value_list)

Peter

Dave, I think i've just invited your github account to my private github repo for this plugin, just so you can download it and see where it's at.

https://github.com/howartp84/Pulse-Coun ... /tag/1.0.2

It's not ready to publish yet, but should be functional for hourly pulse tracking up to 24 hours (and beyond, just not into "days" yet).

Peter

[matt (support)]

Great question (and kudos for thinking about reducing plugin<->Indigo Server calls). Doing a indigo.devices[someID] call will pull down a new device instance from the server. That instance has all of the data (including states), so once you have it you can do individual state look-ups quickly (no server call).

In summary, don't do this:

Code: Select all

stateOne = indigo.devices[someID].states["someStateKey"]
stateTwo = indigo.devices[someID].states["someOtherStateKey"]

but this would be okay/recommended:

Code: Select all

dev = indigo.devices[someID]
stateOne = dev.states["someStateKey"]
stateTwo = dev.states["someOtherStateKey"]

In your example further creating a local variable for the states dict might help performance just a tad but not much since in neither case a server call is made. I might still do it just for readability though.

Dave, I think i've just invited your github account to my private github repo for this plugin, just so you can download it and see where it's at.

https://github.com/howartp84/Pulse-Coun ... /tag/1.0.2

It's not ready to publish yet, but should be functional for hourly pulse tracking up to 24 hours (and beyond, just not into "days" yet).

Peter

Thanks Peter, I got the invitation. I'll check it out ASAP!

Just to save you working it out blindly, there’s one device type with loads of states, plus an action to trigger a pulse.

That’s all at present, more to follow.


Sent from my iPhone using Tapatalk Pro

It would be really nice to have a calendar input for days. I know python can use tkcalendar and pretty sure its not included in OSX install. Maybe we could somehow use this as a time to and from input to generate counting periods for the plugin?

Can you explain more?


Sent from my iPhone using Tapatalk Pro

Not sure if possible but I was reading about tkcalender:

https://readthedocs.org/projects/tkcale ... df/latest/

It uses tkinter, which according to my reading does not come with OSX python and needs installing.

This is the code to get the dates from the calendar...

https://stackoverflow.com/questions/506 ... dar-python. (see code screenshot below)

We can get the date from the calendar selection. Then based upon the date chosen (I would assume from a control page or other prompt) we could chart or send the pulse counting data to a file or matplotlib etc to display data in graphic form. (Similar to what I can display with grafana - see chart below)

I am new to python coding etc so I am having to do alot of reading. Most of you are much better at this stuff than I am so I figured I would try and help where I can.

Let me know if you need more explaining.

[jay (support)]

That likely won't work because plugins don't run in a process that can (safely) display UI (I believe that's what you're looking for, right? A calendar selection UI?) Plugin UI is displayed in the Mac Client app - through a couple of interprocess calls between the client, server, and plugin process. The problem is that we can't be sure that the server and plugin is running on the Mac which is showing the UI - because you can run the client remotely.

You might be able to hack it, but I don't think you could make it reliable enough to distribute as part of the solution. We have several things on our todo list concerning adding other types of controls to the plugin dialog capabilities, and date/time is one, but it's yet to rise to the top of our very long feature request list.