This library provides a foundation for implementing EEBUS use cases in go. It uses the SHIP implementation ship-go and the SPINE implementation spine-go. Both repositories started as part of this repository, before they were moved into their own separate repositories and go packages.
Basic understanding of the EEBUS concepts SHIP and SPINE to use this library is required. Please check the corresponding specifications on the EEBUS downloads website.
The supported functionality contains:
- Support for SHIP 1.0.1 via ship-go
- Support for SPINE 1.3.0 via spine-go
- Certificate handling
- mDNS Support, incl. avahi support
- Connection (websocket) handling, including reconnection and double connections
- Support for handling pairing of devices
api
: global API interface definitions and eebus service configurationfeatures/client
: provides feature helpers with the local SPINE feature having the client role and the remote SPINE feature being the server for easy access to commonly used functionsfeatures/server
: provides feature helpers with the local SPINE feature having the server role for easy access to commonly used functionsservice
: central package which provides access to SHIP and SPINE. Use this to create the EEBUS service, its configuration and connect to remote EEBUS servicesusecases
: containing actor and use case based implementations with use case scenario based APIs and events
The examples folder contains a few demo applications using this stack. These do not provide complete implementations of any use case, but are intended as usage guidelines for the eebus-go stack in general and to have a quick demo.
Therefore, please do not expect any of these examples to provide any meaningful functionality on their own, but instead view them as rough guidelines on the functionality you could implement using the eebus-go stack.
This includes example code for sending an LPC limit 5 seconds after connecting to a compatible device that can receive LPC limits.
go run cmd/controlbox/main.go 4713
4713
is the example server port that this process should listen on
The certificate and key and the local SKI will be generated and printed. You should then save the certificate and the key to a file.
Usage: go run cmd/controlbox/main.go <serverport> <remoteski> <certfile> <keyfile>
remoteski
is the SKI of the remote device or service you want to connect tocertfile
is a local file containing the generated certificate in the first usage runkeyfile
is a local file containing the generated key in the first usage run
This includes example code for accepting LPC and LPP limits from a control box, receiving and printing data to the console from battery (VABD) and pv inverters (VAPD) and grid connection point data (MGCP).
go run cmd/hems/main.go 4714
4714
is the example server port that this process should listen on
The certificate and key and the local SKI will be generated and printed. You should then save the certificate and the key to a file.
Usage: go run cmd/hems/main.go <serverport> <remoteski> <certfile> <keyfile>
remoteski
is the SKI of the remote device or service you want to connect tocertfile
is a local file containing the generated certificate in the first usage runkeyfile
is a local file containing the generated key in the first usage run
This includes example code for accepting LPC from a control box.
go run cmd/hems/main.go 4715
4715
is the example server port that this process should listen on
The certificate and key and the local SKI will be generated and printed. You should then save the certificate and the key to a file.
Usage: go run cmd/evse/main.go <serverport> <remoteski> <certfile> <keyfile>
remoteski
is the SKI of the remote device or service you want to connect tocertfile
is a local file containing the generated certificate in the first usage runkeyfile
is a local file containing the generated key in the first usage run
The remoteski is from the eebus service to connect to. If no certfile or keyfile are provided, they are generated and printed in the console so they can be saved in a file and later used again. The local SKI is also printed.
- Double connection handling is not implemented according to SHIP 12.2.2. Instead the connection initiated by the higher SKI will be kept. Much simpler and always works
- PIN Verification is NOT supported other than SHIP 13.4.4.3.5.1 "none" PIN state is supported!
- Access Methods SHIP 13.4.6 only supports the most basic scenario and only works after PIN verification state is completed.
- Supported registration mechanisms (SHIP 5):
- auto accept (without any interaction mechanism!)
- user verification
This approach has been tested with:
- Elli Charger Connect
- Porsche Mobile Charger Connect
- SMA Home Energy Manager 2.0
Use SetLogger
on Service
to set the logger which needs to conform to the logging.Logging
interface of ship-go.
Example:
configuration = service.NewConfiguration(...)
h.myService = service.NewEEBUSService(configuration, h)
h.myService.SetLogging(h)