Repository navigation
Conversation
Updated Hanchu iESS documentation to include Local BLE setup and prerequisites, and clarified integration steps for both Local BLE and Cloud versions.
This file contains the Predbat configuration for the Hanchu iESS, detailing setup instructions, inverter definitions, and energy management settings.
…equire hanchu-ess-ble 1.4.1 Predbat writes charge_rate/discharge_rate directly, outside the bridge script. On BLE those writes are only staged and get flushed by the next confirm_write, so the inverter's power limits changed on timing alone (e.g. discharge limit left at 0 after a Hold for car). Point both at input_number placeholders and document why. Also require hanchu-ess-ble 1.4.1, which fixes confirm_write reporting success for overlapping flushes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jvw8sZCm3W3cs7Qvp2Zum9
|
Updated following live testing on my own system: templates/hanchu_ble.yaml: charge_rate/discharge_rate now point at two placeholder input_number helpers instead of the integration's charge/discharge power limit entities. Predbat writes those rates directly, outside the bridge script. On BLE a direct write is only staged, so it got flushed by whichever confirm_write ran next. That left the inverter's discharge limit stuck at 0 after a "Hold for car". The new helpers are in Step 1, and the trade-off is explained in the Notes. No changes to the cloud section. Happy to adjust anything if you'd like it structured differently. |
Predbat writes charge_rate/discharge_rate directly. The cloud integration only stages those writes and the bridge script's device_control sends just the time-slot keys, so Predbat's rate never applies on its own but stays pending until the next Write Settings press flushes it. Point both at input_number placeholders, add them to Step 1 and explain in the Notes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jvw8sZCm3W3cs7Qvp2Zum9
|
Also applied the same change to the cloud section: templates/hanchu_cloud.yaml now maps charge_rate/discharge_rate to placeholder helpers (added to cloud Step 1, explained in the Notes). On the cloud integration, Predbat's direct rate writes are only staged and never sent by the bridge script, so they'd sit pending until someone next pressed Write Settings. |
This branch has not been deployed
2 participants
Adds a second Hanchu iESS setup path alongside the existing cloud-based
one, using the local Bluetooth (BLE) integration
(https://github.com/upton68/hanchu-ess-ble) instead of the cloud
integration — control happens entirely over BLE with no dependency on
Hanchu cloud connectivity.
New:
templates/hanchu_ble.yaml— apps.yaml template for the BLE setupprerequisites, helpers, the bridge script and mid-window automation,
the derived daily-energy helpers (import/export/load/PV aren't
natively exposed over BLE, unlike the cloud version), and apps.yaml
configuration
The BLE write path differs from the cloud integration's single-call
iotSet/device_controlAPI — it stages the affected time-slotentities via standard
time.set_valuecalls, then flushes them in oneBLE connection via a new
hanchu_ess_ble.confirm_writeservice (addedin hanchu-ess-ble v1.4.0, released alongside this documentation).
This has been validated on real hardware, including live overnight
charge/discharge cycles driven entirely by Predbat via this setup,
following several days of confirmed stable BLE signal.