Add Device Charger 2 - #85
Conversation
|
…r Station battery fields
This comment was marked as resolved.
This comment was marked as resolved.
… now Power station SOC
This comment was marked as resolved.
This comment was marked as resolved.
… battery output, AbsoluteDecimalField replaces AbsoluteSignedDecimalField
|
How is the actual status for this? I would love to use this with my charger 2 |
|
Hi smai86 the readings are accurate to my testing. It needs checking, possible field name changes for uniformity reasons, and some of the other pull requests have different versions of the read signed decimal. It might be a while before it hits the main release. I am hoping to add some write control for the charger 2 in the future particularly the System on/off toggle after the write control for encrypted v2 devices is implemented, and if I can find the correct register as it is not obvious. |
|
Hey @sidieje , thanks for your work that would be awesome if the charger 2 also gets writeable for the system switch... Let me know if I could help you with some testing. (My config is a Elite 400, Charger 2 and B300K) |
|
I don't have that bug, but there were some somewhat similar bugs with the Apex 300 on early firmware. What is the voltage of your solar input? Mine is 39 V Voc and about 34 V Vmp. I'm wondering if your voltage is lower and perhaps the bug occurs at low voltage. My firmware: IOT v8036.14 I am determined to add the System On/Off toggle, as I also want to automate it. The Charger 2 doesn't have an obvious Boolean toggle changing from 00 to 01 like the v1 devices use. Also, because the System On/Off setting changes multiple functions at once, there are many registers that change state depending on multiple factors—for example, whether silent charging is also enabled, or whether the car battery or expansion battery is being used. I do have some strong suspects, though. However, this integration doesn't currently play nicely with writes that aren't 00 to 01, and I think that is hard-coded in bluetti_device.py. Write requests for v2 devices also don't currently work. However, there is already a very good pull request that fixes those issues, so there's no point in me trying to work around them at the moment. Once write support is working, I'll try to add as much control as possible. |
|
Hey @sidieje, Vmp: 20.5 V I also just noticed that my firmware is still outdated. I’m currently running: IoT: v8036.11 I’ll update to the latest versions later today and hope that this bug has already been fixed. By the way, is there a Discord channel where I could join the discussion and maybe help out or contribute? |
|
If the new firmware doesn't work you could put another panel in series to see if it solves the problem at higher voltage. Sounds like a good excuse to get another panel. I don't know if there is a Discord channel I am kind of new here. |
|
hey @sidieje the new firmware also doen´t work... so i have to try with an other panel... but that is not so easy for me 🙈. |
Brings in upstream release 0.1.8, which includes the fork's own PR Patrick762#80 (dropping the stdlib `asyncio`/`logging` entries from the dependency list), merged upstream on 2026-08-29. New from upstream: * EL10 device support (PR Patrick762#89) * Handsfree 2 device registration with CTRL_AC/CTRL_DC (PR Patrick762#85) * additional EL100V2 fields, and ChargingMode.CUSTOM = 4 (PR Patrick762#87) * `bluetti-readall` also writes a hexdump alongside the JSON (PR Patrick762#92) * `get_full_registers_range()` now starts the sweep at register 0 instead of 1, on both base device v1 and v2 The last item is the only behavioural change. It is reached solely from the `bluetti-readall` diagnostic script; the Home Assistant integration never calls it, so polling is unaffected. Conflict resolution: setup.py `install_requires`. Upstream removed the two stdlib entries from the plain dependency list; this fork had already removed them and additionally carries version floors with the rationale for them (HA wheels index resolution). Upstream's change is a strict subset of what the fork already has, so the fork side is kept in full — verified by diffing the merge base against upstream, whose only setup.py change is those two removals. The fork's release.yml is preserved and upstream's python-publish.yml does not return: publishing to the upstream PyPI project is not this fork's to do. Full suite green (67 tests). The fork's BleakError guards around the handshake writes in device_reader are intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2 participants
Consolidated into first post 15-08-26.
@Patrick762 I think it's ready now. Any changes needed let me know. See second post for pictures of App layout.
This is the working output fields tested against device. I only made minimal necessary field additions.
Change log
Added fields for PPS_OUTPUT
Added fields for PS_BATTERY
Added SignedDecimalField as I couldn't see an existing way to read them.
Added AbsoluteDecimalField to show positive readings of signed decimal for PPS outputs.
Added charger2 device
Notes -
The Charger 2 has different register layout and extra inputs and outputs. Including:
Solar input.
Two battery inputs: car battery and expansion battery
Two DC outputs: PPS output and DC Hub output (DC Hub not added)
Solar input:
FieldName.DC_INPUT_VOLTAGE
FieldName.DC_INPUT_CURRENT
FieldName.DC_INPUT_POWER
Car battery:
FieldName.BATTERY_VOLTAGE
FieldName.BATTERY_CURRENT
FieldName.BATTERY_IO_POWER
Expansion battery:
FieldName.PS_BATTERY_VOLTAGE
FieldName.PS_BATTERY_IO_POWER
FieldName.PS_BATTERY_SOC
PPS Output:
FieldName.PPS_OUTPUT_VOLTAGE
FieldName.PPS_OUTPUT_CURRENT
FieldName.PPS_OUTPUT_POWER
I have used field name PS_BATTERY_IO_POWER because it represents power going into the expansion battery from solar, and power going out of the battery to the PPS so it can be negative or positive reading.
I found the registers for Device ID and Serial Number. It looks like if I explicitly point to them in the charger2 device config then it will ignore the defaults in base_device_v2.py. I selected the register 15500, but it shows multiple times so it could also be 11000 or 1101. 15500 works and is closest to the other used registers.