Base64 in image source

fixed
#48

awesome, thanks a bunch. we’ll give that a shot and let you know. I appreciate you looking into this for us.

#49

Thanks @ipaterson, I think that resolved it.
In my test, I removed the refresh=300 completely…
and about 6 or 7 seconds after the piston ran,
the tile image updated smoothly!!!

Well done, and thanks so much for helping!!

#50

I’ve changed the thread tag to “fixed” (again)… let me know if I was premature (again) but I think @ipaterson has worked his magic nicely on this one!!

Love a happy ending :smile:

#51

That’s great! I think that rounds out the next release, so I’ll get that up to the live dashboard for everyone later this week.

It should still work fine without removing the refresh, to clarify what I posted earlier the refresh is not actually “disabled.” It will continue to run the function that refreshes the image at the interval you specify, but that function will detect and avoid modifying any image with a data url. So theoretically if you had a tile where the piston periodically switched between a data url and a normal web accessible image the dashboard would still try to refresh the web image at the specified interval.

There is a possibility that this change could affect people using normal images. Let’s say you have a piston that runs every 5 minutes and it happens to update the tile to the same URL every time it runs. In that tile you have an image that refreshes every 1 minute. The refresh is performed by adding a parameter to the URL to ensure that the browser does not reload a cached image and in the past since that original image url never updated once you loaded the dashboard. Now every 5 minutes the piston is [potentially, I haven’t tested this] setting the image back to the original URL there may be a “glitchiness” where the image reverts back to an old cached copy before the next refresh interval fires and loads it with a new URL.

The other consideration is whether that osrc property will not allow refreshing web images to be changed by the piston. I have a bit more research here before I can call this done but glad it’s on the right track!

#52

This turned out to not be a concern; Angular will not reset the image unless the URL provided by the piston changes. The refresh remains in control if the piston repeatedly sets the same image URL.

Tested with https://picsum.photos/ e.g. https://picsum.photos/200/?random

This one is a concern, the osrc is never updated so when a piston changes the URL for an image with repeat set it will revert to the previous at the next repeat. I fixed it on staging by updating this osrc if the current img.src does not contain the webCoRE cachebuster refresh parameter. Tested with a piston setting an alternating parameter https://picsum.photos/200/?random&x=0 https://picsum.photos/200/?random&x=1 back and forth.

Please refresh your staging dashboards and let me know if you see anything else that raises concern before this is released. Thanks for reporting and following up!

#53

Yes, I would say magic is definitely an understatement. Thanks a lot to both of you. @ipaterson, we will keep an eye on both versions. we will leave the URL for the saved image enabled for a whole and continue testing the data images. Since or URL call fits the description of your concern, we should hopefully see any issue if there is one.

I have big plans for the data images, working on ways for the PHP to draw all kinds of things from graphs, to weather conditions, to home conditions. The design is still in its primitive stages, but I will post when I have something usable.

thanks again for your help! I’m brand new to webcore, but I have plans to start digging through the webcore code this weekend.

#54

This should be fixed in today’s v0.3.104.20180323 release which will require updating your smartapps at ide.smartthings.com and possibly hard refreshing the dashboard.