adrianghc / hems Goto Github PK

While the intended flow is for modules to set/delete tasks and automation profiles through the Automation and Recommendation Module (see page 20 in doc/thesis.pdf), this can currently be circumvented by interacting with the Data Storage Module directly. It must be ensured that only the Automation and Recommendation Module can tell the Data Storage Module to set or delete tasks and automation profiles, and that all other modules must refer to the Automation and Recommendation Module for this. This may be a hard-coded special case or alternatively, a generic mechanism to restrict certain message types to certain modules could be introduced.

Tests for the settings mechanism should be enhanced with at least two test cases:

1. The settings initialization process (by testing the SETTINGS_INIT message and/or by testing the settings initialization by the Launcher Module).
2. The pre_init_whitelist mechanism for messages that are accepted by a module before the settings initialization has finished.

Currently, tests spawn instances of the Launcher Module and the Data Storage Module to e.g. test communication between modules. It may be cleaner to define two distinct test module types for this purpose instead of misappropriating these existing module classes.

Currently, log messages are timestamped and logged by the Launcher Module in the order that they arrive, which does not necessarily reflect the order in which they are sent. To fix this, messages should be timestamped by the modules that send them. In addition, by buffering a fixed number of messages before logging them (instead of logging messages as they arrive), the Launcher Module could sort all messages in the buffer by their timestamp before logging them, but this is an imperfect solution with many caveats. Alternatively, MSG_LOG messages could be sent synchronously instead of asynchronously.

Currently, message response codes are not documented in the request datatypes in the include/hems/messages headers, but instead as return values for the handler functions for these request messages. This is a very flawed approach from an API documentation standpoint, as a developer wanting to send a message to a module currently needs to look in two places in the code: One to learn the format of the message and a separate place to learn the possible responses. Instead, possible message response codes need to be documented (additionally or exclusively) in the request datatype declarations.