The maximum polling frequency of Pollster is 1 minute. That’s nothing for any sensibly designed system. We’re not talking about seconds or milliseconds here. Typically, Z-Wave controllers poll devices every 20 - 30 seconds to keep their state up to date.
2 Likes
I tend to agree; however, that is what I was told.
Please take it up with the Developer Advocates.; I’m just a messenger and not a good one at that.
##My personal opinion?
Like an automobile recall, SmartThings should absolutely stop selling this product until the fundamental feature of scheduling is fixed. Period.
4 Likes
The execution limit is 250 per minute. That’s a ridiculously high number relative to the scheduling of events by various apps. How many sensors can you set off in one minute?
It’s unlikely, but just something to think about when designing this.
We will be looking for beta testers fairly soon.
4 Likes
Just get all the usernames from the other thread and you’ll have all the testers you need 
5 Likes
[quote=“jodyalbritton, post:65, topic:38398”]
We will be looking for beta testers fairly soon.
[/quote]Considering that they’re coming out with a new scheduler, there doesn’t appear to be any interest in a scheduling capability, and the low chance of it actually ever becoming a capability, I no longer see the point of building my own DH that supports it.
Well… I guess we should be grateful they don’t make automobiles. 
2 Likes
Promises, promises. Always promises, rarely deliver the goods without paying for it with some other failure scheme.
2 Likes
SmartThings also has hinted at launching a rules engine and web UI for a long time too… Hasn’t stopped Community developed SmartRules, Rule Machine, SmartTiles, SharpTools…
Regardless… It definitely won’t be made an official “Capability”; but folks can still pattern Device Types per the specification I wrote.
One refinement: the two steps required to schedule a method call can be reduced to one by using a cover method in your SmartApps (I’ll give example later…). I’m more and more convinced that this can be very close to a 1:1 search and replace for all the native scheduling methods, with just a few lines of extra code added to every SmartApp… Or just to Rule Machine.
[quote=“bravenel, post:69, topic:38398”]
Always promises, rarely deliver the goods without paying for it with some other failure scheme.
[/quote]Do you think it would be a waste of time for me to modify my Thingshield DH so that it supports the capability specs that @tgauchat provided?
I really don’t know. Trusting that ST will fix things hasn’t been a very successful strategy.
4 Likes
Personally, I’d recommend focusing on the most commonly needed methods, and the maximum resolution could be 5 seconds or whatever.
And only PoC with a couple different methods.
Also consider where the datetime interpretation handling is done… I mentioned, for example, nearly everything (except arbitrary cronspec) can be reduced to “number of seconds from now” and “repeat every x seconds”)… I think, … And that math could be easiest in the DTH (Groovy) if you want to keep the device MCU code as light as possible.
Or assume cronspec is available and use a *nix device or cloud.
Would recommend the resolution be 1 second. Many wifi devices out there that require a poll a second which can be brought into the ecosystem if this is possible.
1 Like
1 second may work for many circumstances, but I’d say the spec has to warn that latency will affect maximum accuracy. Remember, the Schedule Driver device has to trigger an Event for each schedule. SmartThings can handle many Events per second (sure it can…), but there’s bound to be cases of queuing if the Cloud is busy.
The goal is to at least match SmartThings’s own specs; i.e., runIn() is considered unreliable for less than “60 seconds”.
