Solarman Proxy

[githubDante]

This is not an issue!

Proxy for solarman dataloggers in TCP-Client mode. Works nicely in collaboration with PySolarman clients.

It's suitable for:

• people who want to pass their data over the Internet, but don't want to expose their dataloggers directly.
• people who want single point of communication with multiple loggers
• developers who want to connect more than 5 clients to the datalogger :blush:

Prebuilt binaries (for arm and amd64) at the moment are available in the artifacts from the GH actions run here.

[davidrapan]

Nice! I will definitely try it!

But I would also like to kinda hijack this thread to ask some semi-related questions.

• pysolarmanv5 server mode, is it even doable? How much is even the communication between solarman servers and the stick reverse engineered? Cause by looking at it the data pushing proly works little bit differently than polling we do, right?
• Sticks also "supports" udp? It offers the option but does it even work? Could pysolarmanv5 also support udp? My thoughts are maybe it could offer better performance? Cause the connection using tcp is not that reliable anyway so maybe it would not be that bad of a trade off.

[githubDante]

pysolarmanv5 server mode, is it even doable?

Definitely doable , the protocol is the same in TCP-Server mode. After the first packet received from the server the logger is doing exactly the same (sending counter packets without a request, disconnect on silence etc.), it's silent otherwise, but reconnects after every TCP timeout.

How much is even the communication between solarman servers and the stick reverse engineered? Cause by looking at it the data pushing proly works little bit differently than polling we do, right?

Can't comment on that. This requires tcpdump from the router, which is something to which I don't have access to

UDP - I think UDP connection will be even more problematic, especially if TCP is unreliable. Broken packets are the first problem which comes to my mind.

[davidrapan]

Can't comment on that. This requires tcpdump from the router, which is something to which I don't have access to

I guess I could send you (but rather privately) pcap of that communication..

The unreliability I'm talking about is more about stick refuses to respond rather than issues with the path. When I for example break down burst of 5 requests to the stick more than half of the packets is just about tcp stuff - so it came to my mind when I was thinking about what on the stick side could be so problematic for the device to have so poor performance.

[githubDante]

SYN & ACK packets, maybe that's what you see in addition to the data packet. Anyway, the lack of response could be due to various reasons (internal error, the logger is doing something else etc.) that we don't know. As for the PCAP file you can drop it here

[davidrapan]

SYN & ACK packets

Sure I know 😆

I said that as poke into TCP and how wasteful it is. 😉 (I was not surprised at all when QUIC came along, but that's OT AF)

Edit: I guess what I was trying to say is that maybe (just maybe) UDP could be less demanding on the stick in general. (Without impacting reliability on connections with stable path)

[davidrapan]

Hey @githubDante, I have that pcapng for you, can you revive that upload link?

[githubDante]

Yes of course.

[davidrapan]

Done.