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
Some users leverage a dedicated external meter to measure the output coming from the inverter i.e. a shelly.
I have observed that the DTU can potentially behave a little sluggish especially if more then 1 inverter is pulled. Thus the idea, an optional config parameter for a MQTT value like we have it for the SMT readers (JSON payload or dedicated value). If set, SF control takes this reader value into consideration for the inverter output (rest remains).
I have observed two situations where that might be useful
1). When running on pure sun power, the external meter already reported high output (sun showed up from clouds) whilst the DTU was running behind and thus did not update the possible limit to optimize the solar usage.
2). When running in mixed more and/or battery only, the limit set by SF control was already in effect whilst the DTU has not yet updated the actually accordingly. From observation it appeared that a limit is in part effective within a few seconds after setting it, whilst the reporting of the DTU takes up to 30 secs.
The text was updated successfully, but these errors were encountered:
Regarding 2): I also observe that the limit is already taken into account quite fast by the inverter, but as the OpenDTU only reports every 5 seconds via MQTT (lower values cannot be configured), the calculated overall power consumption is sometimes negative... I don't see delays of up to 30 seconds as in our example. Do you use OpenDTU and what's your configured MQTT reporting interval?
Some users leverage a dedicated external meter to measure the output coming from the inverter i.e. a shelly.
I have observed that the DTU can potentially behave a little sluggish especially if more then 1 inverter is pulled. Thus the idea, an optional config parameter for a MQTT value like we have it for the SMT readers (JSON payload or dedicated value). If set, SF control takes this reader value into consideration for the inverter output (rest remains).
I have observed two situations where that might be useful
1). When running on pure sun power, the external meter already reported high output (sun showed up from clouds) whilst the DTU was running behind and thus did not update the possible limit to optimize the solar usage.
2). When running in mixed more and/or battery only, the limit set by SF control was already in effect whilst the DTU has not yet updated the actually accordingly. From observation it appeared that a limit is in part effective within a few seconds after setting it, whilst the reporting of the DTU takes up to 30 secs.
The text was updated successfully, but these errors were encountered: