I'm testing this on multiple devices using the local Hetsia address and also trying via Hestari.
Hub security enabled breaks the cameras across the board.
Turning off hub security, cameras work via local Hestia dashboard URL on my Macbook and Windows laptops.
The local dashboard works in Fully Kiosk on my tablet once hub security is disabled.
hestari.com does not work for me anywhere at this point, with or without hub security enabled. I have even tried removing the cameras and still get the page spinning either way.
See below. Seems like hestari.com doesn't like the camera URLs as http. If I enter them in settings as https, the cameras don't work anywhere. To clarify, using https for the camera URLs in settings does not work at all. http camera URLs work only with the local Hestia dashboard URL and hub security disabled.
Hi im still having the issue with removing devices from Hestia after they are removed from maker api i go into the rooms and devices x out the red devices that are no longer in maker api, then save and exit hit refresh at the top of the dashboard to have the same message come back and the device reappear in red again when going into devices and rooms.
Did you go into the app and update the groovy directly through HPM? Your app code and .html file should be tied to v1.6.3.
Just double checking before I do another deep dive into what could be the root cause for you. On my side my cameras work but I have a test camera for RTSP and I have ring cameras so I can see 1 second snapshots, not live feeds.
Again, my cameras work when the camera URLs are http. They are working only via Hestia's local hub URL. Also, hub security is currently disabled. Cameras do not work once hub security is enabled.
Hestari doesn't work for me at all at this point. I should note, that I don't really need it to if the local URL works, but there is definitely an issue.
Two separate fixes went out for two separate reports in this thread — tagging you both since they landed together.
@jkudave — those screenshots were exactly what I needed, thank you. Found it.
Your DevTools screenshot showed a request to /local/hestia-token.json sitting at "(pending)" forever, with a Mixed Content warning right next to it. That's the actual cause: hestari.com loads over HTTPS, but that request goes out to your hub's plain http:// address. Browsers are supposed to block that kind of request, but in some cases — yours included, it turns out — they don't reject it quickly, they just let it hang indefinitely instead of failing. Hestia was waiting on that one request to finish before anything else on the page could load, with no timeout, so it just sat there forever. That's why the shell of the page could still show up while lights, thermostats, and weather all stayed stuck at nothing. Not a Hub Login Security thing after all — that was my earlier guess and it was wrong.
Fix is live now: every request like that gets a timeout, so if one hangs, Hestia just moves on and keeps loading everything else instead of freezing.
Could you give it a clean retest?
Hard refresh hestari.com (Ctrl+Shift+R, or fully close/reopen if you're on the Fire tablet).
Does it load now, spinner and all?
Separately — I also haven't forgotten the camera URL scheme issue you documented (http works only via the local dashboard URL with hub security off, https doesn't work anywhere). That's a distinct problem from the one above, most likely your hub's self-signed HTTPS certificate not being trusted by the browser rather than anything Hestia is doing wrong, but I don't want to claim that without digging in properly. Once we've confirmed the spinning issue is actually resolved, I'll take a closer look at that one specifically.
@jbwrd3 — found your device-removal bug too. Dismissing a "removed from Maker API" device in Settings was supposed to save that change to the hub right away, but it wasn't actually waiting for that save to finish before returning control to you. If you hit refresh right after clicking the ✕ — which is exactly what you described — the page could reload before the removal had actually reached the hub, so it pulled back the old copy with the device still in it. That's why it kept coming back.
Fixed now: the dismiss action waits for the save to actually complete before you can do anything else.
Hard refresh hestari.com (or your local dashboard URL, whichever you use).
Try dismissing the removed device again, then refresh right after like before — it should stick this time.
A new Settings section for figuring out what's going wrong when something isn't working, instead of guessing back and forth in a thread.
Settings > Diagnostics:
8 on-demand connection checks — Hub Reachability, HTTPS/Mixed Content, Maker API Credentials, Hub Login Security, Companion App version, Push Pipeline, Cloud Sync, and Browser/Environment. Each runs independently and reports its own result, so nothing gets stuck waiting on a slow check.
Send Test Notification — confirms push delivery works right now, without waiting for a real device event.
Activity Log — a running record of device events (doors, windows, locks, motion, smoke/CO, water, alarm arm/disarm), captured server-side once either Push Notifications or Announcements is turned on. Shows what actually happened, independent of your notification preferences.
Two real bugs fixed along the way, both found from reports in this thread:
A boot hang affecting HTTPS + HTTP-only-hub setups — the page could spin forever with nothing loading. Root cause was a request during boot that could hang indefinitely with no timeout when blocked by the browser's mixed-content policy; it now times out and lets everything else keep loading.
A Settings sync race where dismissing a device flagged as "removed from Maker API" could bring it right back if you refreshed immediately after — the removal wasn't finishing its save before the page could reload.
No Groovy functionality changed this release — the version bump is just to keep the new Companion App check accurate. If you're not on HPM, re-paste the latest HestiaDashboard.groovy from GitHub so the version matches; on HPM, this shows up as a normal update.
Everything else — Cameras, Artemis, Athena, existing device controls — is unchanged in this release.
Did what you asked with same results devices still return. I also updated to the latest 1.6.4 with same results. Just to be clear i hit the x to remove the devices that is no longer in maker api then i save and apply then the refresh. Refresh only comes up after save and apply.
I can view my camera streams via HTTPS in my browsers, so I am pretty sure the certificate is trusted. I don't recall when, but I likely trusted the certificate when testing at some point.
@jbwrd3 — thanks for the exact sequence, that was the missing piece. My first fix addressed a real but different bug (a fast-refresh race); it wasn't what was actually happening to you.
Here's the real cause: dismissing the device correctly removed it from Rooms & Devices, but I'd missed that it wasn't also being removed from your Artemis sensor list if it was registered as one (contact, motion, smoke, or water sensor). Clicking Save & Apply afterward — completely normal, not a timing issue — rebuilds the internal device list from scratch, and since the device was still sitting in that sensor list, it got pulled right back in. That's why it kept coming back specifically after Save & Apply, exactly like you described.
Fixed now — dismissing a removed device also clears it out of Artemis sensors, so Save & Apply can't reintroduce it.
Could you retest the same way: hard refresh, dismiss the device, Save & Apply, then refresh?
@jkudave — think I found it, and I went back through your original screenshots from a while back to check.
Your camera settings screenshot shows both URLs as https://192.168.x.x/hub2/videoStream/1633.mjpg — no port specified. Hubitat's hub doesn't serve HTTPS on the standard port 443, it uses 8443. Without it, that request has nowhere to actually connect, regardless of certificate trust or hub security — which lines up with everything you've seen: it works fine when you paste the URL straight into a browser tab (where you likely already have :8443 from an old bookmark or address bar history), but not from inside Hestia's settings if the port never made it into what you pasted there.
If you're willing to keep giving it a try, could you update both URLs in Settings > Cameras to:
(same for the Snapshot URL field too) — and see if that gets HTTPS working the way HTTP already does for you. No rush at all, and genuinely appreciate you sticking with this as long as you have.
Also, a minor bug. Cameras in the left menu show 0 of 2 Online until I click on it to go to cameras, even though my cameras are actually online. It then changes to 2 of 2 online. In other words, it shows incorrectly until it is clicked on.
