Battery charging and astrion-home problem

Astrion Astrion - Development & Advanced
1

I’m not sure exactly when this started (whether it was after the latest update or for no reason), but the remote has trouble charging its battery. Right now it’s at, say, 22 percent and has been on the charger for an hour. The charging symbol is on, but it looks more like it’s just holding the battery level steady rather than actually charging. It’s had this issue before too — either charging only up to a low level, or discharging while still on the charger.

It’s hard for me to monitor exactly what’s happening since I’m not home 4 days a week. I did a factory reset, but that hasn’t helped. In the system/app, under “battery,” the charging curve is pretty much flat.

Additionally, it has unstable ping and tends to drop off the Wi-Fi network.

I’m also having trouble adding the “Astrion Home” service — the integration isn’t detecting the remote via the LAN broadcast, even after reinstalling it and resetting the remote to factory settings.

Do I have a defective unit?

2

Hi Robert,

Thanks for the detailed report — that really helps narrow things down.

On the charging behavior first: what you describe (charging icon present but battery level staying flat or drifting) is most commonly caused by a non-stable charging contact rather than a battery or firmware issue.

A few key points from our side:

  • Astrion uses a pogo-pin based charging interface, and if the contact pressure is slightly off (dust, slight misalignment, or uneven seating in the dock), the device can enter a “maintenance state” where it draws intermittent power but doesn’t properly charge.

  • In that state, the system will still show the charging icon because USB power is detected, but the actual charge current may be too low or unstable to increase the battery percentage.

  • This also matches your observation of a relatively flat battery curve.

What we recommend checking:

  1. Remove the device from the dock and clean both contact points (remote + base)

  2. Re-seat the remote firmly and ensure it sits fully flush in the dock

  3. Try a different USB power adapter (stable 5V supply, ideally 2A+)

  4. If possible, gently test whether slight movement of the device affects charging status (to confirm contact sensitivity)

Regarding the Wi-Fi instability:
This is likely separate from charging. However, if the device is occasionally dipping into low-power or unstable power states due to charging issues, Wi-Fi ping instability can appear as a side effect. Once charging stabilizes, we expect connectivity to improve.

About Astrion Home not being discovered via LAN broadcast:
This usually depends on:

  • mDNS / multicast availability on the network

  • whether the device and HA instance are on the same subnet

  • and whether the remote is in a stable network state (not power-fluctuating or reconnecting Wi-Fi)

So I would strongly suggest resolving the charging stability first, then re-testing discovery.

Do we think it is a defective unit?

Based on your description alone, this does not immediately look like a defective battery.

It is more consistent with:

unstable charging contact + possible network instability caused by intermittent power behavior

However, if after cleaning/re-seating and testing with a stable power source the issue persists, we will of course treat it as a hardware case and replace the unit if needed.

If you can, please also share:

  • a short video of the remote seated on the dock

  • battery screen over 10–15 minutes

  • and your Wi-Fi environment (mesh / VLAN / router type)

That will help us confirm the diagnosis much faster.

3

Hi thank you. The battery issue is fixed now — I had to go into Android recovery and do a wipe data and wipe cache. As for Astrion Home, in the HA logs I have: ‘This error originated from a custom integration. Logger: custom_components.astrion.config_flow Source: custom_components/astrion/config_flow.py:159 Integration: Astrion Home (documentation, issues) First occurred: 9:39:56 PM (3 occurrences) Last logged: 9:40:18 PM 【重试】重试后仍无发现，请检查 App 是否在线’"

4

Problem solved — I had two accounts on HA, one had the Astrion credentials but without administrator rights. After all that, you need to issue a new token again, and after pairing with the Astrion remote, restart it once more so it accepts the new token. Thanks for the help. Best regards, Robert

1 Like
5

Thanks Robert — really appreciate you taking the time to trace this down and share the resolution.

What you described makes perfect sense in the context of Home Assistant’s permission model:

  • If the Astrion integration is authenticated under a non-admin HA account, entity discovery and service access can be partially restricted

  • Regenerating the long-lived access token effectively resets the API session scope

  • After pairing, a device restart is required so Astrion re-initializes the HA client and fully rebinds to the updated token context

So the combination of:

  1. account permission mismatch

  2. stale token

  3. missing post-pair restart

can indeed produce exactly the kind of “partial or unstable behavior” you observed.

We’ll also add this case into our internal troubleshooting notes, because it’s not always obvious from the user side and can easily be mistaken for a connectivity or firmware issue.

That said, we are still reviewing a few robustness improvements in the Astrion ↔ HA handshake process to make token revalidation and permission handling more resilient in future updates.

Thanks again for the detailed feedback — it’s genuinely helpful for improving the system for everyone.

6

Sanytron Astrion — Battery Charging Issue Diagnosis

Reported Problem

My Sanytron Astrion remote was not charging properly on the docking station when powered on. The charger display (Ubigbuy 420W GaN PPS PD3.1 140W) showed 3W only for a fraction of a second, then dropped back to 0W. With the remote powered off, charging worked — cycling between 3W for ~10 seconds, then 0W for ~1 second.

Diagnostic Process

Step 1 — Hardware Verification I normally use a USB-C → USB-C cable to power the docking station. For diagnostic purposes I temporarily connected a USB-A cable, which delivers a maximum of 4.5W — confirming this is insufficient to simultaneously charge the battery and power the active remote. After switching back to USB-C → USB-C the problem persisted, suggesting a deeper cause than the power supply itself.

Step 2 — Charging Cycle Characteristics and Mechanical Contact I measured a regular cycle: ~10 seconds of charging (3W) → ~1 second pause. The regularity of the cycle ruled out unstable mechanical contact of the magnetic connectors — this is intentional behavior of the docking station’s charging protocol. It is also worth noting that the positioning of the remote on the dock is not a decisive factor — while there are occasional moments when the dock holds contact less firmly, in the vast majority of cases the contact is good. Crucially, when the charging problem occurs, no repositioning of the remote on the dock helps — which conclusively rules out a mechanical cause.

Step 3 — Powered-Off Remote Test With the remote completely powered off, the battery level actually increased (from 23% upward), confirming that the docking station, magnetic connectors, and battery are all functioning correctly on the hardware level. The problem was software or power management related.

Step 4 — Firmware History I recalled that after a previous wipe data (one week earlier) charging had worked correctly — and I posted about this on the Sanytron forum. A new firmware update then arrived and the problem returned, suggesting a firmware regression.

Step 5 — Android Recovery Wipe Data I first attempted wipe cache only — this had no effect whatsoever. Only wipe data (Power + Back → recovery menu) restored normal operation. After rebooting on version 1.0.38 charging returned to normal: 4W with the screen active, cyclic 3W with the screen off.

Step 6 — Step-by-Step Firmware Updates I performed sequential firmware updates, verifying charging behavior after each one:

  • 1.0.38 → charging OK :white_check_mark:

  • 1.2.0 → charging OK :white_check_mark:

  • 1.2.0.1 → charging OK :white_check_mark:

  • 1.3.0 (beta) → charging OK :white_check_mark:

All versions work correctly after wipe data.

Step 7 — Identifying the Time Pattern Key observation: the problem occurs consistently upon my return home on Thursday after a 4-day absence (I leave on Monday). Wipe data restores normal operation every time. This suggests the cause is the remote remaining powered on and on the docking station for 4 consecutive days — likely causing corruption of application data (log overflow, battery management error, or similar).

Hypothesis

Application data becomes corrupted during extended continuous charging of the remote in powered-on mode. Wipe data clears the corrupted data and restores normal operation. The problem is not tied to any specific firmware version — all tested versions work correctly after wipe data.

Experiments To Be Conducted

Experiment A — already planned (this coming Monday): Before leaving I will power off the remote and leave it on the docking station for 4 days. Upon returning on Thursday I will check whether the charging problem occurs. If it does not — this will confirm that the remote operating in powered-on mode for an extended period on the dock is the culprit.

Experiment B — next step: I will leave the remote powered on for 4 days away from the docking station (e.g. on a desk). Upon returning on Thursday I will check whether the charging problem occurs. If it does not — this will confirm that it is specifically the combination of “powered on + docked for 4 days” that causes data corruption, rather than simply leaving the remote powered on.

Results of both experiments will be published on the Sanytron forum as a detailed bug report.

This text was written based on my own observations and measurements, with editorial assistance from AI (Claude, Anthropic).

8

This is an excellent write-up — very systematic debugging and the timeline correlation is particularly strong.

A few thoughts from our side that might help refine the hypothesis and next steps:

:battery: Charging behavior clarification (important baseline)

What you’re observing (3W → ~10s charging → 1s pause cycle) is actually consistent with a normal PD + battery protection handshake loop on Astrion’s charging controller.

When everything is healthy:

  • The dock negotiates power (USB-C PD)

  • Battery IC allows charge burst (~3–4W typical in UI-active state)

  • System briefly pauses to re-evaluate thermal + load + battery curve

  • Cycle repeats

So the “cycling” itself is not inherently a fault — it becomes meaningful only when the system fails to sustain the charge state.

:brain: Your key observation (very important)

The strongest signal in your report is this:

“After wipe data, ALL firmware versions behave normally again”

That does strongly suggest:

  • not a hardware degradation issue

  • not a charger instability issue

  • not a base firmware incompatibility

Instead, it points to something in:

  • Android power management layer

  • app-level power service

  • or HA / RosCard background process interaction with sleep states

:puzzle_piece: The “4-day docked + powered-on” hypothesis

Your pattern is interesting and plausible in this sense:

When Astrion is:

  • ON

  • docked continuously

  • running HA + WebSocket sync + UI rendering

  • not entering a true idle/off suspend state

…it may hit edge cases like:

  • battery service state desync

  • wakelock accumulation

  • thermal policy throttling that never fully resets

  • background service deadlock after long uptime

A wipe data would reset all of those layers at once — which matches your observation perfectly.

:warning: One correction / nuance

It’s unlikely to be “battery data corruption” in the literal sense.

More likely candidates are:

  • Android power HAL state inconsistency

  • charging service watchdog not resetting correctly

  • HA/RosCard keeping device in a “semi-awake UI loop”

  • USB PD renegotiation stuck in fallback mode after long uptime

:test_tube: Your experiments (very good design)

Your two experiments are exactly what I would also suggest.

To make them even more conclusive, you might add one extra variable:

Experiment C (optional but high value):

  • Powered on + docked

  • BUT manually restart once mid-period (e.g. day 2)

If this prevents the issue → strongly confirms “long uptime state accumulation” rather than dock interaction itself.

:light_bulb: Potential mitigation (if hypothesis is confirmed)

If this is indeed state accumulation over long uptime, there are a few practical mitigations we can test on firmware side:

  • scheduled nightly soft reboot of Astrion (lightweight service restart, not full wipe)

  • reset charging service when dock event detected after >24h uptime

  • watchdog for PD charging state stuck at 0W

  • enforce periodic re-init of battery service during docked idle

These are relatively low-risk fixes if we can reproduce reliably.

:+1: Summary

Your conclusion is directionally very reasonable:

“It’s not firmware-specific — it’s a long-uptime + docked + powered-on state issue that clears on full data reset.”

That is a strong working hypothesis worth reproducing internally.

If you get results from Experiment A/B/C, post them — especially uptime + whether HA was actively used during the 4 days. That detail will matter a lot for isolating whether this is UI loop, power HAL, or charging controller state drift.

9

I would like to add that previously the docking station with the remote was also powered using a Samsung ETA-P10X — a standard old-type 10W charger. The charging problem occurred with that charger as well. This further confirms that the issue is not related to the power supply or cable type, as the problem has been reproduced with multiple different chargers. The root cause is definitively on the software side.

1 Like
10

Hi Robert_P,

I hope you are doing well.

I sincerely apologize for the delayed response to your inquiry. We have already forwarded your feedback to our engineering team, and we truly appreciate your patience, detailed explanations, and thorough descriptions.

Regarding some of the points you raised, our engineers have a few additional questions and would like to kindly ask for your further clarification:

How long does it take for your remote control to charge from below 10% to 100%?

Regarding your statement that “clearing data after file corruption will restore normal function”:

What specific symptoms or phenomena led you to determine that the files were corrupted?

After performing a factory reset, how did you verify that the device had returned to normal working condition?

We look forward to your reply.

11

No sign of the problem returning yet

12

Alright, if this issue occurs again, please let us know so we can help pinpoint the problem. Thank you for your patience and detailed response.