github Philra94/homeassistant-hoymiles-cloud v1.3.0
v1.3.0 — Battery writes actually apply again

latest releases: v1.4.0rc6, v1.4.0rc5, v1.4.0rc4...
one month ago

Fixes battery mode and setting writes, which have been silently doing nothing.

⚠️ If you have changed a battery setting recently, check it

Since the direct write endpoint became the default, changing a battery mode or a reserve SOC could report success in Home Assistant while the inverter kept its previous setting. The entity would show the new value briefly, then revert.

Anyone relying on the integration to control their battery should verify their plant is actually in the mode they expect. Automations that switched modes may never have taken effect.

What was wrong

The undocumented station/setting/battery_config endpoint answers:

{"status":"0","message":"success","data":true}

…while leaving the plant completely unchanged.

Reported by @ocd154 on a HiOne-10S-G3 (#59), who isolated it by swapping only the transport. It was then reproduced against a different account and different hardware: an identical write returned success and read back unchanged via the direct endpoint, and applied correctly via the documented flow. So this was never model- or account-specific — the endpoint is inert, and every user was affected.

The fallback added in v1.2.0 never helped: it only triggered when the direct write reported failure, and it never does.

What changed

The documented write flow is now the primary transport — write → job id → status poll, which is what the Hoymiles web UI itself uses. The direct endpoint remains only as a fallback for accounts the documented flow might not serve.

Every write is now verified by reading the state back. This is the more important half: a vendor success response is no longer treated as evidence that anything happened, on either transport. A write that does not land now surfaces as an error in Home Assistant instead of a silently reverting control.

Immediately after a write the plant briefly reports "[Working Mode] pending" and is unreadable, so the verification retries; a plant that never becomes readable is deliberately not reported as a failure, since the outcome is genuinely unknown.

Also in this release

  • Plant identifiers (station id, station name, device serials) removed from the API documentation, where they had been left by the original capture work.
  • .local/ added to .gitignore.

Related

  • #43 has been reopened — this is the likely real cause of that report, and v1.2.0 did not fix it.

Full Changelog: v1.2.2...v1.3.0

Don't miss a new homeassistant-hoymiles-cloud release

NewReleases is sending notifications on new releases.