Closed GrimmiMeloni closed 9 months ago
Can reproduce locally.
Triggered here: https://github.com/evcc-io/evcc/blob/master/cmd/configure/devicetest.go#L90
which in turn calls https://github.com/evcc-io/evcc/blob/master/charger/easee.go#L432
Caused by async nature of product updates flowing in. Charger.Status()
is called before the charger is actually ready. While the code does wait for the first product update before returning from the charger's factory method, this only confirms that connectivity via SignalR is established. It does however not guarantee a consistent state, yet.
Options:
a) wait specifically for a first CHARGER_OP_MODE
update, before considering the charger instance "ready".
b) do not error out in Status() if c.op_mode
is not set, yet. It is "undefined" - or technically it is the default which is easee.ModeOffline
.
@andig do we have prior art for such situations? For example, do other charger implementations guarantee a consistent state before returning from their factories?
@GrimmiMeloni we typically try to wait for valid state, e.g. in OCPP. Since the wait is guarded by timeout anyway it should be ok to wait for opmode instead of connection. So simply move the once.Close
?
Btw: not sure why the once.Close needs be put inside a defer while we're already holding the lock? I also don't think we need the c.updated
for that purpose at all. One may wish to keep it for checking is SignalR is alive at all, but that's not implemented.
Thanks for the fix.
Regarding c.updated
, it's OK to toss I think. My understanding of wrapping Once
in that defer
was this ensures even if some unexpected exit happens (e.g. future code change?) , we still signal the main thread. But given the timeout on the opposite end of the channel, I have to agree this looks like more code resiliency than really necessary.
Reopening, as we reverted the fix.
will be fixed again by #11435
As reported in #8059, it seems we have some race between the op_mode update and the charger status when running
evcc configure
.Hier die Fehlermeldung nach Configuration mit evcc --log trace configure
Originally posted by @PVJan in https://github.com/evcc-io/evcc/discussions/8059#discussioncomment-7972299