Tip
Harmonogram kontroli MQTT jest przeznaczony do wysyłania zaplanowanych wiadomości z wyprzedzeniem. W przypadku kontroli na żywo zobacz Live MQTT Control zamiast tego.
Ten przewodnik pomoże Ci skonfigurować MQTT na Twoim SmartgridOne Controller, aby zdalnie kontrolować i monitorować instalacje baterii i paneli słonecznych.
Co potrzebujesz
- SmartgridOne Controller z dostępem do internetu.
- Dane uwierzytelniające MQTT: Można je uzyskać od naszego Zespołu Wsparcia.
- Środowisko deweloperskie Python (lub inny klient MQTT). Ten przewodnik korzysta z podstawowego przykładu napisanego w Pythonie, aby pomóc Ci rozpocząć pracę z MQTT i wysyłaniem poleceń. Zalecamy użycie Pythona ze względu na łatwość użycia, ale obsługiwany jest również każdy inny klient MQTT.
Dodatkowe informacje
MQTT to szybki protokół komunikacyjny w internecie. Jest to system wiadomości publish/subscribe, który pozwala na bezpośrednie połączenie między Twoją maszyną a SmartgridOne Controller. Twoje zasoby są klasyfikowane w grupach: solar, bateria, EV i HVAC. W tej chwili ta integracja pozwala na kontrolę na poziomie grupy, a nie per urządzenie.
Konfiguracja po raz pierwszy (punkt wyjścia dla nowych użytkowników)
Mam SmartgridOne Controller, który chciałbym skonfigurować do zdalnej kontroli MQTT.
1. Sprawdź swoją sieć
Upewnij się, że Twoja sieć pozwala na ruch sieciowy MQTT przez port 1883. Możesz to zrobić używając polecenia:
nc -zv mqtt.eniris.be 1883Gdy to polecenie nie jest dostępne, możesz alternatywnie pobrać i wykonać ten kod python.
W razie wątpliwości skonsultuj się z inżynierem sieci lub tymczasowo użyj hotspotu 4G/5G w swoim telefonie, gdy wystąpią błędy połączenia.
Note
Jeśli port 1883 nie jest dostępny z Twojej sieci, oferujemy kopię zapasową na porcie 80. Można to skonfigurować w Twoim kliencie MQTT na późniejszym etapie tego podręcznika.
2. Dodaj swoje urządzenia
Zaloguj się do interfejsu komisjonowania i upewnij się, że urządzenia zostały 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 zdalnej kontroli MQTT.

5. Zdalny sygnał został dodany
Interfejs zdalnej kontroli MQTT został teraz aktywowany na SmartgridOne Controller.
Jesteśmy teraz gotowi do wysyłania podstawowych poleceń przy użyciu prostego przykładu. Kolumna Status informuje, czy jakieś polecenie jest aktywne.
Skrypt demonstracyjny w Pythonie
Dobrym punktem wyjścia byłoby przetestowanie Twojej nowo skonfigurowanej integracji przy użyciu prostego przykładu.
Ten kod testowy wykonuje prostą pracę, ciągle wysyłając następujący harmonogram:
- Bateria: Ładowanie z mocą 5 kW przez 15 minut w 10 minut
- Słońce: Ustaw moc na 0 kW na godzinę w 30 minut.
SmartgridOne Controller odpowiada wiadomością potwierdzającą zawierającą unikalny identyfikator harmonogramu lub wiadomość o błędzie.
Następnie pobieramy następny harmonogram dla obu typów urządzeń, potwierdzając, że polecenie zostało wykonane pomyślnie.
Pobierz plik poniżej w swoim ulubionym IDE Pythona. Wypełnij numer seryjny i dane uwierzytelniające MQTT, i wykonaj skrypt:
Kiedy powyższe zakończy się sukcesem, możesz kontynuować wysyłanie innych typów wiadomości. Wszystkie wiadomości opisano poniżej.
Dokumentacja MQTT do wysyłania poleceń
Ta sekcja szczegółowo opisuje format wiadomości MQTT oraz wymagania dotyczące ładunku do skonfigurowania kontrola harmonogramów urządzeń w sieci SmartgridOne Controller.
Tematy MQTT
- Temat subskrypcyjny:
standard1/rp_one_s/remoteScheduleMetrics/<controller SN> - Temat odpowiedzi:
standard1/outbound/remoteScheduleMetrics/feedback/<controller SN>
Gdzie <controller SN> powinien zostać zastąpiony rzeczywistym numerem seryjnym SmartgridOne Controller, który zamierzasz 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>" (Opcjonalny),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint in watts>,
"site_import": <Site Import in Watts>,
"site_export": <Site Export in Watts>,
"remove_overlap": <True/False> (Opcjonalny) (default=False),
"tag": <Tag String> (Opcjonalny) (default=None),
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedule_ack",
"state": {
"schedule_id": <Schedule ID>,
"deleted_ids": <Schedulde IDs deleted if remove_overlap=True>
"tag": <Tag String> (default=None),
},
"responseCode": 0
}
}2. Ustaw harmonogramy (set_schedules)
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>" (Opcjonalny),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint in watts>,
"site_import": <Site Import in Watts>,
"site_export": <Site Export in Watts>,
"remove_overlap": <True/False> (Opcjonalny) (default=False),
}",
"1": "{
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalny),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint in watts>,
"site_import": <Site Import in Watts>,
"site_export": <Site Export in Watts>,
"remove_overlap": <True/False> (Opcjonalny) (default=False),
}",
...
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedules_ack",
"state": {
"schedule_ids": <Schedule IDs>,
"deleted_ids": <Schedulde IDs deleted if remove_overlap=True>
},
"responseCode": 0
}
}3. Pobierz harmonogram (get_schedule)
Pobiera konkretny harmonogram po ID.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedule",
"fields": {
"id": <Schedule ID>
}
}Odpowiedź:
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}4. Pobierz aktywny harmonogram (get_active_schedule)
Pobiera obecnie 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>" (Opcjonalny),
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_active_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}5. Pobierz następny harmonogram (get_next_schedule)
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>" (Opcjonalny),
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_next_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}6. Pobierz harmonogramy (get_schedules)
Pobiera wszystkie harmonogramy dla określonej daty.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedules",
"fields": {
"date": "<Data 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": [<Schedule>, ...]
},
"responseCode": 0
}
}7. Pobierz przyszłe harmonogramy (get_future_schedules)
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": [<Schedule>, ...]
},
"responseCode": 0
}
}8. Usuń harmonogram (remove_schedule)
Usuwa konkretny harmonogram po ID.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "remove_schedule",
"fields": {
"id": <Schedule ID>
}
}Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "remove_schedule_ack",
"state": "Harmonogram <Schedule ID> został pomyślnie usunięty",
"responseCode": 0
}
}9. Pobierz opinię o witrynie (get_feedback)
Pobiera szczegółowe informacje o stanie systemu.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_feedback",
"fields": {
"device": <Poziom urządzenia (węzła)>
}
}Odpowiedź (Sukces):
10. Topologia witryny (get_toplogy)
Pobiera topologię witryny.
{
"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>,
"nodeType": <nodeType>,
"nomCurrent": <nominalCurrent>
"children": [{<ChildObject>}]
},
"responseCode": 0
}
}Standardowy format odpowiedzi harmonogramu
{
"id": <Schedule ID>,
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcjonalny),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Schedule Policy>",
"power_setpoint_w": <Setpoint in watts>,
"created_at": <Unix Timestamp>
}Typy komponentów i polityki
Aby uzyskać szczegóły dotyczące dostępnych komponentów i polityk, które można zaplanować, zapoznaj się z sekcją Komponenty i polityki MQTT w dokumentacji Live MQTT Control.
Harmonogramy specyficzne dla urządzeń można wysyłać, korzystając z opcjonalnego pola node_id, odnosząc się do ID węzła kontrolowanego urządzenia.
Obsługa błędów
Wszystkie wiadomości mogą zwracać odpowiedź błędu z responseCode: 1, gdy wystąpi błąd:
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "<Message Type>_ack",
"error": <Error Body>,
"responseCode": 1
}
}Gdy wystąpi niepowiązany błąd, typ wiadomości będzie wynosić (general_error).
Typowe błędy obejmują:
- Nakładanie się harmonogramów z istniejącymi harmonogramami
- Nieprawidłowy zakres czasowy
- Typ urządzenia nie znaleziony
- ID harmonogramu nie znaleziony
- Nieprawidłowa polityka dla typu urządzenia
Zasady zarządzania harmonogramem
- Zasady dotyczące nakładania się
- Harmonogramy nie mogą się nakładać dla tego samego typu urządzenia
- Harmonogramy nie mogą się nakładać dla tego samego urządzenia
- Harmonogramy dla tego samego urządzenia i typu urządzenia nie mogą się nakładać
- Istniejące, nachodzące harmonogramy zostaną usunięte, jeśli zmienna
remove_overlapjest ustawiona naTruepodczas tworzenia nowego harmonogramu.
- Każdy harmonogram musi zawierać:
- Ważny typ urządzenia
- Czas rozpoczęcia (znacznik czasu Unix)
- Czas zakończenia (znacznik czasu Unix)
- Politykę (zgodną z dostępnymi politykami dla typu urządzenia)
- Ustalony punkt 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 zmienia się na rozpoczęcie teraz
- Harmonogramy mogą być usunięte tylko wtedy, gdy jeszcze się nie rozpoczęły. Aktywne harmonogramy nie mogą być usunięte.
- Harmonogramy można ustawiać dla różnych typów urządzeń niezależnie
- System automatycznie stosuje odpowiednią politykę, gdy harmonogram staje się aktywny
