My code below doesn’t change the url list of my image gallery widget at all. Is this widget still in Beta?
Blynk.setProperty(V_IMAGE, "urls", "https://s3-us-west-1.amazonaws.com/foo/captures/" + filename + ".jpg");
Blynk.virtualWrite(V_IMAGE, 1);
Also tried Blynk.setProperty(V_IMAGE, "urls", 1, "https://s3-us-west-1.amazonaws.com/foo/captures/" + filename + ".jpg");
“urls” or “url” was never an available setProperty command… someone just assumed it might be in another post… but unfortunately it is not.
Hopefully it or something like that will arrive, but who knows.
Ohhh… nice… 
… looks like that might have been added in last update… only 2 days after that post I linked to above.
But if you are unable to get it to work, then either it is not yet fully supported (may need a Library update?) or you are missing something else needed. If you are Local Server make sure it is also updated.
I am going to check this out on my end now 
This will be a nice addition as I get tired of manually uploading the 13 images I have in one project.
Ah, ok. 
Yeah, I don’t think that code is doing anything on the app side. The URL is valid and accessible from the client. I checked my library and it’s up to the latest (although I would imagine that Blynk.setProperty() didn’t need to change).
Also, I actually can’t save the URL of a static image in the app. The Add Image button is greyed out.
I wrote a bunch of backend code to use this new widget so it’d be great to get it working!
Well so far, using Local Server and latest Android & iOS Beta Apps, the “urls” option of populating all (applicable) image fields seems to sorta work (only testing with a couple of images so far).
But, It doesn’t always fill all the images properly, even if the URL is loaded. However, I am thinking that is related to another issue, as sometimes I have the same results when manually entering a URL…
Exiting and restarting the App seems to help (I also added another image and reflashed my sketch).
BLYNK_CONNECTED() {
Blynk.setProperty(V4, "urls", "http://10.10.3.13:8000/awakish.png", "http://10.10.3.13:8000/sleeping.png", "http://10.10.3.13:8000/Black_and_Grey_Fan.png");
}
That might mean your URL is not actually reachable from the App??
My iOs test seems to work OK… but then I am pulling from a folder on the same PC as my Local Server
You might want to test with a solid URL and save the piecing together of strings for a later test?
Hmm, so this might have something to do with the fact that my URLs are non-canonicalized and the client is not liking them. e.g., I’m sending it ...2018-12-21-02:59:01.jpg (notice the :s), but should be sending it 2018-12-21-02%3A59%3A01.jpg.
So that was part of it, but it still doesn’t work. I got rid of colons in the URL, but repeated calls to Blynk.setProperty(V_IMAGE, "urls", "https://domain.com/image.jpg"); only work once. It doesn’t seem to overwrite URLs in the list. If I manually delete a URL in the client app, it’ll get set by Blynk.setProperty but not overwritten on the next instance.
Any workarounds to make this work?
Hmmm, it does for my test projects… but then I am using different images (and thus differning file names) each time. If you keep the same file name, but somehow change the image associated to that name, then yes, I can see how that will not change. The App goes by the file name, not the content of such.
No, it’s always a unique URL based on a timestamp. I’ve tested the URL from Safari on the same phone as the Blynk client app runs so it’s a valid, reachable one.
An example URL is https://s3-us-west-1.amazonaws.com/my_bucket/captures/2019-01-03-00-38-27.jpg (my_bucket is redacted). As I mentioned, if I delete the URL in the list in the client app, it gets set once, but subsequent calls to Blynk.setProperty() don’t overwrite the list.
(Addendum to original reply):
Looks like I need to either stop/start the app, or kill Blynk and restart for the URL to change, so that’s at least progress! Any way to force a widget update though?
Ahh, yes… sounds like with my “blank image” observations.
Not that I am aware of… but it is still in beta, so we can only wait and see how it works after next update.
Cool. My use case for on-app-load image widget updates is showing the latest capture of my security camera right after Blynk sends me a notification. Would be great to get that working eventually.
Thanks and keep up the good work!
Any official word on the state of Image Gallery? I was able to successfully add 36 images (i.e., URL’s) via the Blynk app / Image Settings. Blynk started crashing around image 37. I’m unable to add / modify a URL using Blynk.setProperty. However, I am able to address / apply the first 36 URL’s using Blynk.virtualWrite. Very cool. Now if I could just add four more URL’s I’d be golden.
iPhone 6+ / iOS 12.1.2
Blynk 2.25.0 (3)
Joe
Looks like modifying url(s) via setProperty is absent in 2.25.0 (3). Will be in next update.
Didn’t get any crash logs. Are there any details? Maybe this is specific to the url you’re trying to add?
I was finally able to successfully add 41 unique URL’s using Image Settings. I first added the same URL 41 times. I then edited each URL starting with index 41 working backwards. After editing the URL corresponding to index 1, I exited Image Settings by clicking on OK. I was able to display all 41 URL’s from the hardware using Blynk.virtualWrite. However, now Blynk crashes every time I access Image Settings.
I don’t think the issue is specific to a URL. Image Settings validates (pings?) each URL and successfully previews the corresponding image. All of my images have a similar URL and are hosted on the same server.
I think the issue is simply related to the number of URL’s / indices. Like I said, things go smoothly up until around index 36, then things start to go South.
I’ve attempted to send logs. Please let me know if the logs don’t contain the information you need.
Joe
I’ve got a crash logs which I think might be yours (although there were only 3 items in the image list in the crash report.
Anyway, there is a crash if you remove the image url from the middle of the list and then go to edit the last one.
