[APP][Pro] 50five - Smart charging at home for you electric vehicle

Apps
,
525

could be that not all charger models support that feature.

526

After two test sessions it seems to be working again. Thanks for the quick response and merger/publishing.

527

Subject: PR #32 — 7 bug fixes for com.newmotion.my (follow-up to #31)

Hi Kaoh,

Thanks for quickly merging and publishing #31 last week — appreciated!

I’ve opened a follow-up PR (#32) with 7 bug fixes I found while investigating a report from a user (KingSize32 on the Homey community forum). The most important one fixes the root cause of the “button briefly turns off then back on” issue when stopping a session:

  • evcharger_charging was mapped to activeSession — when a car is plugged in (even after a successful stop), activeSession stays true, causing the button to snap back ON every 2-minute update cycle. Fixed to use charging > 0 (only true when current is actually flowing).
  • SessionAction was swallowing API errors (return err instead of throw err) — made failures completely invisible.
  • 5 smaller fixes: Console.log ReferenceError, pause timeout too short (10s→30s), null guard in onAdded(), flow card ignoring pause_on_stop, and getAuthCookie() returning undefined on decrypt failure.

PR is here: Fix: 7 bug fixes for button revert, silent API failures, and stability by coertnoordermeer-coder · Pull Request #32 · kaohlive/com.newmotion.my · GitHub

Would you be able to review and publish as v4.1.20? Happy to answer any questions.

Thanks,
Coert

528

@KingSize32 @Sjoerd_4 @thijscrombeen — update on the current situation.

v4.1.19 (merged June 5) introduced the pause_on_stop setting that @KingSize32 asked about. The default is OFF, meaning the button behaves exactly like it did before v4.1.18 — it starts/stops a full transaction using your registered card. You only need to turn the setting ON if you want the block/unblock behavior (useful for automated energy management flows that need to resume without an RFID card).

If your button is still reverting to ON after pressing stop on v4.1.19, I’ve identified the root cause and it’s in PR #32 (not yet merged): the update loop was checking activeSession (which stays true as long as the car is plugged in) instead of charging > 0. So even after a successful stop, the next update cycle — every 2 minutes — would flip the button back on. That’s the exact symptom both @KingSize32 and @Sjoerd_4 described.

PR #32 also fixes a silent error swallowing bug in SessionAction where API failures were returned as values instead of thrown — making it impossible to see why a command failed.

@Kaoh could you take a look at PR #32 when you have a moment? It should resolve the remaining button issues for everyone.

529

Done, analyzed and merged/published to prod.
One attention point is
pause_update_loop 10s increased 30s I remember looking for the minimum stable time for this. The reason to try to sit at the edge of trustworthy time is the user experience waiting for feedback on their action. It takes longer but more reliable. Its a choice that impacts the UX both positive and negative. Just so you know why I had it on 10s.

530

@Kaoh — thanks for the quick merge and for explaining the 10s reasoning, that’s a fair point.

The motivation for 30s was specifically the StopTransaction case: if the charger takes longer than 10s to process the stop (slow API response, network hiccup), the update loop would fire in the meantime, see the charger still charging, and revert evcharger_charging to true — giving the user the impression their stop didn’t work. 30s was a conservative pick to cover that race condition.

A middle ground worth considering: keep 10s as the base but add a second check — after the API call completes, verify evcharger_charging_state has actually changed before restarting the loop. That way normal cases stay fast (10s) and only slow cases wait longer. Happy to open a follow-up PR for that if you think it’s worth it.

Thanks again for maintaining the app!

531

@Kaoh — noted, thanks for setting that up. PR #33 follows the process: version bumped to 4.1.21 in both app.json and .homeycompose/app.json, changelog entry added. Should be git pull && homey app publish straight after merge.

The fix itself addresses the error-handling point you documented in CONTRIBUTING.md — updateDevice() in both start_update_loop and pause_update_loop now has .catch() so an unhandled rejection doesn’t crash the app.

532

merged, syced and pulbished :slight_smile: but Homey did not auto approve, so its on test now, we have to wait x days for it go to live.
Great work!