Grenton – Lua pierwsze kroki

Grenton pozwala na programowanie w LUA. W tym poście chciałbym się przyjrzeć dokładniej jakie narzędzia udostępnia Grenton instalatorowi.

Zacznijmy od początku. Grenton używa LUA jako języka skryptów, który pozwala na sterowanie modułami podpiętymi pod CLU. Podobne rozwiązanie istnieje w Fibaro jak i w innych systemach automatyki domowej. Aby utworzyć program na CLU należy uruchomić Object Managera (link do programu można otrzymać po wysłaniu maila do Grentona. Nie ma go w instrukcjach), nacisnąć przycisk “dodaj skrypt” aby uruchomić edytor. Po chwili klikania w trybie graficznym stworzyłem następujący skrypt.

W wersji tekstowej wygląda on następująco.

DOM->AddToLog(“test”)
if(DOM->x180001305_DIN1->Value==1) then
DOM->x200003152_DOUT1->SetValue(0)
else
DOM->x200003293_DOUT3->SetValue(0)
end

Tryb graficzny posiada narzędzie do przeglądania obiektów (głównie modułów, ale też harmonogramów i termostatów) dostępnych dla CLU. Pozwala on łatwe znalezienie dostępnych wartości i metod. Nazwy modułów można zmieniać na bardziej “ludzkie” Czyli zamiast “x200003152_DOUT1”, można nazwać moduł “swiatlo_salon”.

Aby uruchomić skrypt musi on być wgrany na CLU. Po naciśnięciu przycisku “Uruchom Skrypt” pojawia się następujący komunikat.

Po naciśnięciu przycisku ok. Skrypt wysyłany jest na CLU.

Cała operacja trwa od 3-6 sekund. Po czym czym całe CLU jest resetowane. Czuje, że zmiana konfiguracji może być uciążliwa dla domowników. Gdy wszystkie światła będą gasły po resecie CLU.

Problemem jest brak walidacji poprawności skryptu, a kolorowanie składni to za mało. Można wysłać na CLU nieprawidłowy składniowo skrypt. Spowoduje on, że na CLU zapali się czerwona dioda, a w OM otrzymamy informacje o przekroczonym czasie wykonania komendy. Niestety nie ma dokładnych informacji o błędzie. Jedynym objawem, że coś poszło nie tak jest migająca czerwona dioda na CLU. Istnieje możliwość ściągnięcia logów z CLU, ale o tym później.

Podpowiadanie składni

Po przełączeniu się w tryb tekstowy, w edytorze jest zaimplementowane podpowiadanie.

Co za LUA siedzi w CLU?

Żeby to sprawdzić przygotowałem taki skrypt. Gdzie “DOM” to nazwa mojego CLU. Można CLU i moduły nazwać dowolnie.

DOM->AddToLog(“test loggera”)
DOM->AddToLog(_VERSION)

Uruchomiłem. I podłączyłem się na port telnet (23) do CLU. Za pomocą komendy read sprawdziłem plik LOG.TXT (zobacz wpis).Wynik poniżej:

a:\> read log.txt
Reading from log.txt:

test loggera
Lua 5.1

Na stronie LUA zakładka z wersjami (https://www.lua.org/versions.html) zawiera następujące informacje:

Lua 5.1 was released on 21 Feb 2006

Lua 5.2 was released on 16 Dec 2011.

Lua 5.3 was released on 12 Jan 2015

Link do manualna do wersji 5.1 znajduje się tu: https://www.lua.org/manual/5.1/manual.html.

Dostępne środowisko

Aby dowiedzieć się czegoś o środowisku utworzyłem następujący skrypt.

for n in pairs(_G) do DOM->AddToLog(n) end

Zmienna _G zawiera większość globalnych zmiennych trzymanych w LUA. W przypadku CLU dostępne są następujące zmienne globalnie.

OnInit
string
Timer_00c8a9
package
_VERSION
OBJECT
PIDcontroller_00a64f
require
DOUT_0771
pairs
EventsFor_DIN_7738_4
DIN_7738
ipairs
yyyyy
io
DOUT_7805
mm_200003293
Calendar_009c69
newproxy
module
DIN_8823
_G
DIN_1536
checkAlive
DIN_7217
DIN_5653
EventsFor_DIN_1536_6
EventsFor_DIN_7738_6
mm_180001305
getVar
DOUT_4764
Thermostat_007d37
setVar
DOUT_6304

Pogrubiłem zmienne, które ewidentnie należą do CLU. Te niepogrubione należą do LUA. Dla porównania LUA 5.1 na Ubuntu posiada następujące zmienne przypisane do globalnej tablicy _G.

string
xpcall
package
tostring
print
os
unpack
require
getfenv
setmetatable
next
assert
tonumber
io
rawequal
collectgarbage
arg
getmetatable
module
rawset
math
debug
pcall
table
newproxy
type
coroutine
_G
select
gcinfo
pairs
rawget
loadstring
ipairs
_VERSION
dofile
setfenv
load
error
loadfile

Pogrubiłem te zmienne, które występują na CLU. Jak widać LUA na Grentonie została okrojona do niezbędnego minimum.

Przestrzeń nazw

“Skrypty” dodane w OM są zapisane w pliku na CLU w A:\USER.LUA. I wygląda on następująco:

a:\> read user.lua
Reading from user.lua:

–[[ REMOVED

function test3()

–BEGIN_INIT
–END_INIT

null:execute(0, “test”)
if(DIN_7738:get(0)==1) then
DOUT_4243:set(0, 0)
else
DOUT_6304:set(0, 0)
end

end

–]] — REMOVED

function yyyyy()

–BEGIN_INIT
–END_INIT

null:execute(0, “test loggera”)
null:execute(0, _VERSION)

for n in pairs(_G) do null:execute(0, n) end

end

Warto zauważyć, że usunięte skrypty nie są usuwane. Zostają one jedynie zakomentowane. Inną ciekawą rzeczą jest to, że OM transpiluje skrypt napisany przez użytkownika do formy rozumianej przez CLU. Czyli moja nazwa DOM została zamieniona na “null”, a metoda “AddToLog” to klucz o wartości 0 (zero) przekazany do metody “execute” w obiekcie(?) null.

Wygląda na to, że każdy skrypt ma przestrzeń nazw taką jak funkcja w LUA. Aby zapewnić komunikację między skryptami należy używać paramentów w funkcji lub zmiennych globalnych. Same skrypty są dodane to tablicy _G, więc dostęp do nich jest globalny.

Skrypty mogą przyjmować parametry. Możliwe jest przekazanie tylko trzech typów: string, number, boolean.

Object

W tablicy zmiennych globalnych _G można znaleźć zmienną o nazwie OBJECT. Wygląda na to, że jest to fabryka obiektów modułów dla CLU. Znalazłem w internecie skrypt, który pozwala zwrócić wartości znajdujące się w obiekcie https://gist.github.com/lunixbochs/5b0bb27861a396ab7a86. Zmieniłem tylko ostatnią linię

print(recurse[args[1])) na DOM->AddToLog(recurse(args[1]))

Po uruchomieniu otrzymałem następujący wynik:

{
[“__index”] = “function: 7062e080”
}

Spróbowałem to samo dla obiektu  “DOUT_6304”

{
[“__index”] = “function: 7062e080”
}
“userdata: 706347c8”

Niestety nie wiele widać. I na tę chwilę nie będę drążył tematu. Lista dostępnych metod jest dostępna w OM.

Debugowanie

Do dyspozycji w menu Object Managera, jest dostępne narzędzie “Debugging CLU”.

Ten plik, wygląda jak coś co można wysłać do Grentona, w celu uzyskania pomocy, niż coś co może pomóc instalatorowi.

W katalogu null znajduje się konfiguracja CLU. Pliki:

config.txt – plik w którym zapisane są chyba fizyczne adresy podłączonych modułów do CLU. Zawartość pliku wygląda tak:

00000000
0d1cf160
d8:90:49:eb:a7:40
00000003
00000195
00000000
00000000
0ava5a19:00:00:10
0becce40:01:01:0b
0bebceed:01:01:0b

debug.bin – plik binarny z danymi, które wyglądają jak zapis komunikacji po protokole modbus między modułami.

Logger initialized for CLU version $ (SN $) Sending reset response to $.$.$.$:$ lBaseClass_Set: seting property $ of item $:$ lDinClass_Inertion SN=$:$ value=$ lBaseClass_Execute: executing method $ of item $:$ Debug dump started for CLU version $ (SN $)ĐYŕÔ_
ă

Ož Pń ÝYŕÔ (…)

Trochę słów kluczowych można znaleźć w logach, takich jak: PollA, ReqSe, ACK, RS485_00N, ForceA, SetLD

I dużo, dużo danych binarnych. Pewnie inżynierowie Grentona mają narzędzie do odczytu danych w tym formacie.

main.lua – plik, który startuje CLU. Zawiera wywołanie obiektu SYSTEM i metody loop.

collectgarbage(“collect”)
require “user”
collectgarbage(“collect”)
require “om”collectgarbage(“collect”)

function checkAlive()
return “0d1cf150″end
SYSTEM.Init()

repeat
SYSTEMOM.Loop()
until 1==2

om.lua – plik w którym zapisany jest “program” naszego CLU. Konfiguracja, która została wyklinana w OM. Opisem tego pliku zajmę się w przyszłości.

user.lua  – jest to ostatni plik w katalogu. Zawiera on wszystkie funkcje / skrypty stworzone przez użytkownika.

Błąd składniowy

Gdy zaloguję się telnetem na podłączone CLU do OMa. Mogę wywołać komendę “log print”. W przypadku braku błędu składniowego otrzymałem następujący wynik:

a:\> log print
0993:745: Logger initialized for CLU version 40527 (SN 220000xxx)
0993:758: Sending reset response to 192.168.2.100:55266

A w przypadku wgrania celowo błędnego skryptu na CLU w logach nie ma śladu po błędzie. Jedynie mruga czerwona dioda na CLU.

a:\> log print
0753:745: Logger initialized for CLU version 40527 (SN 220000592)
a:\>

Również plik LOG.TXT jest pusty. Natomiast przy próbie pobrania pliku debugującego, otrzymuję komunikat.

Jeszcze istnieje jedna możliwość dobrania się do “dumpa” logów.

a:\> dump
Initialized drive m: Formating… OK.
m:: 4 MB Free
TFTP serwer started. Dump file saved as “m:\debug.bin”.
a:\>

Wygląda, że udało się zapisać “dump” na dysk m, ale i tak nie można tych danych pobrać za pomocą OM. Jedyną metodą jest usunięcie błędu składniowego i uruchomienie ponownie CLU?

Błąd działania

Stworzyłem skrypt, który wywoła nieistniejącą metodę i spróbuję znaleźć błąd w logach. Skrypt wygląda następująco:

DOM->nieMaMetody()

Przy próbie wgrania skyrptu na CLU otrzymałem następujący komunikat.

Myślałem, że ten wpis znajdę w logu samego OM, ale był on pusty.

Stworzyłem kolejny skrypt:

local x = 50
local y = 10
y = x + z
DOM->AddToLog(y)

Na moim lokalnym LUA powoduje on następujący błąd:

lua: error.lua:4: attempt to perform arithmetic on global ‘z’ (a nil value)
stack traceback:
error.lua:4: in main chunk
[C]: ?

Brakuje zdefiniowanej zmiennej “z”. Skrypt udało się wysłać na CLU. Oraz otrzymałem komunikat o sukcesie. W logach brak śladu błędu.

PODSUMOWUJĄC

• Grenton używa LUA 5.1 z przyciętymi pakietami.
• OM podpowiada metody i parametry metod ze wszystkich modułów.
• Tryb graficzny do bardzo prostych skryptów.
• Brak walidacji składni w edytorze dostarczonym w OM. Najlepiej używać własnego edytora.
• Utrudnione debugowanie skryptów. Brak informacji o błędach. Przy błędach składniowych, mrugająca czerwona dioda.
• W przypadku błędu nie da się ściągnąć pliku “dump” z CLU i wysłac do Grentona.

Pozdrawiam,

T