| Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
|
|
|
|
The new structure for the contact states is the following.
<prefix>/contact/<id>/state
The reasoning is:
- `<prefix>` allows using multiple (Sia) services on the same broker
- `contact` as device type indicates contact-specific semantics
- `<id>` makes different contacts distinguishable
- `state` is the actual payload
|
|
The old prefix `sia-server` was longer and not completely correct. The
topics under this prefix never belong more to the server or the clients.
Thus only `sia` seams to be a good solution.
|
|
This unifies the HOST and PORT constants used so far and removes the
need for a fmt.Sprintf() call.
|
|
This demonstrates the ability to take information from the Homematic
system to MQTT. It is a major proof of concept step towards a minimal
viable product (MVP) Sia server.
|
|
This dependency is required to use MQTT with Go.
|
|
This requests a list of devices from the Homematic central device and
then queries the state of every `SHUTTER_CONTACT`.
This is a good starting point for the server logic.
|
|
This is the minimal viable product (MVP) of this library suitable to
build the MVP of the sia-server.
|
|
This allows to add dependencies to this Go project.
|
|
Meson as a general purpose build system is mightier than what the Go
tool can provide. Furthermore it makes it possible to unify build, run
and other workflows across projects with different languages.
|
|
This is just a minimal starting point for the repository.
|
|
|