Multiple Solar Tracer

[mr12obot]

Is there any way how to use the code to monitor the multiple solar tracer ?

is it will setup it with different device ID?

[Bettapro]

you can change the slave id using MODBUS_SLAVE_ID, it's technically possible to connect multiple solar charge controllers and esp(s). but I'm afraid you can introduce transmit collision (multiple master(s) on the same bus is not a good idea -- if communication is not syncronized properly)
SO you'll still have 1 esp for each solar charge controller and 1 bus for each pair.

This project is based on the assumption that 1 esp connected to 1 epever.
It would be nice to have 1 esp talking with more scc(s).

Main problem is:
assuming 1s latency for each request, esp is refreshing 5 groups of variables at the moment (looping around each group), this imply that it should be capable to update a value every 5 secs. (best scenario).
If we add one (or more) ssc(s) on the same bus, time should be multiplied by the total number of scc(s).

Could you detail a little the reason behind this request?

[mr12obot]

The reason behind this request is if we have upgrade or add more scc in the future. then need monitor all of them as well.

As I read from the documentation below is only need 1 device to monitor all of them. but not details for the wiring configuration each other.

https://www.epever.com/wp-content/uploads/2021/08/PAL-ADP-50AN-Manual-EN-V3.0.pdf

Can we use wiring MAX485 <-> SCC (RJ45) to apply for SCC <-> SCC as well ?

And for the code is it only change the modbus slave id in the config.h ?

[Bettapro]

You can change the salve id...but esp will communicate with it only.
My approach to manage more devices is to replicate the same setup (you already did with yours scc) on each new scc: if you have 3 scc(s) you'll need 3 esp(s) as well.
It's not reccomended to connect more device acting as masters on the same serial bus.

The device on the document is basically talking to every scc, it's chaging the slave id at runtime (esp is not doing so)

There's also another problem, the defined vpin should change to depending on the scc.
Blynk provides only 128 vpins, we're already taking 40 for one (and I'm planning to add some more vpins 😄 ) .

Using one esp for all them will create more problems than advantages.