Repository navigation
Ohme Component Errors and Missing EV Charge Slots in Plan #5444
Description
Activity
Attached log file now includes the Ohme component errors.
Automated first-pass triage — a maintainer will review this before any action is taken.
Classification: bug · Priority: priority_medium
What I investigated
Read your attached
predbat_debug.yamland the quoted traceback against currentmain(v9.3.6-4-g55c887f8, only a few commits past your v9.3.6; none touch this path). The errors come from Predbat's built-in Ohme component (apps/predbat/ohme.py, a vendored copy of dan-r/ohmepy) — not from the Ohme HA integration — which is why the HA integration's own logs stay clean. Your yaml showsohme_automatic: trueandohme_control: 'True', so Predbat-led charge control is enabled, and that control loop is where both parts of your report sit. Theohmeunit-test module passes on main (127 passed, 0 failed) — this path has no coverage, which is why the suite can be green while this misbehaves.Root cause: the repeating 404
- Predbat-led control re-evaluates the plan every 60 s (
CONTROL_INTERVAL_SECONDS,ohme.py:75, called fromrun()atohme.py:325-326). Outside a planned window it pauses the charger (ohme.py:474-475), which is aPOST /v1/chargeSessions/{serial}/stop(ohme.py:1373). - The 404 body in your log —
Entity of type: 'ActiveChargeSessionDB' ... not found— is Ohme's server saying there is no active charge session for the charger to stop, e.g. after the charge finished or once the car is unplugged. This is a different class from ohme_control returns HTTP 404 when attempting to start charging #4719: the route is live; there is just nothing in this session state to stop. - That 404 raises
ApiException, andcontrol_charge()has no handler, so the state transition atohme.py:476(self.control_charging = should_charge) is never recorded. Predbat still believes it is holding a charge window, so a minute later it tries the same stop again — hence the every-minute errors. Each failure also skipsupdate_success_timestamp()at the end ofrun()(ohme.py:328), which the component health monitor watches (component_base.py:216-217), so the component drifts toward unhealthy while the storm runs. - Both of your observations fit the same mechanism: the errors stop once the car is plugged in and a session becomes active again (the stop then lands and the state settles, e.g. after a manual charge), and the error is quiet right now after a recent charge but will return while the charger has no active session.
Likely fix shape for the maintainer: catch
ApiExceptionin the control loop so the intended state is recorded anyway (treating a stop-404 as "nothing to stop"), and avoid pausing when the charger reports no charge in progress. One 404 per state change rather than one per minute.The missing car charging slots
The two symptoms are plausibly the same control design misfiring, and the missing slots line up with a specific gate in it: with
ohme_controlon, Ohme's own schedule is deliberately not used as the car plan (charger_slots_wanted(),ohme.py:613) — Predbat plans the charge itself, and that only happens whilebinary_sensor.predbat_ohme_connectedis on. That sensor is on only while the Ohme session readsPENDING_APPROVAL / CHARGING / PLUGGED_IN / PAUSED(CONNECTED_STATUSES,ohme.py:203, published atohme.py:949); a session that has finished, while the car is still attached, counts as not connected. A car in that attached-but-idle state gets no planned slots while Predbat-led control keeps the charger paused — and only a new live session flips it, which is exactly how the manual charge from the Ohme app "wakes" Predbat. Your snapshot agrees at capture time (8 Oct 14:30:car_charging_slots: [],car_slot_owner: null,io_adjusted: {}), though it can't tell me what state held during the plugged-in-no-slots periods you describe.Related: #4719 (a different Ohme 404 — withdrawn v1 routes, fixed by the v2 migration), #5399/#5401 (the slot-mode-vs-control split that shipped in v9.3.6, the release you just moved onto), #4952 and #5413 (same component, other findings). Also relevant: #5120, merged to main today but not in your v9.3.6 — it stops the published car-charging window start walking forward, and Ohme now parses the plan with the shared parser.
What would settle the missing-slots half
- When the 404s return: a
predbat_debug.yamlandpredbat.logcaptured while it is happening, both from the Debug panel. - For a stretch where the car was plugged in and you expected charging but the plan had no slots: the debug snapshot for that time from the History view (Plan → History, next to the slot — default retention is only ~48 hours, so please grab it soon), plus a
predbat.logcovering the period, and whatsensor.ohme_home_pro_status/ the Ohme app showed then, since the connected-gate is my suspect for this half. See the debug history docs. - Meanwhile, setting
ohme_control: falseshould stop the 404 storm and hand the charger back to Ohme's own schedule, which v9.3.6 can take as the car plan (feat(ohme): take the car plan from Ohme's own schedule when Predbat is not controlling the charger #5401). Worth knowing either way whether charging then resumes on its own.
- Predbat-led control re-evaluates the plan every 60 s (
Describe the bug
When my EV is not plugged in, Predbat logs an Ohme error every minute or so . No errors are visible withing the Ohme HA integration logs and the states are reported correctly.
Once the car is plugged in and the Ohme Home Pro state changes, the Predbat Ohme errors stop. This normally means the plan is updated to incorporate the upcoming car charging session, however recently the plan is not allocating slots for charging. I have had to manually initiate a charge via the Ohme app which seems to wake predbat up and the plan updates to include the car charging slots.
Expected behaviour
Given there is no ev plugged into the Ohme Home Pro
When I view the predbat logs and plan
Then there should be no Ohme component errors displayed in the logs and the plan should not have charging slots.
Given there is an ev plugged into the Ohme Home Pro
When I view the logs and plan
Then I should see in the predbat logs that the ev is plugged in and an update to the plan to include charging slots.
Predbat version
v9.3.6
Environment details
Log Extract
Each bullet point is listed as an individual log entry.
Log file
Currently the error is not displaying following a recent charge, but it will return as I have observed it several times over the past week whilst troubleshooting.
predbat_debug.yaml.txt
Predbat debug yaml file