[DEPRECATED] wx-ApiXU-driver

🚧 Developers
1

This driver has been Deprecated. Once ApiXU was acquired and they reduced the Free account, there's no need to continue developing this driver. Please try the DarkSky driver for most of the same features.

I've been interested in the ApiXu driver because it's long been on my list of Large Apps. It's not very large in lines of code but it is large in it's impact to the Hub. It's one of the contributing factors that triggered a move to a 'coordinator hub' -- and now to three hubs. It converses with internet sites (the cloud) and using sync http, which "steals" the site's response time from the Hub. (The hub waits for the response.) Everyone is encouraged to use Async http to allow the hub to work on other things during the response time. Like a lot of code on Hubitat, ApiXU converses with multiple sites. It gets Sunrise and Sunset times for your location from sunrise-sunset.org and it does so with each polling cycle. While weather can certainly change every few minutes, your sunrise/sun set times won't change again til tomorrow.

Bangali has incorporated previous offerings, and I've offered this latest to him but he's been away for several weeks. I hope it's intentional and not due to illness or accident. :frowning:

Let me be clear.. I don't want to "own" the code but I also want to reduce the load, not just on my hub, but everyone's. I am willing to "Release" my code to bridge the gap but it's not clear to me that the benefit outweighs the turmoil. Turmoil because you'll probably want to add a new Virtual Device with driver and just disable the old.. then when Bangali returns and does integrate it.. switch back. The attribute names are all the same, for Dashboard, as an example, you'd open each tile and just select the new device, no need to change the Attribute.

Only about 10% of the change is visible to users. Quite obviously, ApiXU isn't offering more or better data to me :smiley: The attributes that you use are all the same. What this code tries to do is reduce the load on your hub. 90% of my coding efforts are aimed only at that one goal. I have added a switch to 'roll up' the giant list of selectable attributes after you've made your selections, to reduce the clutter. Here in California, we don't have a lot of 'weather' -- not much sneaks up on us. I don't really need to poll very often so I've extended the poll times to include 1 hour and 3 hours. 3 hours is especially good for those that use a Rule to refresh on demand. Lux/illuminance does change frequently and has always had it's own poll cycle and that's unchanged. It's not really good for detecting that one cloud overhead and thus 5 mins is the current lower limit.

Sunrise and sunset times are now acquired once per day, (and once per Save Preference.) Forecast Precipitation rotates the daily values once per day too, but I've grouped all of the attributes behind a single selector (extended precip).

The question then is: Do I release it or not?
Consensus is: yes, release it. Therefore, in the tradition of using the First Post in a Thread to point to the github release, I've edited this to add:

Initially all the Attributes Selectors are visible. Once you've selected the set you want, you can click the Display All Preferences to off and save preferences. That will "roll up" the Selectors to reduce the clutter.

36%20PM
36%20PM879×448 32.5 KB

Some attributes have been grouped, for example: Latitude and Longitude, with a single Selector (Latitude) so that you don't have to find them individually in an alphabetical list. Other Groups are: Sunrise Sunset and Temp High / Low +1 day.

-- == Release v1.2 == --
This release makes a big change in the way the Attributes are presented to the Hub. From Day One, Attributes have been strings. Wind Speed, Precipitation, and Visibility, to name but a few, are all sent from APIXU as numbers. Beginning with v1.2, wx-ApiXU-Driver submits value to the hub in their intended format. Numbers are numbers (Floating point or Integer) and text remains as Strings. Depending on how you’ve been using APIXU this past year, this change has the possibility of breaking your comparisons.

Please take great care in upgrading to v1.2 and beyond. Take the time to evaluate your use and to check the results. If you find the results are different, either roll back to v1.1.9 or adjust your automations to account for the new values.

-- == Release v1.3 == --

With v1.3, I think I have completed my transition of the original code into something less taxing on the hub. Let me be clear about that statement… the code and therefore the Hub have to do the same work BUT it’s spread out and isn’t continuous.

See: [DEPRECATED] wx-ApiXU-driver - #103 by csteele

-- == Release v1.4 == --

  • Distributed forecastPrecip() into sunRiseSetHandler, for the once a day portion
    and into calcTime and doPoll for the display of data.
  • Reworked updateLux() to use a schedule() vs chained runIn for robustness.
  • Moved sunRiseSet map from 'state' to 'data' storage to declutter State Variable
9 Likes
2

Hmm. This is a difficult one isn't it. I see your dilemma.
From my perspective, anything that reduces the load on the hub has to be a good thing.
If you were to do as you suggest will you fall foul of licensing agreements? I don't know but was just playing devils advocate and asking the question.

3

It's an "Ethics" question, not legal. :slight_smile: Bangali's source is Open, as is mine. Anyone can do anything they want.

Update: I've sent Bangali a PM on the latest, as I have with each previous iteration.. it's just this time he's not around to comment. Had he said "take it, I'm tired" or "don't you dare" (Neither are his language, I was hoping to inject humor!) I would not have posted this conundrum. :smiley:

4

Is it on github? You could put in a pull request and just share the link to the pull request.... It would be up to everyone else to decide what to do with it.....

He has it licensed under Apache 2.0 which usually welcomes community development

EDIT: Or make a fork of it until he is back....

5

Yes Dan, it is on github.. been there for months, maybe 6 months. I don't think many are going to stumble onto it. "Release" as I use it in this case is to publicize the github url. :smiley: In fact, I'd move it to HubitatCommunity repo. :smiley: (since I was the one to encourage it's use as a place to find code.)

1 Like
6

If I would be in your shoes, I would do the following:

  • Make a fork of Bangali's git-repo
  • Implement the changes there
  • Put a pull request back to bengali
  • Give users the link to your fork
  • Once Bangali is back, hash it out with him and then clear that fork or show a readme back to the original repo
6 Likes
7

+1 sounds like a very "ethical" approach!

2 Likes
8

Remember, @Cobra brought up much needed issues regarding code reuse within the Community. I asked Bangali to a) consider my updates and b) "should I release a renamed and highly modified version?"

But he's not been around to answer.. thus THERE is the ethical question. As I said above:

Had he said "take it, I'm tired" or "don't you dare" (Neither are his language, I was hoping to inject humor!) I would not have posted this conundrum. :smiley:

2 Likes
9

From my understanding Andy's primary gripe (rightfully so) is that many apps/drivers are being released using large quantities of his code without giving him any credit for it (basically just cut and paste). I realize it goes further than that, but the modification that you are doing here is quite a bit more than just a "cut and paste/rename" so I see it as less of an issue. IMHO....

3 Likes
10

@csteele pm’d me about this before creating this thread.
I have been the ‘victim’ of ‘code theft’ on a couple of occasions and I see the dilema.
I don’t see this as code theft or anything like that
@csteele has attempted to offer this code on a number of occasions to @bangali with (currently) no response.

I do however; like @dan.t ‘s idea of putting it on a fork and using a pull request to ‘officially’ offer the code for a merge.
That way, @bangali has the option to accept it or work with @csteele to incorporate the mods (or reject it as is his right)

I would take Dan’s suggestion and fork it then release the link to the fork.

Andy

8 Likes
11

Not that my opinion matters so much. I also think this sounds appropriate.

2 Likes
12

I've updated the First Post to 'announce' the Release.

It's out on HubitatCommunity repo for your enjoyment. :smiley:

3 Likes
13

So not knowing a lot about the load you refer to, and still being quite new to the HE community, is this something I should load onto my hub. Currently not looking to have multiple hubs, and not looking for a dip in performance, but im very interested in lux values (be it externally via APIXU or a device locally in my system)

14

I don't think multiple hubs should be on anyone's First Choice list :smiley:

It's a solution to problems you may never have. It's great to know the solution exists, though. :slight_smile:

The built in OpenWeather driver doesn't return Lux so you'll have to choose something else. This code is good for that. However, Lux is a calculated value. There are devices (Aeon MultiSensor6) that report Lux directly. I've read about people sticking one outside (like ME) and others that stick them against a window. For relative LUX (It's brighter now than it was, it's darker now...) those are great. I combine wx-ApiXU + a few Multisensor6's to set a virtual switch to "gloomy day" and adjust lighting accordingly.

21%20PM

I don't think this code hinders the Hub as much as the original. I hope to continue finding and reducing it's resource footprint. :slight_smile:

2 Likes
15

Thanks for this. I've updated.

@bangali mentioned in the WATO thread that he has been away for work, and is having difficulty VPN'ing into his home computer. So I doubt it's sicknesss, just travel.....

2 Likes
16

In addition to @csteele's comment, it may also depend what you want to do with the lux reading and how precise you want to be. In my case, I have an upstairs hallway that gets light through the front windows. I have a Zooz ZSE40 and a rule that says to turn on the hallway lights if there is motion and the lux < nn. If it's night or it's just really cloudy, the lights go on. Your use case may be different.

1 Like
17

I’ve had the apixu driver running on my hub for months and have never had issues with hub slowdowns/lockups etc. Not saying that it hasn’t caused issues for others, just that it’s entirely possible it can work without problems.

2 Likes
18

So now I have this installed, what cool things are people using this for / displaying the date?

19

There's no question that ApiXU-weather works correctly. If you have enough spare CPU cycles and nothing else wanting to use those cycles, like Z-something radios, then you will not see any problem. If, however, all those things are not true on your hub, and you would like to gain access to some CPU cycles so your Z-something radios send their commands to your Z-something switches and lights as fast as possible, then wx-ApiXU-driver might give you at least some of the boost you need.

2 Likes
20

More efficient coding is ALWAYS a plus in my book! Thanks for your work on this!

2 Likes