Ogólnie zrobiłem to tak, że po otrzymaniu zapytania o "channel state", aplikacja wypełnia dane o sieci, potem dane związane z uptime.
Następnie przekazuje taką wstępnie wypełnioną strukturę do "elementu" z SuplaDevice, odpowiedzialnego za kanał, którego dotyczy pytanie:
Code: Select all
virtual void handleGetChannelState(TDSC_ChannelState &channelState);
Konkretny "element" może z otrzymanym channelState zrobić co mu się podoba. Może skasować uzupełnione informacje, może je nadpisać, może dodać swoje. Obuduję jeszcze tą strukturę TDSC_ChannelState w jakąś klasę, aby nie trzeba było się bawić operacjami OR na bitach. Aktualnie metoda handleGetChannelState nie robi nic z tymi danymi. Planuję dodać tam obsługę żywotności światła dla przekaźników (bo w ogólności funkcja "światło" jest konfigurowana w cloud i urządzenie może nie wiedzieć do czego służy przekaźnik).
Można by też to pole użyć do liczenia jak długo urządzenie było włączone.
Co do wyboru kanału "0", to ja osobiście mam wątpliwości. Wszystko jest fajnie, jeśli Twoje urządzenie obsługuje jedną funkcję (albo kilka mocno powiązanych ze sobą kanałów - np. stacja pogodowa). Ale jeśli stacja pogodowa jest postawiona przy bramie przesuwnej i przy okazji ten sam układ obsługuje przekaźnik od bramy, to chyba chciałbym mieć przynajmniej dwa przyciski "i" - jeden w lokalizacji stacji pogodowej, a drugi w lokalizacji bramy - tak abym nie musiał pamiętać, że przekaźnik od bramy jest na tym samym urządzeniu, co stacja pogodowa i tam gdzieś szukać "i".
Myślę, że prawdopodobnie zrobię to domyślnie włączone, z opcją wyłączenia per kanał. Czyli coś w stylu:
Code: Select all
auto relay = new Supla::Control::Relay(14, true, true);
relay->disableChannelState(); // to tylko przykład. Takiej metody jeszcze nie ma w biblitece
Zasilanie bateryjne - chętnie to dopiszę dla urządzenia wykonawczego - tylko potrzebowałbym kogoś, kto z tego korzysta. Trzeba by ustalić skąd brać informację o stanie naładowania i o żywotności baterii.
Zasilanie bateryjne może też dotyczyć samego kanału (np. termometr na oddalonym urządzeniu z RF) - wtedy taką implementację trzeba zrobić dla tego konkretnego kanału. Tylko to już bardziej dotyczy urządzeń typu "bramka" - w tym przypadku np. bramka RF.
Także wydaje mi się, że sytuacji jest sporo. Kokretne rozwiązania będzie łatwiej opracować na konkretnych przykładach.
Supla: bo GPIO to dopiero początek.
