Zaprogramowane sterowanie MQTT
Zaprojektowane sterowanie MQTT jest przeznaczone do zaplanowanych wiadomości z wyprzedzeniem. W przypadku kontroli na żywo, zobacz Kontrola MQTT na żywo 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.
- Poświadczenia MQTT: Można je uzyskać, wysyłając e-mail na adres support@eniris.be.
- Środowisko deweloperskie Pythona (lub jakikolwiek 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ść obsługi, ale wspierany jest również każdy inny klient MQTT.
Dodatkowe informacje
MQTT jest szybkim protokołem komunikacyjnym przez internet. Jest to system wiadomości typu publish/subscribe, który pozwala na bezpośrednie połączenie między Twoją maszyną a SmartgridOne Controller. Twoje zasoby są klasyfikowane na grupy: solar, bateria, EV i HVAC. W chwili obecnej ta integracja pozwala na kontrolę per grupa, 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 zdalnego sterowania MQTT.
1. Sprawdź swoją sieć
Upewnij się, że Twoja sieć pozwala na ruch sieciowy MQTT na porcie 1883. Możesz to zrobić za pomocą polecenia:
nc -zv mqtt.eniris.be 1883
Kiedy to polecenie nie jest dostępne, możesz alternatywnie pobrać i wykonać ten kod pythonowy.
W razie wątpliwości skonsultuj się z inżynierem sieci lub tymczasowo użyj hotspotu 4G/5G swojego telefonu, gdy wystąpią błędy połączenia.
Gdy port 1883 nie jest dostępny z Twojej sieci, oferujemy zapasowy port 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 uruchamiania 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ń, korzystając z prostego przykładu. Kolumna Status informuje, czy jakieś polecenie jest aktywne.
Skrypt demonstracyjny Pythona
Dobre pierwsze kroki będą polegały na przetestowaniu nowo skonfigurowanej integracji za pomocą prostego przykładu.
Ten kod testowy wykonuje prostą czynność polegającą na ciągłym wysyłaniu następującego harmonogramu:
- Bateria: Ładowanie z mocą 5 kW przez 15 minut co 10 minut
- Słońce: Ustawienie mocy na 0 kW przez godzinę co 30 minut
SmartgridOne Controller odpowiada wiadomością potwierdzającą zawierającą unikalny identyfikator harmonogramu lub wiadomością o błędzie.
Następnie pobieramy następny harmonogram dla obu typów urządzeń, potwierdzając, że polecenie było udane.
Proszę pobrać plik poniżej w preferowanym IDE Pythona. Wypełnij swój numer seryjny i poświadczenia MQTT, a następnie wykonaj skrypt:
Gdy powyższe zakończy się sukcesem, 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 do skonfigurowania zdalnego sterowania urządzeniami w sieci SmartgridOne Controller.
Tematy MQTT
- Temat subskrypcji:
standard1/rp_one_s/remoteScheduleMetrics/<controller SN>
- Temat opinii:
standard1/outbound/remoteScheduleMetrics/feedback/<controller SN>
Gdzie <controller SN>
powinno być zastąpione 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>" (Opcjonalnie),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint in watts>,
"replace_overlap": <True/False> (Opcjonalnie) (domyślnie=False),
}
}
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 replace_overlap=True>
},
"responseCode": 0
}
}
2. 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
}
}
3. Pobierz aktywny harmonogram (get_active_schedule
)
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>" (Opcjonalnie),
}
}
Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_active_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}
4. 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>" (Opcjonalnie),
}
}
Odpowiedź (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_next_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}
5. Pobierz harmonogramy (get_schedules
)
Pobiera wszystkie harmonogramy dla konkretnej daty.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedules",
"fields": {
"date": "<Data w formacie dd/mm/yyyy>"
}
}
Response (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}
6. 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": {}
}
Response (Sukces):
{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_future_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}
7. 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>
}
}
Response (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
}
}
8. Pobierz opinie o stronie (get_feedback
)
Pobiera szczegółowe informacje zwrotne o stanie systemu.
{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_feedback",
"fields": {}
}
Response (Sukces):
Struktura ładunku informacji zwrotnej
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 zasady
Aby uzyskać szczegółowe informacje o dostępnych komponentach i zasadach, które można zaplanować, zapoznaj się z sekcją Komponenty i zasady MQTT w dokumentacji Live MQTT Control.
Harmonogramy specyficzne dla urządzeń mogą być wysyłane z użyciem opcjonalnego pola node_id
, odnoszącego się do identyfikatora 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 (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 zasada dla typu urządzenia
Zasady zarządzania harmonogramem
- Zasady 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, nakładające się harmonogramy zostaną usunięte, jeśli zmienna
replace_overlap
będzie ustawiona naTrue
podczas tworzenia nowego harmonogramu.
- Każdy harmonogram musi mieć:
- Ważny typ urządzenia
- Czas rozpoczęcia (znacznik czasu Unix)
- Czas zakończenia (znacznik czasu Unix)
- Zasadę (dopasowaną do dostępnych zasad dla typu urządzenia)
- Punkty ustalenia mocy (dla zasad, które tego wymagają)
- Czas rozpoczęcia musi być przed czasem zakończenia
- Czas rozpoczęcia musi być przynajmniej
pięć
minut w przyszłości - Harmonogramy mogą być usuwane tylko, jeśli zaczynają się przynajmniej
pięć
minut w przyszłości - Harmonogramy mogą być ustawiane dla różnych typów urządzeń niezależnie
- System automatycznie stosuje odpowiednią zasadę, gdy harmonogram staje się aktywny