Unable to get solar_poller to retrieve any data from my Eko (Ginlong) inverter

[guest715]

I’ve been having difficulty getting this to work with my Eko (rebranded Ginlong) inverter. In short, it connects, sends the magic sequence but never receives the expected response. If I enable debug in config.ini, the debug output indicates it never receives anything back from the inverter. I know the inverter works via Bluetooth because the Ginlong Power Monitor application (https://web.archive.org/web/20160605130524/http://www.ginlong.com/Download/down/id/13.html or https://web.archive.org/web/20170606105859/http://www.ginlong.com/Download/down/id/227.html) works in Windows (I’m running solar_poller.pl within Ubuntu). I’m wondering if the magic sequence is never reaching the inverter because what is written by the writeToPort function is buffered and not flushed? If this is the case, perhaps it’s necessary to call the $serial->write_done(0) and/or $serial->write_drain functions after the $serial->write($writeStr) call within the writeToPort function?

Here’s some notes on what I’ve done so far in case it helps anyone else:

• added universe to the main, security and updates sources in /etc/apt/sources.list
• ran “sudo apt-get update”
• ran “sudo apt-get install libwww-curl-perl libappconfig-perl libdevice-serialport-perl”
• removed “/usr/local/bin/“ from the path to config.ini in solar_poller.pl
• after using echo to pipe the output of a command sequence to bluetoothctl, then installing the bluez-tools package and using bt-agent instead, I found I could simply specify the bluetooth pin for pairing with the inverter by creating /var/lib/bluetooth/\<MAC address of BT adapter>/pincodes and adding “\<MAC address of inverter> 0000” after which rfcomm could manage passing the pin code itself
• I found I had to stop the ModemManager service (“sudo systemctl stop ModemManager”) because it would lock /dev/rfcomm0 after the bluetooth connection to the inverter connected
• ran “sudo usermod -a -G dialout \<user>” so the user I was logged in as could open /dev/rfcomm0
• at times, running “sudo rfcomm release 0” also helped
• running “while true; do sudo rfcomm connect 0 \<MAC address of inverter> 1 ; sleep 300 ; done” also helped

[danho-san]

Make sure you have the right device id encoded in the message and the checksum matches the payload. I connect to the inverter from a raspi via a cheap usb RS 485 device. Works.

[danho-san]

protocol see https://github.com/RXM307/ginlong_poller/blob/master/ginlong_rs485_protocol.pdf

[guest715]

Hi @danho-san, thanks for responding to my issue submission. When you refer to the device id, are you referring to the Bluetooth id that is configurable on the inverter between 1 and 99 and not the MAC address of the inverter? If so, my inverter is configured with the default value of 1. Should this work without any changes to solar_poller.pl and/or config.ini? If it’s the MAC address, I’m specifying the correct MAC address in the rfcomm connect command, where I’m also specifying the correct device id of 1, and in the pincodes file in /var/lib/bluetooth/\<MAC address of Bluetooth adapter in my Ubuntu machine>.

[danho-san]

MAC should not be relevant here. It's the device ID. The device ID is the 2nd byte in the message and the checksum at the end of the message needs to be correct. All the examples in the ginlong interface document have ID 02 in the messages. Like here: 7E 02 A1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A3 So, that could have been a source of error.

[guest715]

Hi @danho-san, thanks again for your reply. My inverter is configured with a device id of 1 and, looking at config.ini, by default solar_poller.pl sends a message with the correct device id (Slave address) and corresponding checksum (Check bit) so it would seem the content of the message solar_poller.pl is sending to my inverter might not be the cause of my problem:

7E 01 A1 ... A2