-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add source to enable/disable commands/events #505
Conversation
corneliusclaussen
commented
Jan 23, 2024
•
edited
Loading
edited
84a4278
to
847d96f
Compare
847d96f
to
6e9660b
Compare
88c8d2a
to
bfb8e30
Compare
bfb8e30
to
dc3e7a6
Compare
@james-ctc Anything missing here still or are we good? |
All good to review and merge |
a364314
to
8023cb6
Compare
317b3e4
to
7c387e1
Compare
7c387e1
to
070c72f
Compare
It replaces the old enable/disable commands and adds a source and priority. See README of the API module for more details. Compile time breaking change on the evse_manager interface. All enable/disable calls need to be switched over to the new enable_disable call, for everest-core this is done in this PR. In some uses cases it is useful if e.g. a LocalAPI source disables a connector that only the same local source can enable again. Think of a service technician who has an app to disable the connector locally. Then it should be prevented that it is re-enabled by the CSMS until the service technician enables it again via the same app. Using priorities this is quite flexible and a lot of use-cases can be implemented without a change in EVerest code. The API module also has a new enable_disable command. It also has compatibility implementations for the old enable/disable commands. Signed-off-by: Cornelius Claussen <[email protected]> fix: merge issues fix: updated README Signed-off-by: James Chapman <[email protected]>
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Piet Gömpel <[email protected]>
Signed-off-by: Piet Gömpel <[email protected]>
Signed-off-by: pietfried <[email protected]>
b0b0f7b
to
dbc8527
Compare
@SebaLukas your review is also required for this one. |
description: Priority of this entry. The highest priority is 0. | ||
type: integer | ||
minimum: 0 | ||
maximum: 10000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to use 10000 here? I'd stick to usual byte range boundaries here, e.g. 255 - should be far enough IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look okay to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
…face EVerest release 2024.5.0 introduced a change in the evse_manager interface: see EVerest/everest-core#505 So a small adaption is needed in both modules to cover the new/replaced command(s). Signed-off-by: Michael Heimpold <[email protected]>
…face EVerest release 2024.5.0 introduced a change in the evse_manager interface: see EVerest/everest-core#505 So a small adaption is needed in both modules to cover the new/replaced command(s). Signed-off-by: Michael Heimpold <[email protected]>