For use cases implemented with server features that accept writes:

• Add default checks which reject writes e.g. when no heartbeat is available
• Add an API which the application has to use to allow an incoming write
• Set the write timeouts for automatic declines per use case as defined in the specs

Description

When cemd is connected to an EVSE and the EVSE disconnects the following function is called.

Here the entity is accessed to get the Device however the enitity is nil causing the exception.

evseEntity and evEntity are set to nil when the EVSE got disconnected or the EV unplugged. At the very same time the values may be used in another thread to construct a SPINE message or to gather data which would lead to a panic.

I'm trying to use your software but got an error connecting to VW Elli Wallbox:

go run cmd/main.go 12345 b90d2c1a3597dd416c5418dc28ff022f50a63a5d keys/hems.crt keys/hems.key enp0s31f6
2023-04-08T11:33:43+02:00: INFO Local SKI:  23ef43d7a6487fb9a44c7fbb0d2b840514b8faa6
2023-04-08T11:33:43+02:00: DEBUG mdns: start search
2023-04-08T11:33:43+02:00: DEBUG ski: b90d2c1a3597dd416c5418dc28ff022f50a63a5d name: Elli-Wallbox-2144A1R0AH brand: Elli model: Wallbox typ: Wallbox identifier: Elli-Wallbox-2144A1R0AH register: false host: wallbox-2144A1R0AH.local. port: 4712 addresses: [192.168.105.241]
2023-04-08T11:33:43+02:00: DEBUG delaying connection to b90d2c1a3597dd416c5418dc28ff022f50a63a5d by 2.123s to minimize double connection probability
2023-04-08T11:33:45+02:00: DEBUG trying to connect to b90d2c1a3597dd416c5418dc28ff022f50a63a5d at 192.168.105.241
2023-04-08T11:33:45+02:00: DEBUG initiating connection to b90d2c1a3597dd416c5418dc28ff022f50a63a5d at 192.168.105.241:4712
2023-04-08T11:33:46+02:00: DEBUG connection to b90d2c1a3597dd416c5418dc28ff022f50a63a5d failed:  tls: failed to parse certificate from server: x509: invalid basic constraints b
2023-04-08T11:33:46+02:00: DEBUG trying to connect to b90d2c1a3597dd416c5418dc28ff022f50a63a5d at wallbox-2144A1R0AH.local.
2023-04-08T11:33:46+02:00: DEBUG initiating connection to b90d2c1a3597dd416c5418dc28ff022f50a63a5d at wallbox-2144A1R0AH.local.:4712
2023-04-08T11:33:46+02:00: DEBUG connection to b90d2c1a3597dd416c5418dc28ff022f50a63a5d failed: tls: failed to parse certificate from server: x509: invalid basic constraints b
2023-04-08T11:33:46+02:00: DEBUG restarting mdns search

any ideas what could be wrong?

As of EEBus UC State of Charge does not only contain the State of Charge but furthermore:

• Nominal Capacity
• State of Health
• Actual Travel Range
  However these are not implemented at the moment

The mocks for UCEVCCInterface & UCEVSECCInterface do not match their interfaces.

It would be great if you could think of adding support for heat pumps like the ones from Vailant, which are talking eebus and could a some benefit to manage self consumption of local generated power

Currently, Cem and use cases share the same EventHandlerCB callback type. Together with #23 I'd propose to update as follows:

type DeviceEventCallback func(device spineapi.DeviceRemoteInterface, event EventType)

and

type EntityEventCallback func(entity spineapi.EntityRemoteInterface, event EventType)

Happy to provide a PR.

Right now the event code in all usecases checks the complete stored dataset for the needed functionality. Instead it should use the provided data set from the payload only.

This way it can be made sure that events are only fired if the last incoming dataset really includes the data point for the message. If the remote service uses partial messages, this will work better with this change.

• Remote services should not be hard wired to a solution, instead they should "automatically work" if the remote device supports the same usecases and provides the required features and data
• It may (!!) be better to individually register each supported usecase, instead of working with solutions that need to be configured, if not all usecases should be supported

Creating CEM UCs requires

type EventHandlerCB func(ski string, device spineapi.DeviceRemoteInterface, entity spineapi.EntityRemoteInterface, event EventType)

Given that spineapi.EntityRemoteInterface includes Device() it seems the device parameter is not necessary? Same should apply to SKI via device?

Instead of only getting Device Name & Serial Number, it could be of interest of getting all available infos.

The new pairing process API should be supported and used. The service using CEMd should be able to decide to use the pairing process or define that the added SKI is locally already paired and no UI flow needed.

Currently an SKI has to be registered to the supported use cases category, e.g. emobility or grid. Instead this should be detected on the fly using the returned DetailedDiscoveryData and UseCaseInformation.

while debugging LPC usecase, i was able to close the underlining websocket if the callback get stuck, e.g. while waiting for a long running task.

example code to reproduce

func (s *cem) entityEventCB(ski string, device spineapi.DeviceRemoteInterface, entity spineapi.EntityRemoteInterface, event api.EventType) {
time.Sleep(120 * time.Second)
}

expected behavior:
- callback doesn't affect the spine lib itself

Depending on if the Heartbeats are correctly received by a Controlbox for an interval determines different states that the system needs to go into.
Therefor we need to inform the CEM about the current Heartbeat status so the same is able to handle missing heatbeats and inform other entities to go into failsafe state.

As EEBUS is event driven and all devices can act as server or client for different functionality, the API should reflect that as well. Hence an event driven API should be used, also considering a future Websocket based API to leverage the same style as Go based CEM systems that use this library.