You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem you have/What new integration you would like
It would be great to add support for the Shelly Pro 2 PM.
The power monitoring feature allows for example to use this device with the Current Based Cover component to control garage doors/shutters.
The fact that the device has an Ethernet port is very interesting for some use cases.
Please describe your use case for this integration and alternatives you've tried:
Additional context
I've received a Shelly Pro 2 PM recently.
The only difference with the Shelly Pro 2 is the addition of two ADE7953 chips (one per relay sub-board).
There are two challenges to support this board:
-> Common reset GPIO for both ADE7953
Both ADE7953 reset lines are connected to one single GPIO (GPIO2).
So by default, if we don't do anything, that GPIO will be low and hence asserting the reset of both chips forever.
This will prevent the ESP32 from getting meaningful data from them.
I've tried to modify the ADE7953 driver in order to support a new rst_pin field. Because it looks like it would be much cleaner if this pin is handled by the driver itself. This works well when there is only one ADE7953, but it feels it's not the right solution when there is one common reset pin for several devices.
How could be modify the ADE7953 driver so that it could support several "children" that are the actual devices?
That way, the parent would have a rst_pin that could be common to all children. This is what Tasmota did.
-> Bug when using ADE7953 with esp-idf framework
The default values for voltage_gain, current_gain_* and active_power_gain_* is 0x400000.
But on with ESP IDF framework, the value 0x200000 ends up in the registers.
The bug looks like this:
When putting 0x400000, we read 0x200000 from the device registers
When putting 0x200000, we read 0x100000 from the device registers
For now, I went around both problems in my esphome-devices PR here, but let me know if you have ideas to solve the root cause of those issues!
The text was updated successfully, but these errors were encountered:
mwetterw
added a commit
to mwetterw/esphome-devices
that referenced
this issue
Jan 23, 2025
Describe the problem you have/What new integration you would like
It would be great to add support for the Shelly Pro 2 PM.
The power monitoring feature allows for example to use this device with the Current Based Cover component to control garage doors/shutters.
The fact that the device has an Ethernet port is very interesting for some use cases.
Please describe your use case for this integration and alternatives you've tried:
Additional context
I've received a Shelly Pro 2 PM recently.
The only difference with the Shelly Pro 2 is the addition of two ADE7953 chips (one per relay sub-board).
There are two challenges to support this board:
-> Common reset GPIO for both ADE7953
Both ADE7953 reset lines are connected to one single GPIO (GPIO2).
So by default, if we don't do anything, that GPIO will be low and hence asserting the reset of both chips forever.
This will prevent the ESP32 from getting meaningful data from them.
I've tried to modify the ADE7953 driver in order to support a new rst_pin field. Because it looks like it would be much cleaner if this pin is handled by the driver itself. This works well when there is only one ADE7953, but it feels it's not the right solution when there is one common reset pin for several devices.
How could be modify the ADE7953 driver so that it could support several "children" that are the actual devices?
That way, the parent would have a rst_pin that could be common to all children.
This is what Tasmota did.
-> Bug when using ADE7953 with esp-idf framework
The default values for
voltage_gain
,current_gain_*
andactive_power_gain_*
is 0x400000.But on with ESP IDF framework, the value 0x200000 ends up in the registers.
The bug looks like this:
For now, I went around both problems in my esphome-devices PR here, but let me know if you have ideas to solve the root cause of those issues!
The text was updated successfully, but these errors were encountered: