Wysyłanie danych ze skryptów poza TapHome: zmienna tekstowa i HTTP ze smart rules
Integracja, która w skryptach smart rules oblicza setki wartości, nie może dziś wysłać ich do zewnętrznej usługi jednym żądaniem. Zmienna tekstowa, współdzielone kolekcje albo żądania HTTP ze skryptów smart rules pozwoliłyby dowolnemu skryptowi zbudować jeden JSON i go wysłać.
Dziś wartości obliczone w kilku skryptach trafiają do modułu, który wysyła żądania HTTP, tylko przez setki pomocniczych urządzeń. Dzięki temu pomysłowi skrypty współdzieliłyby jedną wartość, na przykład cały dokument JSON, a moduł wysłałby ją jednym żądaniem.
Dlaczego i jak to wykorzystasz
Coraz więcej instalacji współpracuje z zewnętrzną usługą: zarządzanie energią przez rynek spot, firmowy backend, narzędzie do raportów. Taka usługa zwykle oczekuje jednego żądania z dużą ilością danych. TapHome potrafi te dane obliczyć, ale nie potrafi ich łatwo złożyć i wysłać:
- Smart rule Skrypt może odczytać każde urządzenie instalacji i wykonywać złożone obliczenia, ale nie może wysłać żądania HTTP.
SENDHTTPREQUESTdziała tylko w skryptach Packet parser. - Moduł Packet parser może wysyłać żądania, ale jego skrypty widzą tylko zmienne i urządzenia tego modułu.
- Wartości między nimi można przekazać tylko przez urządzenia, a urządzenie Zmienna przechowuje jedną liczbę, nie tekst ani listę.
Typowy przypadek: usługa w chmurze planuje, kiedy domowy magazyn energii się ładuje, rozładowuje lub sprzedaje energię do sieci. Co dwie minuty oczekuje jednego żądania JSON z predykcją zysków solarnych i prognozą zużycia na każdą godzinę dziś i jutro (4 × 24 wartości) oraz z cenami spotowymi zakupu i sprzedaży na każde 15 minut (2 × 96 wartości). To 288 próbek, każda ze znacznikiem czasu, czyli prawie 600 liczb. Ceny, prognoza i model zużycia są już w różnych skryptach instalacji. Aby trafiły do jednego modułu, który wywołuje usługę, instalator potrzebowałby setek urządzeń Zmienna, po jednym na każdą wartość.
Odczyt wyniku nie jest problemem: moduł Packet parser może co 20 sekund pytać usługę o bieżące polecenie i pokazywać je jako Przełącznik wielowartościowy. Brakuje tylko drogi na zewnątrz.
| Dziś | Z tym pomysłem | |
|---|---|---|
| 600 wartości do wysłania | 600 urządzeń Zmienna | Jedna wspólna wartość |
| Żądanie HTTP | Tylko Packet parser | Także ze smart rules |
| JSON budowany w | Module wysyłającym | Dowolnym skrypcie |
Co będzie możliwe
Oceniamy ten pomysł i nie wybraliśmy jeszcze rozwiązania. Nic z poniższych nie jest zaplanowane, a szczegóły mogą się jeszcze zmienić. Każda z tych opcji rozwiązałaby opisany wyżej przypadek:
- Zmienna tekstowa. Urządzenie Zmienna, które zamiast liczby przechowuje tekst. Jeden skrypt buduje ciąg JSON i go zapisuje, inny skrypt, na przykład w module Packet parser, odczytuje go i wysyła jako treść żądania.
- Współdzielone kolekcje. Kolekcja wartości, na przykład lista cen, zdefiniowana raz i dostępna do odczytu ze skryptów smart rules i ze skryptów Packet parser.
- Żądania HTTP ze smart rule Skrypt.
SENDHTTPREQUESTlub podobna funkcja bezpośrednio w smart rule, tak aby skrypt, który oblicza dane, także je wysyłał. - Wysyłanie przez zdefiniowany kanał. Cel, na przykład endpoint HTTP, byłby zdefiniowany raz, a dowolny skrypt mógłby wysyłać do niego dane, podobnie jak wysyła się powiadomienie.
Co nie będzie możliwe
- Nowe obliczenia w TapHome. Pomysł przenosi dane między skryptami i poza TapHome. Nie dodaje samemu TapHome optymalizacji ani prognozowania.
- Kilka serwerów z jednego modułu. Także ze zmienną tekstową lub współdzielonymi kolekcjami moduł Packet parser wysyła żądania na jeden adres ustawiony w jego ustawieniach. Każdy kolejny serwer nadal potrzebuje własnego modułu.
- Nieograniczona historia w jednej wartości. Pomysł jest przeznaczony dla danych jednego obliczenia, na przykład prognozy na najbliższe dni, a nie do przechowywania pomiarów z wielu miesięcy.
Jak to rozwiązać dzisiaj
- Wykonaj całą pracę w jednym module Packet parser. Zmienne modułu są wspólne dla wszystkich skryptów i urządzeń modułu i mogą przechowywać całą odpowiedź JSON. Gdy dane pochodzą z tego samego serwera, do którego je wysyłasz, moduł może je pobrać, przeliczyć i wysłać bez smart rule. Zobacz Skrypty i zmienne pomocnicze w module.
- Używaj różnych ścieżek na tym samym serwerze.
SENDHTTPREQUESTwysyła na adres modułu, ale ścieżka, metoda, treść i nagłówki mogą być inne przy każdym wywołaniu. Zobacz Funkcje Packet parser. - Pozwól usłudze odbierającej zbierać dane publiczne. Jeśli to Ty prowadzisz usługę, która odbiera dane, może ona sama pobierać dane publiczne, takie jak ceny spotowe. TapHome wysyła wtedy tylko to, co wie tylko on, na przykład stan magazynu energii lub zużycie.
- Urządzenia w module dla kilku wartości. Smart rule Skrypt zapisuje każdą wartość do własnego urządzenia Zmienna w module Packet parser. Skrypt zapisu modułu może odczytać wszystkie swoje urządzenia i wysłać je jednym żądaniem. Działa to dla kilkudziesięciu wartości; przy setkach nie jest praktyczne, bo każda wartość potrzebuje własnego urządzenia.
Dowiedz się więcej
- Gdzie używa się skryptów opisuje, co potrafi każdy rodzaj skryptu.
- Skrypty w smart rules i powiadomieniach opisuje, co smart rule przekazuje swojemu skryptowi.
Którą usługę chcesz podłączyć i ilu danych potrzebuje? Zagłosuj na ten pomysł, obserwuj go, odpowiedz na ankietę i napisz nam w komentarzach.
Co z tego rozwiązałoby Twoją integrację? Zaznacz wszystko, co pasuje.
Powiązane
Historia statusu
- 3 lis 2026 Badanie zainteresowania Opublikowano
Komentarze 0
Zaloguj się na swoje konto TapHome, aby skomentować. Zespół zatwierdza komentarze przed ich wyświetleniem.
Jeszcze nie ma komentarzy.
·
Oryginalny komentarz został usunięty.
Pomysły wskazują kierunek rozwoju, nie zobowiązania. Nie publikujemy dat; wydane funkcje są ogłaszane w informacjach o wydaniu.
Zaloguj się na swoje konto TapHome, aby obserwować. Wyślemy Ci e-mail, gdy coś się zmieni; możesz wypisać się jednym kliknięciem.
Potwierdzanie głosu…