OpenUV Free Account: changes

ariela · January 26, 2019, 10:10am

Hi folks,

considering last email by OpenUV

For someone who missed my first email, starting from 1 Feb 2019 we're going to introduce some important changes to our Pricing Policy and Terms Of Service.

What changed:
Free Plan is still there but its daily quota will be limited to 50 free requests per day since 1 of February 2019 for all free plan users.
A new Fixed-Priced Plan is introduced. The plan offers up to 15'000 reqs/daily for $7.99 per month.
Important: All users who're currently using unlimited plan will be automatically moved to the Fixed-Priced Plan and billed based on the new pricing.
We also happy to offer Unlimited Plan for established enterprise clients. To get your personal quote contact us on support@openuv.io.
What to do next:
If your happy with less than 50 reqs per day then do nothing. Otherwise, consider to update your service background logic and decrease the number of API calls to consume the free API quota more effectively (for example - skip the nighttime updates). 
.....

what do you think if we should implement in the Binding the possibility to poll the service only during the daylight hours?

We need to manage 50 requests per day. Now it means a request every 30 mins. We should stay focused only on 8AM - 8 PM (or even less) and increase to 12 hours -> a request every 15 mins.

Does it make any sense?

@glhopital are you the maintainer of this binding? what do you think?

Thanks
Andrea

glhopital · January 27, 2019, 7:00am

@ariela : yes, I’m this binding maintainer and your suggestion is a neat way to enhance it and help stay in free plan, but this also has to take in account the location you’re querying. I’ll think of this when I’ll update the binding.

ariela · February 4, 2019, 5:50pm

@glhopital

ciao, I don’t know if this is related to the changes ongoing in free account, but starting from (yesterday?) I see OpenUV Binding in unknown state with this log:

2019-02-04 18:41:54.872 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.scheduleUVMaxEvent(OpenUVReportHandler.java:102) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.updateChannels(OpenUVReportHandler.java:130) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.lambda$1(OpenUVReportHandler.java:122) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2019-02-04 18:41:54.985 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.scheduleUVMaxEvent(OpenUVReportHandler.java:102) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.updateChannels(OpenUVReportHandler.java:130) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.lambda$2(OpenUVReportHandler.java:161) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2019-02-04 18:41:55.106 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.scheduleUVMaxEvent(OpenUVReportHandler.java:102) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.updateChannels(OpenUVReportHandler.java:130) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.lambda$2(OpenUVReportHandler.java:161) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2019-02-04 18:41:55.214 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.scheduleUVMaxEvent(OpenUVReportHandler.java:102) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.updateChannels(OpenUVReportHandler.java:130) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.lambda$2(OpenUVReportHandler.java:161) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2019-02-04 18:41:55.349 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.scheduleUVMaxEvent(OpenUVReportHandler.java:102) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.updateChannels(OpenUVReportHandler.java:130) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.lambda$2(OpenUVReportHandler.java:161) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2019-02-04 18:41:55.356 [INFO ] [enhab.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
2019-02-04 18:41:55.420 [INFO ] [o.internal.handler.AstroThingHandler] - Scheduled Positional job astro:sun:local every 300 seconds
2019-02-04 18:41:55.470 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.scheduleUVMaxEvent(OpenUVReportHandler.java:102) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.updateChannels(OpenUVReportHandler.java:130) ~[?:?]
	at org.openhab.binding.openuv.internal.handler.OpenUVReportHandler.lambda$2(OpenUVReportHandler.java:161) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

Dunno if this is related to:

But #467 should be already merged.

Openhabian #1512 here.

thanks

Andrea

JimT · December 3, 2019, 7:41am

Perhaps rather than trying to figure out the location and adjust the frequency / time window, just determine the next poll based on the UV index itself. If the UV Index is very low, the next update will be in an hour or more. If the UV index is high, update up to every 15 minutes.

Since the binding implements REFRESH, this can be done within a rule.

For the first step, I have implemented a simple cron based rule:

Set the Thing refresh to 24 hours 1440mins
Create a rule like this (in jython)

@rule("OpenUV Manual Update")
@when("Time cron 0 0/15 7-16 * * ?")
@when("Time cron 0 0 5,6,17,18,19 * * ?")
def refresh_uv_data(event):
    events.sendCommand("UV_Index", "REFRESH") # My item is called UV_Index

I’m still tweaking the timing, but might resort to scheduling it based on the uv index value itself.

ariela · March 24, 2020, 11:07am

Question is: any “REFRESH” action is a Binding call?

I mean, the binding is not one item (I have 11 items configured using that binding), so if any REFRESH action is a Binding call, that is not working for me (we will finish the free account in 4 calls :))

what you think?

Andrea

ariela · March 24, 2020, 12:04pm

@glhopital

Did you have a chance to think about it?

thanks for your support
ciao

Andrea

glhopital · March 25, 2020, 6:06am

I will take a look at this

ariela · March 25, 2020, 7:31am

FYI this is what I’m trying to do right now, just for your information:

other interesting threads:

github.com/home-assistant/core

OpenUV API is reducing the daily quota for free plans

opened 07:07PM - 10 Jan 19 UTC

closed 12:12PM - 14 Jan 19 UTC

kpine

integration: openuv

**Home Assistant release with the issue:**  Any version, when using the OpenUV component after 2/1/2019. **Last working Home Assistant release (if known):** N/A **Operating environment (Hass.io/Docker/Windows/etc.):**  N/A **Component/platform:**  https://www.home-assistant.io/components/openuv/ **Description of problem:** OpenUV is reducing the API quota for the free plan from 500 requests per day to 50. The component currently sets a default scan interval of 30 minutes based on the 500 per day value. This will result in a minimum of about 48 request per day which is very near the limit. A few restarts of HA and users will exceed it. The _default_ scan interval should be increased to something like 60 minutes (24 per day) to leave a bigger buffer below the limit. The component could also skip night time updates to reduce the number of requests. That might not be worth the coding complexity, whereas a default of about 24 per day is probably good enough for most people. The component documentation should be updated to reflect the new plan limits. **Problem-relevant `configuration.yaml` entries and (fill out even if it seems unimportant):** ```yaml openuv: scan_interval: ``` **Traceback (if applicable):** N/A **Additional information:** The new plan limits are already live at https://www.openuv.io/#pricing. Here is the text of the email detailing the API change: > We changed our Terms. Attention Required. > Hi! Alex is here from OpenUV.io. > > Starting from 1 Feb 2019 we're going to introduce some important changes for our Pricing Policy and Terms Of Service. > > What changed: > > * Free Plan is still there but its daily quota will be changed to 50 free requests per day since 1 of February 2019 for all free plan users. > * We happy to introduce a new Fixed-Priced Plan for Indie Hackers and Smart Home Enthusiasts who's going to integrate OpenUV API into their apps and services but willing to keep their expenses on low. The new Fixed Plan offers up to 15'000 reqs/daily for $7.99 per month. > * We also happy to offer Unlimited Plan for established enterprise clients. To get your personal quote contact us on support@openuv.io. > > What to do next: > > * If your service needs less than 50 reqs per day do nothing. Otherwise reconsider to update your service background logic and decrease the number of API calls to consume the free API quota more effectively (for example skip the nighttime updates). > * If your service needs more than 50 and up to 15'000 reqs/daily try our new $7.99 plan. For that go to OpenUV Dev Console and update your billing details (securely processed by Stripe). The plan will be unlocked immediately. > > That's it. > Cheers and keep yourself safe from the UV rays in 2019! > Alex @ Founder of OpenUV.io >

github.com/home-assistant/core

Adjust OpenUV integration for upcoming API limit changes

home-assistant:dev ← bachya:openuv-api-update

opened 12:24AM - 11 Jan 19 UTC

bachya

+60 -71

## Description: Starting February 1st, OpenUV will be reducing the free tier …of its API to 50 requests per day. The current integration will likely overrun this. To accommodate all possible scenarios, this PR removes automatic polling of the API and, instead, gives users the ability to update sensors manually via the `openuv.update_data` service. Additionally, this PR fixes a bug (caused by a recent OpenUV change) where users would see "Invalid API Key" when configuring the component, even if the API key was valid. **BREAKING CHANGE:** users will now need to use the `openuv.update_data` service to request new data from the API. **Related issue (if applicable):** fixes #19931 and fixes #19950 **Pull request in [home-assistant.io](https://github.com/home-assistant/home-assistant.io) with documentation (if applicable):** https://github.com/home-assistant/home-assistant.io/pull/8127 ## Example entry for `configuration.yaml` (if applicable): ```yaml openuv: api_key: !secret openuv_api_key ``` ## Checklist: - [x] The code change is tested and works locally. - [x] Local tests pass with `tox`. **Your PR cannot be merged unless tests pass** - [x] There is no commented out code in this PR. If user exposed functionality or configuration variables are added/changed: - [x] Documentation added/updated in [home-assistant.io](https://github.com/home-assistant/home-assistant.io) [ex-requir]: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/keyboard.py#L14 [ex-import]: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/keyboard.py#L54

(it’s Home Assistant, but I think the issue is the same)

There is an issue in tracking the Sun activities, if I well understand. I would suggest, if possible, to track the solar radiation from Astro Binding (or doing the same), in order to be sure the model will be applicable at any latitude.

Does it make any sense?

Andrea

glhopital · March 27, 2020, 12:23pm

PR pushed here

ariela · March 27, 2020, 6:01pm

Thank you @glhopital

Any idea to increase the frequency of refresh when the UV reaches high levels?

You should add, for example, the radiation item from Astro Binding, and add the possibility to set at least 2 thresholds with different refresh Tim.

for example, from radiation x to radiation y refresh any z minutes

Radiation should be also enough, you don’t need sun elevation. (if radiation is 0, there is no sun :))

does it make any sense?

thanks again for your support
Andrea