| Age | Commit message (Collapse) | Author |
|---|
|
An unbuffered channel triggers a warning here. This can easily be fixed
by switching to a buffered channel with buffer length 1.
|
|
This implements the minimal functionality to control covers with the Sia
server in the development tool.
Based on that the actual Sia server software can be adapted.
|
|
This makes it easier to distinguish the JSON messages visually.
|
|
This makes the responses from the Shelly device readable.
|
|
This allows to more easily see what is sent to the Shelly device.
|
|
This is the first working command for the Shelly 2PM Gen3.
|
|
Programming in too many languages ... of course not needed in Go.
|
|
Now the connection is immediately established but just closed on SIGTERM
and SIGINT.
This allows to keep the connection for some time and lets the user
decide when to stop.
|
|
This was validated by sniffing the communication with Wireshark. The
following is executed:
- TCP initial handshake
- GET /rpc from tool
- HTTP 101 Switching Protocols (to Websocket) from Shelly
- ACK by tool
- TCP connection close initiated by tool
This shows that the tool is able to make Websocket connections.
|
|
Adding support for Shelly devices requires usage of the Websocket API.
To make development easier a debug tool is created.
Since it is not relevant for users it is not an artefact included into
the deploy file archive. This also avoids later removing it which is by
definition of the public API (see README.md) a breaking change.
|
|
This advertises the support for this and documents links to
documentation and the vendor home page.
|
|
This was forgotten so far and fixed with `go mod tidy`.
|
|
This is the first release of the Sia server. It is the Minimal Viable
Product (MVP).
|
|
This project should use semantic versioning. This requires defining the
public Application Programming Interface (API).
|
|
|
|
|
|
|
|
This information is useful in the deploy tar archive. Thus it is copied
there.
|
|
|
|
Before this commit the start banner `+++ Started Sia server +++` was
printed before the usage instructions. The stop banner was not printed.
The intended behaviour is to print none of them. This is not
implemented.
|
|
This makes it possible to run the Sia server executable on systemd-based
Linux distributions with systemd making system administration easier.
Maintaining these files in the source instead of packaging repository
was decided since systemd is the dominant init system across Linux
distributions and thus not every distribution-specific packaging repo
needs to re-invent the wheel.
|
|
The default configuration from the source tree is embedded into the
executable with Go's embed package to assume the correct defaults.
Furthermore it is now also part of the artifact tar archive to give
users an idea how a configuration file should look like.
|
|
This allows to use the version of the project in the build system
independent from the version control system. Thus a source tar archive
can be built the same and also changing the version control system does
not change anything regarding the build process.
|
|
This is reserved foooooooooor local development.
|
|
Bundling all build artifacts into one tar archive is good practise to
make deployment easier and underline which files in the build directory
are important.
zstd was picked for compression because of the very good compression
ratio.
|
|
This renames `sia-server` to `sia-server-linux-amd64`. This makes clear
for which target environment the executable is built and allows to later
place additional executables for other environments too without name
collisions.
|
|
The primary target environment is a systemd-based Linux system. There
the logging system of the operating system will timestamp the log
messages.
|
|
This is useful during early development to make possible
misconfiguration visible.
Later it might be dropped especially if the config gets larger.
|
|
This allows overwriting values of the default configuration with custom
ones.
|
|
This method makes it easy to validate a configuration.
A call of it is now embedded into the StartupConfiguration.FromJSON()
method which should always be the lowest level function to parse
configurations.
Thus configurations can usually be trusted.
|
|
The default config JSON is embedded as bytes into the executable.
Instead of constants the default values are now parsed from these
embedded bytes.
|
|
This is a first step towards configurability.
|
|
|
|
This indicates if the Sia server is available and connected to the MQTT
broker.
Using the MQTT Will messages these will also be sent if the Sia server
unexpectedly crashes.
Using the retained flag it is ensured that freshly connected MQTT
clients will receive these messages even when they missed the initial
one from the Sia server.
|
|
This is as simple as do not handling errors on state polling.
It ensures the server does not panic when the connection to the OpenCCU
is temporarily not alive.
|
|
Similar to a previous refactoring of the MQTT-related code this removes
all Homematic logic to a dedicated file.
The only connection to the outside is the `tx chan MQTTMessage` channel
and the `HomematicRun()` function.
This makes the code more modular.
|
|
This issues ping request / response messages between the Sia server and
the MQTT broker making sure an interrupted connection is noticed.
|
|
This is a central requirement to ensure a restart of the MQTT broker
does not harm the Sia server operation.
|
|
This makes connection loss visible during debugging.
|
|
This reduces the coupling between the MQTT-related code and everything
else to a single `tx` channel of type `MQTTMessage`.
This improves the code quality significantly.
|
|
This ensures the state updates reach the broker. QoS 2 is not required
since multiple reception of the same state will not make a difference.
|
|
The old version `sia-server` was problematic since the MQTT
specification [1] ensures only this list of valid characters:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
For every other character the broker might support this or not.
[1]: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718031
|
|
`true` and `false` are bad values to describe a contact state. `open`
and `closed` make much more sense.
|
|
This ensures the MQTT broker caches the state when it is sent by Sia and
sends it via MQTT to new MQTT clients.
Thus no state polling is required by the MQTT client.
|
|
The human reaction time is roughly 100 ms. The Nyquist-Shannon
sampling theorem [1] is used for an approximation how often it is
required to sample without humans noticing any delays.
[1]: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
|
|
This avoids frequent MQTT messages containing the same state.
|
|
This state polls the device states with 500 milliseconds period and
publishes the state on every poll.
|
|
This function allows to reduce the lines of code in main() further.
|
|
This reduces the lines of code of the main() function significantly and
groups all start and stop actions.
|
|
This helps to debug potential issues.
|
