OpenWeatherMap-Alerts-Weather-Driver

bdydrp · October 30, 2020, 1:09am

Update to latest, and everything seems to match OWM!
Great work with this driver!!

Matthew · October 30, 2020, 3:30pm

[UPDATED]
v0.4.4
10/30/2020

Changes:

More code cleanups/reductions/optimizations by @nh.schottfam

SPECIAL NOTE IF YOU ARE UPDATING FROM A VERSION PRIOR TO V0.3.2:
(not required if you have version V.0.3.2 or higher already installed or you are doing a first time install)

The suggested updated method with HPM is to do a new install with the new driver (without the 'NWS' in the filename. Once installed, go to your virtual device and update the driver to use the new driver. You can use HPM to delete the old driver as follows: Do an 'Uninstall. If there are two drivers listed with the same name, click on the first "OpenWeatherMap-Alerts Weather Driver". The app asked if I wanted to delete "OpenWeatherMap- NWS -Alerts Weather Driver". Should you pick the wrong one (the one WITHOUT 'NWS' in the name), cancel and retry with the other selection. (Thanks @arnb for those details).

If you do not use HPM then since the filename and the directory name has changed you will need to copy the code and paste it over your current driver. (You cannot use the ImportURL for this this one time because the name and location has changed). Once installed, go to your virtual device and check/update the driver to make sure it is using the new driver.

Angus_M · October 31, 2020, 3:56am

Yes, it's an RM error. I tried to switch out the Darksky driver for this one and it screwed my rule up unfortunately (I simply went through the rule and switched the device). I thought that would work but unfortunately not. It seems I will have to rebuild the rule.

tivomaniac · October 31, 2020, 11:47am

Can you restore your last backup to get the rule back without rebuilding it?

Angus_M · October 31, 2020, 1:35pm

Yeah, actually I tried this but the restore failed. Now I'm away from home. Will try again when I get back with an older backup or rebuild the rule. Not a huge headache, so it's ok.

arnb · October 31, 2020, 2:39pm

Matthew
Could you please add a bool switch allowing for an alternate display of the Precip & POP. I much prefer the version I'm using. It's only few lines of code, has an imbedded space for a browser generated line break, and makes it easier (for me) to read.

Sample code changes
Proposed

my3day += sTD + (myGetData('Precip0').toBigDecimal() > 0 ?
String.format(ddisp_r, myGetData('Precip0').toBigDecimal()) + myGetData(sRMETR) + sSPC + '('+ myGetData('PoP') +'%)' : 'None') + sTDE

Current

my3day += sTD + myGetData('PoP') + '%/' + (myGetData('Precip0').toBigDecimal() > 0 ? String.format(ddisp_r, myGetData('Precip0').toBigDecimal()) + myGetData(sRMETR) : 'None') + sSPC + sTDE

Matthew · October 31, 2020, 3:45pm

I don't like that for several reasons: 1) if there no precip forecasted then it will just show 'None'. I don't know for sure, but I would assume that even if there is no accumulation forecasted thare may be instances when there is a >0% PoP, and if that is possible, this would not show it; and 2) you are reversing the order from the row title (from 'POP/Precip:' to 'Precip/PoP:')

I would propose to just replace the '/' with a space so your browser could generate the line break you desire.

Try this an let me know it it will work for your small screen.

		my3day += '<tr>'
		my3day += sTD+'PoP Precip:'+sTDE
		my3day += sTD + myGetData('PoP') + '% ' + (myGetData('Precip0').toBigDecimal() > 0 ? String.format(ddisp_r, myGetData('Precip0').toBigDecimal()) + myGetData(sRMETR) : 'None') + sTDE
		my3day += sTD + myGetData('PoP1') + '% ' + (myGetData('Precip1').toBigDecimal() > 0 ? String.format(ddisp_r, myGetData('Precip1').toBigDecimal()) + myGetData(sRMETR) : 'None') + sTDE
		my3day += sTD + myGetData('PoP2') + '% ' + (myGetData('Precip2').toBigDecimal() > 0 ? String.format(ddisp_r, myGetData('Precip2').toBigDecimal()) + myGetData(sRMETR) : 'None') + sTDE
		my3day += '</tr>'

arnb · October 31, 2020, 4:42pm

Thank you Mathew. That works for me. It also confirms your concern there can be a chance of precip with no accumulation.

How it displays on my dashboard

Note: did not adjust the PoP/Precip and Low/High text for my test. However I did change it later, and it really improves the brower's use of limited screen real estate eliminating the horizontal scroll bar on my Windows system.

Matthew · October 31, 2020, 8:29pm

[UPDATED]
v0.4.5
10/31/2020

Changes:

Tweaked threedayfcstTile for small screens.

nclark · November 1, 2020, 11:37pm

Just noticed that the high/low on my screen does not have the slash in between the words nor the temperatures, but just space (high low). Could this be a bug introduced with the tweak for small screens?

thebearmay · November 1, 2020, 11:54pm

Believe it was an intentional change...

nclark · November 2, 2020, 12:05am

After reading a bit higher, noticed that also. @Matthew, could this be switch (again) or even better, a field with the separator used for high/low display? The separator could also be a control character like a < br > code or something.

Matthew · November 2, 2020, 2:22am

It could be .... but at this time I choose to not to add additional complexity to accommodate every variation of possible options. The driver was never in tended to be able to accommodate every variation of stylistic desires. If the '/', or other separator character or control code, is important enough for a user then they could edit their copy of the code to put it in easily enough.

Thanks.

bbholthome · November 4, 2020, 3:24pm

Hi @Matthew,
I'm having some difficulty upgrading to the newest version. After some work with no success I have completely uninstalled the old version and installed the new.
I'm not sure if the device page has changed but this is what I'm seeing.

Many of the options are gone. I removed the api key in the snapshot but is there for testing.
The is an error during the api call

dev:30602020-11-04 10:03:58.077 am warnOpenWeatherMap - getWeather() execption java.net.URISyntaxException: Illegal character in query at index 55: https://api.openweathermap.org/data/2.5/weather?zip=N0M 1G0,CA&APPID=xxxxxx
&units=metric

The Zip code (actually a postal code) has a space in it. Probably the space is the issue. The N0M 1G0 was the value I used with the previous version and worked well. I never populated that field in the new install so I don't know where it's coming from.

Matthew · November 4, 2020, 7:49pm

The screen shot looks to be the standard (integrated) OWM driver, not the customer driver in this thread, Use the link in the first post, or HPM to install the custom driver.

bbholthome · November 4, 2020, 8:34pm

OMG how stupid do I feel now? Thanks for the response and for the app.

kevin6 · November 5, 2020, 2:22am

Have been looking hard for an external weather solution and this driver is fantastic! Thanks, @Matthew, great job on this.

arnb · November 5, 2020, 4:48pm

I understand saving as many characters as possible on the big tiles with long urls, however, at the moment using using /tinyurl.com/y42s2ndy vs Weather forecast - OpenWeatherMap saves exactly 3 characters and forces a link to a second cloud site. I understand you want to use this, but for those of us who prefer otherwise, please consider a flag to select using tinyurl, or not.

Additionally, when clicking on the MyTile tinyurl link, I've been seeing more London, GB weather than expected, and sometimes my local city with a London radar map. I'm aware this is likely a OWM issue, but in theory this should not occur when the OWM city code is set. What I've done for now is change my MyTile link to Weather forecast - OpenWeatherMap. Hopefully it shows my selected city 100% of the time. Is anyone else having this issue?

Update: After closely examining the threedayfcstTile and having it come in at 1018 characters, I understand why tinyurl is being with the current html.

Should additional space be needed, the closing </tr> and </td> tags are optional and may be safely removed saving ~165 bytes of data. With tinyurl used ~9 times, using this technique with openweather.org would result in a net savings of ~128 bytes and remove ~9 doubled cloud links.

Matthew · November 5, 2020, 6:26pm

I am interested too if anyone is have an issue with tinyurl. I have not experienced that. That service just forwards to the designated url. I do see the "/tinyurl.com/y42s2ndy/{citycode}" flash very briefly in my browser then it is replaced almost immediately with the "/openweathermap.org/city/{citycode}" url. I presume the issue with OWM not showing your correct city or radar is an OWM issue, not related to tinyurl, but you could test that. You would have to go into the code and look for the 'tinyurl.com' instances in the myTile section and replace those with the direct openweathermap.org url and see if your issue persists or not.

Yes, I know that specific tinyurl only save 3 characters ..... but every character saved helps to preserve the information and formatting going into the tile. Yes, I know there is a desire to avoid unnecessary cloud access, but until we can definitively show that tinyurl is causing a problem, I am not inclined to stop using that service. IMHO, I believe the benefits of using tinyurl out weight the detriments, again, at least until we can definitively show that tinyurl is causing a problem. YMMV.

Thanks.

arnb · November 5, 2020, 7:10pm

You are correct. I overlooked that other tinyurl links besides "/tinyurl.com/y42s2ndy/{citycode}" are used saving a significant amount of space. For example
https://tinyurl.com/y6xrbhpf/26.png
becomes
https://raw.githubusercontent.com/HubitatCommunity/WeatherIcons/master/26.png

I amend my request to change only "/tinyurl.com/y42s2ndy/{citycode}". Also consider eliminating the </tr> and </td> elements should you need or want additional space.

Regarding seeing London, GB weather on my local weather page: I have no idea why that occurs, however it is only in browsers, including Fully and Vivaldi, that don't have 100% functional location services. I've changed the link on the myTile link.

I thought once the location was established or provided, it would be saved in a long term cookie. That's not true, OWM uses Session cookies (actually a good thing), but that does not explain why it occasionally fails with a valid citycode. I will let you know if changing the "/tinyurl.com/y42s2ndy/{citycode}" does anything.

Thank you