Jim's Depository

I have a Sungold SPH5048P All-in-one inverter. It has an RS-485 port and a USB port where you can get information, though it isn't documented how you might do that.

I wrote a program I call sungold which interfaces to the USB port on the Sungold, extracts the information, and reports it in a giant JSON file of mostly correctly interpreted data.

I tried to turn the inverter section on and off, and failed miserably. But I have succeeded in setting and clearing power saver mode, which is good enough for me. How power saving mode works is poorly documented, but without grid/generator power and no load my inverter eventually shuts off and when load appears it eventually comes back on.

The device presents as a serial port where you do Modbus commands to pull blocks of register values. Most values can not be written, but some can. It's hit or miss.

You can run in daemon mode where it will hang around and periodically write a new .json file, or you can run it as a one-shot command and get a json output.

This may work with many different brands of inverters: Many companies use the SRNE internals which is what this targets. Good luck there.

This program just makes the JSON, I grind it up and put it into a web page to monitor things. That ends up looking like this:

While working with those horrible battery management system BLE interfaces, I wanted to probe my various BLE devices and see what services and characteristics they have. I suspect there is a way to do it with the standard-ish bluetooth tools, but they also looked overcomplicated and apparently they also hate humans.

So I did what any civilized program would do, I "wrote" my own in a programming language I do not know. The AIs assured me that Rust's zbus interface was the friendliest API to work with. I've never written Rust, or used D-bus, but why let that stop me.

So I sat down with Claude and told him my wishes for a bluetooth low energy scanning program, and after a false start and a bunch of refinement, and then some locating of catastrophic bugs and maybe getting rid of them I now have the BLE scanner of my dreams.

I still don't know Rust, I kind of meant to learn it, but I haven't really read any of the code. I made it move some things around and structure things a little different, but Claude didn't need me for my coding skills.

Anyway, you too can have blescan. There is a Raspberry Pi Debian package in the release prebuilt, or you can build it yourself.

With no arguments it lists the devices it sees advertising. With a MAC as an argument it maps out the services and characteristics of the device.

$ blescan
Scanning for BLE devices... (5s)
Found 2 device(s):
  AA:BB:CC:DD:EE:FF - My Sensor (-72 dBm)
  11:22:33:44:55:66 - Unknown (-85 dBm)

$ blescan AA:BB:CC:DD:EE:FF
Connecting to AA:BB:CC:DD:EE:FF...
Waiting for GATT services...

GATT profile for AA:BB:CC:DD:EE:FF:

Service: 0x1800 - Generic Access
  Characteristic: 0x2A00 - Device Name [read]
    Value: "My Sensor"
  Characteristic: 0x2A01 - Appearance [read]
    Value: 00 00

Service: 0x180A - Device Information
  Characteristic: 0x2A29 - Manufacturer Name String [read]
    Value: "ACME Corp"
  Characteristic: 0x2A26 - Firmware Revision String [read]
    Value: "1.2.3"

Service: 0x180F - Battery Service
  Characteristic: 0x2A19 - Battery Level [read, notify]
    Value: 64

There's a man page if you want to know more.

I've got 8 Vatrer 12v 100Ahr LiFePO4 batteries in two banks powering a remote installation. The absolute #1 selling point of these batteries is that their BMS (battery management system) will look to see if it is too cold to charge the batteries and run a little heater until the cells warm up enough to charge without destroying them.

The #2 selling point is that the BMS units report the battery state of charge, voltage, current and such over BLE (bluetooth low energy). That lets me better track their state when unattended for months and decide when to cut power off to less critical systems or attempt to start a backup generator.

After much jiggery I have this integrated in the control systems, but those little BMS controllers are really nasty to work with.

Woes

• No sane BLE implementation. They sort of implement a RS-485 interface with a write only string characteristic and a notify only string characteristic. Listen to the one and shout in the other.

• No sane protocol. I'm pretty sure that is some ancient Modbus controller protocol wrapped in the Bluetooth.

• No documentation of the protocol. I get it, I'd be ashamed to admit to that too.

• GIANT DANGER: If a device connects to the BMS, in the BLE sense, then the battery will stop advertising itself and it appears the battery has vanished. If there is a timeout it is more than 12 hours. Lest you think,"well I won't do that then"… there are a lot of sneaky paths for BlueZ and NimBLE that will leave connection stuck on without you knowing it. I found several.

• You apparently can't reset the BMS, I mean it's not like you can take the batteries out or disconnect the power.

Moral

If one of your batteries drops off bluetooth, then reboot all the devices that were talking to it and it may well come back.