ACS issueshttps://git.rwth-aachen.de/groups/acs/-/issues2022-07-15T11:02:30+02:00https://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/17Make new Component for "Lighting Interface"2022-07-15T11:02:30+02:00Matthias Marcus NowakMake new Component for "Lighting Interface"Now we have 2 (or even 3?) ways to control LEDs:
- Directly attached to the ESP, controlled via PWM #5
- Using the PCA9536 GPIO Expander (used in the House exclusively), controlled via I2C
- Upcomming: PCA9956 LED Driver, controlled via...Now we have 2 (or even 3?) ways to control LEDs:
- Directly attached to the ESP, controlled via PWM #5
- Using the PCA9536 GPIO Expander (used in the House exclusively), controlled via I2C
- Upcomming: PCA9956 LED Driver, controlled via I2C
Best way would probably be to create a new component which selects the type of lighting interface usedhttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/16Put WiFi and MQTT config out of component config2022-07-12T15:28:48+02:00Jonathan KlimtPut WiFi and MQTT config out of component configone can use
```
source "../../Kconfig"
```
in a `main/Kconfig.projbuild` file, which works for `idf.py menuconfig` but fails at `idf.py build`...one can use
```
source "../../Kconfig"
```
in a `main/Kconfig.projbuild` file, which works for `idf.py menuconfig` but fails at `idf.py build`...https://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/15Improve Doxygen Docu2022-07-12T15:11:57+02:00Jonathan KlimtImprove Doxygen DocuIt is what it is, and what it is is rather underwhelmingIt is what it is, and what it is is rather underwhelminghttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/14Unify Kconfig.projbuild for entities2022-07-07T18:02:56+02:00Jonathan KlimtUnify Kconfig.projbuild for entitieshttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/13Split legos common library2022-07-07T17:40:00+02:00Jonathan KlimtSplit legos common librarye.g. the power part is not used on the substatione.g. the power part is not used on the substationhttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/12Temperature sensor rework2022-07-07T14:37:36+02:00Jonathan KlimtTemperature sensor reworkMake it more object-likeMake it more object-likehttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/11Pull out SPI init function2022-07-05T18:13:49+02:00Jonathan KlimtPull out SPI init functionhttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/9Update/Remove/Fix Copyright headers2022-07-05T18:05:13+02:00Jonathan KlimtUpdate/Remove/Fix Copyright headershttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/8Audio output for Stadium2022-07-05T16:33:42+02:00Jonathan KlimtAudio output for Stadiumhttps://git.rwth-aachen.de/acs/public/teaching/legos/firmware/-/issues/4MQTT Topics as part of KConfig2022-07-05T16:27:05+02:00Jonathan KlimtMQTT Topics as part of KConfighttps://git.rwth-aachen.de/acs/public/automation/double-virtualization/distributed-dvam/-/issues/2flows.json2022-07-05T11:02:41+02:00Nikolaus Wirtzflows.jsonflows.json not completely cleaned up
- dv am contains comment nod- e "TODO ?" and nodes debug / log to raspi 4
- data contains a debug node that can be removed
- dv asset
- contains a debug node that can be removed
- path of the...flows.json not completely cleaned up
- dv am contains comment nod- e "TODO ?" and nodes debug / log to raspi 4
- data contains a debug node that can be removed
- dv asset
- contains a debug node that can be removed
- path of the functions need to be updated (should be home\pi\distributed-dvam\functions\ABC, I think)
- Flow 1 can be removed
- all debug nodes after "take time" nodes can be switched offLukas LenzLukas Lenzhttps://git.rwth-aachen.de/acs/public/automation/double-virtualization/distributed-dvam/-/issues/1Documentation2022-07-05T10:31:44+02:00Nikolaus WirtzDocumentationhostnames need to be replaced by dummy hostnames before making repo public
command to generate flows.json files is not correct, should be
`python pi-setup-code.py flows.json`
instead of
`pi pi-setup-code.py flows.json`
python needs to ...hostnames need to be replaced by dummy hostnames before making repo public
command to generate flows.json files is not correct, should be
`python pi-setup-code.py flows.json`
instead of
`pi pi-setup-code.py flows.json`
python needs to be installed (not listed in requirements)
several warnings appear when running
sh pi-setup.sh
![grafik](/uploads/0c03dc735cc6855b022e39c38f23beb2/grafik.png)Lukas LenzLukas Lenzhttps://git.rwth-aachen.de/acs/public/virtualization/rpc-lib/rpc-lib/-/issues/4Consider rewriting with serde2022-07-01T14:12:20+02:00Martin Kröningmartin.kroening@eonerc.rwth-aachen.deConsider rewriting with serdehttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/9Code refactoring for behaviors2022-06-01T15:49:52+02:00Sonja HappCode refactoring for behaviorsThe code structure of agent behaviors is currently a little messed up.
- An agent behavior always requires a logic function `execute_agent_behavior()` that defines what the agent does in every simulation time step based on knowledge and ...The code structure of agent behaviors is currently a little messed up.
- An agent behavior always requires a logic function `execute_agent_behavior()` that defines what the agent does in every simulation time step based on knowledge and incoming messages of other agents that have been received via MPI (Message Routers).
- An agent behavior can OPTIONALLY use an instance of `villas_interface` to exchange data with external systems. This interface also requires a logic defining the interface initialization and its behavior in each simulation time step
We need to refactor the code structure so that it is clear where agent behavior logic and where agent VILLAS interface logic are implemented. It should be possible to use one VILLAS interface logic with multiple agent behavior logics and vice versa. Code duplication should be avoided as much as possible.
My first idea is separating the interface init + logic from the behaviors and moving it to separate classes that can be used by agent behaviors and are optionally called during agent behavior logic init and during `execute_agent_behavior()`.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/15Use C++ interface of VILLASnode2022-06-01T15:49:52+02:00Sonja HappUse C++ interface of VILLASnodeWe should switch to the C++ interface of VILLASnode in the `VILLASinterface` class to be compatible with the latest and coming versions of VILLASnode. This entails significant changes in the `VILLASinterface` class.
First and foremost, ...We should switch to the C++ interface of VILLASnode in the `VILLASinterface` class to be compatible with the latest and coming versions of VILLASnode. This entails significant changes in the `VILLASinterface` class.
First and foremost, we have use the "parse" functions of VILLASnode to set the config params of each node. Until now, we access and set these params manually. This is no longer possible because now they are "hidden" behind protected or private members of the VILLASnode `Node` class.
I suggest to move the configuration params for the `VILLASinterface` from the model.props to a separate json file (and specify the json file as config property in the model.props) so that the format of the config is similar to that of VILLASnode. We can read the json file in each process and hand the contents as `json_t` (using libjansson) to the VILLASinterface class.
This approach has one disadvantage: We would need to configure the signals (signal names, types, units) in the json file as well because they have to be known for the parsing process. This collides with the current approach of the `VILLASmessage` class that is used to derive and define a specific message format for an agent behavior and to facilitate the actual transfer of data between VILLASnode and DistAIX. We need to rethink this approach in order to avoid duplication of code and signal definitions.
If have started the work here 390dab5d.
Comments are welcome @felix.wegehttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/11CI: Create unit tests for VILLASnode interface2022-06-01T14:41:45+02:00Sonja HappCI: Create unit tests for VILLASnode interfaceWe should come up with some simple unit tests for the VILLASinterface class for the supported node types mqtt and nanomessage to ease the debugging.
For example, a ping pong between two agents could work to test basic functionality.We should come up with some simple unit tests for the VILLASinterface class for the supported node types mqtt and nanomessage to ease the debugging.
For example, a ping pong between two agents could work to test basic functionality.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/14Allow configuration of simulation start time in model.props file2022-04-25T15:57:26+02:00Sonja HappAllow configuration of simulation start time in model.props fileSee !11See !11Felix WegeFelix Wegehttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/5Handling of unexpected behavior2022-04-25T15:56:01+02:00Stefan DählingHandling of unexpected behaviorCurrently agents assume an ideal communication with other agents. This has to be extended such that agents can handle unexpected situations e.g., messages get lost, an agent replies with an unexpected message, an agent does not reply wit...Currently agents assume an ideal communication with other agents. This has to be extended such that agents can handle unexpected situations e.g., messages get lost, an agent replies with an unexpected message, an agent does not reply within a certain amount of time...https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/7Improve scenario file reading and storing2022-04-25T15:54:38+02:00Sonja HappImprove scenario file reading and storingCurrently all processes read and store the scenario files `component.csv` and `el_grid.csv`. This duplicates data in memory, since the same files are available in each process. Especially for large scenarios, this becomes convenient.
Th...Currently all processes read and store the scenario files `component.csv` and `el_grid.csv`. This duplicates data in memory, since the same files are available in each process. Especially for large scenarios, this becomes convenient.
The scenario files could be read by only one process and stored into an MPI shared memory section accessible by all processes on one computing node.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/6Improve profile reading and storing2022-04-25T15:54:22+02:00Sonja HappImprove profile reading and storingAt the moment, profiles are read by collective MPI IO operations and stored in each process. This can be improved by parallelizing the reading of all profile files and storing the data in a shared memory section on each computing node. T...At the moment, profiles are read by collective MPI IO operations and stored in each process. This can be improved by parallelizing the reading of all profile files and storing the data in a shared memory section on each computing node. The steps to take are the following:
- create a split MPI communicator for each node
- allocate one shared memory segment per profile on each node
- make sure that each profile file is read by only one process in the split MPI communicator
- store profile content to respective shared memory segment
- make sure that the FBScomponents library reads correctly from the shared memory segments
This method should no longer require collective MPI IO operations to read the profile files and reduce the required memory for profile storing.