Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - T

Strony: [1] 2
1
Grenton / Odp: Wsparcie od Grentona
« dnia: Styczeń 17, 2018, 11:45:56 pm  »
No w końcu!

Zgłosiłem tickety! :)


2
Grenton / Odp: Grenton - szczegóły techniczne
« dnia: Grudzień 29, 2017, 02:29:32 pm  »
   
@T
Czy wedle Twojego rozeznania można wyedytować jakiś plik z konfiguracją adresacji IP CLU? Problem jest taki, że w CLU nie można ustawić swojego adresu bramy tylko domyślnie przyjmuje że brama to x.x.x.1 , a jak zapewne wiesz nie zawsze jest tak ;) To następna łyżeczka dziegciu ...

"łyżeczka dzigciu" - śmiechłem srogo  ;D

Jeśli chodzi to CLU to o za pierwszym razem ono używa DHCP, ale i wtedy prawdopodobnie dostanie bramę. Ale OM wymusza przypisanie stałego adresu IP. Nie ma miejsca na wpisanie maski i bramy, nawet jak da się to zmienić w plikach konfiguracyjnych to każda zmiana na CLU z OM nadpisuje (chyba) wszystkie pliki. Boje się, że to by była dłubanina straszna (ręcznie lub skryptem nadpisywać konfigurację po każdej zmianie na clu)


3
Grenton / Odp: Grenton - szczegóły techniczne
« dnia: Grudzień 27, 2017, 01:31:01 pm  »
Dzięki janosick za dobre słowo :)

Brak obsługi zmiennych przez pamięć nieulotną - brak zasilania i user traci własne ustawienia systemu (nie piszę o termostatach)...

Zastanawiałem się jak rozwiązać ten problem i da się. Za pomocą biblioteki "io" w Lua można stworzyć plik lua i wczytać go na event on Init. Do tego pliku można zapisywać aktualny stan systemu. Jest jednak jedno bardzo duże "ale". Takie zapisywanie na pamięci flash CLU prawdopodobnie bardzo szybko ją wykończy. Ja bym to zrobił za pomocą zewnętrznego komputera. Oczywiście to wada / zaleta Grentona, że wszystko się da, tylko trzeba pisać kodzik.

Ciekawe jak wygląda sterowanie jasnością świateł dla dimmerów?
Jasność dla Dimmera przybiera wartość w zakresie od 0 do 1 z rozdziałką 0.01.
RGB przybiera wartości 0-255 jako liczby całkowite, może konwertowane na hex? - nie wiem, jak pisałem nie jestem tak biegły w programistycznych sprawach.
Myślę, że najlepiej możesz sprawdzać działanie korzystając z zakładki Sterowanie każdego obiektu w OM

Jestem ciekaw czy sterowanie jest płynne czy nie? Bo wysłanie i odbiór komunikatu dla moich skryptów to ok 100ms. I teraz jak przesuwasz suwak, to czy wysyła pozycję startową i końcową i robi płynne przejście czy "skacze", bo wysyła co chwilę pozycję palca na suwaku z opóźnieniem?

T napisał na blogu:
Cytuj
Nie jestem pewien jak często zwracany jest stan termometrów....

Z obserwacji termometry z paneli raportują live (green) natomiast 1wire (yellow/blue) minimalnie co 1 min + zmiana stanu?!


Dzięki. U mnie w pokoju temperatura się prawie nie zmienia i ciężko cokolwiek zaobserwować.

Przy okazji odkryłem, że Lua w Grentonie nie jest aż tak mocno okrojona jak mi się wydawało z początku. Oczywiście nie ma biblioteki "socket"  :'(.
Ale są inne takie jak: table, math, debug. Domyślnie nie są załadowane, trzeba je wczytać przez require.


4
Grenton / Odp: Grenton - szczegóły techniczne
« dnia: Grudzień 27, 2017, 02:05:01 am  »
Cześć,

W dalszym ciągu pracuję nad komunikacją z OpenHabem. Tym razem sprawdziłem czy jestem w stanie podszyć się pod aplikację mobilną:

http://domktorymysli.pl/2017/12/grenton-komunikacja-z-telefonem-szczegoly/

TL/DR

Tak. Mogę zarejestrować mój skrypt jako klienta. Prawdopodobnie komunikacja OpenHab z Grentonem będzie oparta o ten sam mechanizm.
Skrypt: https://github.com/Domktorymysli/grenton-client-php/blob/master/examples/fake_phone/fake_phone.php

Pozdrawiam,
T

5
Grenton / Odp: Grenton - szczegóły techniczne
« dnia: Grudzień 20, 2017, 01:08:00 am  »
Robię research, w jaki sposób pobrać listę urządzeń dla OpenHaba, które są wpięte w CLU. Przy okazji opisałem jak wygląda konfiguracja CLU po stronie LUA:

http://domktorymysli.pl/2017/12/grenton-plik-om-lua/

 

6
Grenton / Odp: Grenton - API / Komunikacja z telefonem
« dnia: Grudzień 17, 2017, 12:20:43 am  »
Cześć,

Przepisałem klienta na PHP. Na RPi włącza się szybciej niż Java. Pisałem to na php 7.1 ale na PHP >=5.6 powinno działać.

https://github.com/Domktorymysli/grenton-client-php

D:\Domktorymysli\grenton-php\examples\simple_client>php simple_client.php grenton:exec --help
Usage:
  grenton:exec [options] [--] <c>

Arguments:
  c                            Plik konfiguracyjny. Zobacz przykladowy plik properties-dist.xml

Options:
  -f, --function=FUNCTION      Nazwa funkcji na CLU
  -p, --parameters=PARAMETERS  Parametry funkcji, oddzielone spacją (multiple values allowed)
  -i, --i=I                    Ip zwrotne
  -h, --help                   Display this help message
  -q, --quiet                  Do not output any message
  -V, --version                Display this application version
      --ansi                   Force ANSI output
      --no-ansi                Disable ANSI output
  -n, --no-interaction         Do not ask any interactive question
  -v|vv|vvv, --verbose         Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Skrypt pozwalający na zdalne wywoływanie funkcji na CLU firmy Grenton.

Przykładowe wywołanie:

php simple_client.php grenton:exec ../properties-dist.xml -f test -p param1 -p param2 -i 10.20.30.41

Sprawdziłem też Domoticz i OpenHab. Postanowiłem, że z integracją Grentona będę celował w OpenHab. Głównie dlatego, że jest w Javie i wydaje się bardziej stabilny niż Domoticz. Może się mylę?

Wygląda na to, że będę musiał dopisać własną warstwę między Grentonem a OpenHab w LUA. Coś na kształt toolkita dla Fibaro (https://github.com/Krikroff77/Fibaro-HC2-Lua-Framework).

Taki toolkit pozwalałby na następujące rzeczy:

- serailizowanie / deserializowanie obiektów do JSONa
- discovery - pobranie wszystkich pobranych urządzeń do Clu id / typ. Wygląda na to, że nie da się pobrać nazwy nadanej w OM.
- dodanie prostej kolejki fifo dla wiadomości które są nadawane z CLU (chyba, że znajdę sposób na wysłanie wiadomości z Clu. Coś na kształt Fibaro Net.*)
- pewnie mnóstwo rzeczy o których jeszcze nie wiem :)

Pozdrawiam,
T

7
OpenHab, Domoticz, Jeedom itd... / Odp: OpenHAB 2 - Blebox binding
« dnia: Grudzień 13, 2017, 10:32:21 pm  »
Jestem pod wielkim wrażeniem! Gratuluję i trzymam kciuki za merge!

8
Grenton / Odp: Grenton - API / Komunikacja z telefonem
« dnia: Grudzień 12, 2017, 12:52:11 am  »
    Gratulacje, super robota!
    Przypomina mi się to co kiedyś @sztywniak robił z fibaro - to były czasy  :'(


    Cześć!!

    Dzięki za dobre słowo.

    Czy próbowałeś odpalać skrypty z innego urządzenia niż to na którym był OM? pytam pod kątem RPi[/li][/list]

    Tak. Na RPi jest Java, powinno działać. Niestety moje PI leży gdzieś zakurzone na półce. Może w weekend je odkurzę.
    Ten skrypt jest w Javie jest dlatego, że OM jest napisany w Javie i było mi prościej napisać kod na podstawie zdekompilowanego kodu. Możliwe, że w weekend przepiszę to samo w PHP, które uruchamia się szybciej.

    Wydaje mi się że twoje skrypty nie zastąpią moduły GATE. Z tego co wiem gate ma wysyłać polecenia REST do innych urządzeń, chyba nie ma planowanego Grenton API  :(

    Nie zastąpią? Potrzymaj mi piwo!! :)

    Nie będzie to rozwiązanie tak dobre jak moduł Gate. Trochę sztukowane, ale jak coś jest głupie i działa ...

    Podstawowym problem jest to, że nie namierzyłem jeszcze metody na Clu, która pozwoliłaby wysłać wiadomość do telefonu. Zawsze to telefon inicjalizuje połączenie a CLU odpowiada. Dlatego potrzebne jest miejsce, żeby zbierać komunikaty a skrypt będzie je na bieżąco pobierał. Np co sekundę, minutę, godzinę.

    Po pierwsze potrzebujemy po stronie LUA coś na kształt stosu. Dwie funkcje.

    Jedna pozwalająca na dodawanie elementów na stos.

    function put(message)

        -- inicjalizacja pustej tablicy globalnie
        if (_G['messages'] == nil) then
            _G['messages'] = {}
        end

        -- niestety nie ma biblioteki table na Grentonie
        -- table.insert(_G['messages'], message);

        _G['messages'][#_G['messages'] + 1] = message

    end

    Druga, zdejmująca wiadomości ze stosu:

    local function get()

        -- gdy pusto nil
        if (_G['messages'][#_G['messages']] == nil) then
            return nil
        end

        -- wiadomosc z samej gory
        tmp = _G['messages'][#_G['messages']];
        -- usuniecie pobranej wartosci
        _G['messages'][#_G['messages']] = nil

        return tmp

    end

    Jak to działa? Przykładowe wywołanie w zewnętrznym edytorze (mam zainstalowane lua 5.1 w systemie i większość kodu piszę na boku, dopiero jak działa to wrzucam do CLU)

    put("test message")
    print(get())
    put ("test message 3")
    put("test message 2")
    print(get())
    print(get())

    Wynik:

    test message
    test message 2
    test message 3

    Dodałem te dwie funkcje jako "skrypty" na CLU.

    Teraz na CLU dla jakiegoś zdarzenia na Clu muszę dodać wiadomość. Np. naciśnięcie przycisku lub gdy temperatura spadnie poniżej jakieś wartości na termostacie. Pozostanę przy przycisku.

    Mój przycisk na zdarzeniu OnClick ma przypisane takie wywołanie: DOM->x200003152_DOUT1->Switch(0). Zamiast tego napiszę skrypt:

    DOM->x200003152_DOUT1->Switch(0)
    put("Swiatlo w pokoju ma stan: " .. DOM->x200003152_DOUT1->Value )

    I nazwę go "light_switch" i przypiszę do OnClick w miejsce DOM->x200003152_DOUT1->Switch(0).

    Teraz, gdy włączam światło w pokoju do mojej tablicy _G['messages'] dodawane są kolejne komunikaty. Włączyłem i wyłączyłem światło na digitalin parę razy.
    Za pomocą mojego skryptu, mogę je pobierać wiadomości.

    D:\testy>java -jar simple-client-1.0.jar -c properties-dist.xml -f get -ip 192.168.2.100 -p nil
    Swiatlo w pokoju ma stan: 0.000000

    D:\testy>java -jar simple-client-1.0.jar -c properties-dist.xml -f get -ip 192.168.2.100 -p nil
    Swiatlo w pokoju ma stan: 1.000000

    D:\testy>java -jar simple-client-1.0.jar -c properties-dist.xml -f get -ip 192.168.2.100 -p nil
    nil

    I teraz można z tego zrobić "rest" przez curl.

    Np. tak:


    java -jar simple-client-1.0.jar -c properties-dist.xml -f get -ip 192.168.2.100 -p nil | curl -d @- https://api.czegostam.com


    Podsumowując:

    - Oczywiście, przez moduł Gate obejdzie się bez drutowania.
    - Da się za pomocą tego rozwiązania wysłać wiadomości przez http żeby zintegrować "rest api".
    - Trzeba tylko odpytywać CLU co jakiś czas, czy przypadkiem nie ma nowej wiadomości w globalnej tablicy _G['messages'].
    - W skrypcie put wypada dodać ograniczenie, że można tam przechować max 100 wiadomości, żeby nie zapełnić całej pamięci CLU.
    - Będzie jakieś opóźnienie. Może się okazać, że CLU szybciej zapisuje niż worker czyta. Dlatego napisałem, że rozwiązanie da radę dla 80% przypadków. Gdy wymagasz natychmiastowego działania, to by trzeba było odpytywać CLU np. co sekundę. Chyba, że znajdę funkcję która wysyła wiadomość na podany adres ip. Wtedy nie będzie trzeba używać tego stosu.

    Jeszcze raz dzięki czendler za pytania :)

    Pozdrawiam,
    T
     

    9
    Grenton / Odp: Grenton - API / Komunikacja z telefonem
    « dnia: Grudzień 09, 2017, 03:54:51 pm  »
    Cześć,

    Z góry chciałem przeprosić, pisane na kolanie, ale mam mało czasu.

    Skończyłem pisać pierwszą wersję klienta, który pozwala na wywołanie skryptów z CLU za pomocą komputera.

    Pełny opis tutaj: http://domktorymysli.pl/2017/12/wlasny-modul-gate/

    TL/DR

    Popatrz na repo: https://github.com/Domktorymysli
    ściągnij jara: http://domktorymysli.pl/files/simple-client-1.0.jar
    stwórz własny plik konfiguracyjny podobny do tego: https://github.com/Domktorymysli/grenton-simple-client/blob/master/properties-dist.xml

    uruchom:

    java -jar simple-client-1.0.jar -c properties-dist.xml -f hello_world -ip 192.168.2.100 -p nil

    otrzymasz odpowiedź: hello world

    Możesz napisać skrypt i pobierać dane z CLU np. w celu ich logowania. Możesz wywoływać sceny, bo dostałeś maila na telefon. Co tylko chcesz.

    Pozdrawiam,
    T







    10
    Grenton / Odp: Grenton - API / Komunikacja z telefonem
    « dnia: Grudzień 07, 2017, 01:30:42 am  »
    @T
    Dziękuję za napisanie klienta, będzie trochę problem z testami bo domownicy protestują po restartach, natomiast integracja z Domoticz to świetny pomysł dla rozszerzenia integracji.
    Ogólnie robisz wielką przysługę dla wszystkich użytkowników i firmy w sprawie zwiększenia bezpieczeństwa systemu zakładając, że ktoś od Grentona analizuje twoje wpisy a w to nie wątpię.
    @janosick
    Cytuj
    RPi z zainstalowanym Domoticzem albo OpenHab byłoby świetnym magazynem na dane
    W planach Grentona przewidziana jest chyba chmura i statystyki ale zaleta  "swoich" danych jest nie do przecenienia.

    Z testami możesz się wstrzymać. To co zrobiłem, to komunikacja w jedną stronę. Mam już rozwiązanie działające dwie strony, ale muszę jeszcze nad nim chwilę posiedzieć. Myślę, że w weekend wrzucę dokładną instrukcję jak wszystko w miarę bezboleśnie odpalić.

    Co do Domoticza to istnieją dwie opcje: plugin w Pythonie i plugin w c. Na tę chwilę będę celował w Pythona.




    11
    Grenton / Odp: Grenton - API / Komunikacja z telefonem
    « dnia: Grudzień 04, 2017, 12:04:17 am  »
    @janosick

    Dzięki za dobre słowo. Na razie czytam dokumentację Domoticza. Może mi się uda coś napisać, zanim zostanie wydany moduł Gate? :D

    @andre

    Żeby odczytać temperaturę do wykresów. W LUA musisz napisać skrypt np. taki:

    temperatureSensorOne = DOM->x113247182_ONEW_SENSOR1->Value
    temperatureSensorTwo = DOM->x154160907_ONEW_SENSOR1->Value

    return "{\"t1\":" .. temperatureSensorOne .. ",\"t2\":" .. temperatureSensorTwo .. "}"

    Gdzie wynik to np. JSON, XML czy jakiś Twój własny format. Musisz nazwać tę funkcję np. "test"

    I za pomocą klienta (https://github.com/Domktorymysli/grenton-simple-client/blob/master/src/main/java/com/github/domktorymysli/grenton/simple_client/App.java) wysłać request do CLU. np. taki:

    req:192.168.1.104:00e347:test(nil)

    Gdzie "192.168.1.104" to adres ip na który clu odpowie. "00e347" to id requestu generowane losowo.

    Potem na IP 192.168.1.104 port z którego wysłano wiadomość (tu widzę problem, bo to nie jest jeszcze nigdzie zdefiniowane :) ), CLU odpowie np. tak:

    resp:192.168.2.200:0000e347:{"t1":23.500000,"t2":23.500000}

    Pamiętaj, że limit na wiadomość to 2000 bajtów. Może w ciągu przyszłego tygodnia napiszę klienta, który będzie działał w dwie strony.


    12
    Grenton / Grenton - API / Komunikacja z telefonem
    « dnia: Grudzień 03, 2017, 05:14:10 pm  »
    Cześć,

    Miałem kilka wolnych godzin i ostatecznie udało mi się zrozumieć jak działa szyfrowanie w Grentonie. Szczegółowy opis i linki do kodu pod adresem:
    http://domktorymysli.pl/2017/12/grenton-komunikacja-2/

    TL/DR

    - to nie hackowanie to inżynieria wsteczna.
    - prawdopodobnie da się wyłączyć szyfrowanie na Clu z poziomu OMa w właściwościach projektu.
    - póki nie ma modułu Gate, można stworzyć tymczasową integrację z innymi systemami używając API do komunikacji z telefonem.
    - link do kodu na github: https://github.com/Domktorymysli.


    Co dalej?

    - postaram się udokumentować API.
    - jak znajdę trochę czasu to poprawię klienta i napiszę instrukcję.
    - @andre pamiętam o Tobie, w tej chwili wydaje mi się, że bardzo łatwo pobierać informację o temperaturze z Clu i zrobić na podstawie tych danych wykres. Jak będę miał chwilę to opiszę jak to zrobić.
    - może napiszę adapter Grentona dla Domoticz :D

    Pozdrawiam,
    T







    13
    Grenton / Odp: Grenton - szczegóły techniczne
    « dnia: Listopad 26, 2017, 03:49:31 pm  »
    T-napisał

    Cytuj
    Sterujesz temperaturą w domu za pomocą CLU? Możesz opisać jak Ci to działa?

    Nie jestem zwolennikiem sterowania ogrzewaniem czy wentylacją przy pomocy automatyki domowej zostawiając jej
    jednak funkcje konrolno-alarmowe,wizualizację, powiadomienia, archiwizację zużycia energii i możliwość awaryjnego, zdalnego i lokalnego ON/OFF-a w funkcji STOP.
    Zastępowanie dość złożonych algorytmów nowoczesnych sterowników pogodowych i harmonogramów wbudowanych w oryginalne systemy sterujące ogrzewaniem prostymi PID-ami nie jest właściwe, zwłaszcza, że wymaga wiedzy od osoby obsługującej (dzieci?) W/g mnie powinno to działać w tle i w automacie.
    Niemniej za pomocą Grentona steruję bojlerem elektrycznym (tylko w taniej taryfie G12W) za pomocą wirtualnych kalendarzy i działa to bezbłędnie oraz matami grzejnymi w wybranych pomieszczeniach przy zachowaniu oryginalnych sterowników z czujnikami temperatury podłogi i powietrza regulując timing włączania w zależności od pory dnia (taryfy), obecności osób i zwierząt w domu oraz temperatur z paneli dotykowych i temp.zewnętrznej(czerpnia).Do pełnego spięcia wszystkiego w automat czekam na obsługę modbusa przez Grentona.

    Poruszyłeś bardzo ciekawy temat. Mocno się zastanawiam nad kompetencjami automatyki domowej oraz jak wiele rzeczy można jej powierzyć. Z tego co widzę, Grenton na Facebooku zmienia kierunek na trochę inny, niż ten który prezentował w informacjach marketingowych rok temu. Mianowicie, z systemu który miał integrować się ze wszystkim dookoła zamienia się w system, który niepotrzebnie zwiększa swoje kompetencje. Mam na myśli ostatnie reklamy o możliwości użycia Grentona jako alarmu. Wiem, że integracja jest trudna i o wiele łatwiej jest tworzyć system zamknięty, ale to jest jedna z rzeczy, która wyróżnia ten system na tle pozostałych.

    Zgadzam się w pełni, że wyspecjalizowane, dedykowane systemy, będą wykonywały powierzone zadanie dużo lepiej niż jeden system od wszystkiego.

    Ja planuję użyć Grentona do następujących rzeczy (jeśli chodzi o ogrzewanie i wentylację):

    - siłownikami przy ogrzewaniu w rozdzielaczach za pomocą PID-ów. Komputer pieca będzie pilnował całą resztę. Bez Grentona wszystko powinno działać całkowicie prawidłowo. Raczej jako bajer, gdy chcesz mieć temperaturę niższą w jednym z pokoi, niż ta ustawiona w całym domu.
    - będzie służył jako kolejne zabezpieczenie przed przegrzaniem drewnianej podłogi na ogrzewaniu podłogowym (nie powinno przekroczyć 30 stopni C).
    - będzie sterował pompą ccw. Tu pewnie harmonogram i integracja z alarmem (włączy/wyłączy pompę przy rozbrojeniu/uzbrojeniu alarmu).
    - podobnie, integracja samego z pieca z alarmem może odbywać się przez Grentona i modbus. Możliwe, że można to zrobić łącząc piec z alarmem bez Grentona. Satel chyba ma moduł modbus :)
    - Sterowanie wentylacją przez modbus. Będzie też możliwość sterowania wentylacją z panelu dotykowego.
    - Integracja wentylacji, ogrzewania z alarmem i kontaktronami w oknach. Np. gdy dużo okien otwartych wyłączy ogrzewanie, wentylację.

    Dużo z tych rzeczy można rozwiązać za pomocą Satela, ale chodzi o to, że alarm to alarm!

    Podsumowując, większość tych funkcji to tak jak napisałeś: ON/OFF bez przejmowania kompetencji dedykowanych rozwiązań.





    14
    Grenton / Odp: Grenton - szczegóły techniczne
    « dnia: Listopad 22, 2017, 07:43:47 pm  »
    Cytuj
    Na początku grudnia chciałem kupić wallplug i może jakiś inny moduł...

    Jak tylko na testy to szkoda kasy. Testowałem wallpluga i na aktualnym sofcie działa tylko jako on/off ale stabilnie, podobnie listwa Powernode 6 Switch i Relay Switch, ale tylko podstawowe ramki. RGBW , czujniki ruchu Everspring, FGBS-001, dimmery są wykrywane jako 'nieznane urządzenie zwave' bez parametrów.


    Masz rację! Myślę, że w dwóch zdaniach wyczerpałeś temat :). W plikach OMa są xmle definiujące różne urządzenia z-wave. Ciekawe czy można sobie skonfigurować własne urządzenie?

    Cytuj
    Na tę chwilę widzę kilka możliwości:

    Jest jeszcze jedna, mało elegancka, którą stosuję i działa: przełączanie czujników pomiędzy modułem Grentona a zewnętrznym webserwerem na czas pomiaru ale wymaga restartu CLU watchdogiem co jest uciążliwe jak wszystko gaśnie w domu. Być może gdyby zastosować wspólne zasilanie i wspólną masę dla modułu i webserwera to by chodziło bez przełączania.


    W pliku OM.LUA możesz znaleźć konfigurację termometrów w LUA. Ciekawe czy można dodać/usunąć termometr podczas pracy CLU? Sterujesz temperaturą w domu za pomocą CLU? Możesz opisać jak Ci to działa?

    Super, że zacząłeś to badać i opisywać. Sam jestem programistą i dołączyłem do forum z tego samego powodu co ty, i również, jak ty, byłem trochę zawiedziony jak mało informacji jest na ten temat.
    Fantastycznie, że postanowiłes uzupełnić te lukę.

    Cieszę się, że Ci się podoba!


    Przeczytałem wszystkie twoje posty i nasuwa mi się jedno pytanie. Bardzo mocno skupiłes się na wnetrznosciach systemu, co samo w sobie jest wartościowe, ale wygląda na to, że robisz to aby móc  połączyć się z CLU po http (lub innym protokole) . Jeśli dobrze to zrozumiałem to czemu, zamiast spędzać nad tym czas (wiele wątków kończysz stwierdzeniem "zostawiam to na razie") nie poczekasz na moduł Gate który powinien rozwiązać tę problemy, a przynajmniej zmienić ich optykę?

    Odpowiedzią może być tu "bo nie wiadomo kiedy wyjdzie" - i to by był prawdziwy argument. Wszak miał wyjść już dawno. Ale skoro tak, to czemu nie zdecydowałeś się na Ampio które ma serwer od dawna ( Ba, nawet ma api wystawione po swaggerze) i pozwoliło by ci się skupić na rozwiązaniu prawdziwych problemów.


    Moim planem/celem, w niedalekiej przyszłości, jest sprawdzenie więcej niż jednego systemu automatyki domowej. Na tę chwilę padło na Grentona, bo na tle innych wygląda on na prawdę dobrze, ale cierpi na zupełny brak informacji w internecie. Zanim podłącze pod niego bramę garażową czy alarm, wolę się upewnić jak wygląda komunikacja po wifi, z-wave i tf-bus. Część rzeczy zostawiam nierozwiązanych, bo wiem że jak poszukam w innym miejscu to rozwiązanie się znajdzie. Przyznasz, że to bardzo ciekawe, że zaszyfrowana wiadomość zawsze wygląda tak samo?

    Zgadam się, że moduł Gate załatwiłby problem z odczytem danych z termometrów. Mam już niewielką wiedzę na temat CLU i wydaje mi się, że można ten problem rozwiązać bez modułu Gate. Traktuję ten problem jako zagadkę. Moduł Gate będę potrzebował za około pół roku i po cichu liczę, że Grentonowi się uda. Oraz mam mocną nadzieję, że komunikacja z modułem Gate po webowym API będzie odbywała się po https.

    Może masz dostęp do Ampio? Fajnie by było podejrzeć jak wygląda komunikacja w ich wydaniu.



    15
    Grenton / Odp: Grenton - szczegóły techniczne
    « dnia: Listopad 20, 2017, 11:24:32 pm  »
    Mnie interesuje wspolpraca Grentona z modulami Fibaro, tzn czy stabilnie beda wspolpracowac czy beda zwiechy z-wave jak w Hc2

    Na początku grudnia chciałem kupić wallplug i może jakiś inny moduł, ale wątpię czy będę w stanie zawiesić moduły. Pewnie będę miał ich zbyt mało i będą zbyt blisko CLU. Na pewno opiszę jak wygląda konfiguracja i na co pozwala CLU.

    Bardzo ciekawa inicjatywa.
    Trzymam kciuki, żeby udało Cię się to doprowadzić do końca!

    Dziękuję!! :)

    Dziękuję za bardzo zwięzłą i przydatną kwerendę. Proponuję wstrzymać się z dalszymi testami do czasu zaimplementowania softu dla gate'a i modbusa bo dojdzie dodatkowa możliwość komunikacji z CLU i zapewne powiększy się liczba komend w lua.

    Cytuj
    Jak jest coś co chcielibyście wiedzieć, to dawajcie znać w komentarzach! Postaram się odpowiedzieć w ciągu kilku dni.

    Osobiście interesuje mnie pobieranie danych z czujników 1-wire modułu analog in/out na zewnętrzny serwer w celu archiwizacji i wizualizacji.

    Czekam na moduł Gate z niecierpliwością. Po opisach jestem prawie pewien, że będzie to ten sam moduł co CLU (hardware), tylko ze zmienionym softem. Oraz wydaje mi się, że pod Tf-bus kryje się protokół modbus. Podejrzewam, że inżynierowie Grentona nie chcieli, żeby do magistrali Tf-bus podłączać jakieś nieprzetestowane urządzenia modbus. Mogłoby to mocno wpłynąć na stabilność całości. Ale tylko zgaduję.

    Osobiście interesuje mnie pobieranie danych z czujników 1-wire modułu analog in/out na zewnętrzny serwer w celu archiwizacji i wizualizacji.

    Też chcę to zrobić. Miałem jeden pomysł, żeby użyć pakietu z LUA (http, socket), ale niestety nie jest on dostępny w LUA Grentona. Ale to częste, że twórcy urządzeń embedded wycinają wszystko co niepotrzebne, żeby zapewnić większą stabilność.

    Na tę chwilę widzę kilka możliwości:
    - Za pomocą LUA "io" zapisywać dane do pliku lokalnie na CLU i co jakiś czas pobierać przez tftp. (Dysk "m:" ma 4MB i od częstych zapisów może się zepsuć? Służy on jako miejsce na dumpy oraz tam zapisywany jest plik z nowym romem do aktualizacji)
    - Może da radę zmusić LUA "io", żeby pracowało na zdalnych plikach (mało prawdopodobne)
    - Może da radę wgrać bibliotekę http lub socket na CLU (mało prawdopodobne)
    - Jak zalogujesz się telnetem na CLU, to jest tam komenda "sendto", ale nie wiem jak ona działa i nie wiem jeszcze jak ją wywołać z poziomu LUA w CLU. (Najbardziej prawdopodobne)
    - Jak mi się uda rozszyfrować API, to wydaje mi się, że będzie można odczytywać dane z termostatów przez API do aplikacji na telefon. (Również prawdopodobne)
    - Moduł Gate




    Strony: [1] 2