I’ve looked at your logs and I think there are actually two different issues compounding, which explains why live streaming works but image retrieval doesn’t.
The first issue is the Netatmo stream itself. The token in the URL (the a859f78… in /live/index.m3u8) is a local session that isn’t permanent: it rotates, and the stream is only available when a streaming session is active. You can see this in your logs: sometimes ffmpeg opens the stream, retrieves a few segments, then gets stuck in a loop of 404 errors on the medium and low playlists with « Packet corrupt » messages, and it eventually times out. At other times, it’s a direct 404 on the main m3u8 file, where the token is already invalid. So, when you manually open the camera, it starts a fresh stream and it works, but the background poll hits an expired URL.
The second issue, and I think this is the one blocking your input, is this line:
PayloadTooLargeError: request entity too large
expected: 103788, length: 103788, limit: 102400
Basically, ffmpeg manages to output the image, but it’s 103 KB and Gladys refuses anything over 100 KB. The image is captured but never saved. This matches your issue: your input is outdoors, the scene is more detailed, so the JPEG is heavier and consistently exceeds the limit. Your indoor cameras produce lighter images, which pass when the stream cooperates. That’s probably why this input fails every time while the others work intermittently.
Both issues seem more like integration problems than configuration issues on your part. The PayloadTooLargeError especially: the 100 KB limit is a bit tight for a 1280px outdoor capture, you’d either need to increase it, or lower the resolution or quality of the snapshot.
Yes!! It’s the integration of the PRs that are made to integrate the Netatmo cameras that will solve this. But the porting to external gladys-netatmo can take over. I won’t hide the fact that some core bricks will still be necessary . But normally, detached PRs already exist .
In short, it already works… well, almost, missing the video stream ^^ But a topic to discuss with @pierre-gilles. I’m preparing a point with Claude!!
Well the stream actually works! It’s just that the re-encoding adds a 10/15 second delay!
And no sound!! But this will be handled separately on the core side apparently.
Apparently, to test this better, and logically, we should be able to display one of the device’s parameters to select the stream quality « camera_quality »:
I already have a request to Tuya to allow entering the IP and protocol version fields in the Device files. This goes in the same direction.
We have bypassed this for the moment with a global parameter in the configuration for all cameras in the integration
I haven’t found a solution for the audio stream yet.
And on the other hand, we really need to be able to create documentation with access to the links of the dev platforms because in this case we have no information left to create accounts etc. as we had on the core integrations (or find a way to define starter chapters in the configuration that can include external links?)
EDIT:
For the sound, apparently it’s my test camera that’s broken and no longer gives any sound… sorry
Otherwise, regarding the live delay, Claude makes a proposal:
1. section field type — starter blocks in the config form (Netatmo port needed)
Manifest validation: new section type in the config_schema (and action fields, same engine) — label (chapter title, multilingual), description as plain text ≤ 1000 characters/language, optional links (1–5 entries {url, label}, urlhttps required, unknown fields rejected). Purely presentational: required, default, and placeholder on a section → manifest rejected with 422. The vendored schema reflects everything (enum + links + allOf rules).
No value: validateConfigValue rejects a section key in any config payload (front and integration → 422 „section fields have no value“), nothing is ever written to t_variable, and getConfigForFront does not expose the key.
Front-end rendering (declarative, zero markdown/HTML): title + text + links opened in a new tab with the target domain displayed in parentheses next to the label. As the config_schema is ordered, sections naturally split large forms — including action mini-forms.
2. Permanent „Documentation“ link on the Configuration screen
New getDocsUrls on the server side: the detail GET /api/v1/external_integration/:selector now exposes docs (URLs re-hosted per language, from the store index cache, linked by store_slug — null for a dev install, which has no re-hosted documentation).
The front-end displays a „Documentation“ button in the header of the Configuration card (user language, fallback en), for „device“ as well as „communication“ integrations (shared component).
Fixing an existing gap: getCatalog was not passing the docs field from the index — the documentation link on the installation screen was reading a field that was always missing. It now passes (docs: entry.docs || null), with assertions in the store tests.
. But normally, detached PRs already exist 
.
it was planned ^^
