Timer set charge_current claim with 0 amp

[KipK]

I see Timer is setting a charge_current claim with getMaxHardwareCurrent() if EVSE is active when timer going to active.
But mose of the Time the claim is posted with "0" as max_current , so pilot is locked at 6A )
It looks like properties.setChargeCurrent(_evse->getMaxHardwareCurrent()); gives 0 for whatever reason;

This is part of code in scheduler.cpp:
if(EvseState::Active == currentEvent.getState()) { priority = EvseManager_Priority_Timer; properties.setChargeCurrent(_evse->getMaxHardwareCurrent()); } _evse->claim(EvseClient_OpenEVSE_Schedule, priority, properties);

I'm publishing getMaxHardwareCurrent() in /status to follow it, but it's always at 32A, I don't get why this part of code fails on scheduler.cpp

To reproduce:

• Set a timer to have OpenEvse Active at this time, reboot wifi module, at boot it will publish a timer claim with charge_current at 0.
  ps: I have also tryied replacing getMaxHardwareCurrent() by getMaxConfiguredCurrent() and getMaxCurrent() and same thing happend

[KipK]

After some tests, the bug happen only at wifi module boot.
If state is active under Divert and then Timer switch to Active, the claim is ok getMaxHardwareCurrent() answered 32,
but it always send 0 at wifi module reboot.
Perhaps the serial connection with the evse module is not ready yet when it checks this?

if(EvseState::Active == currentEvent.getState()) { priority = EvseManager_Priority_Timer; uint8_t evse_maxcurrent = _evse->getMaxHardwareCurrent(); if (evse_maxcurrent) { properties.setChargeCurrent(_evse->getMaxHardwareCurrent()); _evse->claim(EvseClient_OpenEVSE_Schedule, priority, properties); } }

[KipK]

That was it,
If I enclose the scheduler loop in this condition:

if(_evse->getMaxHardwareCurrent()) {

and then return delay 1000, if ignoring the loop, it then set the pilot ok at 32A.
So this is just a timing issue, what would be a better check than (_evse->getMaxHardwareCurrent() ?

[KipK]

@jeremypoulter , I think it's pretty related to #452 and co ( #450, #513 , #388, #481 )
When evse is in sleep state and EvseManager set a claim to Active state.
If getMaxHardwareCurrent() answered 0 at start up, there's chance all other evse calls are the same and would explain why it ignores some properties.

as you've commented in evse_monitor.cpp:
// When enabling the OpenEVSE controler it goes into the starting state, this is
// not overley helpful, so we will ignore it

Perhaps setting up on esvemanager something like Set to active state first, wait a bit, then set the other claims props
or Set to Active state, and keep _evaluateClaims to true until evse is ready ?

[jeremypoulter]

I will review it as, it is possible.