Passive listening / sniffing SMA protocol on RS485?

[niharmehta]

I was able to successfully connect in to the RS485 and Yasdi2Mqtt is collecting and sending data to my MQTT server. However, it is not stable with frequent online/offline in the logs with the DeviceID changing to random numbers.
I assume the issue is both Yasdi2Mqtt and the provider monitoring system are both RTU Masters which is not allowed with Modbus . Since there is already an RTU Master polling the inverters, is there any way for yasdi2mqtt to passively sniff the communication on the bus from the existing master and inverters instead of actively polling the PV inverters?

[pkwagner]

yasdi2mqtt is just a rather lightweight wrapper around the SMA yasdi library. Frankly, I cannot imagine yasdi supporting such niche use cases, but if it's possible, you should find the answer there.

Maybe you can play around a bit with the included yasdishell or the library itself. The pre-built Docker images from Konstantin should allow this quite easily [1]. If you find anything not too hacky, I'd gladly integrate it into yasdi2mqtt of course.

Also, @MOS6510 (the godfather of yasdi ;)) may have deeper knowledge on that.

[1] https://github.com/konstantinblaesi/yasdi

[MOS6510]

No, YASDI was designed to be an active master on the bus. It is not possible to "passively sniff" any traffic on the bus without rebuilding anything in YASDI...

[dalklein]

Why is yasdi or yasdi2mqtt operating as a master on the bus? Is it causing the device ids to change, or is that happening for some other reason. In my case the inverter (Sunny Island battery inverter) is the only device on the rs485 (piggyback board in the inverter, to a 485:usb adapter on the RPi), and the inverter is always the only device there. In my controls, I added watchdog timer functionality, so if a device has gone away for some reason, then see if it is back and restart communication with it. If there's no way around the device id's changing on your system, maybe it could use some other command to find the new id and restart using that. But, is the device id the serial number of each inverter?

[dalklein]

Oh, a faster baud rate might work? I have only used 1200, I only have the SI6048US inverters, nothing else on RS485.

In node-red, I use a timeout node that triggers if mqtt messages haven't been received recently enough.

[randyoo]

Yep, the faster baud is working like a champ for about 24 hours now. I’m going to see if I can lower the interval even further, because it’s really handy to see power fluctuations in real time as I’m switching things on and off… it’s decent now, but I’d like to know what the minimum might be. (Edit: interval of 5 seconds seems fine, too) Obviously, for SoC, update resolution isn’t a factor.

I was asking about your watchdog on case it’s opening the serial port, causing the issue with device handles. I had been using node red to monitor phase via my ac coupled grid-tie inverter, so I’d know when the SI cluster was curtailing their output, meaning the battery was close to full.

Very excited to have the actual power and SoC data straight from the Sunny Islands now. Thanks, @pkwagner !

[randyoo]

More on-topic:
@niharmehta, it may just be a matter of the two masters stepping on each other. If you play around with the interval on yasdi2mqtt and/or the provider’s monitor (web box?), maybe you can cut down on the frequency of conflicts.

Or, as @pkwagner suggested, maybe you can have a look at the YASDI code, and see if there’s a way for it to confirm the bus isn’t active before initiating a request.

A final suggestion, if you aren’t running any Sunny Boys on the bus, is to up the baud rate. That way, the data passes much quicker, and you might cut down on the regularity of conflicts. I’ve only got yasdi2mqtt and one Sunny Island on the bus, and it’s working fine at 19200. If your provider monitor supports that speed, and you have no sunny boys on the bus, this might be the easiest “fix”.

[dalklein]

@randyoo Thanks!! Wow!!! Yeah!! it's working so far with 19200 and a 4sec update rate. (only yasdi2mqtt and an SI6048US inverter on the rs485 bus) This is a great improvement, I don't see a need for any faster than that.

At first I forgot to change the baud rate in the inverter also, duh. I did notice issues when trying to use yasdishell to see if the new baud rate was working, while yasdi2mqtt was also running, that's probably not a good idea. Yasdishell would detect the inverter, but would get error -3 when asking for the data.

Previously I was running 1200, and 10 sec update for a long time, but recently realized that sometimes it was failing and it would skip getting good data. I needed to increase the update rate to 13 sec to consistently get data.

[MOS6510]

Mhh....btw...YASDI's device and channel handles are more like a "non-reused file handle": It's a "temporary identifier" for a device or channel for the YASDI API itself but should not be used as a identifier for a device (or channel) for a long time. They may change in some circumstances. A better device identifier would be the device serial number (32 bit) which is always unique....

[niharmehta]

Thank you everyone for all the different ideas. I think I may have solved the problem using some of the information in this thread as well as other discussion topics here. I started looking at the yasdi code and the SMAData1 and SMANET protocol specifications which are pretty specific in the timings and realized with my very rusty C skills, I would more than likely break than solve my problem.
Looking at the notes above and the other discussion topics, it seems like there was potential for speeding up the baud rates as well as using the UDP gateways and the Yasdi IP driver.

Ultimately the solutions that seems to be working for me so far is a combination of using RS485 UDP Server/Client devices (in my case the WaveShare RS485 to Eth(B)) and a combination of baud rate settings to the inverter and the Sunpower PVS2 I am suing could help. After way too much tinkering with settings, I think I found a solution that has been solid for over 24 hours.

I have two SMA SB5000-TL-22 inverters, that seem to be working fine at 19200 baud. On the Waveshare RS485 gateway device connected to the inverters, I set them to transparent UDP with the baud rate to 19200 and the client address to both the Yasdi2Mqtt and the RS485 gateway connected to the Sunpower PVS. I also tested with the USR-TCP232 as a UDP Server which worked as well. On the PV Supervisor side, I set the gateway to 1200baud towards the supervisor .

These settings seem to be working well now. No online/offline messages so far and the PVS Web interface has been showing the inverters connected without errors. The gateway devices along with fast baud rates seem to be keeping the connection times low enough the 1200baud PVS has not noticed it being offline, nor has it overwhelmed the inverters.

[randyoo]

Thanks for the report—you made my day! Glad to know that my suggestion to up the baud rate was helpful, although it’s a little surprising. The SMA Sunny Island documentation indicated that any inverters on the bus would need to operate at 1200 baud, but that advice must have been dated.