Design decisions
Some choices need more than a line in an FAQ. This page explains, openly, why Everstra does — and doesn’t do — certain things. If a feature you expected is missing, chances are it wasn’t an oversight. It was a decision, and here’s the reasoning behind it. For what the modules do and how they fit together, see the overall approach.
Why is there no scheduled-streaming feature?
A lot of people ask for a built-in scheduler: start the YouTube stream at 8:00, stop it at 18:00, repeat every day. It sounds simple. Everstra doesn’t offer it — not for lack of trying, but as a deliberate decision after testing it thoroughly on real cameras. Here’s why.
A YouTube stream key is tied to a single broadcast, not to your channel. With auto-start enabled, sending video to that key brings one broadcast online. But once it ends, nothing automatically creates the next one. Every combination was tested — the channel’s own key, a custom key, “stream now” and scheduled events — and the result was always the same: it goes live once, and a later attempt just hangs, waiting forever. Recurring, unattended streaming simply isn’t possible by pushing video alone.
The only way around this is YouTube’s API — and that’s where it stopped being worth it. Relying on Everstra’s own API access would put a hosted service permanently in the middle of your stream: a dependency, a single point of failure, and something that stops working the day the developer stops. That’s the opposite of what Everstra is: nothing leaves the camera unless you send it there, and it keeps working without anyone in the middle. The alternative — each user creating their own Google Cloud credentials — is technically sound but genuinely punishing to set up. The full click-by-click walkthrough was built and tested; even for someone comfortable with developer tools, it was too much. For the people Everstra is for, it would be hopeless.
So the scheduler is on hold, indefinitely and honestly — not because the easy part couldn’t be built, but because the honest version isn’t good enough, and the good-looking version would break a promise that matters.
How the apps became Axis-signed
For a while, Everstra’s apps shipped unsigned — a deliberate, temporary choice while the signing path was being sorted out. That has changed: all four modules are now signed and countersigned by Axis Communications.
Here’s what that means in practice. On AXIS OS 11.11 and later, each module is built against the current ACAP SDK with manifest schema v2 and then countersigned by Axis. The camera verifies that signature against Axis’s own trust chain before the app runs — a chain that reaches from the device’s firmware up to the application. The practical proof: the apps install even on cameras configured to reject unsigned apps, the hardened setup common in professional and corporate networks.
We kept this page honest when the apps were unsigned, so we’ll be just as plain now: signing is done, verified on real hardware, and every download here carries it.
Why Hub only switches a fixed list
Everstra Hub is the first Everstra module that takes commands from outside the camera — from Home Assistant, over MQTT. That is exactly the kind of door that has to be narrow on purpose, so it is.
A whitelist, not a pass-through. A command does not name an address on the camera; it names an entry in a short, fixed list inside Hub, and that list decides which module, which action and which values are allowed. Anything that is not on it cannot be reached, however the message is worded. Today the list is: start and stop Live streams, and switch Capture jobs on or off.
Nothing that deletes. Clearing a capture job or removing recordings is deliberately not on the list. A remote switch that can destroy recordings is not a switch, and MQTT has no undo. The same goes for anything that is a test rather than a state, and for network, users, time, firmware and other apps — Hub never touches them.
Retained commands are refused. A retained MQTT message is delivered again on every reconnect. A retained “off” would switch a job off after every network blip, forever, with nobody sending anything. Home Assistant does not send retained commands; something that does is misconfigured, and Hub says so instead of obeying.
Camera settings are off until you allow them. Hub can also set some of the camera’s own image and video settings — brightness, exposure, the IR cut filter and similar. Only settings on a fixed list qualify, only if the camera itself marks them as writable, and only after you have enabled writing for each one. The value must fit the camera’s own range or options. Out of the box, nothing is writable.
The result is less than a generic remote control could do — and that is the point. Home Assistant gets the switches that are safe to automate, and nothing that could hurt the camera or your recordings when an automation goes wrong.
Why activation is online now
Until now, the code that decided whether a licence was valid lived entirely inside the app. That works, but it has a weakness every free project eventually meets: whatever the software can check on its own, a determined person can copy along with it.
So the decisive part moved out. The secret that creates a valid licence is no longer in the software at all — only a public key that can check a signature, never make one. When you click Activate online, the camera sends its hardware ID once, the server signs a key for exactly that camera, and the camera stores it. That makes passing licences around clearly harder.
We’ll be plain about the limit: it doesn’t make copying impossible. Software running on a device can always be modified by someone with enough effort. The aim is a fair hurdle, not a fortress — enough that “free” stays sustainable for a one-person project.
What we deliberately did not do:
- No ongoing check. The camera contacts the server once, when you click. It never asks again whether it is still allowed to run — once activated, it’s yours for the lifetime of that camera, even if the server were gone tomorrow.
- No account. Nothing to sign up for, no password, no profile.
- No dead end without internet. The e-mail route stays, for cameras that never see the internet.
- Nothing kept about you. The hardware ID is used to sign the key and then discarded. What remains is a count per day of module, camera model and firmware version — enough to know which cameras the apps must keep working on, and nothing more. The details are in the privacy policy.
Why the update check is opt-in and static
A camera on a mast runs for years. Nobody logs into it every week, and that is exactly how a security fix goes unnoticed. So the apps can now tell you when there is a new version — but only if you want them to.
- Off by default. You switch it on in the License tab; until then no connection is made.
- A static file, not a service. Once a day the camera fetches one small file with the newest version numbers. The same file for every camera — there is no endpoint that could receive anything.
- Nothing about the camera is sent. No hardware ID, no model, not even the installed version. The comparison happens on the camera. We couldn’t count your installations from it if we wanted to.
- It tells, it doesn’t act. Nothing is downloaded or installed automatically. You see a notice with the release date and a Download button, and you decide when.
- Security fixes stand out. A security update is highlighted and its notice can’t be dismissed — that’s the one case where staying quiet would not be doing you a favour.
The alternative would have been a newsletter or an account — both mean handing over an address. A file that anyone can read and nobody has to identify themselves for seemed the more honest way to say “there’s something new”.
Why FTPS is now the default — and old jobs keep running
Plain FTP sends the user name, the password and every file in clear text, readable by anyone on the way. So new uploads use FTPS — the same server, encrypted, with its certificate checked — and SFTP for servers that speak SSH, with the server’s fingerprint checked before anything is sent.
What we did not do is switch existing jobs over silently: a job that uploaded via plain FTP before the update keeps doing so, with a notice in its settings, because a camera that suddenly stops uploading is worse than one that tells you to switch. Plain FTP stays available for a trusted local network — chosen on purpose, with a warning, never by default.
Why the language lists only help you fill in a field
The captions Overlay shows in the image and the e-mail texts of Live and Capture can be pre-filled from 12 languages — but the app has no language setting, and its settings pages remain in English. Picking a language writes its words into the field, and from then on it is your text: you can change any word, and the camera stores exactly what is there.
That keeps the camera simple — no translation tables to load, nothing that changes behind your back with an update — and it means a translation we got wrong is one edit away from right. Languages other than English and German are machine translations, marked “(auto)”; corrections are welcome.
Why third parties are highlighted, not flagged as a warning
Overlay’s privacy page says at the top how many third-party services it talks to — the weather service, the map tiles, the water-level services. The line is orange, not green and not yellow: green means none, yellow on that page means “unencrypted”. A third party is not a fault — the weather data is legitimate, and you switched it on — but it is privacy-relevant, so it should be visible at a glance rather than hidden in a list.
What might come
A note on direction, not a promise. Everstra is a one-person project, and it ships what it can stand behind — so treat everything here as being considered, not scheduled.
A few things under consideration: pulling live values from a local MQTT broker into an overlay (data from your own network, nothing leaving the camera); a text or ticker overlay fed from a URL you choose; and starting a stream or a recording from a camera event, like motion or an input signal. (That last one no longer has to wait for a built-in feature: with Everstra Hub and an automation you build in Home Assistant, a motion or input sensor can already start a Live stream or switch on a Capture job.) Whether any of these ships depends on whether it can be done well and whether people actually need it. Priorities change, and the right thing later beats the wrong thing now.
Three more ideas, at the same stage: night-sky overlays that name what the camera sees — stars, planets, the Moon, satellites and aircraft — and follow them across the image; values from your own weather station, more precise than a public weather service, also usable in text and ticker overlays; and a network share (NAS over SMB) as a storage target for all modules.
For Hub, the same framing applies — considered, not scheduled: a fleet monitor across many cameras and sites; webhooks to any HTTP endpoint besides MQTT; camera metrics as a Prometheus target for Grafana dashboards; starting streams, capture jobs or image settings as part of Home Assistant scenes; a watchdog that notices a module or camera that stopped responding and restarts it deliberately; and a PTZ reaction that turns the camera to a preset position when an event fires. None of this is part of Hub today. The full list is on the Hub page.
Have a feature in mind?
I’m always glad to hear it. If there’s something you’d like Everstra to do, just tell me — no form, no account, a plain email is enough. I read every one.
Whether a request makes it in comes down to four things, honestly weighed: how many people ask for it, whether it can be built well and fits cleanly into how Everstra already works, whether it stays true to what Everstra is — nothing leaves the camera unless you send it there — and whether I have the time to do it properly. A request that meets all four has a real chance. One that breaks the DNA, however popular, doesn’t. I’d rather say no clearly than promise something I can’t stand behind.
Either way, your input shapes what gets built next.