@sbf said in SBFspot funktioniert nicht - Communication Error:

I've never heard of bricked inverters.
Now that I have more info I doubt if we have to spent more time to make SBFspot compatible with this old version of the protocol. If I have a trace log I can see if it possible in a short time frame.

But I took a closer look to the data and have some questions: In the output it looks like
each block occurs twice (when calling with -d5).

The first block is the raw data, the second is the unescaped version: when the data contains 0x7E it is converted to 0x7D + ...
0x7E is start/stop byte of packet (BT only)

What does getPacket(2) or getPacket(5) mean ?
To me it looks like byte 16 is the command - right ?
But what does this command mean ?

cmd is indeed at pos 16. If the meaning is known it is commented in the source code. The SMADATA2+ protocol is reverse engineered and a lot of its data is unknown.

@thommythekid

I found a very old issue with the exact same problem and the solution (spoiler: FW upgrade)
https://github.com/SBFspot/SBFspot/issues/37

SBFspot created this issue in SBFspot/SBFspot

closed CRITICAL: Failed to initialize communication with inverter. #37

@thommythekid said in SBFspot funktioniert nicht - Communication Error:
Still not choosing the path of FW upgrade? V3+ has shadow management (in case you suffer from shadow of course)

Do you know if there is also a kind of documentation of the Bluetooth protocol somewhere within the SBFspot project ?

No, I had some notes on paper but I can't find the anymore (started with SMAspot 10y ago - had to rename it to SBFspot because I used the name SMA. In fact, SMAspot was exactly the name SMA had choosen for their direct marketing stuff: https://www.sma-spot.de/ they even copied my logo )
There are some brief comments in the code, that's all. Moreover, I was forced to move the project a few times (Google code -> Codeplex -> Github) so a lot of info got lost (discussions and issue tracker)

I had the time to compare the start of the communication of your inverter (SB5000 TL-20) and mine of the same family (SB4000 TL-20) and I see the first response is already different:

SB4000:

Initializing...
SUSyID: 125 - SessionID: 935089161 (0x37BC5409)
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 17 00 69 00 00 00 00 00 00
00000010: 01 00 00 00 00 00 01 02 76 65
00000020: 72 0D 0A
23 Bytes sent
getPacket(2)
MAX_CommBuf is now 18 bytes
Received 18 bytes
Received 13 bytes
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 1F 00 61 E7 D3 15 25 80 00
00000010: 00 00 00 00 00 00 02 00 00 04
00000020: 70 00 01 00 00 00 00 01 00 00
00000030: 00
cmd=2
<<<====== Content of pcktBuf =======>>>
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 1F 00 61 E7 D3 15 25 80 00
00000010: 00 00 00 00 00 00 02 00 00 04
00000020: 70 00 01 00 00 00 00 01 00 00
00000030: 00
<<<=================================>>>
MAX_pcktBuf is now 31 bytes
SMA netID=01

SB5000:

Initializing...
SUSyID: 125 - SessionID: 938752662 (0x37F43A96)
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 17 00 69 00 00 00 00 00 00
00000010: 01 00 00 00 00 00 01 02 76 65
00000020: 72 0D 0A
23 Bytes sent
getPacket(2)
MAX_CommBuf is now 18 bytes
Received 18 bytes
Received 9 bytes
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 1B 00 65 26 58 08 25 80 00
00000010: 00 00 00 00 00 00 02 00 00 03
00000020: 70 00 01 01 00 00 00
cmd=2
<<<====== Content of pcktBuf =======>>>
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 1B 00 65 26 58 08 25 80 00
00000010: 00 00 00 00 00 00 02 00 00 03
00000020: 70 00 01 01 00 00 00
<<<=================================>>>
MAX_pcktBuf is now 27 bytes
SMA netID=01

When you look inside the "Content of pcktBuf" the two look pretty much the same:
Start byte 7E, #bytes, checksum and MAC address
All the rest is unknown, except for NetID (= 1) at pos 22
At pos 19 we might have some kind of versioning: 3 vs 4 for newer FW

Below the response of another SB5000 TL-20:

--------: 00 01 02 03 04 05 06 07 08 09
00000000: 7E 1F 00 61 D0 0A 0A 25 80 00
00000010: 00 00 00 00 00 00 02 00 00 04
00000020: 70 00 01 00 00 00 00 01 00 00
00000030: 00

Probably this is the way to differenciate between FW versions.

@thommythekid it´s all in the wiki
https://github.com/SBFspot/SBFspot/wiki/Installation-Linux-SQLite

@thommythekid said in SBFspot funktioniert nicht - Communication Error:

Hätte jemand mal einen vernünftigen Link auf eine Anleitung wie nun der Software Update des WR vonstatten gehen soll. Und einen Link auf die Firmware des WR Sunny Boy 5000TL-20 ?
Ich finde auf der SMA Seite nichts ! Nur Kraut und Rüben ...

https://www.sma.de/en/service/downloads.html
Select "Archive"

@thommythekid Sorry for my answer in English - Mein Deutsch ist nicht so gut
My experience with Raspberry Pi and Bluetooth is that it's a complicated relationship. That said, it's not sure your LogiLink BT-0015 adapter still works flawlessly with newer versions of Raspberry Pi OS (Raspbian)
So, if you can borrow another BT adapter from someone, it is possible SBFspot works correctly. That is the easiest thing to test.
An fimware update might help but is rather drastic. BTW, I doubt if there is still one available for your model.
As a last resort (and I really want to help here) you can sniff the BT traffic between sunny explorer and the inverter (USBlyzer is great for that) If you can provide me the communication data, I might get a solution to make it work. But remember: your setup of sunnyexplorer on windows and SBFspot on raspbian is totally different with different BT hard- and software. Your first test should be another BT adapter on the RPi