Version 2.0 with new DigitalSTROM API #45
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Spelling error in an error message - Fixing a linter error about a buffered channel for signals - Stop DigitalStrom loop on gracefully shutdown
Changes made: - Usage of global Viper config (no need to create a new one) - Update the interface as the public method was `FromEnv` and that wasn't 100% accurate as config could be read from a file. - Now it is checked for required fields and also deprecated ones inside the config module - Improve error handling by making it more Go friendly and return errors if the reading of the config fails (and wrapping viper errors if needed). - Create fixture config file for tests - Extend the tests to cover more cases (defined in file, env, both,...)
Now the HTTP Client has the knowledge about the endpoints and how should they be called (path and params). This is important as the current logic was reappending the token param on each retry and for that reason I updated the params to be passed as url.Values which provide a much better interface to encode them in the URL.
Those values are not being used (they are only passed in CircuitValueChanged struct) and there is no need to keep them on the original struct if they are unused. They are being updated, but the logic is flawed as we are passing the Circuit as a value and not as a reference, therefore the update logic doesn't change the stored value.
Previously we were making one request per (device, channel) pair, and now using the getOutputChannelValue endpoint to fetch all the devices channel values in a single call.
This allows to have parallel instances of digitalstrom-mqtt running in parallel connected to the same DS Server (prod and development). When multiple instances connected to the same server with same subscription ID, then the events are not correctly routed to both running instances, and having different IDs solve it.
This change finalizes the previous work on providing explicit structs for all the objects returned by DS API and to provide functions to call the API directly from the client. This provides better abstraction as the underlying endpoints and parameters structure could be change now under the Client (e.g. migrating to new API version) without the need to change the modules that want to retrieve these endpoints.
Right now they are quite independent and there are no external dependencies and therefore makes sense to have them as a separate packages
This interface is cleaner and encapsulates all the logic related to the connection to the DS server: API calls and event loops. The interface is highly inspired by the implementation of the MQTT client and could be reused externally for other usercases that are not related to export things into MQTT.
This required some changes that simplify things: - EventManager now only holds a channel, the event loop is handled by the client - Subscribed events are passed as part of the options which simplify the management of the event loop and the concurrency changes to the subscribed event types.
Addig an item to the channel blocks until is received by the event loop which will happen only after the idle request gets handled.
This would reorganize the code in a more standarized way: https://github.com/golang-standards/project-layout
Also renamed the client interface as digitalstrom.Client() to be concise and fully descriptive.
Now the events are registered by type and for each type a callback is provided and will be executed when such event received.
Those modules will be independent workflow insisde the DS/MQTT bridge. Some examples of workflows: 1. Circuits: every 30 seconds fetch the values and publish to MQTT 2. Circuits on event publish change and on command receive push change to DS 3. Joker buttons to be added
This module is reponsible for the logic of device values propagation from DS to MQTT and viceversa.
This module is responsible to keep track for all the scene in the apartment and also handle commands to activate a scene.
This module is responsible to subscribe to the push buttons events and publish them into the MQTT server.
The discovery logic is implemented and presents and interface that the modules need to implement in order to get their entities being exported to Home Assistant
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New features:
Downside:
Closes #14 #33 #34 #40 #44