Yes shows up on the NUC built in BT and if I install and external BT it will scan on that too.
I just had a look on your Github in the test-SBFspot folder. In the Config.json file you have the line
“devices”: ["/dev/ttyUSB0"],
I think mine is probably on USB1 - at least thats what it looks like to me from the details I can see in the post a couple of days ago.
technically the devices line is redundant. it’s not in the plain SBFspot. the host_network: true is supposed to pick up all devices.
I will change it to usb1 in the test version. it takes about 20 mins to compile…
You can connect to the addon container with portainer if you want to poke around. any changes you make will be lost on restart.
Tried reinstalling about 15 mins ago - still the same 
Looks like the portainer is no longer able to be installed
Any other suggestions on how I can see whatts going on inside the container?
Alex has portainer.
He’s got a post on these forums somewhere too. 60+ addons
Do you know what architecture(that should be visible in portainer) type it installs as? Perhaps it’s missing a dependancy…
you can use apk add to add things to the container. I usually add nano to look at files etc.
Got the portainer working and into the console of the container. But now im a bit stuck on what to check next. Was hoping that the bluetoothctl would be available in there but it doesnt appear to be.
Not sure what you mean by the arcitecture that should be visible.
try the test version again. I added some stuff. bluetoothctl works in the test version now. You will need to reinstall/reload the store.
Ok, things are improving a little.
I reinstalled the test version but still no luck with sbfspof, exactly same 10 timeouts in 10 seconds.
When I go to the docker console, i can runn bluetoothctl and it works, it sees the bluetooth device and i can scan and see the inverter and other stuff dotted around the house.
So i guess that proves that the bluetooth is gettiing into docker, its just the SMAspot app that isnt able to connect to it.
I did check in the /dev/serial folder and all i can see there is the z-wave and zigbee adapters, i cant see it mapping the bluetooth device
dumb question…
is it actually finding the configs files and are they being filled in.
Compiled for Linux (LE) 64 bit with MySQL support
Commandline Args: -v -ad0 -am0 -mqtt -finq
Reading config '/usr/bin/sbfspot/SBFspot.cfg'
try again in 20 mins(well actually the amd64 version only takes 3 mins to compile so you should be good to go). I hadn’t added the LocalBTAddress into the generateConfig.sh
No change
Is RFComm running in the container?
What is sbfspot compiling as?
Compiled for Linux (LE) 64 bit with MySQL support?
SBFspot V3.9.5
Yet another tool to read power production of SMA solar inverters
(c) 2012-2022, SBF (https://github.com/SBFspot/SBFspot)
Compiled for Linux (LE) 64 bit with MySQL support
Commandline Args: -v -ad0 -am0 -mqtt -finq
Reading config ‘/usr/bin/sbfspot/SBFspot.cfg’
Thu Jul 28 23:45:55 2022: INFO: Starting…
bluetoothctl list
that should list the bt controller and which is default
I did try and add in dbus to the addon earlier. so a fresh install might be needed again…
did you say the nuc had builtin BT as well as using the BT dongle? I may have misunderstood your earlier post, perhaps it only the dongle.
I’m running out of ideas. You are adding the mac in with capitals? someone mentioned that earlier, although it works with either upper or lower case for me.
I suppose if you got really excited you could pair or trust the inverter… although that isn’t normally needed.
edit: I have been meaning to try and get apparmor to work… that might potentially help. When I have tried apparmor previously I get it stuck with being unable to unload the profile. which is ok if I have host os access, not so much if it’s on a remote pi3 without host access lol.
Will try an uninstall and reinstall shortly.
The NUC has built in BT and that is the mac in the last post. I also have a USB BT dongle that I tried plugging in to see if it would work, it was the one that I used on the pi when I sucessfully ran SBFspot on the pi.
When I plug the USB BT into the NUC it shows up in the docker container and Bluetoothctl shows both and I can switch wihich is the default, powere them on and off, scan etc…
The MAC of the inverter only has one letter and it is a capital. Did try changinig to lower at one point, just in case.
I did try pairing the NUC and Inverter from Bluetoothctl within the docker container. It paired but SBFspot still didnt pick it up.
I went ant looked at the bluetooth module in SBFspot last night and see that it uses RFComm but withing the container I cant find any reference. Not sure if that is relevant or not. We have proved that the bluetooth is working in the container. Its just how SBFspot is detecting the local bluetooth that isnt working.
bash-5.1# apk add rfcomm
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/aarch64/APKINDEX.tar.gz
ERROR: unable to select packages:
rfcomm (no such package):
required by: world[rfcomm]
bash-5.1# apk search rfcomm
bluez-alsa-utils-4.0.0-r2
bluez-deprecated-5.65-r0
I can try adding alsa-utils into the container.
apk add bluez-alsa-utils
if you want to try it in portainer, it’s more pointed at audio stuff.
It shouldn’t really need that or any of the other stuff that has been added. It works without all in the other version for me…
I got the same as you. What /dev usb and serial devices do you see?
This is what I see.
I added in “devices”: ["/dev/ttyACM1"],
also added that alsa utils. So try a reinstall of test again.
I don’t think the BT breaking changes effect this addon. It wasn’t using bluepy or pybluez, uses bluez instead. I did see the bleak bit, I will have to dig around with that. The addon still works for me on a pi4-superviser64bit and pi3-haos64bit, and seems to be working for a few others(although I think they might all be pi users, no NUCs… So don’t think its a breaking changes problem.
although I have locked myself out of the pi3 due the apparmor thing atm. I will have to use a different addon on that lol.
That is what I get with ls -l /dev/serial/* and ls -l /dev/se* on pi4
bash-5.1# ls -l /dev/serial/*
/dev/serial/by-id:
total 0
lrwxrwxrwx 1 root root 13 Jul 29 01:17 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B00039D688D-if00 -> ../../ttyACM0
/dev/serial/by-path:
total 0
lrwxrwxrwx 1 root root 13 Jul 29 01:17 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0 -> ../../ttyACM0
bash-5.1# ls -l /dev/serial*
lrwxrwxrwx 1 root root 5 Jul 29 01:17 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Jul 29 01:17 /dev/serial1 -> ttyAMA0
/dev/serial:
total 0
drwxr-xr-x 2 root root 60 Jul 29 01:17 by-id
drwxr-xr-x 2 root root 60 Jul 29 01:17 by-path
bash-5.1# ls -l /dev/se*
lrwxrwxrwx 1 root root 5 Jul 29 01:17 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Jul 29 01:17 /dev/serial1 -> ttyAMA0
/dev/serial:
total 0
drwxr-xr-x 2 root root 60 Jul 29 01:17 by-id
drwxr-xr-x 2 root root 60 Jul 29 01:17 by-path
bash-5.1# ls -l /dev/se*
lrwxrwxrwx 1 root root 5 Jul 29 01:17 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Jul 29 01:17 /dev/serial1 -> ttyAMA0
/dev/serial:
total 0
drwxr-xr-x 2 root root 60 Jul 29 01:17 by-id
drwxr-xr-x 2 root root 60 Jul 29 01:17 by-path
pi3 as above, no usb on the pi3
bash-5.1# ls -l /dev/serial/*
ls: /dev/serial/*: No such file or directory
bash-5.1# ls -l /dev/se*
lrwxrwxrwx 1 root root 7 Mar 11 18:33 /dev/serial1 -> ttyAMA0