V4.2.2 & V2 GUI - Scheduler does not disable charge

[lebsd]

Charge mode set to Eco Divert. My TOU is from 4-9PM. I have set the charge schedule to stop charging (regardless of solar) by 4PM which is when my battery kicks in because I do not want my battery to be used to charge the car. The unit does not stop the charge.

[jeremypoulter]

Currently the schedule is setup to turn on the charge at full power, rather than force the charge off as the expected use case is for charging over night on cheap rate electric and via solar during the day. We would have to make some changes to operate as you are expecting

[KipK]

To prevent your battery being used you can set the divert filter to "no import" mode , i.e. revert your factor rates between attack and decay it should not draws from your battery and cut off sooner.

[lebsd]

Not sure where you set the "divert filter" is under the new V2 GUI. This is what my "self production" screen looks like. (BTW, the sensor is reading from the grid meter, and it is not just the solar production.

Thanks Jeremy for the quick response and clarification on the intent of the TOU for only Fast charge! . I think that the new scheduler should apply to the device in general regardless of what the power source is (I am thinking of a condition where applying the filter in divert mode may cause some issues 🤔, I have some programming background but not specific to OpenEvse, but I can follow the logic from the code so will take a look at the code).

Amplifying info: I have the main panel and the battery backup panel connected to my inverter (SOLARK). OpenEvse is connected to the main panel and is reading the grid power meter (not the solar production). There is a mode of operation on the inverter where it feeds the battery backup panel AND the main panel loads (w/grid active). The problem rises when the charger is lets say charging at 8A maintaining my 1.1 power ratio. At 4PM, the battery kicks in, and as the sun goes down the reduced power is supplemented by the battery, so openevse still senses 1.1 power ratio is met and keeps charging at 8A. The issue here is that OpenEvse will continue to operate at whatever the charging amps are at 4PM, so potentially the amps can be higher which will then discharge my battery faster. What I have been doing is manually disconnecting the charger from the car at 4PM, but if I am not home or forget, the battery will not last as long as originally planned.

[image: image.png]

On Sat, May 6, 2023 at 10:01 AM Guillaume S @.***> wrote:

To prevent your battery being used you can set the divert filter to "no import" mode , i.e. revert your factor rates between attack and decay it should not draws from your battery and cut off sooner.

— Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/631#issuecomment-1537182185, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANGYQV56E3VSBZP2M7SHHTTXEZ7XXANCNFSM6AAAAAAXYGAVWE . You are receiving this because you authored the thread.Message ID: @.***>

[KipK]

In UI2 it's in self production yes. Invert the attack and decay values and it will behave to limit import instead of trying to not waste solar energy. You need to have an +import/-export value for your mqtt feed in export mode, so don't push to your mqtt feed a negative value when your battery kicks in and consider the battery power available as import and not export

Le sam. 6 mai 2023, 21:41, lebsd @.***> a écrit :

Not sure where you set the "divert filter" is under the new V2 GUI. This is what my "self production" screen looks like. (BTW, the sensor is reading from the grid meter, and it is not just the solar production.

Thanks Jeremy for the quick response and clarification on the intent of the TOU for only Fast charge! . I think that the new scheduler should apply to the device in general regardless of what the power source is (I am thinking of a condition where applying the filter in divert mode may cause some issues 🤔, I have some programming background but not specific to OpenEvse, but I can follow the logic from the code so will take a look at the code).

Amplifying info: I have the main panel and the battery backup panel connected to my inverter (SOLARK). OpenEvse is connected to the main panel and is reading the grid power meter (not the solar production). There is a mode of operation on the inverter where it feeds the battery backup panel AND the main panel loads (w/grid active). The problem rises when the charger is lets say charging at 8A maintaining my 1.1 power ratio. At 4PM, the battery kicks in, and as the sun goes down the reduced power is supplemented by the battery, so openevse still senses 1.1 power ratio is met and keeps charging at 8A. The issue here is that OpenEvse will continue to operate at whatever the charging amps are at 4PM, so potentially the amps can be higher which will then discharge my battery faster. What I have been doing is manually disconnecting the charger from the car at 4PM, but if I am not home or forget, the battery will not last as long as originally planned.

[image: image.png]

On Sat, May 6, 2023 at 10:01 AM Guillaume S @.***> wrote:

To prevent your battery being used you can set the divert filter to "no import" mode , i.e. revert your factor rates between attack and decay it should not draws from your battery and cut off sooner.

— Reply to this email directly, view it on GitHub < https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/631#issuecomment-1537182185 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ANGYQV56E3VSBZP2M7SHHTTXEZ7XXANCNFSM6AAAAAAXYGAVWE

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/631#issuecomment-1537209995, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADXKVKKLV4ZVAUWUMTNDS3XE2SNFANCNFSM6AAAAAAXYGAVWE . You are receiving this because you commented.Message ID: @.***>

[larroy]

I think the timers should not override the divert logic, or at least be configurable. Timers is a good way to avoid transients as the solar production is ramping up, as the filtering logic currently is not very reliable for that (when excess is hovering around 6A)