Does opacity work for the image widget?
hey, upgrading is just re-running the installer from the magic-frame folder:
cd magic-frame
./deploy/install.sh
it pulls the new version, grabs the latest images and restarts.
Your data, login and settings all stay.
two things in there, both fair:
-
"opacity" that slider is the shared tile-background opacity, not an image
opacity. on the image widget the photo fills the whole tile and sits in front
of it, so the slider does nothing visible. confusing, not on purpose
i'll hide it on the image/camera widgets. tracked in #39. -
the black bars are the real thing though — that's the fit setting. right now
it's either "fill" (crops to the tile, no bars) or "fit" (whole image, but bars
when a portrait photo sits in a landscape tile - what you've got). so it's
crop-or-bars at the moment.
the proper fix is a third option: keep the whole image sharp and fill the bars
with a blurred version of the same photo instead of black .. like instagram /
video players do with portrait clips. tracked in #38
I spun this up yesterday and it already goes a long way towards replacing the google home max I was using before.
A couple of things that I have run into:
I have a camera feed pop on detection of a person but I can't seem to make the camera feed go full screen. It is only as large as the card allows, as defined in the view editor, unless I click it. I would love the option for the camera feed to go fullscreen, on top of my immich gallery, without me needing to touch the card.
I have immich connected and the wallpaper is working as expected but I haven't been able to get the meta data to show up. I tried to enable a minimal number of API keys from immich as well as all keys but neither worked to show picture metadata. Not sure if this is a bug or if I am doing something wrong.
The last thing that would be nice to have is a live preview of buttons or notifications in the settings menu. Right now, I need to guess a little bit at what each slider does, then close the settings, save and look at the dashboard to see what I changed. Doing it live would reduce the need to go back and forth a bit. Something like the card editor in home assistant where you have the live preview next to the card settings.
Thanks again for building this and sharing it out!
hey thanks alot 
-
camera fullscreen on trigger, realy good one and youre actually the second
person asking for it.
making it go fullscreen on trigger over the gallery without touching anything is
exactly how it should work. tracked in #41 -
the metadata thing isnt the api keys, those only control access (your photos
load so access is fine). two things to check. first in the wallpaper settings
turn on "show metadata / EXIF", the date shows for basicly any photo (it falls
back to the file date), camera and gps only when the photo actually has that
exif. second and probably your case, if you use a split/grid wallpaper with
multiple photos the metadata bar is hidden there on purpose, it only makes sense
for a single image. set it to single image and it should show up. lmk if its
still missing -
live preview in the inspector, yeah the back and forth is annoying. its on my
list but a bit tricky, views can have different sizes so the preview wouldnt
really be 1:1, need to think about how to do it right. but i want it.
thanks again, this kind of feedback realy helps
-
Great to see that in the pipeline!
-
Got it. The dialogs don't currently make that clear. When I switched to single photo, the meta data does start to show up. Would it be possible to enable it for auto split view? On my google home max, it just ends up showing the meta data for both pictures one on top of the other in the bottom right.
For example:
Jul 23, 2023, Anchorage
Apr 1, 2022, Seattle
I have a mix of landscape and portrait photos so the auto side by side is quite nice.
Could an option be added to remove the timer when metadata is shown? When I switched to single image so that I could see the meta data, it was kind of nice to have the blur so that the meta data text stood out but it blocked the full bottom edge of the pictures mostly to show the timer wheel. Maybe the timer where can be an option as well as the width or position of the meta data panel? Justified left or right?
- Understood, this is a tough ask. Even if to start the preview gave a representation so that you could see what the sliders actually did in real time to a representative button could be quite helpful.
Thanks again for taking a look at the suggestions and building this.
I have magic frame up and running but am having troubles connecting to my google calendar. When setting up an OAuth app google says local address are no longer allowed.
Has anyone had success linking their google calendar?
@krmurphy google stopped accepting plain local addresses (private ips, .local etc) as
oauth redirect uris a while ago, they want https + a real domain. the trick
most people miss: the domain does NOT have to be reachable from the internet.
google only checks the format, the redirect happens inside your own browser,
so the domain just needs to resolve to your magic frame box inside your network.
the whole thing is doable in the magic frame gui:
-
grab a free ddns domain (duckdns works) or a cloudflare domain, point it at
your magic frames LAN ip -
settings -> hosting & network: enter the domain, pick dns challenge + your
provider (duckdns, cloudflare etc are built in), save. caddy fetches a real
https cert via dns, no open ports needed -
open the editor via https://yourname.duckdns.org and connect google there,
the redirect url is derived from the domain automatically -
whitelist that redirect url in the google console (googles error page shows
the exact uri if it doesnt match)
no .env editing needed normally, APP_BASE_URL is only a fallback override if
the auto detection ever picks the wrong host.
and yes it works, several people run google calendar this way. its missing from
the docs though, ill add a section, youre not the first to hit this.
(if youre the same kyle from the github issue btw, the empty calendar on
displays without login is a separate bug on my end, fix is coming soon )
-
-
fair ask - i hid the bar in split view because i didnt want to guess which
photo the data belongs to. i want to look into it but not sure yet whats the
right way to solve it, with 4 photos in a grid stacked metadata gets messy
fast, and the wallpaper engine is the one part i touch very carefully (older
tv browsers are picky there). tracked in #44 so it doesnt get lost, no promises
on the how yet.
and good news on the timer wheel: that toggle already exists. wallpaper
settings -> "show loading circle (timer)", untick it. the bottom bar then only
shows up when there is actual metadata to display.
- thats a good middle ground actually, added it as a note to #42. a
representative preview that reacts to the sliders live is way more doable than
a real 1:1 view preview, could be a first step.
thanks again, keep it coming
Thanks Karen 
good news on the first one, the frame is built exactly for
that. wallpaper, clock, calendar and weather all run independent from home
assistant, and the ha tiles keep their last value if ha drops for a moment
and reconnect on their own. so a short hiccup doesnt take the frame down.
only thing, if the image source itself goes down like immich you wont see
photos until its back, thats the one part that leans on something external.
theme switching with ha scenes isnt in yet but i realy like the idea, the
whole frame vibe shifting with the house mood is exactly what this should do.
putting it on the list
Thanks, I ended up getting working using the “secret” ical link in google calendar. Which ended up being really simple with your calendar widget.
Can I use Magic Frame to display and run my Home Assistant dashboard on a digital picture frame? If so, can I use any digital picture frame, or are there specific models or requirements that I should be aware of?
Hey
I used Claude to make adjustments to the built in calendar to enable it to look more like what I had with DakBoard. The amendments are uploaded and installed via the command line and not as a Module that can be uploaded. I asked it to make it into a Module so I can share in case anyone else is interested. However some of the “fixes” it made are to the server itself and not the calendar Module, TBH I have little to no knowledge. I pointed it to the GitHub and told it what I wanted and it created lots of “patches”.
I think all these will be lost should I upgrade from 1.1.1.
I then asked it what may be needed on the server side to make it able to create a Module that won’t need any patches. It came out with the below, I hope this means something to you as it does not me. But escentually its about past events still showing as it is a monthly view that rolls a week at a time, so on Sunday it was showing Mon-Sat as blank, not it shows them and they’re dimmed. Also there was an error with recurring events, if they were changed they would appear twice, once with the old and once with the new. There was also some issue with multi day events showing incorrectly. I will paste what it said and hope you can make sense of it as a feature request please.
Sorry for the long post.
1. Fix the underlying bugs in /api/calendar upstream, in core
These are real bugs independent of our module, worth fixing regardless of the module question:
- The recurring-event exception handling doesn’t relate edited/moved occurrences to their series master, causing duplicate old+new entries after any edit
- The per-feed cache key is keyed only on window duration, not the actual start date — two different date ranges of the same length silently collide and serve each other’s data
- A single malformed/unusual calendar entry (common in years-old calendars) can throw during parsing with no isolation, potentially dropping the whole feed silently
2. Officially support and document a “past events” mode
Right now, “only show events from today onward” is hardcoded with no way to opt out. A documented, stable query parameter (or a mode: "agenda" | "range" flag) for “give me everything in this date range, including the past” would mean any module — ours or someone else’s — doesn’t have to guess at undocumented behavior that could change without notice.
3. Give custom modules a real way to reach external URLs server-side
This is the actual structural gap. Right now the only way a module can get calendar data without hitting CORS is by depending on the internal /api/calendar route, which was never designed as a public contract for modules to rely on. A generic, module-facing “fetch this URL server-side and return the raw text” endpoint (with reasonable safety limits — domain checks, size caps, rate limiting) would let a module bundle its own parsing logic (e.g. ical.js) and be genuinely self-contained, immune to whatever internal changes happen to the core calendar feature over time.
4. Version the module API contract
The deeper issue underneath all of this: our module silently depends on the current undocumented behavior of an internal route. If that route changes shape in a future core update, the module breaks with no warning. A stated, versioned contract for what modules can rely on (even just “these query params on /api/calendar are stable, semver’d, and won’t change without a major bump”) would make third-party modules like this trustworthy long-term instead of accidentally coupled to implementation details.
Item 3 is the one that actually unlocks true “upload two files, done” portability — 1, 2, and 4 are what stop this exact multi-week bug hunt from recurring for the next person who tries this.
hey, this is a really good writeup, thank you for putting that much time into it.
i went through the calendar code and youre onto something with a few of those,
especially the duplicate recurring events after an edit and the caching thing,
those look like real bugs to me and i want to fix them properly for everyone,
not just guess from the text.
could you open an issue or even better a pr with your actual changes and the
module code? then i can see exactly what you touched, make sure nothing else
breaks when i pull it in, and do the bugs and improvements right from there.
way easier for me when i can look at the real code instead of working from a
description.
and yeah small heads up, since your version patches the server directly right
now those changes will get overwritten when you update. thats exactly the kind
of thing the module stuff youre describing would solve, so id rather build it
properly than have you keep patching core. maybe hold off on updating til that
lands.
really appreciate this, it maps out a good chunk of where the module system
needs to go.
Hey magic frame is its own
separate system, not something that runs inside home assistant. you install
it yourself (docker, runs on a pi, nas, old pc whatever) and it hooks into
home assistant over websocket to get your entities live.
once its running its basically just a web page, so any screen that has a
browser can open the view and show it. thats the only real requirement, a
browser. an old tablet in a frame mount, a monitor, a smart monitor (i use a
samsung m5), a screen on a raspberry pi, all work fine.
the one thing that usually doesnt work is a proper consumer photo frame like
aura or nixplay, those are closed and cant open a web page, so theres nothing
to point at your view.
Hey, thanks for your support.
I’ve created the PR with the help of Claude as I have no idea what I’m doing, please let me know if you need anything changed/updated.