I’m absolutely sure using the right password and have no more idea what ton change. The BT quality seems good enough with >70%.
Today all my further connection trials failed. Maybe something changed with last update?
Do you have “quotes” wrapping the password?
The addon is particularly troublesome with “quote mark” as the text is converted from HA to the addon and then to the SBFspot config file. Especially when swapping from UI config mode to YAML config mode.
The password should be showing as “password” in the YAML config
I doubt the update of HA will be the problem, but I haven’t updated yet to confirm.
Thank you @HasQT for your message.
Interesting. As shown in my config.yaml above (Post #359) some of the options are in quote marks, some not.
But all of the passwords are not quoted.
Example with password “TestPW”
Way 1 via GUI: I type TestPW in the password field and when I switch to yaml I also see TestPW without quotes.
Way 2 via yaml: I type “TestPW” with quotes in yaml => click SAVE => quotes dissapear
At my Tests 2-3 ago with successfull connections I used the same password also without quotes.
Yeah the quotes can be annoying, that was why I swapped to using secrets.
This is how my config looks in yaml mode. I have my details in secrets, which means I can also uninstall/reinstall the addon easily on my test machine etc…
All my secret file text is “quote wrapped” like this
Homeassistant needs a restart after adding text to secrets.
BTAddress: "00:80:34:2A:C6:48"
Connection_Type: Bluetooth
Sensors_HA: "No"
BTAddress: "!secret BTAddress"
Password: "!secret SBFpassword"
LocalBTAddress: "!secret LocalBTAddress"
IP_Address: 55.255.255.255
Plantname: "!secret SBFplantname"
Latitude: "!secret home_lat"
Longitude: "!secret home_long"
Timezone: "!secret Timezone"
DateTimeFormat: "'%H:%M:%S %d-%m-%y'"
SQL_Password: "!secret mariadb_pw"
MQTT_User: "!secret mqtt_user"
MQTT_Pass: "!secret mqtt_pass"
MQTT_Topic: homeassistant/sbfspot_{plantname}/sbfspot_{serial}
MQTT_Data: >-
PrgVersion,Plantname,Timestamp,SunRise,SunSet,InvSerial,InvName,InvTime,InvStatus,InvSwVer,InvClass,InvType,InvTemperature,InvGridRelay,EToday,ETotal,GridFreq,PACTot,PAC1,UAC1,IAC1,OperTm,FeedTm,PDCTot,UDC1,UDC2,IDC1,IDC2,PDC1,PDC2,BTSignal,InvWakeupTm,InvSleepTm
PVoutput_SID: "!secret pvoSID"
PVoutput_Key: "!secret pvoAPIkey"
LogLevel: info
FYI just tried using the addon on HAOS 2025.1.1 and it worked without issue.
Tried that. Made no difference. I get no connection to the inverter, whatever I try.
With SBFspot @ Windows on my laptop (near my RP4 with HA) it just takes about 3 seconds to connect, get all wanted values, and disconnect again.
No connection (10\10 attempts fail) or logon failure?
You don’t have complicated password with special characters in it? That trips up the config too.
If it’s logon failure, and you are using secrets, just uninstall\reinstall the addon. That should clear config errors that remain.
The addon runs the same SBFspot as what is running on your PC. The results should be similar.
You can login to the addon and double check your SBFspot.cfg file being written correctly using the terminal (the community one, not the official one)
The command is.
docker exec -it addon_a51a23d8_haos-sbfspot /bin/bash
then
nano SBFspot.cfg
Both. I had this several times today with one, two or three connection attempts:
Connecting to 00:80:25:1E:78:59 (1/10)
Connecting to 00:80:25:1E:78:59 (2/10)
Connecting to 00:80:25:1E:78:59 (3/10)
Initialising...
SUSyID: 125 - SessionID: 856275878
SMA netID=01
Thu Jan 9 14:45:34 2025: CRITICAL: Failed to initialise communication with inverter.`
I also deactivated my internal BT or my external BT and removed my external BT. Made no difference.
No. Easy Password. And it already worked sometimes. And works with the windows version.
Tried that. Wasn’t better.
How to do that without Docker? I have HAOS on a RP4 (and 2 terminal addons).
That’s command for HAOS on rpi4 using Advanced SSH & Web Terminal.
You can run SBFspot directly from the terminal after that command.
HAOS runs on docker(a fairly locked down version). Addons are just docker containers configured to work with HA supervisor.
This is a different error. I think that might be a Bluetooth problem. Perhaps when you removed the BT dongle. These are SBFspot errors though, they don’t come from the addon.
I have done a lot more testing in the meantime and it has cost me a lot of nerves. Most of the time it didn’t work and it wasn’t because of the settings. I tried everything there too…
Then I moved my Home Assistant to a Proxmox VM on a thin client. No change. However, I continued to use the existing external Bluetooth stick. After that didn’t work either, I tried using a different Bluetooth stick. And that was the solution. It works great with the other stick. Thank you @HasQT for your support!
1 Like
Good to hear.
Out of curiosity did you try rpi4 with the new BT dongle?
I personally use a rpi4, I just use the internal Bluetooth. My rpi4 is only about 3 metres from my inverter in my garage though.
I use a VM for testing from my pc. That is about 5 metres away through a few walls.
No, I didn’t. But I’m quite sure that it would work with my RP4 and the new BT stick.
1 Like
Hi @HasQT, is it also possible to use the HA internal SQlite DB instead the MariaDB?
No, not as the addon is currently setup. It would need a different version of SBFspot setup. It also needs the dependencies for SQLite instead of MariaDB added to the docker file for installation. Not impossible. Although it would make more sense as a separate Addon if someone wanted to do a fork for that.
The SQLite DB would need a table structure added in a similar way to MariaDB using the phpMyAdmin addon or similar. I am not sure HA would deal with that table during DB maintenance/updates. It may decide that’s foreign and delete it…
The biggest issue is coordinating with the database when it gets locked down for updates and backups, as that is time when SBFspot would be locked from writing to the DB. That usually causes errors, and I’m not great at interacting with the HA supervisor via the addon controls.
It’s certainly possible in a new addon with the relevant testing.
Edit:
It is also kind of redundant if you aren’t using PVoutput. MariaDB is only used for SBFspotUpload to send data to PVoutput. Data that HA actually receives via MQTT should already be stored in the SQLite DB under the linked MQTT entities. Although the they are probably purged after a timeframe. The MariaDB from the addon standpoint doesn’t have a regular purge interval setup.
Thank you. I wanted to test/use pvoutput. As far as I understand it, this requires the use of the database (MariaDB) entries, right?
Yeah SBFspot parks data in MariaDB. The database table then does abit of a calculation(for nearest 5min data if I recall, that comes from SBFspot directly I don’t change it). The data is then uploaded via SBFspotUpload to PVoutput.
Thanks for the great add-on! However, I still seem to run into some troubles.
This is an extract from the log:
Grid Freq. : 0.00Hz
SUSyID: 138 - SN: 2XXXXXXXXX
Current Inverter Time: 2025-02-08T03:03:19+0100
Inverter Wake-Up Time: 2025-02-07T08:39:13+0100
Inverter Sleep Time : 2025-02-08T03:02:56+0100
MQTT: Publishing (homeassistant/sbfspot_{plantname}/sbfspot_{serial}),"PrgVersion": "3.9.11","Plantname": "PV_Zadeldak","Timestamp": "2025-02-08T03:02:41+0100","SunRise": "2025-02-08T08:10:00+0100","SunSet": "2025-02-08T17:47:00+0100","InvSerial": 2XXXXXXXXX,"InvName": "SB 3600TL-21 409","InvTime": "2025-02-08T03:03:19+0100","InvStatus": "Ok","InvSwVer": "02.81.01.R","InvClass": "Solar Inverters","InvType": "SB 3600TL-21","InvTemperature": 0.000,"InvGridRelay": "Information not available","EToday": 0.000,"ETotal": 34653.087,"GridFreq": 0.000,"PACTot": 0.000,"PAC1": 0.000,"UAC1": 0.000,"IAC1": 0.000,"OperTm": 37246.910,"FeedTm": 35773.416,"PDCTot": 0.000,"UDC1": 0.000,"UDC2": 0.000,"IDC1": 0.000,"IDC2": 0.000,"PDC1": 0.000,"PDC2": 0.000,"BTSignal": 0.000,"InvWakeupTm": "2025-02-07T08:39:13+0100","InvSleepTm": "2025-02-08T03:02:56+0100"
Client null sending CONNECT
Client null received CONNACK (5)
Actually, the logs seems to hang here for a long time. After a few refreshes and many minutes later, this appears:
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
<!--[if IE 7]> <html class="no-js ie7 oldie" lang="en-US"> <![endif]-->
<!--[if IE 8]> <html class="no-js ie8 oldie" lang="en-US"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en-US"> <!--<![endif]-->
<head>
<title>my.ha.url | 524: A timeout occurred</title>
Where my.ha.url is the public URL of my Home Assistance appliance routed through a Cloudflare tunnel. It seems SBFspot is using this URL somewhere to contact something. However, in the SBFspot config, I have explicitly set “core-mariadb” as hostname for mariadb and “core-mosquitto” for mqtt. I can ping these from the terminal in the HA.
Moreover: when I check config of MQTT and listen on the # topic, I see these messages coming from SBFspot like these, which indicate MQTT is working:
Message 282 received on homeassistant/sensor/sbfspot_PV_Zadeldak/sbfspot_XXXXXXXXXXInvSleepTm/config at 3:22 AM:
{"name": "SMA sleep time", "state_topic": "homeassistant/sbfspot_PV_Zadeldak/sbfspot_XXXXXXXXXX", "value_template": "{{ value_json.InvSleepTm | as_timestamp | timestamp_custom( '%H:%M:%S %d-%m-%y' ) | default() }}", "unique_id": "XXXXXXXXXX_InvSleepTm", "enabled_by_default": "true", "icon": "mdi:sleep", "device": { "identifiers": ["HAOS-SBFspot-Sensors"], "name": "HAOS-SBFspot", "model": "SB 3600TL-21", "manufacturer": "SMA", "sw_version": "02.81.01.R" }}
Although, the sensor values are not updated.
What could be wrong? Thanks!
In the logs of MQTT, I see this:
2025-02-08 02:32:36: New connection from 172.30.32.1:43906 on port 1883.
2025-02-08 02:32:36: New client connected from 172.30.32.1:43906 as auto-41ECE56C-E0B8-3AA2-D5F4-10D6C83B51CE (p2, c1, k60, u'sbfspot').
2025-02-08 02:32:36: Client auto-41ECE56C-E0B8-3AA2-D5F4-10D6C83B51CE disconnected.
[40+ similar entries at the same timestamp]
2025-02-08 02:32:36: New connection from 172.30.32.1:44026 on port 1883.
2025-02-08 02:32:36: New client connected from 172.30.32.1:44026 as auto-996BFD05-A95B-41F7-EB3F-D3022F03E087 (p2, c1, k60, u'sbfspot').
2025-02-08 02:32:36: Client auto-996BFD05-A95B-41F7-EB3F-D3022F03E087 disconnected.
2025-02-08 02:32:37: New connection from 172.30.32.1:44040 on port 1883.
2025-02-08 02:32:37: New client connected from 172.30.32.1:44040 as auto-96193F54-03C9-C2D9-8890-E81889DCBF8E (p2, c1, k60, u'sbfspot').
2025-02-08 02:32:37: Client auto-96193F54-03C9-C2D9-8890-E81889DCBF8E disconnected.
[also various similar entries]
2025-02-08 02:32:37: New connection from 172.30.32.1:44158 on port 1883.
2025-02-08 02:32:37: New client connected from 172.30.32.1:44158 as auto-FB16CB88-22B0-D3F5-4FA1-3B46E1707242 (p2, c1, k60, u'sbfspot').
2025-02-08 02:32:37: Client auto-FB16CB88-22B0-D3F5-4FA1-3B46E1707242 disconnected.
2025-02-08 02:33:09: New connection from 172.30.32.1:53048 on port 1883.
2025-02-08 02:33:09: Client auto-8B7BF295-FECB-7A74-7D6A-22448A39D71D disconnected, not authorised.
2025-02-08 02:44:24: Saving in-memory database to /data//mosquitto.db.
2025-02-08 02:53:53: New connection from 172.30.32.1:34832 on port 1883.
2025-02-08 02:53:53: New client connected from 172.30.32.1:34832 as auto-0F325395-A7B7-AE87-0320-DBD1614824CF (p2, c1, k60, u'sbfspot').
2025-02-08 02:53:53: Client auto-0F325395-A7B7-AE87-0320-DBD1614824CF disconnected.
[idem]
2025-02-08 02:53:54: New connection from 172.30.32.1:35124 on port 1883.
2025-02-08 02:53:54: New client connected from 172.30.32.1:35124 as auto-1470B7A8-8BF2-114D-B4A9-1C863769D98B (p2, c1, k60, u'sbfspot').
2025-02-08 02:53:54: Client auto-1470B7A8-8BF2-114D-B4A9-1C863769D98B disconnected.
2025-02-08 02:54:26: New connection from 172.30.32.1:33440 on port 1883.
2025-02-08 02:54:26: Client auto-6F125003-9603-FA58-5E55-A9E1BECB1F83 disconnected, not authorised.
2025-02-08 03:02:08: New connection from 172.30.32.1:45320 on port 1883.
2025-02-08 03:02:08: New client connected from 172.30.32.1:45320 as auto-D7B3559A-7A4E-8C67-48E3-26A1AA2366DC (p2, c1, k60, u'sbfspot').
2025-02-08 03:02:08: Client auto-D7B3559A-7A4E-8C67-48E3-26A1AA2366DC disconnected.
[idem]
2025-02-08 03:02:09: New client connected from 172.30.32.1:45608 as auto-CB776FC3-BF11-F5A0-BE81-C5D9707FC0DE (p2, c1, k60, u'sbfspot').
2025-02-08 03:02:09: Client auto-CB776FC3-BF11-F5A0-BE81-C5D9707FC0DE disconnected.
2025-02-08 03:02:09: New connection from 172.30.32.1:45616 on port 1883.
It seems the SBFspot add-on publishes his stuff on MQTT (although the sensor values don’t get updated) and then tries to do something else (upload data to PVoutput?) but then crashes… It might be that I manually restarted the add-on, causing some new attempts.
More info: the Cloudflare webpage being served after timeout seems to be a thingy in live log windows as it also appears in the MQTT log. Moreover: when I refresh the live log page of SBFspot, I see the previous information back again, with the old timestamps of 45 minutes ago, still hanging, and having the Cloudflare timeout appearing after a long while.
Although, the SBFspot container seems to hang as no more clients are connecting to the MQTT. The latest message on the MQTT topic is always this one:
Message 33 received on homeassistant/sensor/sbfspot_PV_Zadeldak/sbfspot_XXXXXXXXXXInvSleepTm/config at 3:57 AM:
{"name": "SMA sleep time", "state_topic": "homeassistant/sbfspot_PV_Zadeldak/sbfspot_
where the timestamp of the message is always the time of accessing the MQTT config page. More messages are coming in from other sources, but after a refresh of the page, the InvSleepTm message is always the latest, received at the current time…
Update:
When I visit the logs page of the SBFspot through the private hostname on the LAN instead of the public URL on Cloudflare, I get this:
Inverter Wake-Up Time: 2025-02-07T08:39:13+0100
Inverter Sleep Time : 2025-02-08T03:02:56+0100
MQTT: Publishing (homeassistant/sbfspot_{plantname}/sbfspot_{serial}),"PrgVersion": "3.9.11","Plantname": "PV_Zadeldak","Timestamp": "2025-02-08T03:02:41+0100","SunRise": "2025-02-08T08:10:00+0100","SunSet": "2025-02-08T17:47:00+0100","InvSerial": XXXXXXXXXX,"InvName": "SB 3600TL-21 409","InvTime": "2025-02-08T03:03:19+0100","InvStatus": "Ok","InvSwVer": "02.81.01.R","InvClass": "Solar Inverters","InvType": "SB 3600TL-21","InvTemperature": 0.000,"InvGridRelay": "Information not available","EToday": 0.000,"ETotal": 34653.087,"GridFreq": 0.000,"PACTot": 0.000,"PAC1": 0.000,"UAC1": 0.000,"IAC1": 0.000,"OperTm": 37246.910,"FeedTm": 35773.416,"PDCTot": 0.000,"UDC1": 0.000,"UDC2": 0.000,"IDC1": 0.000,"IDC2": 0.000,"PDC1": 0.000,"PDC2": 0.000,"BTSignal": 0.000,"InvWakeupTm": "2025-02-07T08:39:13+0100","InvSleepTm": "2025-02-08T03:02:56+0100"
Client null sending CONNECT
Client null received CONNACK (5)
MQTT: Failed to execute '/usr/bin/mosquitto_pub' mosquitto client installed?
Connection error: Connection Refused: not authorised.
Error: The connection was refused.
Error 1280 while publishing to MQTT Broker
Reading events: 2025-Feb-01
Sat Feb 8 03:02:42 2025: INFO: Done.
INFO: SBFspotUploadDaemon Version 3.0.4
On the public URL, the log seems to crash right after “Client null received CONNACK (5)”, throwing the timeout message many minutes later on.
But very weird there is an error on connecting to the MQTT broker whilst I can see the messages appearing when I listen to the topic?
Have you set up a user and password in the MQTT addon or in homeassistant? You need a separate Username/password combo created for the SBFspot addon to connect to the MQTT addon.
This looks to be the SBFspot addon in the MQTT log. the connection and disconnection is prettty normal. It doesn’t hold open the connection, just sends message and disconnects.
This looks like an unrelated connection to SBFspot. Some other device you are using.
As for the cloudflare error, that looks like a general timeout. Not something I’ve have come across before. I don’t use cloudflare. Not sure where you should start to begin troubleshooting that error. Could be hardware or isp related.
edit:
when you say the Addon is hanging, what time is it? The addon generally doesn’t poll the inverter overnight at say 3am. It usually just runs just outside of sunrise/sunset hours. It should still progress the log though.
[06:20:45] INFO: [SBFspot Upload Log Latest]
SBFspot V3.9.11
Yet another tool to read power production of SMA solar inverters
(c) 2012-2024, SBF (https://github.com/SBFspot/SBFspot)
Compiled for Linux (LE) 64 bit with MySQL support
Commandline Args: -v -ad1 -am0 -ae0 -mqtt
Reading config '/usr/bin/sbfspot/SBFspot.cfg'
Sat Feb 8 06:25:00 2025: INFO: Starting...
sunrise: 06:42
sunset : 20:23
Nothing to do... it's dark. Use -finq to force inquiry.
[06:25:45] INFO: [SBFspot Upload Log Latest]
SBFspot V3.9.11
Yet another tool to read power production of SMA solar inverters
(c) 2012-2024, SBF (https://github.com/SBFspot/SBFspot)
Compiled for Linux (LE) 64 bit with MySQL support
Commandline Args: -v -ad1 -am0 -ae0 -mqtt
Reading config '/usr/bin/sbfspot/SBFspot.cfg'
Sat Feb 8 06:30:00 2025: INFO: Starting...
sunrise: 06:42
sunset : 20:23
Connecting to 00:80myinverter
Hi @HasQT, thanks!
Yes, sure:
(for some reason I get an error when putting both screenshots in one post, so I took a screenshot from the preview and put it here)
Actually, when I reload the add-on, it runs the script once and I see the MQTT messages appear on the topic when I subscribe to it in the MQTT integration. So when they are published, I suppose login was succesfull and access to the topic granted?
Message 33 received on HAOS-SBFspot/device at 11:07 PM:
{"InvSerial": XXXXXXXXXX,"InvName": "SB 3600TL-21 409","InvClass": "Solar Inverters","InvType": "SB 3600TL-21","InvSwVer": "02.81.01.R"}
I also see in the MQTT log the connections are closed normally, and not with a “not authorized” or “timeout” message like for some other users I still have to solve:
2025-02-09 22:53:48: New connection from 172.30.32.1:50338 on port 1883.
2025-02-09 22:53:48: New client connected from 172.30.32.1:50338 as auto-8BC1099C-9BF9-062E-43C4-458A398F44CA (p2, c1, k60, u'sbfspot').
2025-02-09 22:53:48: Client auto-8BC1099C-9BF9-062E-43C4-458A398F44CA disconnected.
2025-02-09 22:54:21: New connection from 172.30.32.1:49610 on port 1883.
2025-02-09 22:54:21: Client auto-26E09844-F821-B9BE-16E2-F4895DD085F8 disconnected, not authorised.
2025-02-09 22:54:51: New connection from 192.168.3.82:53000 on port 1883.
2025-02-09 22:54:51: New client connected from 192.168.3.82:53000 as Sofar2mqtt (p2, c1, k15, u'sofar2mqtt').
2025-02-09 22:55:25: Client Sofar2mqtt has exceeded timeout, disconnecting.
I also enabled debug logging on MQTT and see the message appear over there in the log, so I assume succcesfull authentication?
2025-02-09 23:07:02: Sending PUBLISH to 7cmoZpZjQ0JKE9TUxKZR9D (d0, q0, r1, m0, 'homeassistant/sensor/sbfspot_PV_Zadeldak/sbfspot_XXXXXXXXXX/config', ... (503 bytes))
2025-02-09 23:07:02: Sending PUBLISH to 7cmoZpZjQ0JKE9TUxKZR9D (d0, q0, r1, m0, 'homeassistant/sensor/sbfspot_PV_Zadeldak/sbfspot_XXXXXXXXXX/config', ... (503 bytes))
2025-02-09 23:07:02: Sending PUBLISH to 7cmoZpZjQ0JKE9TUxKZR9D (d0, q0, r1, m0, 'homeassistant/sensor/sbfspot_PV_Zadeldak/sbfspot_XXXXXXXXXXOperTm/config', ... (526 bytes))
My guess is that it’s somewhere related to the way the log frame is kept open. More home assistant core related than MQTT/SBFspot.
Indeed. But does it run once when you reload the integration? Kind of a forced run?
At least, it should have run the whole past day now 