@josh Any chance the Premium Album Art Title accepts any other image format aside from when delivered in a ‘contentType: image/jpeg’ or ‘contentType: image/gif’? Those require the data to be sent as binary data and I can get them to work fine.
I am hoping that I could use a ‘contentType: text/html’ and send the image as a data URI as a workaround to this known Hubitat issue with Cloud Endpoints.
The Album Art tile uses a regular image tag in the browser, so it basically supports any image format that a browser supports (JPEG, PNG, WebP, GIF, MJPEG, etc).
Can you share a bit more about what you’re trying to accomplish? Perhaps there’s another way to accomplish it.
The Hubitat cloud api does not pass a binary HTTP like content-type ‘image/jpeg’, but it works fine via the local api.
However it does pass non-binary base64 image. So you can send an image though a HTML doc (this is a SVG example) and it will display on any browser.
I am attempting to pass an image up from the hub for display on the dashboard, and it only works locally because of these limitations.
What does work is the Refreshable URL Embed you described here which is great, but it use polling and I am attempting to drive the update via a Hubitat event for real time updates. Anyway to hook to objects for events?
Thanks for the reply. My apologies as I should have been clear. I read through the linked post and see that you are trying to push image data across the Hubitat cloud endpoints and that wasn’t working, so you were looking at a workaround of pushing alternative content types…
…but I’m still not clear what the broader goal is. You mentioned that you are trying to pass images up from the hub for display - do you mean files stored in the hub’s local storage? What’s the broader purpose?
For serving images, a common alternative is to store (or dynamically push) the files online somewhere (eg. GitHub) and then point to those. Is there something about that approach that doesn’t work for your setup?
As a side note, I recommend against storing binary large objects (blobs) within device attributes. It’s really not what the device model was intended for and can cause all sorts of headaches. It’s generally better to point to something that serves up the file rather than trying to stuff it into attribute data.
I do have an AWS API Gateway setup that will upload under SSL into a AWS Lambda to AWS S3. It returns a public HTTPS location with a random UUID, which is very secure. I am working now with AWS Rekognition to determine who walked in front of the camera and do things even more fun.
But you guessed it, I am storing images in an image attribute from a FKB driver. Actually moving it to a second C7 Hubitat hub for the reason you state. The image manipulation and resting state size isn’t optimal. I needed to reduce the event history size to prevent the database from getting out of control.
This entire thing is more of a pet project attempting todo something that hasn’t been done, then an actual use case. However, if they do complete the groovy API to allow access to the local storage (like in Rules Engine), it would be a very valid request. The SmartApp works very well with both the AWS S3 image and the Local API image with the Album Art tile.
