Looks like my editor put in an extra /div. Fixed that and played with it a little more, seems to work best as a 2x2 tile on the default dashboard; not sure how it responds in other settings.
Modified Code
def getTile(launch) {
def tile = "<div style='overflow:auto;'>"
def colorStyle = ""
if (textColor != "#000000") colorStyle = "color: $textColor"
if (!clearWhenInactive || (clearWhenInactive && !isInactive())) {
if (launch != null) {
tile = "<div style='padding:0px;height:75%;${colorStyle};'>"
tile += "<img src='${launch.patch}' style='width:75%; top:0px;' ></div>"
tile += "<div style='text-align:center;padding-top:-10%'>"
if (showName) tile += "<p>${launch.name}</p>"
tile += "<p>${launch.timeStr}</p>"
if (showRocket) tile += "<p>${launch.rocket}</p>"
if (showLocality) tile += "<p>${launch.locality}</p>"
if (launch.status != "Scheduled" && launch.status != null && launch.status != "null") tile += "<p>${launch.status}</p>"
tile += "</div>"
}
}
// If no launch to display, display nothing (keep dashboard clean)
return tile
}
Your tile code works good for the native hubitat dashboard. But for some reason it isn't displaying properly on Sharptools. I can't seem to figure out why or how to get it to be consistent with the native dashboard. Any idea?
I'm guessing the HTML structure is just different enough to cause issues. When you do a Right-Click Inspect on the tile what does the structure for it look like?
Given that the images are not consistent (they're not even uniformly square) I don't think there's a good solution outside of just putting the text directly below the image. Out of the example badges, only the current one has the whitespace at the bottom. The others have minimal to no bottom whitespace.
Otherwise you could design something where the text was overlaid on badge with an opaque background.
Yeah, I think this is just the way it is. Like you said, should be fine for most patches.
I played around with the negative margin. I got it to look good on both the HE native dashboard and the sharptools dashboard. So thanks. For whatever reason, it doesn't look the same on the device page. But I guess that doesn't so much matter does it? Don't imagine there's a way to make it look good too, huh?
I've identified an issue attributable to "partial dates" where Space-X doesn't know the exact date of an upcoming launch. For example, right now, the next launch will happen some time in September. The API codes this as the next launch being September 1, which may translate to August 31 depending on your time zone. So, right now it looks like the driver has to be wrong. In fact, it's working as intended, except I just need to account for this exceptional case of partial dates.
Have to figure out what makes sense to do in this case. If it's September 17, and the next launch is going to happen some unspecified date in September, what to display as the "next" launch date.....
The next launch time will be displayed with the level of precision specified by Space-X. So, for example, if the next launch will happen some time within September, the next launch time will just say “September” or “This Month”.
That shows the next launch indeed as being the USSF-44 on October 9.
What's happening here is that the Starlink launch date is not set to the day yet, at least according to the API. You can see that in the API response for the 'upcoming' call, where the date_precision for the Starlink launch is set to 'month', meaning that the launch will happen some time in October (not sure what day yet). The API response puts October 1 as the date and then puts 'month' precision to signify that the launch will happen at some point in October.
The Lift Off app puts the USSF-44 launch as being next, because it's date is actually set. When the day for the Starlink launch is actually set, i.e., date_precision is 'day' or 'hour', then the app will take that launch into account. Does that make sense and seem like a reasonable way to handle it to you?
EDIT: I do see what you're saying though as far as what's listed at SpaceX Rocket Launch Schedule - Space Launch Schedule. There it suggests that the Starlink 30 launch will definitely happen on Sept 29. I'm not sure why it's different, but perhaps because the launch day is fluctuating and/or because it's a 3rd party site. Either way, it looks like the app is handling what's coming from the API correctly. Will be interesting to watch this one and see how the API and that schedule online handle the launch dates.
How much time was there between push for launch and when you checked? It wasn't anything to do with this driver, but rather it was a matter of the quality of the data from the API. Does this suggest to you that the quality is questionable or outdated?
Not sure why, but my dashboard is still showing the wrong launch info. I don't know the elapsed time on the push/change vs. when I looked, but this AM is showing today (13th) rather than the actual plan which appears to be the 15th:
My guess is that it has something to do with how you are populating that tile with the launch time. The mission patch tile has the right launch time overlaid onto it (that reveals a different issue with the mission patch image sizing).
How are you populating that tile with 12/13 on it?
I assumed the "Last Updated" attibrute was the most recent update of the launch date/time. So my bad, obviously Last Updated is the date/time when the launch info was most recently updated.
