justin/anker-shelly-bridge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update DOC.

Browse Source
This commit is contained in:
Sterling Archer
2026-08-12 09:39:44 -07:00
parent 096d4b3990
commit 265e302e3c
2 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/TESTING.md
+2 -2
View File
@@ -50,7 +50,7 @@ Some models pair with the Anker app over Bluetooth only. You press a button on
the unit to make it discoverable and it holds no persistent cloud connection. the unit to make it discoverable and it holds no persistent cloud connection.
The F2000 / PowerHouse 767 works this way. Those devices publish nothing to The F2000 / PowerHouse 767 works this way. Those devices publish nothing to
Anker's MQTT broker and the broker refuses the subscription with Anker's MQTT broker and the broker refuses the subscription with
`Unspecified error(128)`. They cannot be automation sources here — local `Unspecified error(128)`. They cannot be automation sources here. Local
Bluetooth access would need a different project (SolixBLE). Bluetooth access would need a different project (SolixBLE).
Discovery skips devices the cloud reports as disconnected before subscribing, Discovery skips devices the cloud reports as disconnected before subscribing,
@@ -222,7 +222,7 @@ Check the plug before you walk away.
## Before publishing ## Before publishing
- [ ] `device-profiles/` and `state/` are gitignored (the generated `.gitignore` - [ ] `device-profiles/` and `state/` are gitignored (the generated `.gitignore`
covers this, but verify — profiles contain your serial numbers) covers this, but verify, since profiles contain your serial numbers)
- [ ] `notifications.yaml` is not committed - [ ] `notifications.yaml` is not committed
- [ ] no `.env` in the repo - [ ] no `.env` in the repo
- [ ] `git log -p | grep -i -E "password|token|@gmail|user_key"` comes back empty - [ ] `git log -p | grep -i -E "password|token|@gmail|user_key"` comes back empty
README.md → solixauto/README.md
+19 -19
View File
@@ -34,15 +34,15 @@ On Windows, double-click `start.bat`.
That is the whole install. `start.sh` creates its own Python environment, That is the whole install. `start.sh` creates its own Python environment,
installs everything, and hands over to a guided setup with eight steps: installs everything, and hands over to a guided setup with eight steps:
1. **Dependencies** — installs whatever is missing 1. **Dependencies**: installs whatever is missing
2. **Anker account** — your login, stored locally with owner-only permissions 2. **Anker account**: your login, stored locally with owner-only permissions
3. **Find your SOLIX device** — connects and captures every field it reports 3. **Find your SOLIX device**: connects and captures every field it reports
4. **Find your Shelly plug** — scans the local network 4. **Find your Shelly plug**: scans the local network
5. **Check the plug** — finds schedules and timers already on it that would 5. **Check the plug**: finds schedules and timers already on it that would
conflict, and offers to remove them conflict, and offers to remove them
6. **Notifications** — optional push to your phone, with a QR code to scan 6. **Notifications**: optional push to your phone, with a QR code to scan
7. **Rules** — pick a strategy and answer a few questions in plain language 7. **Rules**: pick a strategy and answer a few questions in plain language
8. **Test, then start** — a live dry run against your hardware that switches 8. **Test, then start**: a live dry run against your hardware that switches
nothing, then offers to install a background service nothing, then offers to install a background service
Nothing touches your hardware until step 8 asks. Ctrl-C is safe at any point. Nothing touches your hardware until step 8 asks. Ctrl-C is safe at any point.
@@ -131,7 +131,7 @@ Opens a dashboard at `http://127.0.0.1:8765` showing every device you have
saved: battery level, solar in, grid in, load out, and each Shelly's switch saved: battery level, solar in, grid in, load out, and each Shelly's switch
state and draw. It refreshes every five seconds and keeps a rolling chart. state and draw. It refreshes every five seconds and keeps a rolling chart.
Each device gets a **power bus** — solar and grid drawn from the left, load Each device gets a **power bus**: solar and grid drawn from the left, load
from the right, all to one scale. If the left outweighs the right, the battery from the right, all to one scale. If the left outweighs the right, the battery
is filling. Light and dark themes, remembered between visits. is filling. Light and dark themes, remembered between visits.
@@ -147,7 +147,7 @@ always show live.
## Safety ## Safety
Controlling the power supply to a battery has a specific failure mode: turn Controlling the power supply to a battery has a specific failure mode: turn
charging off, let the battery run flat, and the device drops off the network — charging off, let the battery run flat, and the device drops off the network,
at which point nothing can turn charging back on. The design is built around at which point nothing can turn charging back on. The design is built around
preventing that. preventing that.
@@ -162,7 +162,7 @@ safety:
``` ```
Checked before any rule. It **bypasses the rate limits**, **outranks every Checked before any rule. It **bypasses the rate limits**, **outranks every
rule**, and **latches** once tripped — nothing can turn the plug off again rule**, and **latches** once tripped, so nothing can turn the plug off again
until the battery reaches `release_at`. Without the latch, a solar rule could until the battery reaches `release_at`. Without the latch, a solar rule could
release it at 21% straight back into whatever drained it. release it at 21% straight back into whatever drained it.
@@ -184,7 +184,7 @@ exits. When the plug supplies power to the SOLIX device, `safe_state: on` means
losing sight of it fails toward charging. losing sight of it fails toward charging.
Rules are also never evaluated against **partial** telemetry. If a field a rule Rules are also never evaluated against **partial** telemetry. If a field a rule
needs has not arrived yet, nothing is evaluated at all — including the floor. needs has not arrived yet, nothing is evaluated at all, including the floor.
### Rate limits ### Rate limits
@@ -358,9 +358,9 @@ Anything the upstream
[anker-solix-api](https://github.com/thomluther/anker-solix-api) library [anker-solix-api](https://github.com/thomluther/anker-solix-api) library
supports **and** that holds a cloud connection. supports **and** that holds a cloud connection.
Models pairing with the Anker app over Bluetooth only — press a button on the Models that pair with the Anker app over Bluetooth only, where you press a
unit to make it discoverable — publish nothing to the MQTT broker and cannot be button on the unit to make it discoverable, publish nothing to the MQTT broker
used. The F2000 / PowerHouse 767 works this way. Discovery detects and skips and cannot be used. The F2000 / PowerHouse 767 works this way. Discovery detects and skips
them. them.
Shelly Gen1 and Gen2+ including Gen4, over local HTTP. Shelly Gen1 and Gen2+ including Gen4, over local HTTP.
@@ -373,7 +373,7 @@ combinations should work; reports welcome.
## Known limitations ## Known limitations
- Field mappings come from a community reverse-engineering effort, not from - Field mappings come from a community reverse-engineering effort, not from
Anker. Fields ending in `?` or starting with `unknown_` are unconfirmed — Anker. Fields ending in `?` or starting with `unknown_` are unconfirmed, so
do not build rules on them. do not build rules on them.
- **Verify any field against the Anker app before trusting it.** The solar - **Verify any field against the Anker app before trusting it.** The solar
fields in particular should be watched in daylight and compared to the app fields in particular should be watched in daylight and compared to the app
@@ -407,11 +407,11 @@ credentials, network, and notification status in one place.
## Documentation ## Documentation
- [docs/RULES.md](docs/RULES.md) — power profile format, every option, worked - [docs/RULES.md](docs/RULES.md): power profile format, every option, worked
automation examples automation examples
- [docs/TESTING.md](docs/TESTING.md) — staged checklist for validating a new - [docs/TESTING.md](docs/TESTING.md): staged checklist for validating a new
setup before trusting it with real hardware setup before trusting it with real hardware
- [examples/](examples/) — a solar failover profile and an annotated - [examples/](examples/): a solar failover profile and an annotated
notifications config notifications config
## Contributing ## Contributing