v1.8.1

• furbo.get_events no longer drops the event-name filter when every alert
  is switched off. The default is built from the alerts your cameras have
  enabled, and with none enabled that list came out empty, which put the field
  back to absent and quietly restored the behaviour 1.8.0 exists to avoid.
  Turning alerts off stops new events being recorded; it does not remove the
  ones already there, and asking for a window in the past is a fair thing to do
  with them all off. The request now falls back to everything those cameras can
  report, and to the full vocabulary if their alerts are not known yet.
• The two cat alert-frequency controls have names, options and icons. 1.8.0
  gave Meowing and CatActivity a notification-frequency select each and no
  translations, so they appeared as frequency_cat_activity with raw option
  values. The test that was supposed to catch this only checked the alert
  existed, not that the control it implies was ever described; it now checks
  both, and fails when either is missing.

v1.8.0

• Cat cameras get their own alerts. A Furbo cat camera (FBC0030,
  MC0030) does not report a subset of a dog camera's alerts, it reports a
  different vocabulary: Meowing where a dog barks, CatActivity where a dog
  moves, CatSelfie, CatCrying, CatVomit and the rest. This integration's
  alert list was built from one FB0030 and shipped as everybody's, so a cat
  camera owner got switches for the four keys the two lists happen to share
  and nothing at all for the other fifteen alerts their cameras have. All of
  them are now named, given icons and switchable. Refs #6.
• furbo.get_events can be asked for a cat camera's events. The action
  validated event_names against the alert switches' list, so every name an
  FBC0030 actually uses was refused, and the UI's own picker did not offer
  them either. Event names are their own vocabulary, overlapping the alerts
  without either containing the other: Run, Chew and FurboOnOff are
  alerts the event list cannot filter by, and Earthquake, AutoCalm and
  Fighting are the other way round. The action now uses that list.
• furbo.get_events sends the event names it did not used to. The Furbo
  app never omits that field; it sends the account's enabled alerts on every
  request. Leaving it out returns events on some accounts and nothing at all
  on others, a difference invisible from the outside. When you do not name
  any, the enabled alerts for the cameras you asked about are sent, which is
  what the app does with information this integration already holds.
• Cat models are named rather than shown as raw product ids, and the everyday
  alerts enabled by default now include the cat equivalents, so a cat camera
  no longer arrives with every switch turned off.
• Tests now fail if the alert list, the translations, the icons and the
  action's picker stop agreeing with each other. Four hand-maintained copies
  of overlapping lists is how the above happened.

v1.7.3

• The debug line for furbo.get_events now includes the window it sent, by
  value. Field names alone could not distinguish a build sending seconds
  from one sending microseconds, which is the difference between 1.7.1 and
  1.7.2 and therefore the first thing worth checking when the action returns
  nothing on one install while working on another. The window is the caller's
  own choice of times, not a secret. Everything else in that line stays names
  only. Refs #6.

v1.7.2

• furbo.get_events returns your events. It had never returned any. The
  endpoint filters on an event's Id, which is a microsecond timestamp, so
  its window is in microseconds; this integration sent seconds. Every window
  therefore landed in January 1970, matched nothing, and came back as an
  empty list with no error at all, because the request was perfectly valid
  and simply selected no events.
  Found by reading the Furbo app's own request model after four rounds of
  guessing failed to. Reported and patiently retested throughout by
  @renaybbbb in #6.

v1.7.0

• The window on furbo.get_events is now optional. Leave start and
  end out and you get the most recent events with no time filter at all;
  give one end alone for everything since, or until, a moment.
• Why this matters beyond convenience: the action still returns nothing on at
  least one account, and a window the cloud does not filter the way this
  integration expects is indistinguishable from a week with nothing in it.
  Both come back as an empty list. Asking with no window at all is the one
  call that separates them, and until now the action would not let you make
  it. Refs #6.

v1.6.2

• furbo.get_events stops reporting a response it cannot read as an empty
  day. It stopped erroring in 1.5.1 and started returning nothing instead,
  because the response was read for a field named Events and an absent name
  produced an empty list, exactly as a quiet afternoon would. Those are
  different facts and an automation cannot act on the difference if both
  arrive as nothing, so a response with no Events list now fails, and says
  in the error which fields it did carry. Field names only: the values in that
  body are video links into your home.
  Reported in #6. This does not yet make the action return your events; it
  makes the reason visible so the request can be corrected.

v1.6.1

• Today's activity counts no longer start the day holding yesterday's.
  The calendar is read at most hourly, and that hour was counted in elapsed
  time alone. A reading taken shortly before midnight therefore sat inside its
  hour well past midnight, serving yesterday's totals and summary under a name
  that says today. The cached figures now carry the date they counted, and
  midnight in your account's timezone ends it.
• A new day that cannot be fetched reads zero rather than yesterday's numbers.
  Carrying values over is right within a day and wrong across one. The hourly
  backoff is unaffected, so a rate-limited account still gets one attempt.
• Signing back in around midnight no longer restores yesterday's counts.
  The figures kept between fetches are now held with the date they counted,
  rather than read back off the last stored update. That stored update is only
  replaced when a whole refresh succeeds, so a refresh that read the calendar
  and then failed on something later left the previous day's numbers in place
  to be picked up and relabelled. A dead token also no longer spends the hour:
  it is not this host refusing us, so the refresh after renewal can ask
  again rather than sitting the hour out on nothing.
• Signing back in through the add-on clears the add-on's warning. The
  notice about it waiting for a verification code stayed up after a recovery
  that had visibly just worked, with nothing to press. A password sign-in
  still leaves it alone, because that says nothing about the add-on.

v1.5.1

• furbo.get_events did not work at all in 1.5.0. Every call came back as
  Furbo API error 400 (code 12001). The cloud requires the list of cameras
  and 1.5.0 treated it as optional, so a call that did not name one was
  refused. It now defaults to every camera on the account, and naming one
  still narrows it. Found by the reporter in #6 testing it the day it shipped.
• Event names are checked before the call. Furbo answers a name it does
  not recognise with the same bare 12001 it gives for a missing field, so a
  typo was indistinguishable from a bug. The field is now a dropdown of the
  names Furbo accepts.
• furbo.get_events read a plain time in the wrong timezone. A window
  written without an offset, which is how most people write one, was read in
  the timezone of the machine Home Assistant runs on rather than the timezone
  Home Assistant is set to. On a container those differ: asking for 19:00 from
  a London install fetched the clips from 20:00. Both ends of the window are
  now read as the local time the automation was written in.
• A window with an offset on one end and not the other no longer fails.
  Mixing the two raised an unhandled error instead of returning clips.
• The repair notice about the add-on waiting for a verification code is now
  cleared when the account is deleted. It was registered against the
  integration rather than the entry, so removing the account left a permanent
  warning about an add-on nothing was waiting on, with nothing to press.

v1.5.0

• New: two actions that hand back Furbo data for your own automations.
  Asked for in #6, by someone who wants to build their own recap videos.

  • furbo.get_events returns the detected events in a window you choose,
    each with its own video clips and thumbnail. The window is yours, so
    unlike Furbo's own daily recap this is not limited to 07:00-19:00, and
    overnight activity is included if you ask for it.
  • furbo.get_insight_report returns the written daily report the app shows
    as a day's recap.

  Both return their answer to the caller rather than storing it. That is
  deliberate: an entity's attributes are written to the recorder, included in
  diagnostics downloads and pasted into issue reports, and neither of these
  has a fixed shape worth holding there. Your automation decides what to
  download, where to put it and how long to keep it, which is the part of
  "build my own recap" that is yours rather than the integration's.

  Downloading and keeping a clip library is deliberately not included. That is
  a media pipeline, not an integration, and these actions give an automation
  everything it needs to do it the way you want.

v1.4.1

• Signing in again no longer registers Home Assistant as a new device.
  Furbo binds a MobileId per login and caps how many an account may hold, and
  reauthenticating minted a fresh one every time instead of reusing the one the
  entry already had. That spends the account's allowance on the same
  installation over and over, and something has to give way: the likely
  casualty is the Furbo Bridge add-on's own binding, which is exactly what
  leaves it unable to renew and asking for a verification code of its own.
  Reauth and reconfigure now reuse the identity the entry registered; a genuinely
  new entry still gets a new one.
• The login response's DeviceBindingLimit is logged by value at debug level,
  so how many bindings an account actually allows can be read rather than
  guessed at. The response carries no refresh token of any kind, which is now
  confirmed from a real login rather than assumed.