Sniffing the traffic from the datalogger

[hazbot72]

I followed the design laid out here and was pleasantly surprised that I managed to get it all set up correctly on first attempt and everything works perfectly.

My datalogger (S3-WIFI-ST) continues to send data to Solis Cloud as before and is none the wiser that it is no longer plugged directly into the inverter. Meanwhile I am collecting stats locally every 10 seconds using Node Red with the modbus add-in, and forwarding them to MQTT and a subset to InfluxDB. From there I view everything in Grafana.

Many thanks @alienatedsec for documenting this! It is exactly the setup that I had been hoping for.

One thing I thought I might have been able to do is to "snoop" the traffic coming from the datalogger and then decipher the Modbus requests which (it thinks) it is sending to the inverter. I thought this might help to figure out which registers I need to capture.

I have tried using tcpdump/Wireshark to capture network packets and decode them as Modbus protocol (which apparently Wireshark can do) , but I do not get any recognisable traffic this way.

I also tried setting up a Modbus TCP proxy (https://github.com/tiagocoutinho/modbus-proxy) on a Raspberry Pi and directing requests from the client Waveshare through it, and again the datalogger kept working fine but there isn't enough detail in the proxy logs to figure out what the datalogger is doing.

Anybody else tried this approach to decode what the datalogger is requesting?

It's just a side note to the otherwise successful outcome but I am curious to see if this is possible or even useful.

[alienatedsec]

Hi @hazbot72

I followed the design laid out here and was pleasantly surprised that I managed to get it all set up correctly on first attempt and everything works perfectly.

It is great to hear about another successful installation - it's so handy even when Solis Cloud is down for some reason ;) I made it more interactive with my recent automation to report on the inverter status. Check it out over here - https://github.com/alienatedsec/solis-ha-modbus-cloud/wiki/Sample-Automations#inverter-status-changes

Meanwhile I am collecting stats locally every 10 seconds using Node Red with the modbus add-in, and forwarding them to MQTT and a subset to InfluxDB. From there I view everything in Grafana.

If you could share any configs for your NodeRED it would be great - I am going to upgrade from the DLS-W to S2-WL-ST which is still in my drawer. That will make my SolisMon3 and current setup decommissioned, and I like Grafana a lot. I would need to follow something similar to yours to keep receiving the following :)

Anybody else tried this approach to decode what the datalogger is requesting?

I know that @jmccrohan was analysing the traffic when we discussed my attempts for my design (which ended up with this repo), and maybe he could share the outcome of his investigation. I even looked at the emails and found our conversation about sniffing Waveshare's data back in February :)

[jmccrohan]

Often the registers are ahead of the inverter f/w versions, and some only apply to new S6 inverters, but definitely a handy resource. Solis keep them updated too. I do a diff with the old version every time a new Solis Cloud APK is pushed and there are always new registers added.

[hazbot72]

extracting the data files from the APK, genius :) I wish I had thought of that!

This side quest was prompted by my search for a reliable metric for "house load power" , i.e. the total power draw for everything in the house, aside from any considerations of battery in/out , solar in, etc etc.

I did previously find the above two PDFs along the way, and also checked the example register config that ships with solismon3. I thought that register 33147 "house_load_power" would give me the value I need.

In reality though what I find is that this register often returns a value of zero, for extended periods of time (e.g. 15/20 minutes), which can't be correct as there is never zero load in my house :)

So that is why I was trying to find out exactly which registers the datalogger was using.

I had assumed that the datalogger boots up and reads the model number of the inverter, sends that to Solis Cloud, and Solis responds with a map of registers specific to that model of inverter. I guess that is the way I would design this kind of system if I were in their shoes.
Anyway I will go dig into the json files from the APK and see if I can find a suitable register that I haven't tried yet. Thanks for the tip @jmccrohan !

[hazbot72]

If you could share any configs for your NodeRED it would be great - I am going to upgrade from the DLS-W to S2-WL-ST which is still in my drawer. That will make my SolisMon3 and current setup decommissioned, and I like Grafana a lot. I would need to follow something similar to yours to keep receiving the following :)

@alienatedsec yes of course I will be happy to share that. Will tidy them up a bit and export the flow json.

[jmccrohan]

This side quest was prompted by my search for a reliable metric for "house load power" , i.e. the total power draw for everything in the house, aside from any considerations of battery in/out , solar in, etc etc.

I did previously find the above two PDFs along the way, and also checked the example register config that ships with solismon3. I thought that register 33147 "house_load_power" would give me the value I need.

In reality though what I find is that this register often returns a value of zero, for extended periods of time (e.g. 15/20 minutes), which can't be correct as there is never zero load in my house :)

@hazbot72 33147 is what I am using, but I too have observed periods of 0W during the night. What I have observed is that when the house load is lower than circa 150W, the value falls to zero. The inverter is still supplying power during this period as evidenced by both the Solis battery discharge current and MyEnergi generation and grid CTs. It doesn't bother me too much tbh.

[wawyed]

Just to add to this. I experience the same issue with house load :(. I have a ticket open with Solis but they are not being very helpful... I don't know if anyone has tried but I believe there are two ways to connect the CT grid or load side. Mine is grid side and I was wondering if changing it to load side would make the value be more "accurate". Unfortunately the latest firmware that solis put on my inverter removed the option to change ct location weirdly enough

[hazbot72]

@alienatedsec here is the Node Red flow which I use to pull metrics from the Waveshare server and forward to MQTT & InfluxDB

I am using Node Red 3.0.2 and the module "node-red-contrib-modbus" 5.25.0

The blocks of registers to pull from the inverter are defined in the "inject" node. Each block has an arbitrary name (block1, block2 etc) which needs to match up to the same names in the "switch" node

There is a function node corresponding to each block which adds the title of each metric and its scaling factor if any.

Lastly the list of metrics which are to be forwarded to InfluxDB (I don't send all of them, only a few) is in the function node called "filter to DB"

flows.json.txt

[alienatedsec]

Page 34, point 6.4 onwards of this guideline could allow sniffing data from datalogger

https://www.waveshare.com/w/upload/4/4d/RS485-to-eth-b-user-manual-EN-v1.33.pdf

[chezlong]

Similar to comments above, I'm just starting out with a simple sniff of the modbus traffic between the datalogger and inverter, using an isolated RS485 to USB jobbie. I'd be interested if anyone has found the same strange pattern of requests the logger does:
It requests in a cycle of 3 blocks, like:
---|block A| - 28 second gap- |block B| - 17 sec gap- |Block C| - 8 sec gap - |block A again|--- etc
The blocks are all different sizes and are made up of several MODBUS register read requests (type 4) usually for multiple registers
Block A is 95 bytes (inc. address, length, checksum, etc) and is just one read multiple request of 82 bytes, starting at 33000
Block B is 728 bytes and consists of 12 separate read multiple requests, mostly type 04 but the last one is a 03. The first three have an invalid address 0x0bb7 and elicit an error code from the inverter.
Block C is 412 bytes and consists of 12 separate read multiple request, all type 04, apart from the last one (type 3)

Interestingly, there are several repeats of the same read multiple requests (same starting address, same length) across the three blocks.

I'm guessing there isn't much storage in the logger, so its reading smaller blocks and sending the register data to Solis cloud in multiple pushes, but it is strange that there are so many repeat requests for the same registers. Obviously some of the returned data will be different, but given the clock data seems to report only a single snapshot every 4 mins, it seems a bit strange.
The three errors are a bit of a mystery too.

Anyone else see similar?
[EDIT] I should say the logger is a DLS-L ethernet only one ME-121001-V1.0.6(202107141620)

[alienatedsec]

@chezlong Looks like a great step forward. I recently switched from DLS-W to S2-WL-ST and will be doing the same using this method.

In fact, I also have the DLS-L, and I can share a newer firmware ME-121001-V1.0.6(202209071030) if you are interested.

[chezlong]

The new firmware sounds interesting- any improvements/features known?
I've only just got inverter control going from the app (yes, I know, the DLS-L isn't supposed to be OK for remote control) , so slightly twitchy about messing it up.

[alienatedsec]

any improvements/features known?

@chezlong I have no idea about what improvements it brings. Its fine if you do not want to risk it.

[chezlong]

If you have access to it I'll take a copy anyway, please. I sort of assumed the firmware for any bit of the kit (inverter, batteries, logger, etc) would be done remotely anyway, but it appears not!

[hn]

Instead of intercepting the RS485 traffic, you could intercept the connection of the S3 stick to the Solis Cloud and redirect/decode/block the traffic at HTTPS level. But, I actually recommend completely replacing the S3 firmware with ESPHome.