Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
public:smart2b:home [2024/01/08 14:33] sergio.lujan_um.es |
public:smart2b:home [2024/10/09 08:53] (current) |
||
---|---|---|---|
Line 163: | Line 163: | ||
- Note the `ABL-.*` at the end of the URL. As a consequence, | - Note the `ABL-.*` at the end of the URL. As a consequence, | ||
+ | ### Verification of Context Source Registrations | ||
+ | After registering the Context Source it can be checked if the registrations process was successful --- i.e. the integrating partner software component that receives the messages from the NGSI-LD Broker in WP3 Smart2B Platform is supposed to be registered before actuation can carry over from the WP3 Smart2B platform all the way down to the building equipment. | ||
+ | |||
+ | The following POSTMAN collection can be employed in order to verify if the Context Source Registration took place successfully. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **IMPORTANT** | ||
+ | |||
+ | There is a limitation of `1000` items per query, specified as an URL option like this: | ||
+ | |||
+ | ``` | ||
+ | https:// | ||
+ | ``` | ||
+ | |||
+ | In order to request the following 1000 items, the `offset` variable must be set like this: | ||
+ | |||
+ | ``` | ||
+ | https:// | ||
+ | ``` | ||
+ | |||
+ | - For more information about the high-level architecture and flow of Actuation, please refer to [Low level interaction for actuation with NGSI-LD Broker](# | ||
## Smart2B platform resource monitoring processes | ## Smart2B platform resource monitoring processes | ||
Line 404: | Line 426: | ||
Knowing this, we would ask Brida to contact the partners in charge of the endpoint " | Knowing this, we would ask Brida to contact the partners in charge of the endpoint " | ||
``` | ``` | ||
+ | |||
+ | ## Actuation | ||
+ | |||
+ | ### Low level interaction for actuation with NGSI-LD Broker | ||
+ | |||
+ | **IMPORTANT** please note that in this scenario, the Sequence starter would be the T3.3 Translator developed by Andrea EB. | ||
+ | {{: | ||
+ | |||
+ | |||
+ | {{: | ||
+ | |||
+ | ### Procedure to check actuation issues. | ||
+ | |||
+ | - First of all, check that the entity is created in the broker, using the Entity Info Collection Spreadsheet. It must be in the `Actuators` tab of the spreadsheet. | ||
+ | - Check that the query is using the right attribute --- Column `J` in the spreadsheet. | ||
+ | - Check the status of the **Context Source registration** - **TODO** | ||
+ | - E.g. Query with a GET request the same ACTUATOR entity and look at the `command` attributes and their info. | ||
+ | - Query the broker itself to get relevant information about the Context Source registration for its entities --- should get the partner IP address and TCP port. | ||
+ | - Check that a Context Source Registration exists for the particular entity in the Broker. For this, follow [these instructions](# | ||
+ | - If the context source registration is not propertly done --- get in contact with the relevant pilot owner. (For SCML it would be EDP SEL, for AOC its either ODINS or EB, for ABL its Martin Kaufman, for CJC is EB, for ARA is EDP Miguel) | ||
+ | - If the context source is successfully registered, when the commands are not reaching the building equipment, get in contact with the relevant pilot owner. | ||
+ | |||
+ | |||
+ | ## Get a complete list of Smart2B platform entities by type | ||
+ | |||
+ | Below is attached a JSON file that contains a Postman collection with the necessary requests to recover all the information corresponding to the entities of each type that are registered on the Smart2B platform: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | To import a collection of requests into Postman we must go to our Workspace, press the " | ||
+ | |||
+ | This Postman collection contains the requests necessary to request an authentication token, an authorization token, and then retrieve the information for all entities of a specific type. To launch these last requests, we must always keep the " | ||
+ | |||
+ | |||
+ | ## Healthcheck and Gotify monitoring | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Due to the recent issues due to services being down in pilot tests, we will integrate a simple watchdog mechanism. | ||
+ | |||
+ | The intention of this mechanism is to have a common notification platform (Gotify.odins.es) where all the relevant partners (specially the pilot owners) will be notified within minutes if a component is down due to some unknown reason. | ||
+ | |||
+ | ### Steps to follow by non-technical partners (Project coordination or Pilot Leaders) | ||
+ | |||
+ | - Gotify is the chosen tool to notify relevant partners (coordination, | ||
+ | |||
+ | - In your favourite device, go to https:// | ||
+ | |||
+ | - user: `smart2b` | ||
+ | - pass: `52MTf4hxcYnNJCrM` | ||
+ | |||
+ | Alternatively you might install the official Gotify SmartPhone Tools | ||
+ | |||
+ | - https:// | ||
+ | |||
+ | Check periodically this notification web when an experiment is near. If there are recent notifications, | ||
+ | |||
+ | ### Steps to implement by Integrating/ | ||
+ | |||
+ | #### Gotify.odins.es | ||
+ | |||
+ | - Gotify is the chosen tool to notify other partners (coordination, | ||
+ | |||
+ | - ODINS is running our own instance of Gotify at https:// | ||
+ | |||
+ | - Got there and use the following credentials: | ||
+ | |||
+ | - user: `smart2b` | ||
+ | - pass: `52MTf4hxcYnNJCrM` | ||
+ | |||
+ | - Next, create your own APP at the top titled after your partner --- here we have relative freedom to pick anything that makes sense to you, do not constrain yourself with the details. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - **NOTE** you might disregard the `Priority`, it is something that has not been discussed yet at a technical level and do whatever. For us all notifications are to be attended so priority is not a criteria to pick which one to attend. | ||
+ | |||
+ | - Choose your created APP and get your authorization token: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - This token is the one that must be employed by the next section. | ||
+ | |||
+ | - Besides, the gotify procedure might be employed in case that something is going wrong or an issue has been detected proactively. | ||
+ | |||
+ | - https:// | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | #### Healtchecks.io | ||
+ | |||
+ | - Each partner must create their own account in the free service https:// | ||
+ | |||
+ | - Next create a project within the application | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - Next create a check with the most frequency possible, adapted to your needs, but we are talking a matter of minutes. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - Click the three-dot menu to setup the check | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - Click on the Use examples in order to know what queries must be run from the watched component towards healthcheck | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **NOTE** that many different languages/ | ||
+ | |||
+ | - Next, click the `INTEGRATIONS` tab and choose your preferred methods, among them email is suggested. | ||
+ | |||
+ | - Next, click the `Gotify` integration, | ||
+ | |||
+ | - In the `Gotify Server URL` type `https:// | ||
+ | |||
+ | - In the `Application Token` paste the APP token that you grabbed from `gotify.odins.es`. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | It should look like this. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - It is recommended that you try to test the integration and see if the notification reaches Gotify | ||
+ | |||
+ | {{: | ||
+ | |||
+ | - Henceforth, the monitored component must ping the `healthchecks.io` server within the specified period of time. Otherwise, it will post a notification towards Gotify, so that all the partners are aware that maybe something is wrong and can react accordingly. | ||
+ | |||
+ | |||
+ | |||