Looks good now here too. Thanks for your time on this as well.
OK chalk this one up to a mild case of OCD. It appears that the images for weather conditions are offset to the right a bit, is there anyway to easily make them centered?
Example for mytile:
Ok, can of worms time...
Capabilities have 'built in' Attributes. All Attributes other than the built-in have been Strings forever. To implement the change requested by @raidflex and @craigspree , I must break with History and define the Attributes correctly, to match what APIXU delivers.
I have to assume that this might break things.
For example, one of the more recent changes Bangali added was for Forecast Precipitation across +- 2 days. They are all Strings, but precipitation is a number, a number with a decimal point. There's no way to know how many people are using each Attribute and how Attributes that change to be numbers instead of strings will impact individuals.
My thinking of the moment is... Bangali's code works and for those that need Strings, who aren't ready to change automations that rely on them being strings should A) use Bangali's code or B) not upgrade past 1.1.9 until they're ready to migrate.
Any opinions on this?
Seems reasonable to offer the options. If someone doesn't want to reconfigure automations, stay put on 1.1.9, or use the original code. Now that RM offers "custom attributes" it seems like a definite feature to offer the content as a number so it can be used.
At this rate, there won't be much of a resemblance of the original code left! I'm sure this is becoming a bigger project than you expected, and we are grateful for your efforts.
No, not really.
If you display the image only in a browser (right click, view image) you'll see that the image is really, truly right shifted. It must be intentional from whomever built the Library of images.
Well that's a sign of someone with questionable sanity!
Kidding of course...
In my head, the original code has two major portions... the UI, that we users see -- what I think of as 'fronend'; and the interaction with the websites and Hub DB that is largely invisible -- what I think of as 'backend.' I was so focused on efficiency, I never looked at what the 'frontend' was doing. Today broke that I thought I had carefully kept my mitts off the 'frontend'. I reorganized it, grouped some together, but each line was intact from the original source.
Now that I'm looking... Ay yi yi
I rely upon a niche app by @Cobra that uses apixu rain to trigger a switch. So, I'll punt your question to Andy.
Decimal is fine
The app actually converts the string to a decimal as you can’t multiply a string
-- == 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.
GitHub has all prior versions. Open the repository and click History. You will see the list of updates and on the far right of v1.1.9 is a button with < >
Click that button and you can get to the Raw code. Copy it and paste it into your Driver Code. (You cannot use Import because Import gets the very latest version.)
There is also a Branch called master119 that is the same code.
Here’s the list of Attributes that have changed and the Type (Float or Integer) they are now:
The remaining Attributes are unchanged, still Strings:
Thanks for the update. It did indeed break some of my rules, which I didnt think it would....so there's that. But it's now fixed. Also, it rationalises some of my rules too, since I was needing work arounds as strings could not be compared (<, > etc). This helps a lot. Thanks!
Hi @csteele and anyone else using this superb driver.
With the original driver occasionally, and by that maybe every other day maybe, I would see the lux level report 5. Basically its dark. (it's bright sunshine at the moment, or it was ). The next poll would seem to update it to its correct level.
Today with this driver I've noticed that it seems to keep reporting 5 on and off through the day.
Anyone else seeing these issues?
EDIT: Just to add to the plot, if I switch back to bangalis driver and save preferences it shows the correct value. Toggle back to this driver and it shows 5 again. I'm using the same API key, virtual device etc. just switching the driver.
I checked my logs and I didn;t notice any lux going from brite to dark... but i did see large gaps of reporting. say 5-6 hours during the night. and they happened to report 5 as the first lux value.
I noted this too, just started with 1.2 I believe.
Bangali's equation for lux has a minimum level of 5. Therefore 5 is saying "dark of night." I don't know why it is 5 and not, say 4 or 6.666, but that's what it's coded to do. I didn't alter that Yet.
Lux cares about sunrise time, sunset time, noon time and current time. It uses those values to determine the sun's potential brightness. It then takes 'cloud cover factor (cCF)' to reduce the potential brightness to the calculated Lux value.
If you turn on Debugs, you should see this set of logs:
dev:10 2019-06-27 04:50:10.687 pm debug illuminated dev:10 2019-06-27 04:50:10.681 pm debug cCF dev:10 2019-06-27 04:50:10.678 pm debug condition: 1000 | condition text: Sunny | condition factor: 1 | lux: 4480 dev:10 2019-06-27 04:50:10.675 pm debug between noon and sunset dev:10 2019-06-27 04:50:10.671 pm info wx-ApiXU lux calc for: 90001
IF sunrise/sunset doesn't yet exist, Lux gets skipped and this log entry should tell you that:
dev:10 2019-06-27 04:50:10.671 pm info no wx-ApiXU lux without sunRiseSet value. dev:10 2019-06-27 04:50:10.671 pm info wx-ApiXU lux calc for: 90001
If you get that message, sunRiseSet is called immediately.
THAT is one of the "backend" items I changed completely... Clearly Sunrise and Sunset don't change very much at all day by day.. getting new values 96 times a day. (15 mins = 4 per hour, 24hrs a day = 96 visits to the same website.)
I altered the code to acquire sunrise/set values once per day, just after midnight AND anytime the values are "empty."
My logs show Lux is reducing, as the sun begins to set over the last 15 mins:
dev:10 2019-06-27 04:59:19.135 pm debug illuminated dev:10 2019-06-27 04:59:19.132 pm debug cCF dev:10 2019-06-27 04:59:19.128 pm debug condition: 1000 | condition text: Sunny | condition factor: 1 | lux: 4268 dev:10 2019-06-27 04:59:19.125 pm debug between noon and sunset dev:10 2019-06-27 04:59:19.120 pm info wx-ApiXU lux calc for: 90001 dev:10 2019-06-27 04:54:19.128 pm debug illuminated dev:10 2019-06-27 04:54:19.125 pm debug cCF dev:10 2019-06-27 04:54:19.120 pm debug condition: 1000 | condition text: Sunny | condition factor: 1 | lux: 4384 dev:10 2019-06-27 04:54:19.116 pm debug between noon and sunset dev:10 2019-06-27 04:54:19.110 pm info wx-ApiXU lux calc for: 90001 dev:10 2019-06-27 04:53:21.903 pm info skip wx-ApiXU forecast precip dev:10 2019-06-27 04:53:21.900 pm debug illuminated dev:10 2019-06-27 04:53:21.897 pm debug cCF dev:10 2019-06-27 04:53:21.894 pm debug condition: 1000 | condition text: Sunny | condition factor: 1 | lux: 4406 dev:10 2019-06-27 04:53:21.891 pm debug between noon and sunset dev:10 2019-06-27 04:53:21.884 pm info wx-ApiXU lux calc for: 90001
4406 --> 4384 --> 4268
I've added some debug code to my instance to track Lux in my Logs... I'll see if I can duplicate it.
Wikipedia has this table:
...suggesting that 3.4 would be a "better" than 5 but really... 5 is quite good enough for RM comparisons.
I appreciate that 5 'is just a number' and could be anything really. It's all relative.
I'll turn logging on and see whats happening.
Thanks for the quick response.
EDIT : Not sure what is going on but as soon as I turned on debug logging it started to work. I have been hitting the using the save preferences button to give 'it a kick' so I don't think it is hitting the save button that started things working but who knows.
I've also been toggling between the 2 drivers and one was working and one wasn't. Spooky?
Save Preferences does indeed restart everything.
The existing schedules all get cleared then added back (created) again. (Polling once per day at 12:10 + 8 on Fridays for Cobra's Update Check + Auto debug stop + auto 'roll-up" + Poll every N minutes + poll Lux every L mins) Then a Poll is run and 2 seconds later Sunrise/Set runs.
So, basically one of everything occurs at "Save Preferences" - the entire driver is restarted.
What's different from Bangali's ??
Not much: 1) Cobra's Update Check. 2) sunrise/sunset runs on every poll 3) auto debug and auto rollup don't exist.
I have 672 lines of logging from overnight. Nothing interesting in it except a) Lux ran every 5 mins as expected. b) Lux = 5 occurred at 9:48pm and repeated every 5 min til 4:23am, rapidly rising and crossed over 100 at 5:53am.
It's still running, of course, and I'll look every few hours to verify I don't see any 'odd' lux readings, especially 5's.
Would it be possible to reduce the lux polling overnight? Say when it's 5?