Thinking about drivers I have written and the recent conversations around scheduled jobs.... I was thinking it would be handy to have a built-in option on every Device Edit page (or even just a basic app) to schedule commands available on devices, rather than developers needing to build it in to each driver that needs it. Common examples include a basic "every X minutes run refresh()", etc. Perhaps a small link displayed under each command button could open a separate page where the schedule could be configured?
I know this is not a major impost on a developers time to make this available, but would be a cool feature that would put the control in the users hands, rather than relying on the options the developer makes available. It would also help in providing a consistent outcome, removing complications baed on developer experience and knowledge.
This is also something that can be achieved through RM, but it would be nice to keep something like this close to the device it relates to and more light-weight.
Simon
Aside from the fact that every driver would have to modified to support this -- no small effort -- it pretty much blows of the platform distinction of device and automation, don't you think?
I guess I'd never really looked at it like that or known that was a thing, but now that you mention it I can see what you mean. And fair point, it does muddy the waters in that regard.
I wasn't wanting to impose that kind of effort. I was thinking more about how there are common elements on the Device page that a developer does not need to include in their driver, such as the link to the Events page. I was thinking another button or UI element could be introduced that took the user to a small page where a small rule could be setup along the lines of "trigger periodically every X mins" with an action of "run a custom command", allowing the user to choose from the commands offered for the device.
If it doesn't fit within the vision for the platform, or it is likely to be a lot of work, then that's fine, it is only for a very minor convenience I was suggesting the change. Thanks for taking a look.
Simon
Whoa, slippery slope! Whatever you put there won't be enough for some people. Next thing you know, there are requests to add more... Even a link to Basic Rule carrying the device is fraught with issues, like do you want it as a trigger, or an action, etc.
There remains the more general UI/UX issue of how to make things more obvious for new users, how to get them started. You know, it's like learning to ride a bike: those first few attempts are tough, then it gets easy.
I don't know what you mean... We never pile on and ask for more... do we...? 
Yeah, good point, it's easy for me to sit here and focus on my narrow scoped requirement, but as you say, it opens the gate for an explosion of requests once you introduce automation on the Device page. I think I can see what you meant earlier now, everything should have it's place to make it easier for both the user and the developers.
I've avoided developing apps up until this point, wanting to keep my learning curve small at the beginning. But 3 years down the track there are situations now where I really should start to look at moving some of the automation elements and user interaction for my creations into apps, rather than having users managing the setup in the device page.
