Age | Commit message (Collapse) | Author |
|
|
|
Using Kconfig for now is a way to continue faster for now. Proper
runtime configuration should be added later.
The firmware in general should be fully usable without a DHCPv6 server
to not require central infrastructure.
While IPv6 link-local addresses provide static and unique addresses for
local communication and SLAAC provides global addresses there is still a
need for an additional static address.
For this there are basically two choices:
- global IPv6 prefixes
- IPv6 unique local addresses (ULAs)
ULAs are picked with this commit. They cannot be routed which makes
isolation from the internet independent of firewall rules adding
security.
Furthermore by picking them randomly they are in practise always unique.
This allows to assign them without a central IP network management and
allows to keep those addresses forever. Both great advantages over the
IPv4 192.168.0.0/16 and similar ranges.
|
|
|
|
The primary interface for this firmware was so far HTTP. This protocol
is not suitable for small and bidirectional messages which are
time-critical.
If something like this needs to be implemented with HTTP the best
approach is likely long-polling which at least makes it possible for the
server / the firmware to send data to the client / user as reaction to
an event like a closed door sensor.
TCP would fix this issue and is a good choice. Nevertheless web clients
are not allowed to open TCP connections for security purposes.
Thus the WebSocket protocol was created to fill this gap.
To not duplicate the any effort the WebSocket API should be used for
small, time-critical messages for all clients (one with TCP support like
CLI tools as well as web clients).
HTTP is still kept to provide a web page but also for functionality
where HTTP is more suitable like firmware uploads.
|
|
The heartbeat of the firmware might be used for multiple purposes. It
can trigger a blinking LED on the PCB, can be displayed in a client
program or might serve additional purposes.
Since at least display in client programs should be implemented and
multiple clients should be support in long term it improves the code
structure to use a zbus channel here to publish heartbeat messages in a
publish-subscribe pattern.
That way the publishing of the heartbeat message and the receiving by an
unknown number of observers is completely decoupled. A central trait of
the publish-subscribe pattern and an advantage for a modular code
structure.
|
|
This provides the index HTML page.
|
|
The used MAC address is from an example range. Later it can easily be
combined with reading from a MAC-providing EEPROM chip to using a unique
hardware MAC on the device.
|
|
|
|
|
|
Network-based logging via the syslog protocol allows to log from many
IoT devices to a central log server.
This makes reading logs way easier. Choosing UDP removes the need for
logic keeping a state. Maybe dropped packages are acceptable for the use
case but should be rare anyway.
|
|
This makes it easier to develop the whole network-related firmware parts
on a simulation board instead of hardware.
The nucleo_f767zi board has likely a hardware bug making Ethernet
sometimes fail. This is not suitable for development.
|
|
The Mozilla Public License seems to be suitable for this firmware
project. See the original license text for details.
This commit also adds a `.txt` suffix to the LICENSE file to make the
file type more visible to humans and tools.
|
|
This makes the name shorter which is especially relevant for Git commit
messages.
|