NEWS
SBFspot funktioniert nicht - Communication Error
-
@thommythekid
Der aktuelle SunnyExplorer erzwingt ein "besseres" Passwort!
Die Standardpasswörter 0000 bzw. 1111 können damit nicht mehr verwendet werden.
Nur mit einem alten SunnyExplorer ist die Verwendung von 0000 als Userpasswort noch möglich.Die Net-ID sollte 1 für eine Punkt zu Punkt Verbindung und > 1 für ein SMA Mesh Netzwerk sein.
Bei Bedarf kann ich einen "alten" SunnyExplorer bereitstellen.
Ich bin mir ziemlich sicher, dass Deine Probleme nach einem Firmwareupdate (mit SD-Karte!) gelöst sind.
ACHTUNG!
Wenn die aktuelle Firmware < 1.71 ist, erst auf Firmware 1.71 und in einem zweiten Schritt auf 3.20 Updaten. Beide Versionen sind im ZIP enthalten.P.S. Ich habe keinen Bluetooth SunnyBoy, nur einen SB 3300 TL-HC, habe mich aber in der Vergangenheit intensiv mit SMA Bluetooth befasst.
Tschau
Uwe -
@uweklatt Das mit den Standardpasswörtern hab ich ja verstanden, aber ich habe ja nun
schon X-fach ein neues konformes PW vergeben, für USER und INST - nur es hat nichts bewirkt (Wahrscheinlich weil er das neue PW nicht erfolgreich in den WR übertragen kann - kommt aber auch keine Fehlermeldung). Er geht einfach in den Hauptbildschirm über und sagt nichts.
Wenn ich den Sunny Data Explorer dann schließe und wieder öffne, soll ich erneut die Passwörter ändern... Und die angezeigte NetID FF hab nicht ich mir ausgesucht - die wird einfach so angezeigt.Noch etwas, was vielleicht eine gewisse Logik reinbringt (Erklärung wären unterschiedliche Bluetooth Protokolle). Ich hab den Longshine Bluetooth Adapter wieder an den alten Windows95 PC gehängt und testen wollen ob alles noch funktioniert. Dabei habe ich festgestellt, dass die Software, die ich damals installiert habe und die ich noch immer verwende Sunny Data Control 4.0 - nicht Sunny Explorer heißt !!
Ich denke, so kann das Ganze evtl. dann doch wieder Sinn machen. Sunny Data Control (wie es aussieht nur bis Windows7) - kompatibel mit dem alten Bluetooth Protokoll des WR und Sunny Explorer (mit Windows 10) - kompatibel mit dem neuen Bluetooth Protokoll und damit nicht fähig mit meinem WR mit dem aktuellen FW Stand vernünftig zu kommunizieren...
Wäre dann aber schon schwach, wenn SMA keine Abwärtskompatibilität in Sunny Explorer eingebaut hat.
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 ...viele Grüße
ThommyTheKid -
@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" -
@sbf We are coming closer...
Thank you very much for this link - I was able to Download Sunny Data Control 4.0, which I have searched for a long time before without success. Next I installed it without any problems on my Windows 10 machine. And finally I was able to Connect the inverter with my new stick LogiLink BT-0015 and it worked out of the box ! So special driver needed ! All the information I found before on the internet seems to be rubbish !Well, at least I have a working solution on a more current Windows which makes it easier to try to sniff the BT network traffic.
But to be able to then change SBFspot accordingly (this might be some try and error approaches) I need to get this thing compiled on my Raspi. And I am not able to do so right now ! @sbf: do you probably also have a link to a documentation how to build (not only install) SBFspot on Raspi ?
After copying the git sources from the SBFspot directory I tried:
pi@raspberrypi:~/tom_sbf $ make test -d || mkdir -p test -d sqlite/bin/ || mkdir -p sqlite/bin/ g++ -s -o sqlite/bin/SBFspot -Wl,-Bdynamic -lpthread -lbluetooth -lboost_date_time -lboost_system /usr/bin/ld: cannot find -lboost_date_time /usr/bin/ld: cannot find -lboost_system collect2: error: ld returned 1 exit status make: *** [makefile:119: sqlite/bin/SBFspot] Error 1
also this call fails with a fully different error message:
pi@raspberrypi:~/tom_sbf $ make nosql test -d nosql/obj/ || mkdir -p nosql/obj/ test -d nosql/bin/ || mkdir -p nosql/bin/ g++ boost_ext.cpp -c -Wall -O2 -Wno-unused-local-typedefs -Wno-psabi -std=c++11 -o nosql/obj/boost_ext.o In file included from boost_ext.cpp:35: boost_ext.h:47:10: fatal error: boost/version.hpp: No such file or directory #include <boost/version.hpp> ^~~~~~~~~~~~~~~~~~~ compilation terminated. make: *** [makefile:116: nosql/obj/boost_ext.o] Error 1
What I would need is a full description how to build SBFspot on Raspi from scratch !
kind regards
ThommyTheKid -
@thommythekid it´s all in the wiki
https://github.com/SBFspot/SBFspot/wiki/Installation-Linux-SQLite -
@sbf GREAT THANKS !! I have the make running, after performing the steps described in the Wiki from the beginning... But the executable does still not work - still aborts with the message: "CRITICAL: Failed to initialize communication with inverter"
But I am able to build the executable now which is great. Let's see if I get get further here.
Do you know if there is also a kind of documentation of the Bluetooth protocol somewhere within the SBFspot project ?If I do not make progress I am considering the sniffing approach. Let's see.
kind regards
ThommyTheKid -
@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 FWBelow 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.
-
I found a very old issue with the exact same problem and the solution (spoiler: FW upgrade)
https://github.com/SBFspot/SBFspot/issues/37 -
@sbf Hi again,
well I really fear that something goes wrong when I try a software update since this is a very old system that is running for almost 14 years now and I would prefer not to touch it. I have read about cases where folks have bricked the inverters and the only answer from SMA was an expensive hardware replacement of the whole inverter.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).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 <<<=================================>>>
I think I have understood that it always starts with 7E followed by the length (1B in my case - so 27 decimal) - right ? You also mentioned NetID is pos 22 (decimal) - ok - it is 1 in my case.
What does getPacket(2) or getPacket(5) mean ?
To me it looks like byte 16 is the command - right ?
The commands occur in the sequence cmd = 2, cmd =10, cmd =5 !
But what does this command mean ? Can you tell me ?kind regards
ThommyTheKid -
@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.