I noticed that these are missing while looking at dissassembly of the
Pytes implementation of the protocol. I also found Pylontech sample
CAN messages] which match the Pytes implementation [1]:
```
CAN ID – followed by 2 to 8 bytes of data:
0x351 – 14 02 74 0E 74 0E CC 01 – Battery voltage + current limits
^^^^^ discharge cutoff voltage 46.0V
0x355 – 1A 00 64 00 – State of Health (SOH) / State of Charge (SOC)
0x356 – 4e 13 02 03 04 05 – Voltage / Current / Temp
0x359 – 00 00 00 00 0A 50 4E – Protection & Alarm flags
^^^^^ always 0x50 0x59 in Pytes implementation
^^ module count (matches the blog article image)
0x35C – C0 00 – Battery charge request flags
^^ two possible additional flags (bit 3 and bit 4)
0x35E – 50 59 4C 4F 4E 20 20 20 – Manufacturer name (“PYLON “)
^^^^^^^^^^^^^^ Note: Pytes sends a 5-byte message "PYTES" instead
padding with spaces
```
The extra charge request flag is "bit4: SOC low" (Seems to be SoC < 10%
threshold for Pytes), I haven't bothered adding that as it provides
little value.
[1] https://www.setfirelabs.com/green-energy/pylontech-can-reading-can-replication
the workflows running unconditionally for each push and each PR are run
twice when pushing to a branch that is to be merged by a PR and if that
branch is a branch local to the repo (rather than in a fork).
if the package.json file changes, we must trigger building the web
application, as in particular, a completely different version of yarn
could be required.
we need to change the working directory to the webapp directory such
that corepack installs and uses the expected version of yarn. otherwise,
corepack installs a copy of yarn into the repository root directory.
we added shell=True so that on Windows, yarn would be found. however,
using the list syntax to define the command and its arguments to
Python's subprocess is broken on GNU/Linux by shell=True. instead, use a
single string (command and arguments), which works on both Windows and
GNU/Linux.
this allows us to fix the version of yarn, the Node.js package manager,
to a particular version. using corepack is the recommended way to use
yarn these days.
this allows us to fix the version of yarn, the Node.js package manager,
to a particular version. using corepack is the recommended way to use
yarn these days.
the "Yarn Linting" action causes a warning to appear about a deprecated
Node version. switch to actions/setup-node@v4, which is already in use
by the action building the web app for the firmware, to avoid this
warning.
the "Yarn Linting" action causes a warning to appear about a deprecated
Node version. switch to actions/setup-node@v4, which is already in use
by the action building the web app for the firmware, to avoid this
warning.
it seems this action has not been run for nealry a year. it has only
been run twice at all. it is not maintained, as it uses older Node.js
in particular. also, it seems to be redundant to build.yml, which
already builds firmware for every commit.
