move things around

docs/pages/command.md

@@ -82,10 +82,10 @@ Or change the detector sensibility on all detector logics in all traffic lights:
 `command/all/all/detector/sensibility`
 
 
-## Response
-How would command responses be handled? We would use the request-response pattern, which is based on Response Topics. When you send a command, you pass a topic that would want to response to be published to. A supervisor sending a command could pass the response topic:
-`response/<supervisor_id>/component/module/command`.
+## Result
+How would command results be handled? We would use the request-result pattern, which is based on Result Topics. When you send a command, you pass a topic that would want to result to be published to. A supervisor sending a command could pass the result topic:
+`result/<supervisor_id>/component/module/command`.
 
-When a supervisor with id 22ba changing plan with `command/45fe/main/tlc/plan`, the respons would be send to `response/22ba/main/tlc/plan`.
+When a supervisor with id 22ba changing plan with `command/45fe/main/tlc/plan`, the respons would be send to `result/22ba/main/tlc/plan`.
 
-All supervisor can receive response if the just subscribe to `response/+/main/tlc/plan`.
+All supervisor can receive result if the just subscribe to `result/+/main/tlc/plan`.

docs/pages/messages.md

@@ -3,13 +3,40 @@ title: Messages
 permalink: /messages/
 nav_order: 100
 has_children: true
+has_toc: false
 ---
 
 # Messages
-RSMP 4 is based on MQTT. Messages are  send by publishing to a topic path and passing a payload.
+RSMP 4 defines the following messages with coresponding topic paths structures:
 
 
-## Payload
+| Message type | Topic path |
+|-|-|
+| [Presence](presence.md) | `presence/<sender>` |
+| [Status](status.md) | `status/<module>/<code>/<sender>/<component>` |
+| [Command](command.md) | `command/<module>/<code>/<receiver>/<component>` |
+| [Result](result.md) | `result/<module>/<code>/<sender>/<component>` |
+| [Alarm](alarm.md) | `alarm/<module>/<code>/<sender>/<component>` |
+| [Reaction](reaction.md) | `reaction/<module>/<code>/<receiver>/<component>` |
+
+
+All these topic paths (except presence) follow this layout:
+
+```
+<type>/<module>/<code>/<node>[/<component>]
+```
+
+- type: the type of message, either presence, statuss, command, resposne, alarm or reaction.
+- module: the name of the module.
+- code: the code of command/status/alarm within the module.
+- node: the id of the sender or receiver, depending on the message type.
+- component: indentifies one or more [components](components.md).
+
+The component can be left out as a shortcut to refer to the main component.
+
+The component is includes as part of the topic path (except for presence messages) to ensure that you can retain status, commands an alarms for each component.
+
+## Payload CBOR Encoding
 Message payloads consist of JSON encoded in binary format using [CBOR (Concise Binary Object Representation)](https://cbor.io).
 
 Using CBOR encoding saves space, while still retaining the JSON data model, which is very easy to work with.

docs/pages/result.md

@@ -0,0 +1,19 @@
+---
+title: Result
+parent: Messages
+nav_order: 3
+permalink: /messages/result/
+---
+
+## Command Result
+A command result is published after handling a command.
+
+```
+result/<module>/<code>/<sender>[/<component>]
+````
+
+Examples:
+```
+result/tlc/2/45fe             # TLC M0002 (for main component) result from node 45fe
+result/sensor/17/45fe/dl/3    # Sensor M0017 for detector logic 3 from node 45fe
+```