Thank you and Sorry.
1 Like
No problem, we will get this sorted out.
The data is there and I just typed it in and the icon came up.
So let me dig in a little. Be back in a while. 
Thank you and not a major deal. Just see if it was bug or something I did wrong.
I just installed this and it looks like everything is working for me 
It will take a bunch of fiddling to get it perfectly designed for my tablet displays, but I see this working really well! 
I completely removed it and reinstalled it. Thus, so far it looks good now. I'll try rebooting the hub and see if that makes any difference.
1 Like
Today the forecastTable1 is too big in the Weather Dot Gov Child app:
Today - Isolated rain showers before 2pm. Mostly cloudy, with a high near 70. South wind 6 to 15 mph, with gusts as high as 25 mph. Chance of precipitation is 20%.
Tonight - Rain showers between 8pm and 2am, then showers and thunderstorms. Cloudy, with a low around 58. South wind 12 to 20 mph, with gusts as high as 32 mph. Chance of precipitation is 100%. New rainfall amounts between a half and three quarters of an inch possible.
Monday - Showers and thunderstorms before 2pm, then a chance of showers and thunderstorms between 2pm and 5pm. Mostly cloudy, with a high near 76. Southwest wind 20 to 24 mph, with gusts as high as 51 mph. Chance of precipitation is 100%. New rainfall amounts between 1 and 2 inches possible.
Monday Night - Mostly clear, with a low around 43. West wind 7 to 20 mph, with gusts as high as 32 mph. New rainfall amounts less than a tenth of an inch possible.
Tile Count: 1128
That results in a warning in the log:
app:35|2020-04-12 10:47:46.619 am|warn|Excluded attribute forecastTable1 size of attribute > 1024 characters
And I get nothing in my forecastTable1 tile. It just has "Please Select an Attribute."
I tracked the problem to getWeeklyData(evt), where the table gets generated. It looks like there needs to be some logic to calculate the length of forecastTable[1234] and truncate the last wDetailedForecast if necessary. Unless it's possible to get Dashboard to take a longer string.
I guess the easiest thing would be to figure out a max length for each day, assuming they all have max length, and truncate wDetailedForecast (maybe adding ellipsis to indicate that). Unfortunately, that would do a lot of unnecessary truncation. Just seems like the quickest fix given the iteration. I'd rather have something truncated there than "Please Select an Attribute."
Maybe it would be no problem to calculate what the total would be if the string concatenation were to occur, then truncate the wDetailedForecast if necessary. (Possibly not including wName, either, I suppose, if it's really long.) Just was thinking of an easy way to keep all the calculations inside each iteration.
lol, you put waaaay to much thought into something very simple. 
New version on Github...
Child:
V1.0.2 - 04/12/20 - Fixed Forecast from exceeding the 1024 limit
Won't that fix be a problem for the HTML closure tags? If you truncate forecastTable[1234] at the end, you would remove (potentially part of) </table>, and also (part of) </small></td></tr>
I had the same thought at first, but then looked at what would get truncated and realized it would be a problem.
New version on Github...
Please update child app and Tile driver
I just looked at the new code, and it seems like it will create malformed HTML. I don't see </td></tr> getting added to any of the table rows. I'm pretty sure a lot of browsers will handle that kind of mistake OK, but it is not good HTML and may be broken in some user agents.
Maybe using your current idea for forecastTable1, you could add </td></tr> at the beginning for (x >= 1 && x <= 2), then do
forecastTable1a = forecastTable1.take(1005)
forecastTable1a += "</td></tr></table>"
outside the iterations.
That could still fail if the first or second day was really long, but is much less likely to fail. I guess it's easier to just put the idea here:
if(smallTileF) { if(x == 0) forecastTable1 = "<table width=100% align=left style='text-align:left;font-size:${sF}px'><tr><td><b>${wName}</b> - ${wDetailedForecast}" }
if(!smallTileF) { if(x == 0) forecastTable1 = "<table width=100% align=left style='text-align:left'><tr><td><b>${wName}</b> - ${wDetailedForecast}" }
if(x >= 1 && x <= 2) forecastTable1 += "</td></tr><tr><td><b>${wName}</b> - ${wDetailedForecast}"
and
if(forecastTable1) {
forecastTable1a = forecastTable1.take(1005)
forecastTable1a += "</td></tr></table>"
tileDevice.forecastData1(forecastTable1a)
}
That seems safer, and should only fail in really extreme cases.
How are you calculating wind speed? Reason I ask, it last night we had winds of 30-40 MPH. It was showing nowhere near that.
Right now, the actual wind is 17 MPH or so, but the app is showing 4.78. So I got to looking and if I am reading correctly, I think the dataset returns the value in m/s but does your driver calculate windspeed using km/s to mph?
Line 327
kphTOmph(xwindSpeed)
Here is the dataset return for windspeed from the weather.gov api
"windSpeed": {
"value": 7.7000000000000002,
"unitCode": "unit:m_s-1",
"qualityControl": "qc:V"
},
I found an online converter to convert meters per second to miles per hour and it works out.
1 Like
Please do some research on this. This is not a mistake. Both </td> and </tr> are optional in HTML. The code is valid.
I'm used to writing XHTML. I actually hadn't noticed that Hubitat writes HTML rather than XHTML.
1 Like
To test this I went back to 4 detailed forecasts per table (and moved the text-align and font-size to the table tag to reduce repetition). That actually hit the limit for me right now. I also didn't think the table needed align=left with width=100%, which was a further reduction in characters. It works well!
if(smallTileF) { if(x == 0) forecastTable1 = "<table width=100% style='text-align:left;font-size:${sF}px'>" }
if(!smallTileF) { if(x == 0) forecastTable1 = "<table width=100% style='text-align:left'>" }
if(x >= 0 && x <= 3) forecastTable1 += "<tr><td><b>${wName}</b> - ${wDetailedForecast}"
and
if(forecastTable1) {
if(forecastTable1.length() > 1015){
forecastTable1a = forecastTable1.take(1012)
forecastTable1a += "..."
} else {
forecastTable1a = forecastTable1
}
forecastTable1a += "</table>"
tileDevice.forecastData1(forecastTable1a)
}
Gave me:
Thanks, fixed in new version
Data Driver:
V1.0.1 - 04/13/20 - Fixed Wind speed, precipitation calculations
That fixed it. Thanks!
Maybe the reported wind speed unit depends on the station.
If they always report in m/s, it would be a really easy fix in the WDG data driver:
def xwindSpeed = response.data.properties.windSpeed.value * 3.6
My station reported m/s, also:
"windSpeed": {
"value": 4.5999999999999996,
"unitCode": "unit:m_s-1",
"qualityControl": "qc:V"
},
