quick reassurance: MudiModem doesn't replace the stock interface — it just adds an extra "MODEM" menu at the top of the GL admin GUI. The normal interface stays fully intact, you just use both side by side. So there's nothing to switch, and you don't lose anything.
If you ever want to remove it, there's a clean uninstall (the mirror image of the install):
curl -fsSL ``https://raw.githubusercontent.com/kevinherzig/MudiModem/main/uninstall.sh`` | sh
That removes the panel and the menu entries again. For any details, best to ask Kevin (@kevinherzig) — it's his panel.
I used to have once a ZTE U60 Pro prototype / R&D device (I got it used via ebay). It had a so called “Power Supply Mode”. It disconnected the battery charging when on power supply (USB-C).
The battery was losing about 1% per day while not being charged (but the router was fully working on power) - it was supposed to keep the charge always at least at 40%-60%.
This feature was pretty cool even though the 40%-60% feature didn´t work on the R&D device. (ZTE support was obviously not willing to help on a R&D device, but I guess they will introduce this feature at some point of time with a firmware update)
Mudi 7 always charges up to 100%. A threshold feature (i.e. disconnect the battery charge unless battery charge falls below XX% then charge again up to YY%) would be absolutely great and save a lot on battery life.
Fair point, and thank you both — I posted before reading the full thread, which is on me.
I had missed the charge_en approach and the MudiModem panel entirely. Nothing bothers me about the modem extension; I simply did not know it existed. I was about to go the external smart plug route for something that already has a proper native solution.
So to correct my own post: the workaround is not an external smart plug. The E5800 charger driver does expose charge control, ChiliGLi's script uses it, and MudiModem puts a slider on top of it. That is a far better answer than what I described.
My request therefore narrows to one thing only: please make this a supported setting in firmware, so it survives updates and does not need to be reapplied after every flash. The community has already proven it works and has done the hard part.
Thanks to ChiliGLi and Kevin for the work, and apologies for the noise.
any chance to modify the battery feature so it could execute following?
Stop charging at XX % of battery charge.
Resume charging at YY% of battery chage.
i.e. it would stop charging when the battery load has reached 80%, it would resume charging when reaching 20% (example YY% value)
As mentioned earlier I used to have a ZTE U60 Pro that had this feature included but a bit different. Once the “Power Supply Mode” was enabled the device stopped charging the battery at whatever is the current charge level. (No slider function) The feature should however automatically make sure it keeps 40%-60% always. (Again no slider function)
Batteries lose charging power in standby mode or while not being used. In the ZTE case it was about 1% per day. In your scenario I assume the Mudi 7 will resume charging whenever it falls below 80% - so I guess when it reaches 79% it will charge 1%? Correct?
But this is not necessary. It is also okay to let it drop down further (i.e. 20%) and then let it recharge in one go back to 80%. I assume this is better for the battery life time?
I see it the same way; that would be the clean solution. The script and the MudiModem slider already show that the charging control works properly in the E5800 driver. If GL.iNet adopted this as an official, update-safe firmware setting, it would be a real advantage for permanent installations: it would survive updates and wouldn’t have to be set again after every flash. +1 from me, very welcome.
Thanks for your detailed thoughts — you’ve clearly given this a lot of consideration. Here’s my personal view on it:
I wouldn’t really want two separate values (stop at XX / resume charging at YY). For most users, that would quickly become confusing, and the benefit is fairly marginal — sometimes even counterproductive: if the battery is constantly discharging and charging back up, you’re more likely to accumulate unnecessary cycles.
In my view, a single threshold is completely sufficient. The slider goes down to 50%, and 50% is a really good value for continuous operation on mains power — the battery then sits comfortably in the middle instead of remaining at a high charge level all the time.
One more general thought on battery care: With modern lithium-ion batteries, the main thing is to avoid keeping them at a high state of charge and in the heat for extended periods. The cells don’t need “exercise” or regular full charge cycles — that’s more of a myth from the NiCd era; every cycle causes wear. Your 20–80% window doesn’t do any harm, but compared with maintaining the battery around ~50%, it offers no benefit as long as the device is connected to power anyway.
In short: I’m all for a clean charging-limit threshold — I’d skip the two-value hysteresis. But of course, that’s just my opinion.
One can choose the best constant charge. So depending on the user scenario the values should differ. Somebody who is just using it frequently in a mobile scenario that depends on battery should ideally use 80% charge if it lasts long enough for the case (i.e. travel by train or car for just a couple of hours) .
For somebody having it on permanent charge and seldom using it mobile the constant charge of 50% seems to be ideal. This would be my scenario: I´m using the Mudi 7 in a camper. It is on permanent charge. But I don´t want to remove the battery for redundancy reasons and in case I want to swap physical SIM cards without rebooting need.
*You or GL.iNet in case they adapt this might want to disable settings at 50% and below.
a few months ago, i reverse-engineered the quec-battery daemon (which controls battery charging, including sending PD PPS messages to the charger, etc) and reimplemented it. (or rather, an LLM did most of the heavy lifting anyway)
this means the Mudi could use PPS to fast-charge close to configured voltage limit (instead of dropping to the less efficient buck-boost charger much earlier), since the reimplemented daemon can command the PPS charger to start ramping down supply voltage once the battery approaches the voltage limit
(also means that /etc/config/qlbattery actually starts becoming useful, in the original daemon those params weren’t being used)
i’ve been using it for a few months (and so has my friend), and so far i haven’t seen any issues. i set the voltage limit to 4050mV, which corresponds to ~78% on the UI (as long as the charge counter doesn’t fuck up lol - that’s why i prefer a voltage limit over a % limit)
to use this:
cross-compile quec_battery from the repo
upload it to your Mudi /usr/bin/quec_battery2 or whatever
stop the original charging daemon with /etc/init.d/charge.init stop
edit /etc/init.d/charge.init to point to quec_battery2
uci set qlbattery.settings.charge_limit_mv='4050'; uci commit
/etc/init.d/charge.init start
use at your own risk, no warranty. though imo it’s pretty safe, since the PPS charge controller has failsafes (it’ll cut off the supply power and drop back to buck-boost charging if the PD PPS charger supplies a voltage that’s higher than expected by the controller)
