Safer Feeds, Smaller Sensors

Version 1.2.0 takes what a feed publishes seriously: markup is cleaned before it ever reaches a card, and a feed can no longer fill its sensor with more than Home Assistant is willing to store. Feeds also stop being write-once — one can be pointed at a new address without being rebuilt, and every sensor now says which feed it polls.

What a feed can put on your dashboard

• Feed content is cleaned before it leaves the integration. Scripts, style blocks, event handlers such as onerror and javascript: links are removed from every value the sensor exposes — summaries, content, titles, authors and the feed level values. A feed could previously put a script into a dashboard through any card that renders its HTML. Feed markup is still publisher content and deserves the same caution as before, but it no longer arrives live.
• Link, image and audio URLs are checked too. They end up as an href or a src, so a javascript: or data: URL is dropped rather than handed to a card.

A history the recorder actually keeps

• Fewer entries are kept, by default. Feeds added through the UI used to keep up to 9999 entries with the full article text, which pushed the sensor past the recorder's 16 KiB limit — so its history was stored without any attributes at all. The new default is the newest 5, and you can raise show_topn again whenever you like.
• Long text is shortened to 250 characters. The new max_text_length option controls it; set it to 0 to keep the full article text. Text is cut at a tag boundary and any open markup is closed again, so a shortened summary never ends inside a tag. Links, images, audio URLs and ids are never shortened.
• Download diagnostics. The config entry now offers a diagnostics download: the settings in effect, whether the last poll worked, how many entries and which fields came out of it, and how close the sensor is to that 16 KiB limit. Entry texts are left out and the feed URL is reported redacted, so the file is safe to attach to an issue.

Feeds you can find, read and move

• A feed can be pointed at a new URL. [#5] Use Reconfigure on the integration entry to change the address a feed is polled from — a new domain, a reverse proxy in front of a self hosted feed, a changed subscription token. The sensor keeps its entity id, its history, its name and its area, so the cards, templates and automations that use it keep working. Until now the only way was to delete the feed and add it again, which left all of that behind.
• Each sensor shows which feed it polls. [#5] A feed_url attribute carries the address, on UI and YAML feeds alike, so state_attr('sensor.my_feed', 'feed_url') or Developer tools > States answers it without opening the feed's configuration.
• Every feed gets its own device. A feed added through the UI appears as a device named after the feed, linking to the feed URL, with its sensor attached. Sensors keep the names and entity ids they had.
• YAML feeds appear in the entity registry. They can be renamed, hidden or assigned to an area like any other entity. As long as you leave name and feed_url alone, the sensor keeps its entity id and everything you set on it.

Setting one up

• An address has to actually serve a feed. Adding a feed now checks that the URL returns RSS or Atom. An ordinary web page is rejected with a clear message instead of becoming an entry whose sensor sits at 0 forever. The same check runs when you change a feed's URL.
• Inclusions and Exclusions are pickers. Instead of typing a comma separated list, you pick field names from a dropdown and can still type your own. Feeds configured the old way are converted on upgrade and keep filtering exactly as before.
• German translations. The setup, reconfigure and options forms are all available in German.

Fixes

• Dates that cannot be read are left out. A date the parsers did not understand used to be replaced with the current time, so the entry looked freshly published and moved on every poll. It now simply has no date, and the log names the value that could not be read.
• Two awkward feed dates no longer take the poll down. A malformed date could raise out of the parser and leave the whole feed unfetched rather than costing that one entry its timestamp.
• An entry with nothing left in it is skipped. Inclusions narrow enough to empty an entry used to leave a blank item in the list.

Good to know

Upgrading changes two settings on feeds you already have, and only where nobody chose them. A UI feed still carrying 9999 entries — the old form's own default, not a choice — is moved to 5, as is any stored value below 1, which showed nothing at all. A number you picked yourself is left alone. YAML feeds are not capped: they keep every entry unless you set show_topn yourself, because their state is the number of entries and capping it would rewrite what their recorder history means.

Changing name or feed_url on a YAML feed — or removing it from configuration.yaml — still creates a new entity and leaves the old one behind as unavailable; delete it under Settings > Devices & Services > Entities. If you want a rename to keep the sensor's identity, use a UI entry, which is identified by its config entry rather than by its name.