IQRF Gateway Daemon issueshttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues2024-03-28T14:18:40+01:00https://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/240Update JSON API schemas2024-03-28T14:18:40+01:00Karel HanákUpdate JSON API schemas- [ ] update to draft 7 and use new features (if-then-else, const instead of single element enums and more...)
- [ ] shared definitions and references
- [ ] add missing required lists
- [ ] add missing additionalProperties (false)
- [ ] ...- [ ] update to draft 7 and use new features (if-then-else, const instead of single element enums and more...)
- [ ] shared definitions and references
- [ ] add missing required lists
- [ ] add missing additionalProperties (false)
- [ ] add missing additionalItems (false)
- [ ] minimum and maximum of numeric properties by data type and number of bytes
- [ ] update schemas to include new propertiesv3.0.xOndřej HujňákOndřej Hujňákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/251include command and nadr in DALI FRC response2024-03-27T14:07:48+01:00Karel Hanákinclude command and nadr in DALI FRC response/data/rsp/result/command
/data/rsp/result/answers/[]/nadr/data/rsp/result/command
/data/rsp/result/answers/[]/nadrKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/252JsonDpaApiIqrfStdExt: use nlohmann json to process data response data, fix se...2024-03-26T15:59:45+01:00Karel HanákJsonDpaApiIqrfStdExt: use nlohmann json to process data response data, fix selected nodes- removed first item in result object (zero value coordinator item)
- selected nodes now actually returns only selected nodes
- replaced rapidjson with nlohmann json- removed first item in result object (zero value coordinator item)
- selected nodes now actually returns only selected nodes
- replaced rapidjson with nlohmann jsonKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/250Replace JS drivers with native C++ library2024-03-04T13:11:53+01:00Karel HanákReplace JS drivers with native C++ libraryKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/242IqrfDb: rework to include metadata2024-03-01T14:38:48+01:00Karel HanákIqrfDb: rework to include metadata- [ ] rozdělit IqrfDb na 2 komponenty (interní API pro DB a enumerační komponenta)
- [ ] nejprve posbírat všechny potřebné informace a až následně zasahovat do databáze
- [ ] pokusit se vyenumerovat produkt z metadat, fallback při chybác...- [ ] rozdělit IqrfDb na 2 komponenty (interní API pro DB a enumerační komponenta)
- [ ] nejprve posbírat všechny potřebné informace a až následně zasahovat do databáze
- [ ] pokusit se vyenumerovat produkt z metadat, fallback při chybách
----------------------------------------------------------------------------
Aktuální proces
## 1 Zjištění stavu sítě
- bonded => toEnumerate
- discovered => discovered
- mids => mids
- routing (vrn, parent, zone) ...
Data jsou uložena do množin a map s adresou jako klíč.
Porovnání se záznamy zařízení v DB:
- pokud adresa je v DB a není v bonded, je vložena do mapy pro odestranění
- pokud adresa je v DB a v bonded a sedí MID, adresa je odebrána z množiny pro enumeraci
- pokud adresa je v DB a v bonded a nesedí MID, adresa zůstává v množině pro enumeraci
- pokud adresa není v DB, adresa zůstává v množině pro enumeraci
Pokud je vynucena opětovaná enumerace, provádí se vše.
## 2 Enumerace zařízení
### 2.1 Enumerace [C]
- data z coordinatorParams, získáno z IqrfDpa komponenty
- čtveřice hwpid, hwpidver, os, dpa použita jako klíč unikátního produkt a produkt uložen v mapě produktů (pokud čtveřici již známe z předchozího zařízení, použije se existující)
- zařízení uloženo v mapě produkt-zařízení jako dvojice adresa a pointer na unikátní produkt
### 2.2 Enumerace [N]
#### 2.2a Polling
- pokud se má vyenumerovat jen jedno zařízení
- provádí se OS read a peripheral enumeration dotazy
- ze získaných dat opět unikátní produkt a dvojice produkt-zařízení uloženy
#### 2.2b FRC
- frc hwpid, os, dpa (zde se získává i verze OS, tu není třeba zjišťovat, důležitý je OS build)
- ze získaných dat opět unikátní produkt a dvojice produkt-zařízení uloženy
## 3 Enumerace produktových balíčků
Pro každé zařízení najít balíček, doplnit produktové informace, vytvořit záznamy produktu a zařízení
### 3.1 Nalezení balíčku
- pokus získání balíčku z cache dle konkrétní čtveřice hwpid, hwpidver, os, dpa
- pokud selže, zkusit najít produkt v db a použít místo balíčku
- pokud selže, pokus získat balíček dle 0, 0, os dpa
- pokud selže pokus získat balíček s hwpid, hwpidver, os a nižší verzí dpa
### 3.2 Update produktového záznamu z balíčku
- do produktu doplněny handler, hash, poznámky, custom driver
### 3.3 Uložení driverů
- pro každou periferii produktu pokus najít záznam driveru v DB (dle čísla periferie a verze driveru)
- pokud driver neexistuje, vytvoří se nový driver záznam v db a id driveru se předá produktu pro pozdější párování
- pokud driver existuje v DB, použije se existující záznam
### 3.4 Uložení produktů a zařízení
- pokud v DB neexistuje produktový záznam, vytvoří se a dále se vytvoří vztah mezi produktem a drivery
- pokud v DB existuje produktový záznam, použije se
- pokud v DB neexistuje zařízení s adresou, vytvoří se nové
- pokud v DB existuje zařízení s adresou, updatují se jeho položky a změny jsou uloženy
Nakonec jsou načteny produktové drivery.
## 4 Enumerace standardů
### 4.1 Selekce zařízení k enumeraci
- u každého zařízení v DB zkontrolovat zda jeho standardy byly vyenumerovány
- pokud nebyly, nebo pokud je vynucena enumerace, adresa zařízení je uložena k enumeraci standardů
### 4.2 Enumerace jednotlivých standardů
- pro každé zvolené zařízení se zkontroluje v DB jestli má standardy
- pokud implementuje standard
#### 4.2.1 Binout
- enumerace binout request
- pokud existuje záznam pro BinaryOutputDevice, updatovat počet implementovaných BO
- pokud záznam neexistuje, vytvořit nový (deviceId, počet)
#### 4.2.2 Dali
- pokud zařízení má periferii, uložen záznam pro DaliDevice (deviceId)
#### 4.2.3 Light
- enumerace binout request
- pokud existuje záznam pro LightDevice, updatovat počet implementovaných BO
- pokud záznam neexistuje, vytvořit nový (deviceId, počet)
#### 4.2.4 Sensor
- enumerace senzorů zařízení
- pro každý typ kontrola existence záznamu v DB
- pokud typ senzoru existuje, použije se záznam
- pokud neexistuje, vytvoří se nový záznam
- vytvořen nový vztah zařízení-senzor pro každý sensor type v odpovědi enumerace senzorův3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/248SensorDataService: asynchronous API notifications2024-02-19T11:49:18+01:00Karel HanákSensorDataService: asynchronous API notificationsDevise status codes for individual states:
- started
- failed to start (exclusive access, why else?)
- finished
- more?Devise status codes for individual states:
- started
- failed to start (exclusive access, why else?)
- finished
- more?v3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/208Scheduler rework2024-02-19T11:45:39+01:00Karel HanákScheduler rework- [ ] request processing should not depend DPA queue as there is no interaction with the network
- [x] use UUIDv4 as task ID instead of signed integers
- [x] respect existing task IDs instead of always generating new ones (generate new o...- [ ] request processing should not depend DPA queue as there is no interaction with the network
- [x] use UUIDv4 as task ID instead of signed integers
- [x] respect existing task IDs instead of always generating new ones (generate new on collision)
- [ ] select execution condition and store only relevant information (currently if-elseif-else)
- [x] accept ISO time format and take timezone into account when processing one-shot task execution
- [x] edit existing task instead of having to remove old task and create new (also leads to new task ID)
- [x] complete jsonschema specification (w/o messages)
Relevant issues:
open-source/iqrf-gateway-daemon#168
open-source/iqrf-gateway-daemon#169
@ondracekr @spinarr Input on these would be great, additional suggestions or specs. To be discussed.v3.1.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/211Zpracování management API requestů ve vlastní frontě2024-02-19T11:45:34+01:00Karel HanákZpracování management API requestů ve vlastní frontěAktuálně se všechny requesty zpracovávají jednou frontou.
Requesty, které nijak nepracují s IQRF sítí by měly být zpracovány ve vlastní frontě. Běžící requesty, které pracují s IQRF sítí by neměly blokovat zpracování ostatních requestů....Aktuálně se všechny requesty zpracovávají jednou frontou.
Requesty, které nijak nepracují s IQRF sítí by měly být zpracovány ve vlastní frontě. Běžící requesty, které pracují s IQRF sítí by neměly blokovat zpracování ostatních requestů. Aktuálně existuje jen jedna fronta.
Příkladem nežádané situace je dotaz na získání tasků plánovače, ale v případě že fronta je plná, tak se dotaz zahodí i přesto, že ke zpracování IQRF síť nepotřebuje. Nejen, že není možné získat tasky, není je možné ani smazat, zrušit. Prakticky je daemon nepoužitelný skrze api v takovýchto situacích.
Získání verze daemona například nijak nezávisí na dokončení autonetworku...
Pro začátek navrhuji 2 fronty:
-management tasky (plánovač, verze daemona, mód, exit, databázové requesty, pokud jen vytahují informace z databáze a nekomunikují se sítí)
-síťové tasky (vše pro periferie, iqmesh služby...)
Je třeba se také zamyslet nad potenciálními prioritami některých requestů, abychom se mohli rozhodnout jak se zachovat v určitých situacích.v3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/246SensorDataService: poll and frc failure information in response2024-01-30T13:20:16+01:00Rostislav SpinarSensorDataService: poll and frc failure information in response- should we indicate in json rsp that some readings/nodes are not available in the poll period?
- should we indicate different nodes error states as we get them from sensor frc or read sensors dpa responses?
also @ondracekr- should we indicate in json rsp that some readings/nodes are not available in the poll period?
- should we indicate different nodes error states as we get them from sensor frc or read sensors dpa responses?
also @ondracekrv3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/245JsonSplitter: differentiate between messaging types to prevent instance name ...2024-01-02T10:16:35+01:00Karel HanákJsonSplitter: differentiate between messaging types to prevent instance name collisionsv3.0.xhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/243Scheduler: blacklist API messages that shouldn't be scheduled2023-12-11T11:02:15+01:00Karel HanákScheduler: blacklist API messages that shouldn't be scheduledv3.1.xhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/241IqrfDb: check for new/different package ID when re-enumerating network2023-12-11T10:53:00+01:00Karel HanákIqrfDb: check for new/different package ID when re-enumerating networkif cache returns different package ID for a combination of OS, DPA and HWPID:
- [ ] update device record
- [ ] check for changes in device-sensor pairings
- [ ] update drivers
- [ ] reload js render contextsif cache returns different package ID for a combination of OS, DPA and HWPID:
- [ ] update device record
- [ ] check for changes in device-sensor pairings
- [ ] update drivers
- [ ] reload js render contextsv3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/234IqrfDb: check and update product information when cache is updated2023-12-09T10:29:37+01:00Karel HanákIqrfDb: check and update product information when cache is updatedv3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/239coordinating network traffic with autonomously running services2023-12-08T13:08:21+01:00Karel Hanákcoordinating network traffic with autonomously running servicesexample: sensor data service worker active, data fetching in progress => use management queue to stop worker => perform actions => start worker again
- [ ] manage iqrf network queue via management queueexample: sensor data service worker active, data fetching in progress => use management queue to stop worker => perform actions => start worker again
- [ ] manage iqrf network queue via management queuev3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/207Websocket security2023-12-08T12:48:52+01:00Roman Ondráčekroman.ondracek@iqrf.orgWebsocket security1. Je potřeba přidat podporu šifrování komunikace pro WebSocket
* [ ] @mikuluf Implementace ([ukázková implementace](https://github.com/zaphoyd/websocketpp/blob/master/examples/echo_server_tls/echo_server_tls.cpp))
* [x] @ondrace...1. Je potřeba přidat podporu šifrování komunikace pro WebSocket
* [ ] @mikuluf Implementace ([ukázková implementace](https://github.com/zaphoyd/websocketpp/blob/master/examples/echo_server_tls/echo_server_tls.cpp))
* [x] @ondracekr Vygenerování TLS klíčů během instalace balíčku + úprava balíčků pro webapp, aby byl nově vygenerovaný klíč použit také pro HTTPS
2. Je potřeba autentizovat a autorizovat uživatele/další aplikace
* Autentizace uživatelů může být řešena pomocí jména a hesla (musí se ukládat pouze hash hesla, bezpečné hashovací funkce jsou například bcrypt, scrypt a Argon2) a autorizace může být řešena pomocí JSON Web Tokenů ([RFC 7519](https://tools.ietf.org/html/rfc7519)). Řešení pro webapp. Knihovny pro C++: https://github.com/troian/josepp, https://github.com/Thalhammer/jwt-cpp
* Autorizace dalších aplikací může být řešena přes API klíče.
* Je nutné vymyslet jak uživatele autentizovat a autorizovat, když daemon nebude běžet.
* Token/API klíč bude muset být v JSON requestu.
3. WebSocket a UDP rozhraní by se měli upravit, aby šlo nastavit i na jakých adresách budou poslouchat. Protože aktuální řešení pouze kontroluje hlavičku `Host`, do které si může každý napsat co chce. A běžný uživatel se nebude hrabat v iptables/nftables, aby upravil nastavení firewallu.https://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/232Metadata format2023-12-08T12:45:55+01:00Karel HanákMetadata format```json
{
"metadataVersion": 0,
"sensors": [
{
"id": "TEMPERATURE",
"type": 1,
"name": "Temperature",
"shortName": "t",
"unit": "°C",
"decimalPlaces"...```json
{
"metadataVersion": 0,
"sensors": [
{
"id": "TEMPERATURE",
"type": 1,
"name": "Temperature",
"shortName": "t",
"unit": "°C",
"decimalPlaces": 4,
"frcs": [144, 224]
},
{
"id": "BINARYDATA7",
"type": 129,
"name": "Binary data7",
"shortName": "bin7",
"unit": "?",
"decimalPlaces": 0,
"frcs": [16, 144],
"breakdown": [
{
"id": "BINARYDATA7",
"type": 129,
"name": "Potentiometer",
"shortName": "pot",
"unit": "%",
"decimalPlaces": 1
}
]
},
{
"id": "BINARYDATA7",
"type": 129,
"name": "Binary data7",
"shortName": "bin7",
"unit": "?",
"decimalPlaces": 0,
"frcs": [16, 144],
"breakdown": [
{
"id": "BINARYDATA7",
"type": 129,
"name": "Light indicator",
"shortName": "pot",
"unit": "%",
"decimalPlaces": 1
}
]
}
],
"profiles": [
{
"versions": {
"min": 0,
"max": 1
},
"frcAggregation": false,
"beaming": false,
"routing": true,
"repeater": false,
"iqarosCompatible": true,
"iqrfSensor": [0,1,2],
"iqrfBinaryOutput": 2
},
{
"versions": {
"min": 2,
"max": -1 // neomezený interval zhora
},
"frcAggregation": false,
"beaming": false,
"routing": true,
"repeater": false,
"iqarosCompatible": true,
"iqrfSensor": [0,1,2],
"iqrfBinaryOutput": 4
}
]
}v3.0.xKarel HanákKarel Hanákhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/180Uart interface2023-12-08T12:45:20+01:00Rostislav SpinarUart interfacehttps://github.com/iqrfsdk/clibuart/issues/7
Long term testing needed.https://github.com/iqrfsdk/clibuart/issues/7
Long term testing needed.v3.1.xRoman Ondráčekroman.ondracek@iqrf.orgRoman Ondráčekroman.ondracek@iqrf.orghttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/195GPIO pin number handling2023-12-08T12:40:59+01:00Tomáš HoraGPIO pin number handlingTaken from the email conversation from our college Jiri Cech.
It seems that the variable used for storing GPIO pin number overflows.
Conditions:
- i.MX 8M Mini SBC running Debian Buster (kernel 5.4.70)
- I2C expander mapped to position...Taken from the email conversation from our college Jiri Cech.
It seems that the variable used for storing GPIO pin number overflows.
Conditions:
- i.MX 8M Mini SBC running Debian Buster (kernel 5.4.70)
- I2C expander mapped to position 504 (currently using pin numbers 509,510,511)
- driver https://coral.googlesource.com/linux-imx/+/refs/tags/10-1/drivers/gpio/gpio-pi4ioe5v6408.c
The daemon does not interact with the GPIO pins at all. After checking the logs, it seems that the value 509 overflow to -2 (see /sys/class/gpio/gpio-2/direction below).
Also attaching IQRF webapp configuration and list of mapped gpios as screenshots below.
```
● iqrf-gateway-daemon.service - IQRF Gateway Daemon
Loaded: loaded (/lib/systemd/system/iqrf-gateway-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-05-20 07:08:11 UTC; 18min ago
Docs: man:iqrfgd2(1)
https://docs.iqrf.org/iqrf-gateway/
Main PID: 582 (iqrfgd2)
Tasks: 18 (limit: 414)
Memory: 20.2M
CGroup: /system.slice/iqrf-gateway-daemon.service
└─582 /usr/bin/iqrfgd2 /etc/iqrf-gateway-daemon/config.json
May 20 07:08:20 unipi iqrfgd2[582]: clibuart_gpio_setup() setDir failed wait for 100 ms to next try: 9
May 20 07:08:20 unipi iqrfgd2[582]: Error during opening file (set direction): /sys/class/gpio/gpio-2/direction No such file or directory
May 20 07:08:20 unipi iqrfgd2[582]: clibuart_gpio_setup() setDir failed wait for 100 ms to next try: 10
May 20 07:08:20 unipi iqrfgd2[582]: Error during opening file: No such file or directory
May 20 07:08:20 unipi iqrfgd2[582]: Error: Cannot get TR reset msg => interface to DPA coordinator is not working - verify (CDC or SPI or UART) configuration
May 20 07:08:23 unipi iqrfgd2[582]: Error: Cannot get TR parameters msg => interface to DPA coordinator is not working - verify (CDC or SPI or UART) configuration
May 20 07:08:23 unipi iqrfgd2[582]: Loading IqrfRepo cache ...
May 20 07:08:23 unipi iqrfgd2[582]: Loading IqrfRepo cache success
May 20 07:08:23 unipi iqrfgd2[582]: Cannot load required package for: os="0000" dpa="0000"
May 20 07:08:23 unipi iqrfgd2[582]: Loaded package for: os="08B1" dpa="0300"
```
![webapp](/uploads/b2d08f385b0bada1f61f12f84a88b7bb/webapp.png)
![gpio](/uploads/bd4c4f738f44863be5b87a1f1e71b259/gpio.png)v3.1.xRoman Ondráčekroman.ondracek@iqrf.orgRoman Ondráčekroman.ondracek@iqrf.orghttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/204OTA Update: partial execution2023-12-08T12:40:17+01:00Karel HanákOTA Update: partial executionIn it's current state, it is impossible to perform OTA upload without a fully compatible network, meaning that if one device is not compatible with uploaded handler or plugin, the entire process will not start.
There are two solutions i...In it's current state, it is impossible to perform OTA upload without a fully compatible network, meaning that if one device is not compatible with uploaded handler or plugin, the entire process will not start.
There are two solutions in my mind:
1. Extend the functionality and API to allow for OTA update of selected nodes
- This will require significant changes and additional logic: add `selectedNodes`, intersection of bonded (+ online) and selected nodes, remove incompatible nodes (compatibility logic already exists, but currently prevents the process in case of a single incompatible node), perform action and return objects with detailed information about each node (offline, incompatible), that information would then have to be used to specify nodes (online, compatible and successful operation result) to perform the next action in a following request (via `selectedNodes`). This is extremely unreliable, because while Webapp (UI) exists, we cannot prevent every single failure if the JSON API is used. (e.g. OtaUpload load code as the first one).
2. Compound the OTA update steps into a single request that executes all three steps.
- I think this is a better approach, given that Daemon does not retain state of the update process between requests, it only makes sense that we would perform OTA update in one request. The idea is that we still extend the API and add `selectedNodes`, but we only use it for the initial selection of nodes. If no nodes are specified, we start with the entire network as a set and remove nodes in each stage (online nodes => compatible online nodes => verified compatible online nodes => result). In the response, we provide a report for each node and why the process failed for that particular device (it was offline, it is not compatible, verification failed, loading the code failed). If the request is sent with selected nodes, the subset logic will stay the same for the most part, but we also add "selected" qualifier.v3.1.xhttps://gitlab.iqrf.org/open-source/iqrf-gateway-daemon/-/issues/238Scheduler: update task files2023-12-08T12:39:30+01:00Karel HanákScheduler: update task files- [x] remove cron array from API messages
- [x] remove scheduler record methods working with cron array
- [x] remove task object option from API messages
- [x] update existing records to always be array of tasks
- [ ] change timespec to ...- [x] remove cron array from API messages
- [x] remove scheduler record methods working with cron array
- [x] remove task object option from API messages
- [x] update existing records to always be array of tasks
- [ ] change timespec to one property specifying execution time type (oneshot, periodic, cron) and one property for value
- [ ] change messaging to messagings property as arrayv3.1.xKarel HanákKarel Hanák