added solarman provider and template for deye-hybrid-3p-solarman

[tlmnb]

I've added a new provider for the solarman protocol which is used by the LSW-3 data logger. The protocol description can be found here. In general it is modbus with a layer on top. Unfortunately I had to copy a lot from the modbus provider as I didn't want to add this provider into the modbus provider. Maybe there might be a more elegant way. I also appreciate some feedback as I recently started developing in golang.
I'll add a PR to update the documentation later

[andig]

Great PR, thank you!

This is a lot of code and added complexity. I'm not convinced yet that we should add this. Are these devices wide-spread? Are there any alternative solutions like HA modules or similar?

Regarding choice of implementation: while a provider is a working approach- shouldn't this rather be a meter type instead? Is it absolutely necessary to duplicate such a large amount of modbus code?

[deadrabbit87]

I would be in favour of it. The Deye is relatively sensitive with regard to the RTU mode.

An identical manufacturer is Sunsynk, for example.

I didn't know a solution with Home Assistant and Solarman

[tlmnb]

Thank you for your feedback.
Regarding the question how much these devices are used, here in the development area all (~60) houses were equipped with deye inverters using a lsw-3 data logger stick which uses the solarman protocol. I know at least one other neighbor who wants to use evcc for charging his ev.
See also this discussion.

The question whether it should be implemented as a meter or a provider, it is true that the data logger sticks are only used for inverters. From what I know no other devices use this way of communication. Therefore I guess it should be a meter.

Anyhow I will try to find a solution to avoid the large amount of duplicated code.

[PeterPablo]

Regarding the question of relevance. LSE-3 (ethernet) or LSW-3 (wifi) data loggers are used with SofarSolar inverters. This can be seen from the linked discussion of @tlmnb. FYI @cschlipf

[andig]

Anyhow I will try to find a solution to avoid the large amount of duplicated code.

Just thinking loud:

In general it is modbus with a layer on top.

is there any chance we could use ModbusRTU/TCP as underlying protocol and wrap that in a meter implementation (instead of reimplementing the entire modbus stack)? If not: could we potentially (not sure this would technically be better) add something like a ModbusSolarMan solarmanPackager and/or ModbusSolarManOverTCP to evcc-io/modbus?

[andig]

Regarding the question of relevance. LSE-3 (ethernet) or LSW-3 (wifi) data loggers are used with SofarSolar inverters.

Can they been integrated any other way than an implementation in evcc?

[PeterPablo]

See https://docs.evcc.io/docs/devices/meters#hyd-520k-3ph

…

Message ID: ***@***.***>

[andig]

@PeterPablo what do you mean- that integration is already available?

[tlmnb]

In general it is modbus with a layer on top.

is there any chance we could use ModbusRTU/TCP as underlying protocol and wrap that in a meter implementation (instead of reimplementing the entire modbus stack)? If not: could we potentially (not sure this would technically be better) add something like a ModbusSolarMan solarmanPackager and/or ModbusSolarManOverTCP to evcc-io/modbus?

I had a look how the underlying client from grid-x implements the communication variants. I think I found here a way that I can also implement a client by using their interfaces. In my opinion I have to implement something like this for the solarman protocol.
So that would mean that the low-level communication would be still handled by the grid-x modbus client only the way how the messages are build would be custom.
But this would mean that the modbus provider would need an additional modbus type.

@PeterPablo what do you mean- that integration is already available?

I think he just wanted to emphasize that the lsw-3/solarman devices exists but are not implemented yet.

[andig]

But this would mean that the modbus provider would need an additional modbus type.

Not if you make the result a meter or just its own type. Lets see how it looks when the basic interface is implemented.

[andig]

Closing until updated