| Age | Commit message (Collapse) | Author |
|---|
|
This allows the sending part of the code to decide about the retain
flag. The MQTT go routine will set it accordingly.
|
|
This adds support for the TP-Link HS100 Wi-Fi plugs.
|
|
|
|
This is required to assign IDs and IP addresses.
|
|
|
|
This adds basic support for Shelly 2PM Gen3 devices.
|
|
This allows basic control of Covers connected to Shelly devices.
|
|
This scales better when additional receiving routes will be added.
|
|
This results in the information of which command is to issue and which
IP address the command has to be sent to.
This is what is needed to deliver the message with Websockets. This
delivery is the last step to implement basic Shelly cover support.
|
|
This let's the Sia server receive cover movement commands. For now they
are simply logged.
|
|
This simplifies debugging.
|
|
|
|
This allows to specify Shelly cover devices to be added to the
configuration file with all information required by the Sia server.
|
|
This makes sure the maximum `mqtt/topic-prefix` string length is
accepted.
|
|
This allows easily to add JSON configuration files testing certain
aspects.
|
|
Since the default configuration is a valid configuration it should
belong to this new directory. This allows to continue with extending
automated tests to test all configurations in this directory.
|
|
The validation step is always called in .FromJSON().
|
|
This was forgotten so far and fixed with `go mod tidy`.
|
|
It is even quite late to document the main application programming
interface (API) of the Sia server. This is now fixed.
|
|
An unbuffered channel triggers a warning here. This can easily be fixed
by switching to a buffered channel with buffer length 1.
|
|
This advertises the support for this and documents links to
documentation and the vendor home page.
|
|
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 makes clear that the current version is not a clean release.
|
|
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.
|
