[OBSOLETE] "Pollster" - A SmartThings Polling Daemon

Refresh or Poll to use? My device seems to work with both. Is there a way to tell which one is lightweight, or is there a preference to use Refresh vs Poll?

Often, poll and refresh end up calling the exact same code in the Devive Type Handler groovy code.

Has anyone noticed Pollster is now dying again more frequently? I think @geko mentioned he was going to modify the smartapp to re-run every sunset/sunrise which means at the most, your system would only go 12 hours without pollster running. I think thatā€™s a good idea.

I had to reset mine, yes I noticed. :smile:

I really really really wish the native ST poll worked, the platform would be better for it, because they could control/throttle polling.

OR they could make Pollster official, and set limits on polling for devices, so that the system wasnā€™t overloaded.

As much as I love and use Pollster, I think polling is what is killing the cloud, which is why I set all my devices to use modes and events as much as possible. I have two time based routines (sun up and down) which are backed up with IFTTT, and the rest of my setup is event driven only. I believe itā€™s why I rarely have problems.

2 Likes

This does not make sense. Everything in the cloud is event driven, including polling. The only difference is that event are generated by a cron scheduler instead of a device or user action.

The problem is inability of the cloud to handle large number of events in a timely manner. I have logs that clearly show that occasionally (meaning several times a week) events are delayed by as much as 10 seconds and their execution time grows to as long as 40 seconds. All these thread are being killed by a grim ripper. This results in actions (routines, etc.) not being executed or their incomplete execution. This affects all events, without exception.

5 Likes

However, since time based ā€œeventsā€ are more likely to bunch up - at the top of the hour, top of the minute, etc. - the observable effect is that building up and cancelling (the grim reaper effect you mention) hits them. True events based upon physical actions (walking by a motion sensor or the temp in a room changing) will be much more evenly spread out.

Now here is something really odd. Pollster was failing on me a lot this morning. I took a few minutes and pieced in something that was mentioned by someone here in the community (Iā€™m sorry, but I managed to loose the bookmark on the thread so I canā€™t say who) that doesnā€™t using polling but instead depends upon temperature sensors changing temp to periodically refresh things. With enough temp sensors something is always changing so you get a fairly current status without polling.

Well, I figured that it may make sense to stitch in a subscription to a temp sensor temp change event to work in addition to the watchdog process. Essentially if none of the sets have kicked off within a safety period then it will perform the restart.

I wrote it and started it up. Now for the odd part - since Iā€™ve started this one running in parallel with the stock Pollster, the stock Pollster has crashed twice today and the one with the temp subscription hasnā€™t crashed once. The subscription hasnā€™t even been used to do anything. Certainly not sure if it means anything but it is curious.

1 Like

Thereā€™s no doubt about it, but timers and scheduling are the crux of automation. Certain things have to happen on the clock or X seconds or minutes after physical event (e.g. motion event). If this basic functionality does not work, everyting else is futile. Can you guarantee that the temperature will change within 5 minutes after the motion event to turn the light off?

1 Like

Of course not - as you said you have to have things scheduled. My point was that walking by the motion sensor probably didnā€™t happen exactly at the top of the minute, or worse, top of the hour - so the initial event and the follow on time to turn off the light are more likely to be evenly spread out and therefore avoid the micropeaks of activity that happen with scheduled things. Just my theory as to why ā€œscheduledā€ things appear, at the gross level, to be more unreliable than ā€œeventā€ things. Of course, another hole in my theory is that Polllster seems to make some effort to stay off of the predictable times, as wellā€¦

Polster randomizes seconds in its schedule, but it does not seem to help either. Iā€™m pretty sure SmartThings is staggering scheduled jobs within at least +/- 30 seconds, possibly more, to try to spread out peak loads. Anyway, if youā€™re polling every few minutes, youā€™re bound to hit close to peak load anyway.

My point was that walking by the motion sensor probably didnā€™t happen exactly at the top of the minute

True, but weā€™re taking probabilities now. Automation is supposed to be deterministic, not a willy-nilly ā€œkeep my fingers crossed and hope the light will turn onā€.

2 Likes

Not to veer from topic at hand, but does anyone know if Wemo Polls or Refreshes?

As many know, wemo is a pain in the butt for Smartthings. I have several unfortunately and they periodically go offline. when ST canā€™t see them, commands donā€™t execute. Iā€™d like to set the correct command for Pollster so my Wemos update. Poll or Refresh?

thanks

+1 on this question. WeMo devices or showing incorrect status is my primary reason for running Pollster; itā€™s also the biggest WAF issue for our home automation. I actually have replaced a few WeMo switches with z-wave for critical lights - WiFi just doesnā€™t cut it as a home automation backbone.

What I find odd is that Wemo is a known problem for ST. They have ā€œupdatedā€ their wemo app recently, but we still seem to be having difficulties with it. IFTTT does not have a problem with Wemo. Itā€™s strange. At the least ST should have some sort of protocol that automatically calls for a refresh of devices with out our needing to manually do it - Or need a third party smart app.

This is weird. Iā€™ve been watching live logging almost all day and I cannot get the stock pollster to stay running - basically at all.

However, the one I modified to subscribe to a temp change seems to be running almost completely stable. Thatā€™s a mystery for someone that knows the arch. details a lot better than I do.

All Iā€™m doing is checking the last time some of the three groups polled (from the status.trunX) and if it is too long then call the restart() routine - just like the watchdog routine in the stock version. It seems to work, however, I get this error if I ever have to restart:

12:26:15 PM: error org.hibernate.AssertionFailure: collection [physicalgraph.location.Location.hubs] was not processed by flush() @ line 222

It is in the restart routine itself and is trying to resubscribe to the ā€œappā€:
subscribe(app, onAppTouch)

It has only kicked in a couple of times today, total, whereas the stock one has completely died with no message at least a dozen.

I was mainly putting this in to see if I could - still learning a lot about this environment. Any ideas why the above error would happen? I could just set a flag and skip over it - any downside to that?

Cool thanks. May I ask why we wouldnā€™t want to ā€œsubscribe, timesync and pollā€ all at once? is it taxing to the system? does Belkin freak out when it has to many refresh commands?

@dmw999
dont suppose you would share your modified code?

I didnā€™t know how to see all of that - that is a great piece of information. Thanks!

Actually, I think it MAY be the other way around??? The original code has watchDogTask() call restart(), restart() calls updated(), update() unschedules all and calls initialize() which subscribes to the appā€™s onAppTouch event. I added an unsubscribe() into updated(). I just changed it to unsubscribe(sensor) (for the temp sensor). So in the stock code it was always resubscribing without unsubscribing. Havenā€™t had it need to restart to test the theory yet, but thanks for the inspiration.

The code is embarrassingly quick and dirty hacked together right now - I was just doing it to see if I couldā€¦ Let me clean it up a bit and see if this error is gone (so it actually does what it is supposed to do) and Iā€™ll post it.

##Pollster Version 1.4 is released. Enjoy your pollingā€¦ :slight_smile:

Version 1.4.1. Released 1/19/2016

  • Four polling groups.
  • Execute watchdog process upon app touch and location events (sunrise, sunset or mode change).
  • Watchdog process will restart Pollster if any of the polling schedules is late by 10 minutes or more.
  • Donā€™t use ā€œhideableā€ section attribute due to UI rendering bug.

Please visit https://github.com/statusbits/smartthings/

P.S. A bug was discovered and fixed in version 1.4.1. This bug only affects polling group #4.

3 Likes

Thanks! Updated via GitHub replication. Will let you know how it goes. Didnā€™t you have 4 polling groups before though?

Correct. I borrowed one of the four available slots to run the watchdog process. However, it didnā€™t quite work because watchdog process was failing for the same reason the polling processes were. So now, instead of running watchdog on schedule, itā€™s triggered by the location events.

1 Like

Hi,

i was trying to play around with this a bit to get my Smartthings Hub to reflect my changes of the Hue Bulbs at a faster rate. My Plan is to trigger the refresh command for the Hue Bulb every 1-5 Seconds. I was trying to modify the code to enable me to input in seconds, instead of minutes, but whatever i do, it stays at 1 Minute intervals as the minimum.
Can somebody please point me in the right direction?