Expose ability to change longPoll and shortPoll values

[jimboca]

I have a node server where I need to configure the shortPoll on the fly. https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues/13

[jimboca]

@BenoitMercier or @bpaauwe would it be possible to add this?

[mkohanim]

Actually, I like this idea a lot.

With kind regards,

---

Michel Kohanim

         CEO

(p) 818.631.0333

http://www.universal-devices.comhttp://www.universal-devices.com/

---

---

From: Jimbo.Automates @.> Sent: Saturday, May 25, 2024 9:45:39 AM To: UniversalDevicesInc/udi_python_interface @.> Cc: Subscribed @.***> Subject: Re: [UniversalDevicesInc/udi_python_interface] Expose ability to change longPoll and shortPoll values (Issue #26)

@BenoitMercierhttps://github.com/BenoitMercier or @bpaauwehttps://github.com/bpaauwe would it be possible to add this?

— Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/udi_python_interface/issues/26#issuecomment-2131358426, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPNPOTCBXISNLNOZ5OTZEC53HAVCNFSM6AAAAAAS3HMGTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZRGM2TQNBSGY. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[bpaauwe]

Seems like this is more of a PG3 issue than an interface issue. PG3 stores the values for short/long poll in it's database and uses those values to configure timers that send messages to the plug-in when those timers trigger.

These values for each plug-in are currently user configurable.

Allowing the plug-in to modify these values at runtime will create a conflict between what the user sets and what the plug-in sets. This could lead to user confusion. I.E. I set the short poll to 60 seconds, why are things only updating every 120 seconds?

Also, are the plug-in changes only temporary or are they allowed to update the configuration database?

The short/long poll timers are a convenience for plug-ins and plug-ins are not required to use them if they don't meet the requirements of the plug-in.

For the Airthings issue referenced above, it seems like a better solution would be to not use short poll at all and have the plug-in calculate the required poll interval based on the number of sensors being polled and do that polling implementation internally. Making the user guess at a value and then having the plug-in override it anyway seems like a less optimal user experience.

[jimboca]

I could invent my own polling interval and set it internally to the maximum allowed based on the number of sensors, but I'd prefer to just use the existing short poll mechanism and allow the plugin to automatically set the value, or use a value determined by the user if they prefer a longer period. If I used my own, then it would still be restricted to only be triggered when the short poll is called, or I'd have to start a new thread and handle it internally which seems wrong. Why not let the plugin change the short poll and have it reflected in the database.

[bpaauwe]

Thinking about it some more, maybe a better solution would be to create a third type of poll interval. Leave short poll and long poll as is but add a third interval that is set by the plug-in. That way PG3 would still be doing the timers. By default, the new timer would be disabled and only enabled if the plug-in configures it.

This allows the existing API to be used. Since PG3 sends a POLL message with a flag to indicate weather it's the short or long interval, so that there's another flag value; shortpoll, longpoll, programedpoll or something like that.

We could also give the plug-in author the choice to expose the short/long poll configuration such that those could be disabled if the plug-in doesn't need them.

[bpaauwe]

Why not let the plugin change the short poll and have it reflected in the database.

1) because you're overriding something that is supposed to be user configured. That seems wrong to me. 2) short/long poll have had a specific behavior/meaning for years now. I think it would be better to add to the API than change existing API.

[bpaauwe]

What my proposal doesn't allow for is the ability for the user to override the plug-in's programmable interval. But you could do that with a custom parameter. That way it would be obvious to the user that they are overriding whatever the plug-in wanted to do with a specific value.

[jimboca]

Why not let the plugin change the short poll and have it reflected in the database.

because you're overriding something that is supposed to be user configured. That seems wrong to me.

something that "can" be user configured, but rarely is, and the default values are supplied by the plugin.

short/long poll have had a specific behavior/meaning for years now. I think it would be better to add to the API than change existing API

What is the "specific behavior/meaning" .it pretty much means something different in each plugin depending on their needs. The documentation just says "The POLL event is published periodically based on the shortPoll and longPoll configuration settings. " Allowing a plugin to optionally override poll values doesn't seem like that big of a change.

Why add something new, like programedpoll, which will break current behavior since some plugins likely use "if short_poll: do shortpoll; else do longpoll", which obviously is not the best but know it exists.

[mkohanim]

I have always wanted to update the poll interval in my own plugins, but I understand what Bob is suggesting and it makes sense: it may cause confusion for the user and add to support tickets. Maybe a third plugin-defined polling interval is not bad. If it’s 0, then no polling. Otherwise, poll.

With kind regards,

---

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

---

From: Jimbo.Automates @.> Sent: Sunday, May 26, 2024 12:26 PM To: UniversalDevicesInc/udi_python_interface @.> Cc: Michel Kohanim @.>; Comment @.> Subject: Re: [UniversalDevicesInc/udi_python_interface] Expose ability to change longPoll and shortPoll values (Issue #26)

Why not let the plugin change the short poll and have it reflected in the database.

because you're overriding something that is supposed to be user configured. That seems wrong to me.

something that "can" be user configured, but rarely is, and the default values are supplied by the plugin.

short/long poll have had a specific behavior/meaning for years now. I think it would be better to add to the API than change existing API

What is the "specific behavior/meaning" .it pretty much means something different in each plugin depending on their needs. The documentation just says "The POLL event is published periodically based on the shortPoll and longPoll configuration settings. " Allowing a plugin to optionally override poll values doesn't seem like that big of a change.

Why add something new, like programedpoll, which will break current behavior since some plugins likely use "if short_poll: do shortpoll; else do longpoll", which obviously is not the best but know it exists.

— Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/udi_python_interface/issues/26#issuecomment-2132371519, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPKDCPFJH6WNQAUURBLZEIZOBAVCNFSM6AAAAAAS3HMGTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGM3TCNJRHE. You are receiving this because you commented.Message ID: @.**@.>>

[bpaauwe]

What is the "specific behavior/meaning" .it pretty much means something different in each plugin depending on their needs. The documentation just says "The POLL event is published periodically based on the shortPoll and longPoll configuration settings. " Allowing a plugin to optionally override poll values doesn't seem like that big of a change.

What I meant was that polling intervals are typically used to control how often something is queried for status updates and that the user has the ability to define those intervals. You're correct in that for many users, they just don't care what the interval is and having the plug-in automatically adjust it would probably go unnoticed. But I have faith that there are some who would set a poll value and then complain when it wasn't updating at that interval.

Why add something new, like programedpoll, which will break current behavior since some plugins likely use "if short_poll: do shortpoll; else do longpoll", which obviously is not the best but know it exists.

That was my first thought too, but it really should be implemented such that you only get a programmed poll event if your plug-in has configured a programmed poll interval. Existing plug-ins wouldn't be configuring one, so they'd never get the event.

I think the same should be done for both short and long poll so that plug-in authors can decide if they need those or not. If the plug-in only needs one poll interval, the other shouldn't even show up on the configuration page. If a plug-in doesn't need any polling, no polling configuration should be present.

The biggest problem with allowing plug-ins to override the poll intervals is that you now have two ways to set the intervals and there's no clear way for the user to know how this works. One plug-in may take the user entered value as the value to use and only override it if the user hasn't set a value. Another plug-in may use the user's entered value as just a guideline and adjust it as necessary. Maybe one plug-in treats the user setting as a maximum interval and another treats it as the minimum interval.

With a programmed poll interval controlled by the plug-in, you then have the ability to define how that works using custom parameters. You can have custom parameters for minimum interval and maximum interval that the user configures while the plug-in is then free to set the interval anywhere between the two as needed. To me, this is then far less confusing than re-purposing the existing short/long poll values

[jimboca]

My intent was to have a driver which defined Auto Set Short Poll True|False so it would be clear to the user.

I agree having a new polling and allow plugins to specifically define if they want long, short or programed would be best, but that's a big change and I was proposing what I thought was a simple change that had a better chance of actually being implemented since my original request was ignored for 18 months. :)

[BenoitMercier]

If a plugin needs to run something on schedule at a rate that is determined by the plugin, then why do we need to have that exposed to the user?

In my opinion, that logic should be in the plugin itself. PG3 does not add much value to this.

To make things easy, look at this module. You can schedule a task, and modify a schedule on the fly as needed: https://pypi.org/project/schedule/

[jimboca]

@BenoitMercier as I said, I can create my own thread and handle it, but polling functionality already exists in PG3 so why should I have to start a new thread to handle it, which I will if this doesn't happen.

[BenoitMercier]

@UniversalDevicesInc/jimbo, Because polling from PG3 does not work the way you need it. It is meant to be user configurable.

It does not make sense to me to have the plugin tell PG3 to send a new type of poll message to the plugin, when there are simpler solutions like scheduler.

[jimboca]

Wow, thanks for the consideration. Yes simpler for you, not if others need it. nevermind.

[bpaauwe]

I can see the benefit of having a standardized way to handle rate-limited polling. All the weather service plug-ins have this issue too and I've not come up with a good way to handle it. The weather services complicate this a bit more because the actual limit is based on the subscription plan that the user has subscribed to, not a fixed value. But if the user could enter the rate limit into the plug-in and have the plug-in then program the poll interval to not exceed that limit seems useful and more intuitive than making the user calculate the interval based on the rate limits.

@jimboca I didn't mean to imply that you hadn't thought through how allowing the plug-in to change the poll interval would work for your plug-in. My concern is that not everyone will put the same effort into it and we'll end up with different behaviors from various plug-ins for something that's currently consistent.

Adding something like "programmed poll" isn't really any more work than modifying PG3 to allow plug-in's to change the existing poll intervals. Both require a new PG3 API. Adding "programmed poll" does mean adding a database field and another timer, both of which are fairly easy. Extending this to allow plug-in authors to disable existing polls is really a different feature (and should probably be a different request).

[mkohanim]

Why can't there be another poll type (short, long, plugin)?

[BenoitMercier]

Do we need to have the user determine and enter rate limits into a new type of poll? Or do we need the plugin to determine the schedule?

[mkohanim]

I would assume that it's just the plugin. Something like @ in unix.

With kind regards,

---

Michel Kohanim

         CEO

(p) 818.631.0333

http://www.universal-devices.comhttp://www.universal-devices.com/

---

---

From: BenoitMercier @.> Sent: Monday, May 27, 2024 6:07:43 PM To: UniversalDevicesInc/udi_python_interface @.> Cc: Michel Kohanim @.>; Comment @.> Subject: Re: [UniversalDevicesInc/udi_python_interface] Expose ability to change longPoll and shortPoll values (Issue #26)

Do we need to have the user determine and enter rate limits into a new type of poll? Or do we need the plugin to determine the schedule?

— Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/udi_python_interface/issues/26#issuecomment-2134190478, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPKAICV6TY7Q4SBXCFDZEPKF7AVCNFSM6AAAAAAS3HMGTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZUGE4TANBXHA. You are receiving this because you commented.Message ID: @.***>

[jimboca]

Plugin only. If the plugin wants to allow the user override then it can be another driver. Which I will do in airthings.

[bpaauwe]

agree, plug-in only. For the weather services, I would probably have a custom parameter where the user enters the rate limit based on the service/subscription.