maybe you will have some luck, but all rpi3 I’ve tried had frozing bluetooth after like 6-10 requests. rpi3+ does not have those issues at all.
you can definitely try to run sbfspot with built-in bt and if it will work for whole day, you’ll have quite big chance it will run reliably since then, if not … well disable onboard BT and go dongle
are you running somewhere some sql database for something? as sbfspot is way easier to use that way.
if not, it’s not end of the world.
My Rpi´s are all 3B models, one is actually 3B+ (the one running my main openhab server).
Hmailserver (my mail server) uses Microsoft SQL server compact 3.5 ENU. But I have no idea how to add databases to it. It was all done by Hmailserver installer.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
51
I can organise you a Bluetooth dongle for the C2 if you want one?
Thanks Start. But I think I´ll try go with the LAN connection which is already there, (not sure if it will conflict with the inverter having connection to the SMA Smart Energy Meter at the same time). If it does, a BT dongle might come in hand.
Hi all,
Sounds interesting, but I lost how to being able to gather information from SMA SunnyBoy with Speedwire WebConnect? Do I have to run the Python Script, or simply Mqtt, which is running on my OpenHab to connect to Worx Landroid anyway. I believr/understood I have to do some configuration with Mqtt? But fail to get it working/configured properly.
My OpenHab is running on a Windows Machine
Regards,
Joerg
Typical problems include register numbering versus addressing. Historically, modbus register number 1 is found at address 0. It is often unclear which variation any given document talks about.
openHAB modbus binding always talks addresses; so sometimes if register NN looks funny it is worth checking register NN-1.
Then modbus has “table” addressing - traditionally, different types of modbus register are distinguished by the numbering i.e. “discrete” are 10001 to 19999, “input” are 30001 to 39999.
The table numbers are not used in the protocol layer - “input 30775” would be configured in the binding as “Input type, 774”. Probably?!
Table number use limits the address range, so “extended addressing” is also used. That just means that 30775 means 30775 (or maybe 30774) and that’s what you’d put in the binding config.
32-bit (or 64-bit etc.) values can highlight another issue. Modbus protocol only knows 16-bit registers, to make a 32-bit value we must use two registers. Usually NN and NN+1 - but which is the “high” part and which the “low”? There is no rule and not even a convention, is it A+B or B+A?
The binding provides two versions of datatypes i.e. int32 and int32swap. It’s up to you to find out which your device uses.
For 32-bit words, they can be signed or unsigned integers. Furthermore, they can be float numbers - at least there is a convention for that using IEEE encoding. But the word-swap dilemma still applies.
So its a bit of a nightmare. “Address 30775” might be 30774 or 775 or 774, the format might be int32 or or uint32 or float32 or int32swap or uint32swap or float32swap.
The manufacturer docs may give more help, sometimes you have to trial and error.
I recognize the formatting/parsing challenges, but have been able to setup a connection to my SMA Sunny Boy over the WiFi via the standard Modbus binding.
I do still have some parsing challenges, where my current config has a Modbus poller for each data field eg. I have 1 poller setup on address 30775, with length 2, type ‘input register’ to pull current power in kWh. Setup of the data field uses the same address 30775, with type 32 bit unsigned integer.
This works, but I get parsing errors if I extend the poller to a length >2 and try to read multiple data fields. Not ideal, but workable.
The bigger issue I have is that the modbus data turns into garbage at night, when the panels are not generating any energy. When I connect to the SMA webpage I do see normal values. Any idea what is causing this and how to solve?
hi rossko57, thanks for your quick response. I did not see this in the FAQ and CPU shutdown in case of low voltage explains the behavior as indeed I see NaN values on a few registers.
I managed to use a quick & dirty javascript transformation to “fix” this:
I did some further tests on my earlier issue to read multiple registers at the same time and this does seem to work correctly now. I think that I got confused as I was trying to read multiple Daily Yield registers before (30535-30539) but these always return NaN even though according to the Modbus docs for my SB3.6-1AV-40 they should work (Total Yield at 30529-30533 works fine).
I have made a fork of this project and am testing mqtt support. This way you can send values from the pysma library to any mqtt broker and pick them up with Openhab. Will post the code soon here when done.
Example rules to calculate daytotals (not provided by SMA webinterface).
You will need to create 2 additional items not bound to a binding.
rule1: Write the total yield provided by webconnect to the item
rule “solar-rule1”
when
Time cron “00 59 23 1/1 * ? *”
then
Yield.sendCommand(Solar_Total_Yield_kWh.state as DecimalType)
end
rule2: subtract the Yield of the previous day from the new total yield provided by webconnect as soon as it changes and write to new item.
rule “solar-rule2”
when
Item Solar_Total_Yield_kWh changed
then
Yield_DayTotal.postUpdate((Solar_Total_Yield_kWh.state as DecimalType) - (Yield.state as DecimalType))
end
Optional: you can write the total earnings to influx each day
Thanks for sharing. Can I request to inform from where you get the ID for a total today or spot_ac_power?
How can I get the ID for other sensors and parameters?
I got the same error as Superwutz since I migrated towards OH3.
File "sma.py", line 32, in <module>
cmd_login = '534d4100000402a000000001003a001060650ea0ffffffffffff00017800%s00010000000004800c04fdff07000000840300004c20cb5100000000%s00000000' % (struct.pack('<I', src_serial).encode('hex'), get_encoded_pw(user_pw))
AttributeError: 'bytes' object has no attribute 'encode'
The “encode” function doesn’t exist in python 3.
Did anyone rewrite this script for python 3? I am not familiar enough with python to do it myself.
Well I’m also on openhab 3 and got the modbus working but the valeus are off so I’m still missing something there.
Will post it as soon as I have it working true the modbus.
Here’s how I approiached this issue by means of SBFspot and the openHAB REST API:
In essence, I rely on SBFspot to get the inverter data through bluetooth and store it in a SQLite database. Then I query this SQLite database and post relevant data to openHAB through the REST API.