search

hoylabs / OpenDTU-OnBattery

Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters, VE.Direct devices, battery management systems, and related peripherals
GNU General Public License v2.0
301 stars 63 forks source link

[Request] Support for Huawei R4850G2 via SN64HVD230DR #999

Open drahdiwaberl opened 4 months ago

drahdiwaberl commented 4 months ago

Describe the solution you'd like

there's a new - potentially simpler and safer - option for adding a CAN-bus with this extension for the Fusion board which is using a TI SN65HVD230DR

also the upcoming pcb of @swingstate https://github.com/helgeerbe/OpenDTU-OnBattery/discussions/541 uses this transceiver chip

it would be nice to have the option to configure a Huawei PSU connected to this.

Describe alternatives you've considered

tried the current implemented solution with a MCP2515/TJA1050 with the Fusion Board and one other ESP-board - but got neither to work (or stopped trying due to magic smoke in the air).

so for now i'm running it without issues a SN65HVD230DR board with esphome

drahdiwaberl commented 4 months ago

there's an esphome component for connecting that way https://github.com/mb-software/esphome-huawei-r4850

AndreasBoehm commented 2 months ago

I think that this should not be too big of a deal but we will need someone that can write code and has the hardware. I thought about buying a Huawei PSU but I am not sure if i will actually use it.

drahdiwaberl commented 2 months ago

assuming you're the one who could write code? ;)

schätz mal du würdest es easy wieder anbringen.. meins rennt schon ziemlich viel, hab aber auch einiges an ac-überschuss aus 800+1500W microwechselrichtern - mal schaun wie's dann mit weniger sonne und dafür extremeren schwankungen beim dynamischen import-preis ausschaut..

schlimmchen commented 2 months ago

assuming you're the one who could write code? ;)

eeeeer, yes?! one of only two actually active contributors right now. sooo... where is your pull request?

LennartF22 commented 2 days ago

@schlimmchen If there is need for it, I could implement this. I don't have a Huawei PSU, but I could do some mocking on the CAN bus and at least make sure that there is nothing obvious broken before giving a build to someone to test.

schlimmchen commented 2 days ago

If there is need for it

@LennartF22 Well, I am not sure if "need" is the right word here, but this is a valid request and implementing it would be highly appreciated, so I would certainly want to merge it. I would love to use the AC charging feature myself one day and using the OpenDTU Fusion CAN shield would definitely be a great plus. So please go ahead :blush: I can probably contribute some matching updates to the documentation.

drahdiwaberl commented 2 days ago

and well (again), it would be the only way to allow NRF+CMT+huaweiAC, isn't it?

btw i'm thinking about getting a second huaweiAC to spread load on two phases - which a. will probably make my next feature request ;) and b. allow me to more easily test if anyone starts working on this..

schlimmchen commented 2 days ago

and well (again), it would be the only way to allow NRF+CMT+huaweiAC, isn't it?

No, as @LennartF22 is also hard at work with the SpiManager, which will eventually allow to use this combination -- as far as I understand.

LennartF22 commented 1 day ago

@drahdiwaberl With the new SpiManager it is possible to support up to three devices on the same SPI master peripheral. The driver for the SPI devices must support this though:

Devices that don‘t support shared SPI buses yet still need a dedicated SPI bus. Therefore, nRF + CMT (+ W5500) + Huawei-CAN currently need 3 SPI buses, which is one too many. In the future, nRF + CMT + Huawei-CAN will work via the same SPI bus, so that one bus is completely free for 1/3 more devices, depending on whether these additional devices support sharing.

Still, implementing support for ESP32’s internal CAN controller makes sense, not only because of the Fusion CAN/ISO shield, also because it’s a bit absurd that one must add an external CAN controller while the ESP32 already comes with it. Only when a second CAN bus is needed, one should have to add an additional, external CAN bus controller.

@schlimmchen I will start working on the implementation next week. I just wanted to make sure that nobody is working on that yet.

drahdiwaberl commented 1 day ago

because it’s a bit absurd that one must add an external CAN controller while the ESP32 already comes with it.

word! 🤗

also - while it's nice that they exist and are available - all these extra boards and cheap components are potential points of failure in the whole system which makes the systems less reliable and errors possibly hard to find..