AMAGE PVD

Zasada działania

PVD może działać jako aplikacja terminalowa, jednak głównym założeniem jest praca ciągła, w charakterze usługi systemowej. Aplikacja ładuje i rejestruje moduły dostawców oraz odbiorców. Kiedy dostawca generuje wiadomość, przekazuje ją do rdzenia aplikacji, a ta rozsyła ją do poszczególnych odbiorców.

Dostawcy i odbiorcy

Dopuszczalne są różne implementacje dostawców i odbiorców. Dostawca odpowiada nie tylko za zebranie danych, ale też za utworzenie zalążka wiadomości w postaci mapowań UUID celu (standardowo ustawienie parametru zasobu w systemie Amage) na zebrane wartości. Informacje o mapowaniach PVD pobiera z serwera Amage Sync z którym jest sparowany. W sytuacjach szczególnych, np. jeśli parowanie nie jest możliwe, dane mapowania można wprowadzić ręcznie, jako plik mapping.json. Forma tego pliku zostanie szczegółowo opisana w dalszej części instrukcji.

Odbiorca odpowiada za obsługę wiadomości. Standardowo dostępnym odbiorcą jest moduł odpowiadający za przekazywanie danych do sparowanego serwera Amage Sync.

Wymagania

Jedynym bezwzględnym wymaganiem PVD jest dostępność środowiska uruchomieniowego Java w wersji 8 lub nowszej oraz ilość pamięci pozwalająca na buforowanie danych w przypadku problemów ze swobodnym przekazywaniem wiadomości odbiorcom - zalecane jest minimum 512 MB RAM.

Instalacja i konfiguracja aplikacji

Instalacja aplikacji polega na rozpakowaniu archiwum pvd-all.zip w wybranej lokalizacji. W następnej kolejności należy skonfigurować aplikację oraz jej moduły, co opisane zostało w tym rozdziale.

Pliki konfiguracyjne znajdują się w katalogu configs i podkatalogach, wszystkie pliki konfiguracyjne są zapisywane w formacie JSON.

Jakakolwiek modyfikacja konfiguracji aplikacji wymaga jej restartu - tylko wtedy wprowadzone zmiany odniosą skutek.

Ustawienie katalogu startowego

Aplikacja w trakcie uruchamiania korzysta ze zmiennej systemowej user.home w celu określenia katalogu startowego zawierającego wszystkie dane konfiguracyjne oraz jako miejsce przechowywania danych dodatkowych (baza danych na dane tymczasowe, logi itp.).

Domyślnie katalog ten jest ustawiany na katalog użytkownika. Aby uruchomić aplikację z innym katalogiem startowym należy uruchomić maszynę JVM z opcją -Duser.home=<katalog>. Pozwoli to wskazać dowolne miejsce przechowywania plików.

Struktura katalogu: * configs - katalog z konfiguracjami aplikacji * consumers - katalog z bibliotekami konsumentów * suppliers - katalog z bibliotekami dostawców * db - katalog lokalnej bazy danych * logs - katalog na logi aplikacji oraz wszystkich dostawców/konsumentów

Wszystkie ścieżki w dokumentacji odnoszą się względem katalogu user.home. Dla ułatwienia w ścieżkach wszystkich danych ten katalog będzie oznaczony jako <user.home>.

Konfiguracja aplikacji

Ścieżka do pliku: <user.home>/configs/core_config.json Plik jest opcjonalny, jeżeli nie istnieje (stan domyślny), aplikacja zostanie uruchomiona z ustawieniami domyślnymi (opisane poniżej).

Przykładowa konfiguracja aplikacji:

{
   "suppliersPath":"file:///path/to/suppliers",
   "consumersPath":"file:///path/to/consumers",
   "port":9900,
   "manualNativeLibs":false,
   "debug":false,
   "noRepeat":false,
   "heartbeatTime":-1,
   "cleanupTime": 3600,
   "validityTime": 43200,
   "updateMappingsTime":-1,
   "suppliersDirs": [ "path1", "path2"],
   "suppliersEnabled": [ "s-example"],
   "consumersDirs": [ "path1", "path2"],
   "consumersEnabled": [ "c-example"]
}

  • suppliersPath - (URL) ścieżka do katalogu z modułami suppliers, domyślnie katalog suppliers

  • consumersPath - (URL) ścieżka do katalogu z modulami consumers, domyślnie katalog consumers

  • port - (int) port do komunikacji międzyprocesowej (RMI), domyślnie 9900. Używana wewnętrznie, do wysyłania żądań do działającej w tle instancji aplikacji (status, zamknięcie, itp.). Nie ma potrzeby zmiany tej wartości, chyba, że jest w konflikcie z inną używającą danego portu usługą lub inną instancją PVD.

  • debug - (boolean) tryb debug aplikacji (szczegółowe komunikaty) domyślnie false. Powoduje logowanie dużej ilości dodatkowych informacji i w związku z tym należy go używać tylko przy weryfikacji instalacji oraz rozwiązywaniu problemów.

  • noRepeat - (boolean) wyłączenie lokalnej bazy danych, domyślnie false. Przy bardzo dużej ilości danych może znacząco poprawić sprawność działania aplikacji, jednak uniemożliwia wznawianie wysyłania wiadomości, które z jakiegoś powodu nie zostały poprawnie obsłużone przez odbiorcę.

  • consumerThreads (int) ilość wątków używanych jednocześnie przez odbiorców, domyślnie 4. Zwiększenie tej wartości może pozwolić na usprawnienie przepływu informacji kosztem zwiększenia zużycia pamięci oraz obciążenia odbiorcy (np. serwera Sync).

  • manualNativeLibs - (boolean) ręczne ustawianie potrzebnych zewnętrznych bibliotek, domyślnie false. Gdy ta opcja jest wyłączona, aplikacja spróbuje samodzielnie załadować natywne biblioteki, co jest zalecanym zachowaniem. Może jednak zaistnieć konieczność ręcznego ładowania takich bibliotek na nietypowych konfiguracjach systemowych.

  • repeatTime - (long) odstęp czasowy wznawiania, liczony w sekundach, domyślnie 1800 (30 minut)

  • validityTime - (long) czas ważności wiadomości, liczony w minutach, domyślnie 43200 (30 dni)

  • cleanupTime - (long) czas sprzątania bazy danych, liczony w sekundach, domyślnie 3600 (1 godzina)

  • repeatLimit - (long) ilość wiadomości do załadowania przy pojedynczej próbie powtórzenia, domyślnie 200

  • heartBeatTime - (long) odstęp czasowy wysyłania na sparowany serwer Sync informacji diagnostycznych (status), liczony w minutach, domyślnie 15 (15 minut). Ustawienie wartości -1 spowoduje wyłączenie wysyłania informacji diagnostycznych.

  • updateMappingsTime - (long) odstęp czasowy odpytywania sparowanego serwera Sync o aktualizacje mapowań, liczony w minutach, domyślnie 15 (15 minut). Ustawienie wartości -1 spowoduje wyłączenie odpytywania serwera o aktualizacje.

  • suppliersDirs - lista ścieżek do lokalizacji bibliotek dostawców. Przydatne, gdy biblioteki znajdują się w rozproszonych katalogach lub w trakcie prac rozwojowych na kodzie źródłowym.

  • suppliersEnabled - lista włączonych modułów dostawców. Pozwala włączyć tylko te moduły, które są oczekiwane. Jeśli parametru nie ma lub jest pusty ładowane są wszystkie moduły dostawców. Wprowadzamy tutaj identyfikatory odpowiednich dostawców.

  • consumersDirs - lista ścieżek do lokalizacji bibliotek konsumentów. Przydatne, gdy biblioteki znajdują się w rozproszonych katalogach lub w trakcie prac rozwojowych na kodzie źródłowym.

  • consumersEnabled - lista włączonych modułów konsumentów. Pozwala włączyć tylko te moduły, które są oczekiwane. Jeśli parametru nie ma lub jest pusty ładowane są wszystkie moduły dostawców. Wprowadzamy tutaj identyfikatory odpowiednich dostawców.

Konfiguracja modułów

Jeśli nie zostało ustawione inaczej, pliki modułów domyślnie zlokalizowane są w katalogach suppliers (dostawcy) oraz consumers (odbiorcy). Każdy z tych modułów to plik z rozszerzeniem .jar. Wyłączenie modułu polega na usunięciu pliku modułu lub - lepiej - zmianie jego rozszerzenia (np. z nazwa_modulu.jar na nazwa_modulu.jar.disabled).

Inną możliwością podania modułów i ich włączenia jest skorzystanie z opcji suppliersDirs oraz suppliersEnabled oraz tak samo dla konsumentów consumersDirs oraz consumersEnabled.

Lokalizacja plików konfiguracyjnych poszczególnych modułów powinna być zgodna z wzorcem: <user.home>/configs/[typ modułu]/[nazwa modułu]/[nazwa instancji modułu].json, gdzie: * typ modułu to suppliers w przypadku dostawcy i consumers w przypadku odbiorcy. * nazwa modułu to wewnętrzna nazwa modułu (różna od nazwy pliku modułu!) * nazwa instancji modułu nazwa instancji modułu może być dowolna - aplikacja przeszukuje katalog z konfiguracją modułu i każdy z plików konfiguracyjnych ładuje jako kolejną instancję, o nazwie identycznej z nazwą pliku (z pominięciem rozszerzenia .json).

Brak plików konfiguracyjnych dla modułów, które powinny zostać załadowane, poskutkuje błędem inicjalizacji aplikacji. Z drugiej strony, jeżeli plik konfiguracyjny istnieje, ale odpowiadający mu moduł jest wyłączony/usunięty, to taki plik zostanie po prostu zignorowany.

Szczegółowy opis konfiguracji poszczególnych modułów znajduje się w dalszej części instrukcji.

Parowanie z serwerem Sync/Web

Parowanie z serwerem Sync/Web jest czynnością opcjonalną, jednak jeżeli nie zostanie wykonane, aplikacja nie będzie wysyłać informacji o statusie oraz samodzielnie pobierać zaktualizowanych mapowań.

Wygenerowany w aplikacji Amage Desktop plik assetsync.conf należy umieścić w katalogu configs i zrestartować aplikację.

Plik mapowania

W przypadku, gdy aplikacja PVD nie jest sparowana, istnieje możliwość ręcznego wprowadzenia pliku mapowania. Plik musi być zlokalizowany w <user.home>/configs/mapping.json i mieć następującą strukturę:

{
   "version": 0,
   "data": {
       "[klucz_1]": "[UUID_1]",
       "[klucz_2]": "[UUID_2]",
       "[klucz_N]": "[UUID_N]"
   }
}

Pole version może zostać pominięte, wówczas automatycznie zostanie ustawiona wartość 0, która jest zalecana przy ręcznym wprowadzaniu mapowania - spowoduje to automatyczną aktualizację mapowania na nową wersję w przypadku sparowania z serwerem Sync w przyszłości.

Brak pola data będzie równoznaczny z brakiem mapowań. Wartością tego pola jest oddzielona przecinkami lista par klucz → UUID.

Plik mapowania służy do powiązania danych powstających w modułach dostawców z odpowiednimi parametrami w systemie AMAGE. Parametry w systemie AMAGE identyfikowane są przez ich wartość UUID. Lista taka pozwala wskazać, gdzie parametr odczytany przez dostawców ma zostać wpisany w systemie AMAGE w liście parametrów.
W zależności od konfiguracji modułów, plik mapowania może być opcjonalny, gdyż konfiguracja danego modułu już będzie określała powiązania parametrów danego modułu (np. rejestru MODBUS) z odpowiednim parametrem w systemie.

Uruchamianie aplikacji z linii poleceń:

Aplikację można uruchomić z linii poleceń:

java -jar pvd-core.jar

Skrót klawiszowy CTRL+C spowoduje przerwanie działania programu. Aplikacja powinna być używana jako usługa systemowa i tak została zaprojektowana, ale powyższy sposób pozwala na szybką weryfikację poprawności konfiguracji i sprawdzenie jej działania.

Aby zmienić katalog startowy można użyć składni:

java -Duser.home=<katalog> -jar pvd-core.jar

W katalogu głównym aplikacji znajduje się prosty skrypt startowy dla środowiska GNU/Linux.

Instalacja usług systemowych

Poniższa sekcja opisuje kroki wymagane do uruchomienia PVD jako usługi systemowej, osobno dla systemów Windows i Linux.

Windows

Należy przejść do katalogu win_service za wykorzystaniem konsoli/linii komend.

Uwaga: pod niektórymi systemami 64-bitowymi użycie dołączonego pliku prunsrv.exe może okazać się niemożliwe. W takim wypadku należy zastąpić go plikiem dostępnym w win_service/amd64/prunsrv.exe.

Następnie należy zmodyfikować plik service.bat ustawiając wszystkie parametry, które znajdują się w pierwszej części konfiguracji. Pozwala to na zmianę nazwy usługi, ścieżki JVM itp.

  • SERVICE_NAME - nazwa usługi. Nie mogą istnieć w systemie Windows dwie usługi o tej samej nazwie.

  • SERVICE_CODE - kod usługi stosowany do systemów logowania. Identyfikator logowania w systemie windows.

  • DESCRIPTION - opis usługi

  • CONFIG_HOME - lokalizacja katalogu z konfiguracją/logami itp. Pozwala to na umieszczenie katalogu konfiguracji poza katalogiem instalacji aplikacji, co w dalszym etapie umożliwi aktualizację aplikacji do nowszej wersji bez konieczności przechowywania katalogu konfiguracji w tym samym miejscu.

  • LOG_LEVEL - domyślny poziom logowania szczegółów. Opcje: Error, Info, Warn, Debug

  • JAVA_HOME powinien wskazywać na katalog gdzie zainstalowano środowisko Java.

Instalacja usługi

Po modyfikacji pliku service.bat należy uruchomić go z argumentem install:

service install
Uwaga: konsola (program cmd) musi zostać uruchomiona z uprawnieniami administratora, w przeciwnym wypadku usługa nie zostanie zainstalowana poprawnie.

Powinien pokazać się komunikat o pomyślnym zainstalowaniu usługi, od tego momentu usługa o nazwie PVD Application (lub taka jaka została mu nadana) powinna być widoczna na liście usług systemu Windows i gotowa do pracy w trybie automatycznego uruchomienia.

Pierwsze uruchomienie usługi należy zainicjować ręcznie. Uwaga: centrum usług należy uruchomić z uprawnieniami administratora.

Automatyczne wznawianie

W celu zabezpieczenia się przed niespodziewanym wyłączeniem aplikacji należy przejść do usług (services) Windows i znaleźć usługę o wybranej nazwie w konfiguracji (domyślnie PVD Application). Następnie wybieramy ustawienia oraz w zakładce odzyskiwanie (recovery) ustawiamy, by za każdym niepowodzeniem usługa się resetowała (preferowane po 0 min). Dzięki czemu aplikacja automatycznie uruchomi się natychmiast po wystąpieniu problemu.

Deinstalacja usługi

Usuwanie usługi aplikacji PVD jest analogiczne do jej instalacji.

Przed usunięciem usługi należy ją znaleźć w widoku usług systemowych (domyślna nazwa PVD Application). Należy ją zatrzymać (w panelu zarządzania usługami systemu Windows. Kolejnym i ostatnim krokiem jest wykonanie poniższego polecenia w konsoli z uprawnieniami administratora:

service remove

Powinien pokazać się komunikat o pomyślnym usunięciu usługi, od tego momentu usługa nie będzie widoczna na liście i nie będzie uruchamiana podczas startu systemu.

Usunięcie należy wykonywać z uprawnieniami administratora. Konsola tekstowe musi być uruchomiona z takimi uprawnieniami.

Linux

Aby zainstalować usługi, należy wykonać dwa skrypty z folderu linux_service, dzięki którym aplikacja będzie startowała przy uruchomieniu systemu.

Przed instalacją należy uzupełnić skrypt startowy pvdapp:

APP_ROOT="/opt/pvd"
JVM_EXE="java"
BIN="pvd-core.jar"
JMX_PORT="9010"
JMX_IP="10.0.0.70"

Należy ustawić: * APP_ROOT - ścieżka do katalogu z aplikacją * JVM_EXE - ścieżka do pliku wykonywalnego Java * BIN - nazwa głównego pliku jar z aplikacją * JMX_PORT - port, na którym będzie można się połączyć z JMX w celach diagnostycznych. * JMX_IP - adres IP na którym działa usługa JMX

installmxserver - instalowanie serwera moxy jako usługi installpvdapp - instalowanie aplikacji jako usługi

sudo ./installmxserver
sudo ./installpvdapp

Używając skryptu o nazwie "pvdapp" można uruchomić program w trybie: * start - domyślny tryb działania * stop - zatrzymanie pracy aplikacji * restart - restart aplikacji * status - pokazuje aktualny stan modułów

Automatyczne wznawianie

W celu zabezpieczenia się przed niespodziewanym wyłączeniem aplikacji należy uruchomić z terminala crontab -e, a następnie dopisać na końcu pliku:

*/5 * * * * /sciezka/do/pvdapp start

Gdzie zamiast 5 można podać inna wartość. Jest to odstęp czasowy (w minutach), pomiędzy próbą ponownego uruchomienia aplikacji.

W razie problemów można zmienić domyślny edytor tekstowy np. nano używając polecenia:

export EDITOR=/usr/bin/nano

Dostępne moduły i ich konfiguracja

Ta część instrukcji opisuje dostępne moduły z rozróżnieniem który jest dostawcą, a który odbiorcą.

Dostawca: pvd-supplier-IEC-62056-21

Nazwa modułu: s-IEC-62056-21

Moduł ten pozwala na odczyt pomiarów z liczników energii elektrycznej zgodnych ze standardem IEC-62056-21. Moduł ten odczytuje dane z portów szeregowych, w co najwyżej jednym wątku na port.

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/suppliers/s-IEC-62056-21/default.json (zamiast default dopuszczalna jest inna, własna nazwa).

{
"sleepTime": 30,
"verboseMode": false,
"threadPoolSize":2,
   "sleepBetweenQuerying": 0,
   "disableDelayForUnavailableDevices": false,
"meterGroupConfigs" : [
	{
		"portName":"/dev/ttyr00",
           "sleepBetweenQuerying": 30,
           "sleepTime": 15,
           "active":true,
           "globalMultipliers":[
	    {
		    "name":"standard",
		    "configs" : {
                   "1.6.0":"{value}*{multiplier}",
                   "1.8.0":"{value}*{multiplier}"
		    }
        },
	    {
		    "name":"pozyton",
		    "configs" : {
                   "107":"{value}*{multiplier}",
                   "109":"{value}*{multiplier}"
		    }
	    }
           ],
		"configs": [
			{
				"deviceAddress":"51034542",
				"initialBaudRate": 2400,
				"timeout": 10000,
                   "active":false,
                   "multiplier":"sqrt(4)/(3^2+2)",
                   "multiplierTemplateName":"standard",
                   "multipliersMap": {
                       "1.6.1":"{value}*12",
                       "1.8.1":"{value}*{multiplier}"
		        }
			},
			{
				"deviceAddress":"023-0000691",
				"initialBaudRate": 9600,
				"timeout": 10000,
                   "meterType": "POZYTON"
			}
		]
	},
       {
		"portName":"/dev/ttyr02",
		"configs": [
			{
				"deviceAddress":"51204143",
				"initialBaudRate": 2400,
				"timeout": 10000
			},
			{
				"deviceAddress":"51255055",
				"initialBaudRate": 2400,
				"timeout": 10000
			}
		]
	}
]
}

  • sleepTime - (int) odstęp czasowy w sekundach pomiędzy ściąganiem danych z licznika, domyślnie 60s, można go skonfigurować globalnie oraz następnie nadpisywać dla danej konfiguracji portu

  • verboseMode - (boolean) tryb pracy licznika dający więcej informacji, domyślnie false

  • threadPoolSize - (int) maksymalny rozmiar puli wątków wykorzystywany do odczytywania danych z liczników. Jeżeli jest większy od ilości portów, zostaje obcięty do tej ilości.

  • disableDelayForUnavailableDevices - (boolean) wyłącza automatyczne opóźnienie dla urządzeń, które nie są dostępne (np. brak odpowiedzi). Ułatwia diagnostykę i podłączenie takich urządzeń, gdyż system nie będzie opóźniał kolejnych odczytów w przypadku, gdy urządzenie nie odpowiada. Domyślne opóźnienie to 10 odczytów.

  • globalMultipliers - (lista) zawierająca unikatową nazwę (name) jak i mapę z adresem odczytanej wartości na sposób w jaki ma być przeliczana dana wartość. Musi zawierać {value} → czyli odczytaną wartość oraz opcjonalnie {multiplier} czyli wyrażenie z danego licznika.

  • portName - (String) nazwa portu, na którym znajduję się dany licznik (dla linuxa są to porty tty, dla windows COM, a dla moxy ttyr).

  • deviceAddress - (String) numer seryjny urządzenia, adres unikalny dla danego urządzenia dzięki, któremu możemy go identyfikować.

  • initialBaudRate - (int) wartość specyficzna dla danego typu licznika, jest to częstotliwość pracy charakterystyczna również dla danego portu.

  • sleepBetweenQuerying - (int) odstęp czasowy w sekundach pomiędzy odpytywaniem poszczególnych liczników na danym porcie

  • meterType - (String) modbustyp licznika, jeżeli jest on zgodny ze standardem, pole może być pominięte. Dostępne wartości: STANDARD (domyślna), POZYTON

  • active - (boolean) czy port jest aktywny, domyślnie true, opcjonalnie można wyłączyć, dodatkowo gdy port jest aktywny można wyłączyć poszczególny licznik.

  • multiplier - (String), mnożnik danego licznika. Może to być pojedyncza wartość jak i wyrażenie.

  • multiplierTemplateName - (String) nazwa z wykorzystywanego wzorca, musi to być nazwa występująca w globalMultipliers w polu name * multipliersMap - (Map) unikalna mapa dla danego licznika z przelicznikami wartości. Musi występować {value} w przeciwnym wypadku zwracana jest wartość domyślna odczytana z licznika. Jeżeli taki sam parametr występuje w globalMultipliers zostaję on nadpisany tym przelicznikiem.

W przypadku, gdy urządzenie nie odpowiada (brak komunikacji) i taki efekt występuje przez 3 kolejne próby odczytu, to system automatycznie przestaje próbować komunikować się z urządzeniem przez 10 kolejnych odczytów. Pozwala to na ograniczenie blokowania komunikacji z innymi urządzeniami na tej samej magistrali. Po poprawnym odczycie, system automatycznie przywraca odczyt z ustaloną, maksymalną częstotliwością. Wyłączyć to zachowanie (np. do celów diagnostycznych) możemy za pomocą globalnej opcji disableDelayForUnavailableDevices

Mapowania

Klucz mapowany na UUID jest zbudowany z numeru seryjnego urządzenia, znaku # oraz ustandaryzowanego kodu odczytywanej wartości, np. 38547626#1.8.0 (nr seryjny 38547626, kod wartości 1.8.0) lub 023-0000691#102.1 (nr seryjny 023-0000691, kod wartości 102.1).

Dostawca: pvd-supplier-modbus

Nazwa modułu: s-modbus

Moduł ten pozwala na odczyt wartości po protokole modbus TCP (np. z falownika).

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/suppliers/s-modbus/default.json (zamiast default dopuszczalna jest inna, własna nazwa, np. opisująca to konkretne źródło danych).

Wersja 1 konfiguracji

Wersja 1 konfiguracji opisuje komunikację za pomocą podstawowych typów danych. Zachowana dla kompatybilności z istniejącymi konfiguracjami. Rozpoznawana przez trzy parametry w definicj rejestru np. "0:float:100".

{
     "debug": false,
     "devices":[
           {
               "ip":"192.168.1.104",
               "port":502,
               "sleepTime":10,
               "description":"Falownik Testowy",
			"enabled":"true",
               "useLoHiWordOrder": "false",
               "data": {
                   "0:float:100":"fd005850-86c9-498e-8ab2-d3d7a739daa6",
                   "1:int:0":"2a9ed604-bac9-44b9-84b0-01f91f3b4ee4",
                   "2:float:100":"b063bc0a-06ec-40c8-a5fa-721275443388",
                   "3:float:10":"6028f30e-205a-4fa6-8e9a-0fc4ed11d979",
                   "4:float:10":"46f2b46c-da21-425a-a118-95a8c09b4422",
                   "5:float:10":"38ce3bb2-33b9-49ad-8d85-12eec0020653",
                   "6:int:0":"a2f75e59-96df-4b83-81fe-8e6e96e24330",
                   "7:float:10":"41be100f-ba9a-41a2-bd51-801fc922157f"
               }
           },
        {
            "ip":"192.168.1.105",
            "port":502,
            "sleepTime":10,
            "description":"Falownik Testowy 2",
"enabled":"false",
            "data": {
                "0:float:100":"fd005850-86c9-498e-8ab2-d3d7a739daa6",
                "1:int:0":"2a9ed604-bac9-44b9-84b0-01f91f3b4ee4",
                "2:float:100":"b063bc0a-06ec-40c8-a5fa-721275443388",
                "3:float:10":"6028f30e-205a-4fa6-8e9a-0fc4ed11d979",
                "4:float:10":"46f2b46c-da21-425a-a118-95a8c09b4422",
                "5:float:10":"38ce3bb2-33b9-49ad-8d85-12eec0020653",
                "6:int:0":"a2f75e59-96df-4b83-81fe-8e6e96e24330",
                "7:float:10":"41be100f-ba9a-41a2-bd51-801fc922157f"
            }
        }
        ]
}

Wersja 2 konfiguracji

Wersja 2 konfiguracji opisuje komunikację za pomocą wszystkich znanych typów danych MODBUS. Stara się obsłużyć wszystkie typy danych.

{
     "debug": false,
     "devices":[
           {
               "ip":"192.168.1.104",
               "port":502,
               "unitId":1,
               "addressShift":-1,
               "sleepTime":10,
               "useLoHiWordOrder": "false",
               "description":"Falownik Testowy",
			"enabled":"true",
               "data": {
                   "40072:uint32:Power Active:2": "b2ddc792-cf40-42b7-b9ce-82eb68928ac3",
                   "40005:string32:Manufacturer:0": "c2ddc792-cf40-42b7-b9ce-82eb68928ac3",
               }
           }
       ]
}

Dane definicyjne:

  • debug - (boolean) flaga włączona pozwala na logowanie w logach/konsoli informacji z biblioteki komunikacyjnej oraz wyświetlania danych wysyłanych i odbieranych w formacie HEX

Dane ogólne zawierają informacje o poszczególnych urządzeniach.

  • ip - (String) adres ip urządzenia.

  • port - (int) port po którym będziemy się łączyć (standardowo 502).

  • unitId - (int) numer jednostki modbus (zwykle 1)

  • addressShift - (int) przesunięcie adresów np. -1. Nakładane zawsze w przypadku odczytu. Pozwala na definicję w mapowaniu rzeczywistych adresów z dokumentacji a jednocześnie odpowiednim przesunięciu zgodnie z protokołem danego urządzenia. <Opcja>

  • addressBase - (int) bazowa wartość adresu. Dodawana zawsze do adresu. <Opcja>

  • description - (String) opis urządzenia.

  • useLoHiWordOrder - Przy odczycie DWORD (dwóch rejestrów) domyślnie stosujemy ułożenie rejestrów HiLo czyli najpierw najwyższy bajt a potem w dół do najniższego. Przy włączeniu tej opcji stosujemy odwrotne ułożenie ALE tylko w przypadku rejestrów. Czyli Jeśli odczytamy bajty z DWÓCH rejestrów [A] [B] [C] [D] to ułożenie HiLo będzie MSB [A] [B] [C] [D] LSB, natomiast w przypadku ułożenia LoHi będzie to MSB [C] [D] [A] [B] LSB.

  • sleepTime - (int) odstęp czasowy w sekundach do odczytu protokołu.

  • enabled - (boolean) flaga czy chcemy odczytywać dane urządzenie.

  • data - (Map<String, UUID>) Mapa rejestrów które będziemy odczytywać, oraz UUID pod jakie mają być wrzucane.

Format mapy rejestrów, zawiera parę konfiguracji rejestru i UUID ustawień parametru.

Wersja 1 konfiguracji

Konfiguracja rejestru składa się z trzech pól:

  • numer rejestru (np. 2003)

  • typu danych - int lub float

  • dzielnik - określa przez jaką liczbę będzie dzielony odczyt np. dla odczytu rejestru 1000 z wartością 1234 o typie float i dzielniku 100 otrzymujemy wynik 12,34

Wersja 2 konfiguracji

Konfiguracja rejestru składa się z 4 pól:

  • numer rejestru (np. 2003)

  • typ danych - uint16, uint32, uint64, int16, bitfield16, enum16, acc32, float32, string32, string16

  • opis - opis dla użytkownika (pojawia się w logach)

  • dzielnik - określa przez jaką liczbę będzie dzielony odczyt np. dla odczytu rejestru 1000 z wartością 1234 o typie float i dzielniku 100 otrzymujemy wynik 12,34. Zawsze stosujemy 2 znaki po przecinku

Dostawca: pvd-supplier-modbus-rtu

Nazwa modułu: s-modbus-rtu

Moduł ten pozwala na odczyt wartości z urządzeń po protokole modbus RTU czyli protokół MODBUS po magistralach szeregowych typu RS-232/RS-485. W dokumentacji pomijamy mechanizm fizycznego podłączenia urządzenia/konwertera RS do danego systemu, na którym jest zainstalowana aplikacja PVD.

Do podłączeń można wykorzystać również urządzenia pośredniczące typu Moxa N-Port (lub podobny). W tym przypadku zwykle istnieje dodatkowe oprogramowanie narzędziowe danego producenta, które umożliwia udostępnienie portów szeregowych danego urządzenia jako wirtualne porty szeregowe czy to w środowisku Windows czy Linux. Należy odnieść się do dokumentacji producenta aby podłączyć/zamapować odpowiednie porty.

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/suppliers/s-modbus-rtu/default.json (zamiast default dopuszczalna jest inna, własna nazwa, np. opisująca to konkretne źródło danych). Może istnieć dowolna liczba takich konfiguracji np. z podziałem na poszczególne porty szeregowe.

Konfiguracja

Konfiguracja podzielona jest na drzewo danych. Urządzenia fizyczne (jednostki komunikacyjne) grupowane są w porty komunikacyjne (szeregowe) o takich samych parametrach komunikacyjnych. Czyli mamy hierarchię konfiguracja ogólna → porty → urządzenia.

Przykładowy plik konfiguracji znajduje się poniżej. Zawiera on definicję jednego portu szeregowego oraz jednego urządzenia podpiętego do tego portu.

{
   "sleepTime": 30,
   "debug": false,
   "threadPoolSize": 1,
   "sleepBetweenQuerying": 2,
   "disableDelayForUnavailableDevices": false,
   "ports": [
       {
           "sleepTime": 3,
           "sleepBetweenQuerying": 1,
           "active": true,
           "port": "/dev/ttyUSB0",
           "baudRate": 9600,
           "dataBits": 8,
           "stopBits": 1,
           "parity": "None",
           "devices": [
               {
                   "name": "Test modbus RTU device",
                   "description": "additional description for the device",
                   "active": true,
                   "unitId": 1,
                   "addressShift": 0,
                   "addressBase": 0,
                   "useLoHiWordOrder": true,
                   "sleepTime": 5,
                   "data": {
                       "0:float32:Current Voltage - clamp A:0": "97c95bd0-abe4-4770-bdef-23b6f075cd0f",
                       "2:float32:Current Voltage - clamp B:100": "97d95bd0-abe4-4770-bdef-23b6f075cd0f"
                   }
               }
           ]
       }
   ]
}
Przyjęto że jeden port szeregowy posiada swoje definicje tj. prędkość bitową, parametry komunikacji jednolite dla wszystkich urządzeń podpiętych pod ten port. Wynika to z właściwości łącza danych. Różne prędkości/parametry mogą spowodować błędne działanie urządzeń spiętych w tej samej magistrali.

Dane definicyjne ogólne:

  • sleepTime - (int) odstęp czasowy w sekundach pomiędzy ściąganiem danych z urządzenia, domyślnie 60s, można go skonfigurować globalnie oraz następnie nadpisywać dla danej konfiguracji portu

  • debug - (boolean) flaga włączona pozwala na logowanie w logach/konsoli informacji z biblioteki komunikacyjnej oraz wyświetlania danych wysyłanych i odbieranych w formacie HEX

  • threadPoolSize - (int) maksymalny rozmiar puli wątków wykorzystywany do odczytywania danych z urządzeń. Jeżeli jest większy od ilości portów, zostaje obcięty do tej ilości.

  • sleepBetweenQuerying - (int) odstęp czasowy w sekundach pomiędzy odpytywaniem poszczególnych urządzeń na danym porcie. Można nadpisywać go w poszczególnych portach.

  • disableDelayForUnavailableDevices - (boolean) wyłącza automatyczne opóźnienie dla urządzeń, które nie są dostępne (np. brak odpowiedzi). Ułatwia diagnostykę i podłączenie takich urządzeń, gdyż system nie będzie opóźniał kolejnych odczytów w przypadku, gdy urządzenie nie odpowiada. Domyślne opóźnienie to 10 odczytów.

Dane portu szeregowego:

  • sleepTime - (int) odstęp czasowy w sekundach pomiędzy ściąganiem danych z urządzenia,

  • sleepBetweenQuerying - (int) odstęp czasowy w sekundach pomiędzy odpytywaniem poszczególnych urządzeń na danym porcie

  • active - czy port jest aktywny i odczytujemy z niego dane

  • port - nazwa portu np. COM1, /dev/ttyUSB0 itp.

  • baudRate - prędkość bitowa np. 9600

  • dataBits - liczba bitów danych - 7/8

  • stopBits - liczba bitów stopu - 0/1

  • parity - parzystość komunikacji - wartości: Even, Mark, None, Odd, Space

Dane poszczególnego urządzenia:

  • name - (String) nazwa urządzenia (pojawia się w logach)

  • description - (String) opis urządzenia - opisowo pole dla konfiguracji

  • active - (boolean) flaga czy chcemy odczytywać dane urządzenie.

  • unitId - (int) numer jednostki modbus (zwykle 1)

  • addressShift - (int) przesunięcie adresów np. -1. Nakładane zawsze w przypadku odczytu. Pozwala na definicję w mapowaniu rzeczywistych adresów z dokumentacji a jednocześnie odpowiednim przesunięciu zgodnie z protokołem danego urządzenia. <Opcja>

  • addressBase - (int) bazowa wartość adresu. Dodawana zawsze do adresu. <Opcja>

  • useLoHiWordOrder - Przy odczycie DWORD (dwóch rejestrów) domyślnie stosujemy ułożenie rejestrów HiLo czyli najpierw najwyższy bajt a potem w dół do najniższego. Przy włączeniu tej opcji stosujemy odwrotne ułożenie ALE tylko w przypadku rejestrów. Czyli Jeśli odczytamy bajty z DWÓCH rejestrów [A] [B] [C] [D] to ułożenie HiLo będzie MSB [A] [B] [C] [D] LSB, natomiast w przypadku ułożenia LoHi będzie to MSB [C] [D] [A] [B] LSB.

  • sleepTime - (int) odstęp czasowy w sekundach do odczytu protokołu.

  • data - (Map<String, UUID>) Mapa rejestrów które będziemy odczytywać, oraz UUID pod jakie mają być wrzucane.

Format mapy rejestrów, zawiera parę konfiguracji rejestru i UUID ustawień parametru są zgodne z wersją 2 konfiguracji Modbus TCP tj.

Wersja (2) konfiguracji

Konfiguracja rejestru składa się z 4 pól:

  • numer rejestru (np. 2003)

  • typ danych - uint16, uint32, uint64, int16, bitfield16, enum16, acc32, float32, string32, string16

  • opis - opis dla użytkownika (pojawia się w logach)

  • dzielnik - określa przez jaką liczbę będzie dzielony odczyt np. dla odczytu rejestru 1000 z wartością 1234 o typie float i dzielniku 100 otrzymujemy wynik 12,34. Zawsze stosujemy 2 znaki po przecinku

W przypadku, gdy urządzenie nie odpowiada (brak komunikacji) i taki efekt występuje przez 3 kolejne próby odczytu, to system automatycznie przestaje próbować komunikować się z urządzeniem przez 10 kolejnych odczytów. Pozwala to na ograniczenie blokowania komunikacji z innymi urządzeniami na tej samej magistrali. Po poprawnym odczycie, system automatycznie przywraca odczyt z ustaloną, maksymalną częstotliwością. Wyłączyć to zachowanie (np. do celów diagnostycznych) możemy za pomocą globalnej opcji disableDelayForUnavailableDevices

Dostawca: pvd-file-content-reader

Nazwa modułu: s-file-content

Moduł ten pozwala na okresowy odczyt wartości z pliku. Pozwala np. na odczyt danych przechowywanych w systemie /proc lub w innych plikach np. wartości parametrów czujników 1-Wire wykorzystujących widok na system plików.

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/suppliers/s-file-content/default.json (zamiast default dopuszczalna jest inna, własna nazwa, np. opisująca to konkretne źródło danych).

{
 "pathFile":"/path/to/file",
 "sleepTime":10,
 "uuid":"f01ec5fd-117c-4cbf-aed8-1ab6066bd4c7",
 "charsetName":"UTF-8"
}

  • pathFile - (path) ścieżka do pliku, z którego chcemy czytać dane.

  • sleepTime - (int) odstęp czasowy w sekundach do odczytu z pliku.

  • uuid - (uuid) unikalny numer uuid parametru dla tego pliku (taki sam jak w aplikacji).

  • charsetName - (String) opcjonalny wybór kodowania, domyślnie UTF-8

Odbiorca: pvd-consumer-params-rest

Nazwa modułu: c-params-rest

Moduł ten pozwala na przekazywanie wiadomości do wybranego serwera Sync.

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/consumers/c-params-rest/default.json. (zamiast default dopuszczalna jest inna, własna nazwa, np. opisująca odbiorcę).

{
   "connectionTimeout": 5,
   "skipTime": 180,
   "restConfig": {
       "apiKey": "666f6f",
       "apiSecret": "626172",
       "protocol": "http",
       "host": "localhost",
       "context": "",
       "port": 5000,
       "deviceUUID": "26f4c3a7-3820-4d0f-844e-134da324a40b"
   }
}

  • connectionTimeout - (int) czas (w sekundach), po którym połączenie zostanie uznane za nieudane, domyślnie 5. Zapobiega blokowaniu się wyjścia.

  • skipTime - (int) czas (w sekundach), który musi minąć po nieudanym połączeniu, zanim zostanie podjęta ponowna próba, domyślnie 180. Zapobiega blokowaniu się wyjścia.

Wartość pola restConfig wskazuje na konfigurację połączenia z serwerem Sync. Jeżeli jest to ten sam serwer, z którym aplikacja została sparowana, wystarczy wstawić tutaj konfigurację z pliku assetsync.conf.

  • apiKey - (String) apiKey urządzenia

  • apiSecret - (String) apiSecret urządzenia

  • protocol - (String) rodzaj używanego protokołu do wysyłania danych

  • host - (String) adres serwera Synca

  • context - (String) kontekst serwera assetsync

  • port - (int) numer używanego portu do komunikacji z assetsync

  • deviceUUID - (uuid) unikalny uuid urządzenia

Dostawca: pvd-supplier-test

Nazwa modułu: s-example

Generuje przypadkowe dane w odstępach czasu.

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/suppliers/s-example/default.json. (zamiast default dopuszczalna jest inna, własna nazwa).

Wszystkie pola są opcjonalne.

{
   "threadPoolSize": 1,
   "generatorsQuantity": 1,
   "sleepTime": 1000,
   "payloadSize": 1,
   "parameterUUID": "ef466d4f-ec72-44c5-939c-287e7646b125"
}

  • threadPoolSize - (int) ilość wątków użytych do generowania wartości, domyślnie 1.

  • generatorsQuantity - (int) ilość generatorów.

  • sleepTime - (int) czas (w milisekundach) co ile odpytywać generator o wartość.

  • payloadSize - (int) ilość wygenerowanych wartości.

  • parameterUUID - (UUID) parametr, którego dotyczy generowana wartość

Odbiorca: pvd-consumer-test

Nazwa modułu: c-example

Loguje wszystkie odebrane wiadomości, nie przekazuje ich dalej.

Przykładowa ścieżka do pliku konfiguracyjnego: <user.home>/configs/consumers/c-example/default.json. (zamiast default dopuszczalna jest inna, własna nazwa).

Ten moduł nie pozwala na konfigurację, plik konfiguracyjny wygląda zawsze tak samo:

{}

Dostawca: pvd-supplier-DLMS

Nazwa modułu: s-DLMS

Dostawca DLMS pozwala na komunikację z urządzeniami z wykorzystaniem protokołu DLMS. Konfiguracja dostawcy polega na określeniu parametrów dostępowych dla urządzeń oraz listy kodów OBIS, które będą odczytywane z tych urządzeń.

{
"sleepTime": 30,
"threadPoolSize":2,
   "obisCodes": ["1.1.2.6.0.255"],
"meterGroupConfigs" : [
	{
		"portName":"/dev/ttyUSB0",
		"configs" : [
			{
				"deviceAddress":"9569",
				"initialBaudRate": 9600,
				"timeout": 10000,
				"logicalId":1,
                   "clientId":16
			}
		]
	}
   ]
}

  • threadPoolSize - (int) ilość wątków użytych do generowania wartości, domyślnie 1.

  • obisCodes - (list) lista kodów OBIS, które będą odczytywane z urządzeń

  • meterGroupConfig - (struct) struktura konfiguracji liczników

  • deviceAddress - (strign) numer seryjny urządzenia

  • logicalId - (int) logiczne ID urządzenia w ramach komunikacji

  • clientId (int) identyfikator klienta dostępowego

Mapowanie na parametry realizowane za pomocą konfiguracji mapowania sync.

Dostawca: pvd-supplier-sql

Nazwa modułu: s-sql

Mechanizm pobierania danych z zewnętrznego źródła w postaci tabeli z pomiarami. Definicja dostawcy realizowana za pomocą przykładowej konfiguracji z dostępem do serwera MS SQL:

{
   "dbDriver":"com.microsoft.sqlserver.jdbc.SQLServerDriver",
   "dbUrl":"jdbc:sqlserver://100.100.100.100\\INSTANCE:1433;databaseName=database;",
   "dbUser":"amage",
   "dbPassword":"amage",
   "tableName":"POMIARY",
   "timeBetweenDispatch": 120,
}

  • dbDriver - klasa sterownika JDBC do dostępu. Dostępne MS SQL server oraz PostgreSQL.

  • dbUrl - URL w formacie JDBC dostępu do bazy danych

  • dbUser - użytkownik do autoryzacji dostępu

  • dbPassword - hasło użytkownika do autoryzacji dostępu

  • tableName - nazwa tabeli źródłowej, z której pobieramy dane

  • timeBetweenDispatch - czas pomiędzy skanowaniami tabeli źródłowej w sekundach.

Kolumny w tabeli źródłowej muszą posiadać następującą strukturę:

  • DateTime - date - data odczytu

  • TagName - string - nazwa parametru

  • Value - string - wartość parametru

Po odczycie następuje skasowanie całej zawartości tabeli pomiarów (w danej sesji).

Mapowanie na parametry realizowane za pomocą konfiguracji mapowania sync.

Odbiorca: pvd-consumer-params-sql

Nazwa modułu: c-params-sql

Odbiera danych parametrów z systemu Sync oraz przekazuje je do tabel zewnętrznych o ustalonej strukturze.

Kolumny w tabeli źródłowej muszą posiadać następującą strukturę:

  • [1] - date - data odczytu

  • [2] - string - nazwa parametru

  • [3] - string - wartość parametru

Przykładowy plik konfiguracji:

{
   "dbDriver":"com.microsoft.sqlserver.jdbc.SQLServerDriver",
   "dbUrl":"jdbc:sqlserver://100.100.100.100\\INSTANCE:1433;databaseName=database;",
   "dbUser":"amage",
   "dbPassword":"amage",
"targetParams": [
    {
        "valueName":"00MKA10CE901",
        "uuid":"37073696-74cf-4a40-847f-bae4a2debedc",
        "multiplier":1
    },
    {
        "valueName":"00AEA00CE902",
        "uuid":"65a56440-018b-4ddd-b1f9-ae6cce642e31",
        "multiplier":1
    },
    {
        "valueName":"00AEA00CE901",
        "uuid":"ee6e896d-a0ab-4932-8635-5f25e6e9ef63",
        "multiplier":1
    }
],
   "table" : [
       {
           "tableName":"dbo.Liczniki_E_01M",
           "time":60
       },
       {
           "tableName":"dbo.Liczniki_E_15M",
           "time":900
       }
   ]
}

  • dbDriver - klasa sterownika JDBC do dostępu. Dostępne MS SQL server oraz PostgreSQL.

  • dbUrl - URL w formacie JDBC dostępu do bazy danych

  • dbUser - użytkownik do autoryzacji dostępu

  • dbPassword - hasło użytkownika do autoryzacji dostępu

  • targetParams - docelowe parametry do eksportu

  • table - tabele, do których będą eksportowane dane

  • valueName - nazwa docelowego paramtru do wpisania do tabeli docelowej

  • uuid - UUID ustawień parametru w systemie AMAGE do eksportu do zewnętrznego systemu

  • multiplier - mnożnik do wykonania w przypadku danych liczbowych

  • tableName - nazwa tabeli do eksportu

  • time - okres wysyłania danych

Takie podejście pozwala na eksport danych w różnych okresach czasu do różnych tabel.

Odbiorca: pvd-failure

Nazwa modułu: c-failure

Testowy odbiorca danych, który na odebranie jakiejkolwiek wiadomości generuje odpowiedź DispatchResult.FAILURE.

Dostawca: pvd-supplier-huawei-pv-rest

Nazwa modułu: s-huawei-pv-rest

Mechanizm pobierania danych dotyczących przemienników częstotliwości wykorzystywanych w systemach fotowoltaicznych. Komunikacja następuje poprzez interfejs HTTP REST do zewnętrznego serwera firmy Huawei (w momencie pisania dokumentacji serwery w domenie fusionsolar.huawei.com). Oznacza to, że aplikacja musi mieć dostęp do w/w adresu i adresów potomnych w tej domenie aby umożliwić dostęp do tych danych.

{
   "devices": [
       {
           "description": "Huawei PV - SUN2000-15KTL-M0 - SN: 123",
           "userName": "user",
           "systemCode": "systemcode",
           "stationCode": "xxx",
           "deviceId": 0,
           "deviceTypeId": 0,
           "sleepTime": 10,
            "data": {
                "grid_frequency:Grid frequency:0": "d119b575-0604-4404-b954-017a828fe98d"
            },
           "enabled": true
       }
   ]
}

  • description - Opis urządzenia

  • userName - użytkownik do logowania do systemu REST

  • systemCode - kod systemowy do logowania do systemu REST

  • stationCode - identyfikator stacji

  • deviceId - numer urządzenia

  • deviceTypeId - typ urządzenia

  • sleepTime - czas przerw pomiędzy odczytamy (sekundy)

  • enabled - włączenie/wyłączenie konfiguracji

  • data - dane mapowania parametrów na UUID ustawień parametrów

Szkielet konfiguracji można wygenerować bezpośrednio w aplikacji AMAGE dla danego urządzenia. W menu kontekstowym zasobu znajdują się akcje generacji pliku szkieletowego.

Po utworzeniu w/w pliku szkieletowego można przystąpić do konfiguracji dalszej. Najważniejsze to posiadać dane userName/systemCode otrzymane od wdrożeniowców systemu Huawei (lub bezpośrednio z Huawei Solar). Dane te wpisujemy do konfiguracji.

Jeśli nie znamy identyfikatora stacji, ID urządzenia lub jego typu, to pozostawiając domyślne wartości "xxx" lub 0 system w trakcie uruchomienia wyświetli wszystkie dostępne dane, z których będzie można skopiować te informacje. Informacje te można skopiować również z interfejsu WWW dostępu do danych przez Huawei.

Po wypełnieniu wszystkich danych należy odpowiednio skonfigurować mapowania ustawień parametrów. Składa się on z trzech segmentów:

<nr funkcji>:<nazwa>:<skalowanie>

gdzie:

  • numer funkcji to nazwa funkcji ze słownika poniżej. Odpowiada parametrom możliwym do odczytu przez urządzenia

  • nazwa - pomocniczy parametr, wyświetlany w logach PVD i pochodzących z konfiguracji parametrów w aplikacji AMAGE

  • skalowanie - 0 → brak skalowania. Jeśli > 0 to wartość mierzona zostanie PODZIELONA na daną wartość. Pozwala to np. odczytać dane w kWh i zamienić na MWh bezpośrednio przed przesłaniem do systemu głównego.

Odbiorca: pvd-consumer-csv

Nazwa modułu: c-csv

Moduł pozwala zapisać dane lokalnie w środowisku uruchomieniowym aplikacji PVD. Dane odbierane są przez standardowe metody od dostawców danych a następnie zapisywane w pliku formatu CSV (separator średnik ;) w katalogu docelowym. Po włączeniu opcji separateFiles na true system po odebraniu wiadomości zapisuje je w osobnych plikach dla każdego identyfikatora UUID.

W przypadku separateFiles = false w katalogu docelowym tworzony jest plik o nazwie output.csv i do niego zapisywane są wartości w formacie:

  • znacznik czasu (ISO)

  • identyfikator UUID parametru

  • odczytana wartość parametru

np.

2022-05-12T13:10:44.888;b89da96b-d444-4adc-93b7-b9b7e0798c12;11341;

W przypadku separateFiles = true tworzone są osobne pliki. Dla w/w przypadku utworzony zostanie w katalogu docelowym plik o nazwie b89da96b-d444-4adc-93b7-b9b7e0798c12.csv i zawartości przykładowej (jeden rekord):

2022-05-12T13:10:44.888;11341;

Pliki są uzupełniane tj. jeśli istnieją i nie są puste to wartości zostaną dopisane na końcu pliku

Przykład konfiguracji:

{
   "resultPath": "/home/user/result_folder",
   "separateFiles": true
}