Jump to content

Keeps overwriting my short poll setting


Recommended Posts

Posted

I upgraded to 1.2.1 and it sets short poll to the minimum for devices, which is good, but it keeps resetting it to that minimum over again after I change it to something longer. I suspect it's during the next polling cycle because It doesn't happen right away. 

Part of my reason for setting it longer is that it helps prevent hitting API rate limit for those times when I have to restart the plug-in or reboot. (I have 8 devices.) While this isn't a daily thing, of course, it often comes in clumps with more than one restart, which ends up blowing the limit. With this in mind, in addition to letting people be able to set their own short poll, could the plug-in save a timestamp of the last time it did a poll such that it lives through restarts?

 

Posted

Version 1.2.2 changes the default for Auto Short Poll to False, so now it will stay false if you have that set, and will stay True if you change it to True.

I'll think about saving the timestamp, but the effort required isn't worth it right now, many other things to work on in my spare time, and personally I just ignore the issue since it shortly corrects itself.

 

Posted

ok, i now see the option to set auto short poll in Admin Console. Did not notice that before. A good place for that would be on config page for plug-in right below the poll config info.

When I reinstalled plug-in to get 1.2.2, it set the values too low for all three of my instances. Correct me if I'm wrong but I'm now having to choose between always having to change polling every update vs. having the plug-in change it for me to the minimum it calculates and overwriting any change I make the next time it reads data. Could the plug-in not just leave any existing short poll setting alone at restart and during data updates? Or at least during data updates? The latter is the bigger flaw in this.

I understand if a timestamp solution is too complicated. Yes, there are more beneficial things to work on if it's not an easy thing. As long as Airthings continues to only temporarily block things when over the limit, it's not major issue. 

Thanks

Posted (edited)

It could be a config option, but personally it makes more sense to me for it to be controllable as a driver because you can now also set short poll from a driver as well.  This way it can be changed to longer polls when slow updates are ok, and shorter polls when you want faster updates.

The plugin will only change the value if Auto mode is on, otherwise it should not be changing.  If you are seeing something else then let me know and I'll look into it when back home again.

 

Edited by Jimbo.Automates
Posted

I did notice today that if I change short poll using the GUI and the long poll is the same or shorter than the number I set, it changes it back (or changes it to long poll - not sure. It was the same in my case). So I had to go into plug-in config to first change long poll to something longer. There was no message about this in the GUI. I just knew the issue from having gotten the message doing that in plug-in config. You may need to add long poll to GUI and have a message pop-up there if the numbers don't work if you want to keep things this way.

Posted

Well the long poll does matter because if user picks a short poll that's longer than the long poll using the GUI, it won't stick.

I'm not sure what the heartbeat is all about for this, anyway. Is the number important for something, i.e. could I set it to 10000 or something ridiculous?  Is it something one can use for anything?

Thanks.

 

Posted

The heartbeat is the only thing done on longPoll which is a way to monitor that the plugin is alive by checking for DON/DOF on the controller.

I'll update the code to increase the longPoll if it's less than the shortPoll.


Sent from my Pixel 8 Pro using Tapatalk

Posted
42 minutes ago, Jimbo.Automates said:

I'll update the code to increase the longPoll if it's less than the shortPoll.
 

Hold on publishing that change. I got a ton of these errors last night again, which you suggested was fixed in 1.2.2:

Have turned on debug level for logs - hopefully it happens again soon. Could be tonight because it's been happening almost daily since I reported it. It requires a restart, which then causes API limit to be reached not long after the restart. I wish there was a way to stop/start plug-in from IoX so I could heal things programmatically instead of manually. 

 

Posted
On 7/25/2024 at 7:54 PM, johnnyt said:

Hold on publishing that change. I got a ton of these errors last night again, which you suggested was fixed in 1.2.2:

 

 

The other error has not re-occurred. Maybe I just needed to reboot/restart PG3. (I did a reboot)

Guest
This topic is now closed to further replies.

×
×
  • Create New...