Tämä ei kyllä ainakaan Pörssärissä oikein pidä paikkaansa, koska rajapinta ei voi palauttaa mitään semmoista mitä skripti ei osaa käsitellä eikä muistiakaan oikein voi yhtäkkiä mikään haukata liikaa.
Itse olen kyllä aina kuvitellut, että SSL-kättelyn jälkeen siihen väliin ei kyllä enää pääse, mutta voin olla väärässä. Ja oma koodi kyllä varmasti kaatuisi, mutta tuohon Aten tekemään skriptiin uskon kyllä aika idioottivarmana tekeleenä nykyisellään.Ei voi sinänsä varmuudella tietää mitä verkossa on välissä. Voihan olla vaikka joku proxy tms.... Reverse proxyt tai erilaiset palomuurit varsinkin voi joskus olla jänniä. Eli kutsu ei välttämättä päädy edes perille asti, vaan väliltä tulee jo joku virhe.
Siihen ei me skriptikoodarit voida vaikuttaa, että millaisen verkon sisältä kutsuja tehdään. Vierastan muutenkin ajatusta, että "mun koodi ei voi kaatua". Käsittääkseni ei vielä täysin idioottivarmaa "Hello World!" ohjelmaakaan ole tehty.
SSL yhteys on mahdollista terminoida ja jatkaa sitten eteenpäin. Mutta nämä toki ei ole kotiverkkojen juttuja.
Ehkä näitä pitäisi tutkia - eli kokeilla tarkistaako laite sitä vastapään sertifikaattia.
Kiitos ja kumarrus
, tuo auttoiMuokkaus: scripti toimii shellyssä taas
Minkätyyppistä toiminnallisuutta tällä haetaan? Sinällään skriptissä on normaalit aikatoiminnallisuudet nykyään käytössä, niin toki ainakin sillälailla onnistuu, että määritettyinä tunteina ei ohjausta suoriteta. Vai onko ajatuksena saada tuo aina manuaalisesti paussille tms?
Timereita olen yrittänyt käyttää, mutta onko Shellyssä rajoitus montako timeria voi olla käytössä? Miten timerin saa sammutettua, jotta voi käynnistää uuden?Scripti lukee lämpötiloja kahdelta add-on sensorilta ja tämän olen saanut timeria käyttämällä tapahtumaan halutulla aikavälillä. Nyt haluaisin sellaisen toiminnon, että antureiden eron ollessa riittävän iso, niin antureiden arvoja ei luettaisi x aikaan. Tämän ajan umpeuduttua lähdettäisiin taas alusta liikkeelle.
Miksi et vain yhdellä ajastimella lue lämpötiloja ja toteuta hystereesiä ohjaukseen?
Menisikö jotenkin niin, että sinulla on jokin tilamuuttuja true/false pidetäänkö taukoa mittauksissa vai ei ja toinen muuttuja tauon pituuden laskemiseksi.
Juurikin tällainen on ollut yrityksenä tehdä, mutta en ole onnistunut sitä tekemään.
Tähän malliin se varmaan kannattaisi tehdä. Ilmeisesti nuo harvemmin ajetut pitäisi olla omissa funktioissa, joita pääloopista kutsutaan tietyissä vaiheissa? Näitä funktion kutsuja ja sieltä palaamista oikeaan kohtaan koodia en vain ole saanut toimimaan. Pääsen kyllä funktion sisään, mutta sieltä palaaminen päälooppiin on ongelma.
En osaa sanoa, onko tuo mahdollista (ohjaan shellyjä ulkoa käsin), mutta ellei ole (shellyn skripteille aliohjelmakutsutilapinoa), voinee noihin rakentaa jonkinlaisen semaforijärjestelmän, eli erilliset taskit pyörivät erillään loopissa, ja jäävät aina odottamaan oman timerinsa kulumista loppuun ja sitten viestivät toisten vastaavien säikeiden kanssa keskinäisten muistipaikkojen kautta ja odottelevat vastasuunnan muuttujan tilan perusteella oikeaa hetkeä jatkaa eteenpäin. Jos muistipaikat on nimetty kunkin säieparin ja viestintäsuunnan mukaan yksikäsitteisesti, ei edes tarvita useampivaiheista semaforilogiikkaa (ja deadlockin mahdollisuudet on aika selväpiirteistä pitää hanskassa, jos rakenne ja toimintalogiikka eivät leviä kahta useammalle loogiselle säiekerrokselle).
Tee yksittäinen funktio mitä tuo timer aina kutsuu. Funktiossa sitten
github.com
Curl-sovellus pyörii jossakin moniajokäyttöjärjestelmässä tyypillisesti (unix-sukuiset, windowsit tms.) ja tuolla vain lähetetään parametroitu http-käsky shellylle. Missään shellyssä ei taida olla riittävän syviä systeemipalveluita, jotta tukisi natiivia curlia? Oikaiskaa, jos erehdyn...
Tarkoititko niitä Shelly.call rpc-kutsuja? Mitä meinaat tehdä?
Tuo on POST-kutsu, menisikö jotenkin näin. Vaatii lisäksi jonkun eventwatcherin mikä toteuttaa tuon kutsun kun releen tila muuttuu. Shellyn esimerkkikirjastossa on muistaakseni jonkinlainen skriptiesimerkki tuon event watcherin käyttöön.
function ParseResponse(res, error_code, error_msg, ud) {
if (error_code != 0) {
print("Request error: ", error_code, error_msg);
} else {
if (res.code === 200) {
let response = JSON.parse(res.body);
print(response);
} else {
print('Request failed: ', res.code);
}
}
}
let username = 'xxx'
let password = 'xxx'
let urlToCall = 'http://' + username + ':' + password + '@192.168.10.10/api/limit/config'
let payload = 'data={"serial":"11418180xxxx", "limit_type":1, "limit_value":50}'
Shelly.call("HTTP.POST", { url: urlToCall, body: payload, timeout: 15, ssl_ca: "*" }, ParseResponse);Joo hyvä huomio! Korjasin tuon esimerkkiskriptin niin, että jos plaintext ei sisäverkossa haittaa, niin tuolla pitäisi onnistua muuttamalla nuo tunnukset oikein muuttujiin. Mutta tosiaan tuo ei ole erityisen tietoturvallinen tapa.
No niin näkyy olevan. Paikallinen käyttöliittymä laitteen ip-osoitteella kuitenkin toki toimii asetusten tekemiseksi.
Kokeilin tätä muuttaen asetukset vastaamaan omiani, mutta en saanut toimimaan. Consoleen tuli seuraavat ilmoitukset:
Palataan vielä tähän kun pientä edistystä on tapahtunut, mutta maaliin en ole vielä päässyt. Tuo aikaisemmin kertomani openDTU dokumentaatiosta löytynyt cURL komento ei toiminut edes tietokoneelta lähetettynä. Tuon sain nyt ratkaistua ja ohjaus onnistuu tietokoneelta käskyllä
Jos se nyt vaan on noista vääränlaisista lainausmerkeistä ollut curlissakin kiinni, niin toimiiko sitten toisinpäin myös shellyssä?
function ParseResponse(res, error_code, error_msg, ud) {
if (error_code != 0) {
print("Request error: ", error_code, error_msg);
} else {
if (res.code === 200) {
let response = JSON.parse(res.body);
print(response);
} else {
print("Request failed: ", res.code);
}
}
}
let username = "xxx"
let password = "xxx"
let urlToCall = "http://" + username + ":" + password + "@192.168.10.10/api/limit/config"
let payload = "data={'serial':'11418180xxxx', 'limit_type':1, 'limit_value':50}"
Shelly.call("HTTP.POST", { url: urlToCall, body: payload, timeout: 15, ssl_ca: "*" }, ParseResponse);