Wskazówka
Zaplanowane sterowanie MQTT jest przeznaczone do wiadomości zaplanowanych z wyprzedzeniem. Do sterowania na żywo zobacz Live MQTT Control.
Ten przewodnik pomoże Ci skonfigurować MQTT na Twoim SmartgridOne, aby zdalnie sterować i monitorować instalacje baterii i paneli słonecznych.
Co jest potrzebne
- Controller z dostępem do internetu.

- Dane uwierzytelniające MQTT: można je zamówić u naszego Zespołu Wsparcia.
- Środowisko programistyczne Pythona (lub inny klient MQTT). Ten przewodnik używa podstawowego przykładu napisanego w Pythonie, aby ułatwić Ci rozpoczęcie pracy z MQTT i wysyłaniem poleceń. Zalecamy użycie Pythona ze względu na łatwość obsługi, ale wspierany jest każdy inny klient MQTT.
Dodatkowe informacje
MQTT to szybki protokół komunikacyjny przez internet. Jest to system wiadomości w modelu publish/subcribe, który pozwala na bezpośrednie połączenie pomiędzy Twoją maszyną a


Konfiguracja po raz pierwszy (Punkt startowy dla nowych użytkowników)
Mam

1. Sprawdź swoją sieć
Upewnij się, że Twoja sieć pozwala na ruch sieciowy mqtt przez port 1883. Możesz to zrobić za pomocą polecenia:
nc -zv mqtt.eniris.be 1883Jeśli to polecenie nie jest dostępne, możesz alternatywnie pobrać i uruchomić kod w Pythonie:
W razie wątpliwości skonsultuj się z inżynierem sieciowym lub tymczasowo użyj hotspotu 4G/5G ze swojego telefonu, gdy wystąpią błędy połączenia.
Notatka
Jeśli port 1883 nie jest dostępny z Twojej sieci, oferujemy awaryjne połączenie na porcie 80. Można je skonfigurować w kliencie MQTT na późniejszym etapie tego podręcznika.
2. Dodaj swoje urządzenia
Zaloguj się do interfejsu uruchomieniowego i upewnij się, że urządzenia są dodane do SmartgridOne Controller.
3. Dodaj zewnętrzny sygnał MQTT



4. Włącz zdalny sygnał MQTT
Wybierz wszystkie urządzenia, które chcesz uwzględnić w Zdalnym Sterowaniu MQTT.

5. Zdalny sygnał został dodany
Interfejs Zdalnego Sterowania MQTT został teraz aktywowany na SmartgridOne Controller.
Jesteśmy teraz gotowi do wysyłania podstawowych poleceń za pomocą prostego przykładu. Kolumna Status informuje, czy jakieś polecenie jest aktywne.
Skrypt demo w Pythonie
Dobrym punktem startowym jest przetestowanie nowo skonfigurowanej integracji za pomocą prostego przykładu.
Testowy kod wykonuje ciągłe wysyłanie następującego harmonogramu:
- Bateria: ładowanie mocą 5 kW przez 15 minut za 10 minut
- Solar: ustawienie mocy na 0 kW na godzinę za 30 minut
SmartgridOne Controller odpowiada komunikatem potwierdzającym zawierającym unikalny identyfikator harmonogramu lub komunikatem o błędzie.
Następnie pobieramy następny harmonogram dla obu typów urządzeń, potwierdzając, że polecenie zakończyło się powodzeniem.
Proszę pobrać plik poniżej do preferowanego IDE Pythona. Wypełnij numer seryjny i dane uwierzytelniające MQTT, a następnie uruchom skrypt:
Jeśli powyższe zakończy się powodzeniem, możesz kontynuować wysyłanie innych typów wiadomości. Wszystkie wiadomości są opisane poniżej.
Dokumentacja MQTT do wysyłania poleceń
Ta sekcja szczegółowo opisuje format wiadomości MQTT oraz wymagania dotyczące ładunku (payload) do ustawiania zaplanowanego sterowania urządzeniami w sieci SmartgridOne Controller.
Tematy MQTT
- Temat subskrypcji:
general_error - Temat informacji zwrotnej:
remove_overlap
Gdzie True należy zastąpić rzeczywistym numerem seryjnym SmartgridOne Controller, które chcesz kontrolować.
Typy wiadomości MQTT
1. Ustaw Harmonogram (set_schedule)
Tworzy nowy harmonogram dla typu urządzenia.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "set_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalne),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Wartość nastawy w watach>,
"site_import": <Import obiektu w watach>,
"site_export": <Eksport obiektu w watach>,
"remove_overlap": <True/False> (Opcjonalne) (domyślnie False),
"tag": <Napis tagu> (Opcjonalne) (domyślnie None),
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedule_ack",
"state": {
"schedule_id": <ID harmonogramu>,
"deleted_ids": <Usunięte ID harmonogramów jeśli remove_overlap=True>
"tag": <Napis tagu> (domyślnie None),
},
"responseCode": 0
}
}2. Ustaw Harmonogramy (general_error)
Tworzy wiele nowych harmonogramów.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "set_schedules",
"fields":
"0": "{
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalne),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Wartość nastawy w watach>,
"site_import": <Import obiektu w watach>,
"site_export": <Eksport obiektu w watach>,
"remove_overlap": <True/False> (Opcjonalne) (domyślnie False),
}",
"1": "{
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalne),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Wartość nastawy w watach>,
"site_import": <Import obiektu w watach>,
"site_export": <Eksport obiektu w watach>,
"remove_overlap": <True/False> (Opcjonalne) (domyślnie False),
}",
...
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedules_ack",
"state": {
"schedule_ids": <ID harmonogramów>,
"deleted_ids": <Usunięte ID harmonogramów jeśli remove_overlap=True>
},
"responseCode": 0
}
}3. Pobierz Harmonogram (general_error)
Pobiera konkretny harmonogram po ID.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedule",
"fields": {
"id": <ID harmonogramu>
}
}Odpowiedź:
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedule_ack",
"state": <Harmonogram>,
"responseCode": 0
}
}4. Pobierz Aktywny Harmonogram (general_error)
Pobiera aktualnie aktywny harmonogram dla typu urządzenia.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_active_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalne),
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_active_schedule_ack",
"state": <Harmonogram>,
"responseCode": 0
}
}5. Pobierz Następny Harmonogram (general_error)
Pobiera następny nadchodzący harmonogram dla typu urządzenia.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_next_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalne),
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_next_schedule_ack",
"state": <Harmonogram>,
"responseCode": 0
}
}6. Pobierz Harmonogramy (general_error)
Pobiera wszystkie harmonogramy dla konkretnej daty.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedules",
"fields": {
"date": "<String daty w formacie dd/mm/yyyy>"
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedules_ack",
"state": {
"schedules": [<Harmonogram>, ...]
},
"responseCode": 0
}
}7. Pobierz Przyszłe Harmonogramy (general_error)
Pobiera wszystkie przyszłe harmonogramy.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_future_schedules",
"fields": {}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_future_schedules_ack",
"state": {
"schedules": [<Harmonogram>, ...]
},
"responseCode": 0
}
}8. Usuń Harmonogram (general_error)
Usuwa konkretny harmonogram po ID.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "remove_schedule",
"fields": {
"id": <ID harmonogramu>
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "remove_schedule_ack",
"state": "Harmonogram <ID harmonogramu> został pomyślnie usunięty",
"responseCode": 0
}
}9. Pobierz Informacje Zwrotne Serwisu (general_error)
Pobiera szczegółowe informacje zwrotne o stanie systemu.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_feedback",
"fields": {
"device": <Poziom urządzenia (node)>
}
}Odpowiedź (Sukces):
Struktura ładunku informacji zwrotnej
10. Topologia serwisu (general_error)
Pobiera topologię obiektu.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_topology",
"fields": {}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_topology_ack",
"state": {
"nodeId": <nodeId>,
"isControllable": <boolean>,
"nodeType": <nodeType>,
"nomCurrent": <nominalCurrent>
"children": [{<ChildObject>}]
},
"responseCode": 0
}
}Standardowy format odpowiedzi harmonogramu
{
"id": <ID harmonogramu>,
"device_type": "<Typ urządzenia>",
"node_id": "<ID węzła>" (Opcjonalne),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Polityka harmonogramu>",
"power_setpoint_w": <Wartość nastawy w watach>,
"created_at": <Unix Timestamp>
}Rodzaje komponentów i polityki
Szczegóły dotyczące dostępnych komponentów i polityk, które mogą być zaplanowane, znajdują się w sekcji MQTT Components and Policies w dokumentacji Live MQTT Control.
Specyficzne harmonogramy dla urządzeń można wysyłać za pomocą opcjonalnego pola general_error, odnoszącego się do ID węzła sterowalnego urządzenia.
Obsługa błędów
Wszystkie wiadomości mogą zwrócić odpowiedź z błędem zawierającą remove_overlap, gdy wystąpi błąd:
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "<Typ wiadomości>_ack",
"error": <Treść błędu>,
"responseCode": 1
}
}Gdy wystąpi błąd niezwiązany bezpośrednio, typ wiadomości będzie (general_error).
Typowe błędy to:
- Nakładanie się harmonogramów z istniejącymi
- Nieprawidłowy zakres czasu
- Nie znaleziono typu urządzenia
- Nie znaleziono ID harmonogramu
- Nieprawidłowa polityka dla typu urządzenia
Zasady zarządzania harmonogramami
- Zasady nakładania się
- Harmonogramy nie mogą nakładać się dla tego samego typu urządzenia
- Harmonogramy nie mogą nakładać się dla tego samego urządzenia
- Harmonogramy dla tego samego urządzenia i typu urządzenia nie mogą się nakładać
- Istniejące, nakładające się harmonogramy zostaną usunięte, jeśli zmienna
remove_overlapjest ustawiona naTrueprzy tworzeniu nowego harmonogramu.
- Każdy harmonogram musi zawierać:
- Prawidłowy typ urządzenia
- Czas rozpoczęcia (Unix timestamp)
- Czas zakończenia (Unix timestamp)
- Politykę (zgodną z politykami dostępnymi dla typu urządzenia)
- Nastawę mocy (dla polityk, które tego wymagają)
- Czas rozpoczęcia musi być wcześniejszy niż czas zakończenia
- Jeśli czas rozpoczęcia jest w przeszłości, automatycznie zmieniany jest na czas obecny
- Harmonogramy mogą być usuwane tylko, jeśli jeszcze się nie rozpoczęły. Aktywne harmonogramy nie mogą być usunięte.
- Harmonogramy mogą być ustawiane niezależnie dla różnych typów urządzeń
- System automatycznie stosuje odpowiednią politykę, gdy harmonogram staje się aktywny
