EventRunner 4 - QuickApp HC3

[jang]

Här är en liten intro till EventRunner4

EventRunner4.fqa

(167.02 KiB) Downloaded 712 times

EventRunner4 är en QuickApp för HC3 som gör det enkelt att definiera regler för olika hemmautomatiseringsuppgifter.

• Att tända eller släcka lampor eller andra enheter vid speciella tidpunkter på dygnet eller speciella dagar.
• Att repetera något under vissa tidsintervall, ex. att blinka en lampa eller att slå på en värmare 5min varje timme.
• Att reagera när en eller flera sensorer triggas och slå på belysning.
• Att slå av belysning när sensorer inte har triggats under en viss tid.
• Att skicka ett meddelande när ett fönster stått öppet i 10min, och fortsätta att skicka meddelanden var 10:e minut fönstret fortsätter att vara öppet.
• Att slå på belysning när medelvärdet av ett antal lux sensorer överstiger ett visst värde.
• Etc etc.

Den här typen av regler är enkla att definiera i EventRunner4.
Språket EventRunner använder för regler kallar jag för ”EventScript” och de har formen

Code: Select all

<villkor> => <kommandon>

Ex.

Code: Select all

55:breached => 66:on

Regeln säger att om sensor med id 55 triggas så slå på lampa med id 66

De flesta komponenter i HC3 has ett numeriskt id. Ex en z-wave rörelsesensor har id 55. I EventRunner kan vi testa vilka värden en device har med <id>:<property>.
I vårt exempel testar vi om rörelsesensor 55 har triggat med 55:breached som returnera sant eller falskt. Om vårt villkor är sant så utförs vårt kommando, 66:on som tänder lampan.

Villkoret i exemplet är bara en test, om 55 har triggats, men vi kan skriva mer komplexa test.
För att skapa komplexa tester använder vi operatorerna ’och’ som skrivs som ’&’, ’eller’ som skrivs som ’|’, och ’inte’ som skrivs som ’!’

Code: Select all

!55:breached => 66:off

…om sensor 55 blir ”inte triggad”, dvs. ”safe” så släck lampa 66.
Det finns en property för safe.

Code: Select all

55:safe => 66:off

Vi kan göra reglerna mer specifika genom att addera ytterligare villkor med ’&’

Code: Select all

55:breached & 06:00..08:00 => 66:on

<tid A>..<tid B> testar om tiden då regeln triggas faller inom intervallet och i så fall returnerar sant. I vårt fall om 55 triggas och tiden är ex. 07:00 kommer villkoret att vara sant och kommandot 66:on att köras.

Code: Select all

55:breached & wday(’mon-fri’) => 66:on

wday(<day string>) är en funktion som testar om den nuvarande dagen är inom de dagar som specificeras. I vårt exempel måndag till fredag.

Tidskonstanter i EventScript skrivs som HH:MM eller HH:MM:SS. Ex. sju på morgonen är 07:00 och 15 sekunder skrivs som 00:00:15.
Internt i regler översätts 00:00:15 till talet 15 och 07:00 till 3600*7, dvs antal sekunder.
Det gör att vi kan utföra vissa aritmetiska operationer med tid. 07:00+00:00:15 == 07:00:15 etc.

• Det finns vissa fördefinerade tidsvariabler

• ’sunset’ är tid för solnedgång i dag.

• ’sunrise’ är tid för soluppgång i dag.

• ’dusk’ är tid för gryning (lite tidigare än soluppgång)

• ’dawn’ är tid för skyming (lite senare än solnedgång)

• ’now’ tiden just nu (när regeln kör)

• ’midnight’ tiden för föregående midnatt.

Alla utom den sista är på formen HH:MM. ’midnight’ är annorlunda då den är uttryckt i absolut tid – epoc. Det är antal sekunder sedan 1 januari 1973 och är det sätt datorer oftast lagrar absolut tid. Jag kommer att visa någon regel där ’midnight’ är bra att ha.

Så vi kan trigga en regel om en enhet ändra värde.
Vi kan också trigga en regel på vissa tider

Code: Select all

@07:00 => 66:on

Här slår vi på lampa 66 varje dag kl 7.

Code: Select all

@07:00 & wday(’sat-sun’) => 66:on

Slå på lampa 66 kl 7 men bara om det är lördag eller söndag.

Vi kan också använda tidsvariabler

Code: Select all

@sunset-00:30 & wday(’sat-sun’) => 66:on

I det här fallet 30min före sunset. Varje natt kl. 00:00 uppdateras tidsvariablerna till dagens värde för sunset etc. Värdena beror på vilken geografisk plats du har konfigurerat din HC3 till.

@ är en funktion som tar som argument ett antal sekunder efter midnatt och triggar regel då. Det låter oss göra aritmetik som i exemplet ovan. Vi kan också göra så här..

Code: Select all

@min(sunrise-00:30,07:00) & wday(’sat-sun’) => 66:on

‘min’ är en funktion som returnerar det minsta värdet av de 2 argumenten. För regeln innebär det att den kommer att trigga regeln soluppgång-30min eller kl 07:00, beroende på vad som infaller tidigast.

Code: Select all

@00:00 => 66:on

slår på lampa 66 vid midnatt. Använd inte 'midnight' eftersom det är absolut tid. 00:00 är lika med 0 och är den tid i sekunder efter midnatt vi vill att regel ska köra.

Det finns en annan variant, @@ (två snabel-a) som istället triggar regel med det intervall som anges.

Code: Select all

@@00:05 => 66:toggle

Regeln ovan körs var 5:e minut och slår av/på lampa 66. Kanske inte så praktisk regel. Men det kan vara så att det är ngn enhet behöver aktivera regelbundet vid vissa tidpunkter.

Code: Select all

@@00:30 & sunrise..12:00 & wday(’mon-fri’)  => 77:on

Här slår vi på enhet 77 var 30 minut, mellan soluppgång och 12 på vardagar.

Låt oss återvända till regler som triggar om enheter ändrar värden.
Vo använda :safe och :breached för att testa om en sensor hade triggats eller gått tillbaka till normalt läge. Det finns en uppsjö av andra funktioner/tester. Här är några..

• <id>:safe – returnerar sant om sensor inte är triggad

• <id>:breached – returnerar sant om sensor är triggad

• <id>:isOn – returnera sant om enhet är påslagen
  66:isOn => 88:on
  Om 66 slås på, slå också på enhet 88

• <id>:isOff – returnera sant om enhet är avslagen

• <id>:lux – returnera enhets luxvärde (om det är en luxmätare)

• 99:lux > 200 => 88:on
  Slå på enhet 88 om luxmätare 99s värde överstiger 200

• <id>:temp – returnera temperatur från en termometer

• <id>:bat -- returnerar batteristyrkan i procent för en batteridriven enhet

• <id>:isOpen – sant om enhet är öppen, fungerar för rollerShutter enheter

• <id>:isClosed

• <id>:isSecure -- fungerar för vissa lås

• <id>:isUnsecure

Kommandon, som vi använder efter ’=>’ i våra regler är bl.a

• <id>:on – Slå på enhet

• <id>:off – Slå av enhet

• <id>:value=<tal>, sätt enhets ’value’ till angivet värde. En dimmer kontrollerar sin ljusstyrka så
  Ex.

  Code: Select all

  89:breached & sunset..sunrise => 109:value=50

  Om sensor 90 triggas efter solnedgång sätt dimnivå till 50% för dimmer 109

Vi kan ersätta <id> med en lista av enheter för att testa eller utföra kommandon på flera enheter samtidigt.
En lista skrivs som {x,y,z,..}

Code: Select all

{89,88}:breached & sunset..sunrise => {109,110,11}:value=50

Om antingen 89 eller 88 triggas kör regeln som dimrar 3 lampor.
:safe fungerar lite annorlunda

Code: Select all

{89,88}:safe & sunset..sunrise => {109,110,11}:off

Om både sensor 88 och 89 är safe så slå av lamporna. Det är oftast så man vill att :safe ska fungera för flera sensorer.

En annan funktion som kan vara bra att känna till är ’log’ som skriver ut en text i konsolen när regeln körs.
Ex.

Code: Select all

@sunset => log(’Nu är det solnedgång’)

Det är ofta praktiskt att logga vad som händer.
Observera att vi använder ’….’ för att definiera strängen som ska skrivas ut och inte ”…”.
Anledningen är att våra regler är strängar som kommer att omges av ”…” och då kan vi inte ha strängar som definieras på samma sätt inuti våra regler – se exempel nedan.

Hur lägger man in regler i EventRunner4 QA?

Här är en video
https://www.youtube.com/watch?time_cont ... e=emb_logo
som går igenom hur man laddar ner och installerar EventRunner4.fqa
Man öppnar sedan QA editorn for EventRunner4 och skriver reglerna som strängar till funktionen rule(<string>)
Ex.

Code: Select all

rule(”{89,88}:safe & sunset..sunrise => {109,110,11}:off”)

Ok, det var del 1.
Det finns många fler funktioner och sätt att interagera med enheter av olika typer. EventScript är egentligen ett komplett programmeringsspråk och vi ska senare hur vi kan använda det för att strukturera våra automatiseringsregler.

[forumadmin]

Grym guide

Finns det någon lista över tillgängliga commands? Typ som Krikroff gjort med sin Sonos QuickApp.

Hur gör man något så enkelt som att:
Om rörelsesensor --> breached --> tänd belysning, starta Sonos på volym 10. Men bara OM "ID xx" är tänt i ett annat rum. Och släck/pausa sonos efter rörelsesensor är safe sedan xx min.

[jang]

Grym guide

Finns det någon lista över tillgängliga commands? Typ som Krikroff gjort med sin Sonos QuickApp.

Hur gör man något så enkelt som att:
Om rörelsesensor --> breached --> tänd belysning, starta Sonos på volym 10. Men bara OM "ID xx" är tänt i ett annat rum. Och släck/pausa sonos efter rörelsesensor är safe sedan xx min.

Det kommer en part 2 och 3 med mera info.

Code: Select all

sensor = 33 -- rörelsesensor
lamp = 44 -- lampa i annat rum
sonos = 99 -- ID of Krikroffs sonos QA
rule("sensor:breached & lamp:isOn => fibaro.call(sonos,'play')")
rule("trueFor(00:05,sensor:safe) & lamp:isOn => fibaro.call(sonos,'pause')")

[forumadmin]

Grymt!

Vore intressant om ni som kör med EventRunner kunde dela med er lite av era Rules ni satt upp, så man får lite inspiration kring vad som är möjligt!

[MastrUsr]

Grymt!

Vore intressant om ni som kör med EventRunner kunde dela med er lite av era Rules ni satt upp, så man får lite inspiration kring vad som är möjligt!

Tummen upp på det!

Skickat från min SM-N960F via Tapatalk

[jang]

Mitt sista enkla lilla favorittrick är "2-knapps-kontrollen"

Code: Select all

  
keyfob = 88
rule("keyfob:central.keyAttribute=='Pressed' & keyPrim => post({type=fmt('Key%s_%s',keyPrim,keyfob:central.keyId)}); keyPrim=nil")  
rule("keyfob:central.keyAttribute=='Pressed' & keyPrim==nil => keyPrim=keyfob:central.keyId; wait(2); keyPrim=nil")

Jag har en sådan där remote från Fibaro med 6 knappar (FGKF-601, cirklar,kryss,...) och jag har några knappar som styr dagliga funktioner (tända belysning etc) och andra knappar som jag använder för mina labbscener. Den ger ifrån sig centralSceneEvents när man trycker på en knapp. Att bara ha 6 knappar gjorde att jag snabbt hade tilldelat alla knappar och blandat ihop dem - och min fru tordes inte använda den...

Regeln ovan slår ihop knappar som tryck inom 2s till ett event av typ #Key<knapp1>_<knapp2> som man sedan kan använda för att trigga regler. I teorin 36 events.... #Key reglerna kan leva i harmoni med standardregler som bara triggar på keyfob:central.* på det normala sättet, ex. single-click eller Hold.
Ex.

Code: Select all

rule("#Key1_2 => lights:on")
rule("#Key2_1 => lights:off")

1-2 tänder, motsatsen 2-1 släcker. etc.
Knappkombinationer kan ligga horisontalt eller vertikalt på de 2*3 knapparna (över och undervåning layout?)
...och alla mina experiment är reserverade för knappkombination 6-* nu.

[jang]

Det här är en regel som bara fungerar för HC3.
På HC2:an tyckte jag att alarmhantering var lite sisådär. På HC3:an är det en ny modell.
Man definierar larmzoner (eller partitioner) och tilldelar enheter till olika zoner (samma enhet kan vara i många zoner). Sedan larmar man på och av sina zoner.
Det funkar ganska bra. Man kan sätta en fördröjning från att man larmar på tills larmet blir aktiverat, så man hinner ut eller gå och lägga sig...
Problemet är att när man slår på larmet vill man kontrollera att inte någon sensor är aktiv. ex ett fönster som står öppet. Tyvärr får scener ingen trigger när larmet slås på utan först när det aktiveras - sedan får man triggers om larmet löses ut.

I ER4 finns det support för få en trigger/event redan när larmet slås på så att man hinner kontrollera enheter och slå av larmet om någon enhet var aktiverad.
Reglerna nedan är ett generellt system för att hantera larm - och det går att bygga ut med fler regler för hur det aktiveras eller vilka aktioner som ska utföras vid larm. Det samspelar dessutom med om man aktiverar larmet med App eller Web GUI.

Code: Select all

  rule("user=2")
  
  rule([[keyfob:central.keyId==3 => -- Keyfob att aktivera/avaktivera larmzon 1  (0 betyder hela huset)
    || 1:alarm.armed >> 1:alarm=false; log('avaktiverar 1');
    || !1:alarm.armed >> 1:alarm=true; log('aktiverar 1')
    ]])
    
   rule("1:alarm='watch'") -- Sätter bevakning på zon 1 och skickar ett event om den slås på via regel eller GUI/App
   
   --- Ovanstående regler är specifika för zon 1. Lägg till andra zoner eller 0 för hela huset. All regler nedan är generiska för alla zoner ------
   
  rule([[#alarm{id='$id',property='willArm',value='$secs'} => -- Notifiering att alarmet har aktiverats - vi har fördröjningstiden på oss att kolla att allt är ok...
        local alarm = id:alarm;
        if alarm.devices:safe then                            -- Kolla att fönster/dörrar är stängda
          user:msg = log("Alarmzon '%s' kommer att  aktiveras om %s sekunder",alarm.name,secs) 
        else
           id:alarm=false;
           user:msg = log("Alarmzon '%s' har fönster/dörr/sensor öppen, slår av alarm",alarm.name) 
        end
        ]])

  rule([[#alarm{id='$id',property='armed',value=true} =>
        user:msg = log("Alarmzon '%s' är nu aktiverad",id:alarm.name)
        ]])

  rule([[#alarm{id='$id',property='armed',value=false} =>
        user:msg = log("Alarmzon '%s' är nu avaktiverad",id:alarm.name)
        ]])

  rule([[#alarm{id='$id',property='breached',value=true} =>       -- Alarmzon löst ut!
        user:msg = log("Alarmzon '%s' triggad!",id:alarm.name);
        for i=1,5 do log("Tuut!") end -- Gör något så att tjuvarna blir rädda... man får en trigger per zon.
       ]])

  rule([[#alarm{property='homeBreached',value=false} =>  -- Alla alarmzoner säkrade
        user:msg = log("Alarm säkrat")
       ]])
 

[jang]

Del 2 av vår EventRunner4 tutorial.

Förra delen gick igenom några enkla regler och hur vi lade in dem i EventRunner4.fqa.
Vi definierar regler med hjälp av funktionen 'rule' och själva regeln är en sträng som vi ger som argument.
Ex.

Code: Select all

rule("88:breached => 99:on")

En sak att tänka på är att om vi vill logga en meddelande inuti en regel med 'log' funcktionen så kan vi inte använda definiera smeddelandet med "..." eftersom den hela regeln själv är innesluten i "...".
Lua tillåter även att strängar definieras med '...' och det är lösningen.

Code: Select all

rule("88:breached => log('Sensor 88 aktiverad!')")

Vi kan också göra tvärtom

Ibland kanske vi vill använda både " och ' inuti våra regler, och då kan vi använda Lua's 'multi-line' sträng definition, [[ ... ]]

Code: Select all

rule([[88:breached => log("Sensor '88' aktiverad!")]])

Fördelen är också att vi då kan definiera regler över flera rader.

Code: Select all

rule([[88:breached => 
    log("Sensor '88' aktiverad!")
    ]])

...vilket kan vara praktiskt om reglerna blir långa.

Reglerna läggs in i funktionen 'main()' som finns definierad EventRunner4's 'main' fil. Om ni tittar på videon i del 1 så ser ni hur man installerar EventRunner4.fqa och hur man öppnar och editerar 'main' filen i QAn.
Strukturen i main filen ser ut ungefär som:

Code: Select all

_debugFlags.trigger = true -- log incoming triggers
_debugFlags.fcall=true     -- log fibaro.call
_debugFlags.post = true    -- log internal posts
_debugFlags.rule=false     -- log rules being invoked (true or false)
_debugFlags.ruleTrue=true  -- log only rules that are true
_debugFlags.pubsub=true    -- log only rules that are true
------------- Put your rules inside QuickApp:main() -------------------

function QuickApp:main()    -- EventScript version
  local rule = function(...) return self:evalScript(...) end          -- old rule function
  self:enableTriggerType({"device","global-variable","custom-event","profile","alarm"}) -- types of events we want
  
  HT = { 
    keyfob = 26, 
    motion= 21,
    temp = 22, 
    lux = 23,
  }
  
  Util.defvars(HT)
  Util.reverseMapDef(HT)
end

De första raderna definierar ett antal flaggar som avgör vad ER4 loggar i konsolen när den kör. 'true' så loggas det och 'false' så loggas det inte.

Code: Select all

_debugFlags.trigger = true

Alla inkommande triggers utifrån, genererade av HC3. Ex. när sensorer eller fibaro globala variabler ändrar värden så loggas det som "Incoming trigger: ...". Det kan vara bra att se vilka triggers som kommer in till ER4. Om man ser triggern men regeln inte aktiveras då vet vi att det är ngt skumt med regeln. Formatet på triggers ska efterleva formatet på sourceTriggers om ni har jobbat med scener på HC3:an. Det är alltid en Lua tabell med formatet {type=<typ>, ...}

Code: Select all

_debugFlags.fcall=true 

Den ser till att logga alla anrop till fibaro.call. fibaro.call är den funktion som används oftast till att styra enheter, slå av och på lampor etc. Många EventRunner funktioner översätts till fibaro.call anrop.
Ex. regel

Code: Select all

rule("88:breached => 109:on")

och sensor 88 aktiveras så ser vi i loggen

Code: Select all

[08.10.2020] [10:28:41] [DEBUG]: Incoming trigger:{"value":true,"id":88,"old":false,"type":"device","property":"value"}
[08.10.2020] [10:28:41] [DEBUG]: [true]>>'Rule:1[88:isOn => 109:on]'
[08.10.2020] [10:28:41] [DEBUG]: fibaro.call(109,"turnOn") => nil

Första loggen är den trigger som genereras i HC3 när 88 ändrar värde från fale till true.
Andra loggen visar att regelns villkor blev sant och högersidan av '=>' kommer astt köras (dvs 109:on)
Sista loggen skriver ut anropet till fibaro.call som anropas som en effekt av 109:on. '=> nil' betyder bara att fibaro.call inte returnerar något värde

Code: Select all

_debugFlags.post = true

Inkommande triggers genererar events i ER4. Men vi kan också posta egna event. Det finns ett tidigare inlägg där vi kombinerar 2 tryck på en remote till ett kombinerat event (ex. Key1_2) och postar det. Vi kan få alla sådana post loggade med den här optionen. Vissa av ER4's egna funktioner postar också events.
Vi kommer att ta upp events och fördelen med dem i en senare post.

Code: Select all

_debugFlags.rule=false  

Den här flaggan loggar alla regler som triggas av events. Observera att en regel kan triggas men inte köras. Ex.

Code: Select all

rule("88:breached => 109:on")

Regeln kommer att triggas varje gång 88 ändrar värde. Men om det nya värdet är false (inte breached) så kommer resten av regeln (höger om '=>') inte att köras. Ibland kan det vara bra att slå på den här flaggan för att förstå om regler triggas eller inte. Om den triggas men inte kör när jag förväntar mig det så är det ngt fel på villkoret (vänster om '=>')

Code: Select all

_debugFlags.ruleTrue=true  -- log only rules that are true

Den här flaggan loggar bara regler som triggas och vars villkor är sant. Som i loggexemplet ovan.

Code: Select all

_debugFlags.pubsub=true    

Det här är en flagga som loggar vissa specifika meddelanden som används för att kommunicera mellan olika EvenetRunner4 QAs (ja, man kan ha mer än en ER4 QA om man vill). Vi tar upp mer om det i en senare post.

Det finns ett antal till debugflaggor men de ovan är de vanligaste.

Den nästa konstruktionen i mail filen är

Code: Select all

function QuickApp:main() 
  
end

som är den funktion där vi definierar våra regler. Det finns några fördefinierade funktioner där:

Code: Select all

local rule = function(...) return self:evalScript(...) end          -- old rule function

Här definierar vi funktionen 'rule' som vi använder för att definiera regler. Den heter egentligen 'self:evalScript' men det är lite långt att skriva...

Code: Select all

self:enableTriggerType({"device","global-variable","custom-event","profile","alarm"}) -- types of events we want

Här är en lista av vilka inkommande triggers vi vill ha till ER4. Det här är de vanligaste typerna så man ska inte behöva ändra i den.

Code: Select all

  HT = { 
    keyfob = 26, 
    motion= 21,
    temp = 22, 
    lux = 23,
  }

Här definerar vi en "Home Table". Idén är att vi sätter upp en Lua tabell med de enheter vi använder i våra regler. Alla enheter har ett numeriskt id. Vår tabell HT här säger att temp=22.
Lua tabller kan vara nästade, vilket kan hjälpa oss at strukturera våra enhetsnamn.

Code: Select all

  HT = {
    ['kök'] = {
       lampa = 88,
       sensor = 99
    },
    vardagsrum = {
      lampa = 109,
      sensor = 110
    },
    keyfob = 26
  }

Code: Select all

Util.defvars(HT)

Det här anropet tar vår HT tabell och definierar regelvariabler får de element som finns i tabellen.
Notera att ord med åäö måste definieras som ['kök'] eftersom det inte är tillåtet att ha åäö i namn på Lua variabler. Men i våra ER regler behöver vi det inte.

Code: Select all

rule("kök.sensor:breached => vardagsrum.lampa:on")

Hierarkin refereras till med '.' mellan varje nivå.

Här bör noteras att vi kan också referera till Lua globala variabler i våra regler också.

Code: Select all

myGlobal = 88
rule("myGlobal:breached => ...)

...fungerar. Med ovanstående globala HT tabell fungerar det också:

Code: Select all

rule("HT.kök.sensor:breached => ...)

men observera att vi måste referera till HT för att komma åt elementen. Util.defvars definierar upp kök.lampa, kök.sensor etc som interna regel variabler. Regelvariabler är också lite effektivare att använda men skillnaden är inte så stor.

Code: Select all

Util.reverseMapDef(HT)

Den sista funktionen tar vår HT tabell och mappar upp den så om vi anropar
rule("vardagsrum.lampa:on")
och har satt _debugFlags.fcall=true så loggas

Code: Select all

[08.10.2020] [10:28:41] [DEBUG]: fibaro.call(vardagsrum.lampa,"turnOn") => nil

dvs. den använder 'vardagsrum.lampa' istället för 109, vilket gör loggen tydligare.

Hur bygger man upp en "Home table"? Jag tycker själv om att definiera den för hand, med de namn och struktur som jag väljer. Det finns de som har väldigt många enheter och vill ha ett skript som automatiskt genererar en HT.
Idén är att man konstruerar den och sedan lägger den i en fibaro global variable så att andra scener och QA kan komma åt den.
För att lägga en Lua tabell i en fibaro global måste vi konvertera den till en sträng eftersom det är det enda vi kan lagra i en fibaro global. Det görs med funktionen json.encode(<tabell>)

Code: Select all

fibaro.setGlobalVariable("HT",json.encode(HT))

För att läsa in den gör vi motsatsen

Code: Select all

HT = json.decode((fibaro.getGlobalVariable("HT")))

Det finns en lång tråd på Fibaro forumet om Home tables. https://forum.fibaro.com/topic/23942-tu ... scene-ids/

En liten bonus. I vår main() så följer det med ett flertal regler som är bortkommenterade. Det finns 3 regler som ser ut såhär:

Code: Select all

-- rule("@{catch,05:00} => Util.checkForUpdates()")
-- rule("#File_update{} => log('New file version:%s - %s',env.event.file,env.event.version)")
-- rule("#File_update{} => Util.updateFile(env.event.file)")

Avkommentera reglerna (ta bort --) så kommer ER4 QAn att automatiskt uppdatera sig varje morgon kl. 05:00 om det finns en ny version av EventRunner4.fqa.
Den kommer också att se om det finns en uppdatering om QAn startas om (ex. när du sparar den med nya regler).
Det kan vara praktiskt eftersom det kommer nya buggfixar och finesser allteftersom de upptäcks och behövs.

Ok, slut på del 2. Del 3 blir en genomgång av de kommandon som kan användas i regler.

[RH_Dreambox]

Två frågor om ER4
1) Kan man på något sätt skicka nedanstående kommando direkt från ER4 eller måste jag ha en separat scen eller QA för detta?
Kommamndona går till en tablet med ImperiHome på hallväggen som skulle kunna få mer och bättre funkionalitet då.

Code: Select all

http://192.168.1.16:8080/api/rest/dashboard/wakeup

2) Kan man via en regel i ER4 ändra en annan QA's variabler? Jag har en QA där jag manuellt ändrar status och tider via dess interface, men tanken var att man även skall kunna schemalägga denna QA via regler i ER4.

[jang]

Två frågor om ER4
1) Kan man på något sätt skicka nedanstående kommando direkt från ER4 eller måste jag ha en separat scen eller QA för detta?
Kommamndona går till en tablet med ImperiHome på hallväggen som skulle kunna få mer och bättre funkionalitet då.

Code: Select all

http://192.168.1.16:8080/api/rest/dashboard/wakeup

Ja det ska gå bra.

Code: Select all

rule("@17:00 => http.get('http://192.168.1.16:8080/api/rest/dashboard/wakeup')")

2) Kan man via en regel i ER4 ändra en annan QA's variabler? Jag har en QA där jag manuellt ändrar status och tider via dess interface, men tanken var att man även skall kunna schemalägga denna QA via regler i ER4.

Menar du en QA's quickAppVariabler ?
Isåfall ja.

Code: Select all

rule("@17:00 => fibaro.call(otherQA,'setVariable','VariableName',value)")

[RH_Dreambox]

Tack Jang, det fungerar jättebra att skicka både kommandon och även TTS-meddelanden till ImperiHome's inbyggda TTS-server.
Nu blir det mycket enklare att skicka TTS-meddelanden. Tidigare skickade jag dem till ett separat skript via en global variabel.
Och ja, det är QA'ns egna variabler jag tänker ändra via ER4.
Tummen upp för nya ER4

[jang]

Tack Jang, det fungerar jättebra att skicka både kommandon och även TTS-meddelanden till ImperiHome's inbyggda TTS-server.
Nu blir det mycket enklare att skicka TTS-meddelanden. Tidigare skickade jag dem till ett separat skript via en global variabel.
Och ja, det är QA'ns egna variabler jag tänker ändra via ER4.
Tummen upp för nya ER4

Om du gör det i många regler skulle jag definiera ett event för det. (jag vet inte vilka funktioner du har i imperihome)

Code: Select all

rule("#ImperiHome{cmd='$cmd'} => http.get(fmt('http://192.168.1.16:8080/api/rest/dashboard/%s',cmd))")

rule("@sunrise=> post(#ImperiHome{cmd='wakeup'})")
rule("@sunset => post(#ImperiHome{cmd='goodnight'})")

[RH_Dreambox]

@jang , Tack för tipsen, de funkar utmärkt!
Men nu har jag problem med en regel i ER4. Där skall man kunna schemalägga start av en QA (motorvärmare).
Allt fungerar när jag lägger in starttimma och startminut via separata variabler, men jag vill förenkla tidsinmatningen genom att skriva tex 06:30.
Jag har kollat lite annan kod som du gjort, men den fungerar inte i ER4's miljö.
Kan du ge mig en hint om hur det skall skrivas?

Code: Select all

Starttid = "06:30"
    hour,minute = Starttid('(%d%d) : (%d%d)')
    rule([[@00:00 => 
            || fibaro.call(133,'setVariable','Dep_Hour',hour);
            || fibaro.call(133,'setVariable','Dep_Minute',minute);
            || fibaro.call(133,'setVariable','Heat_Status','Auto');
            || fibaro.call(133,'updateView','btn_standby','text','Standby');
            || fibaro.call(133,'updateView','btn_auto','text','AUTO');
            ]])

[jang]

@jang , Tack för tipsen, de funkar utmärkt!
Men nu har jag problem med en regel i ER4. Där skall man kunna schemalägga start av en QA (motorvärmare).
Allt fungerar när jag lägger in starttimma och startminut via separata variabler, men jag vill förenkla tidsinmatningen genom att skriva tex 06:30.
Jag har kollat lite annan kod som du gjort, men den fungerar inte i ER4's miljö.
Kan du ge mig en hint om hur det skall skrivas?

Code: Select all

Starttid = "06:30"
    hour,minute = Starttid('(%d%d) : (%d%d)')
    rule([[@00:00 => 
            || fibaro.call(133,'setVariable','Dep_Hour',hour);
            || fibaro.call(133,'setVariable','Dep_Minute',minute);
            || fibaro.call(133,'setVariable','Heat_Status','Auto');
            || fibaro.call(133,'updateView','btn_standby','text','Standby');
            || fibaro.call(133,'updateView','btn_auto','text','AUTO');
            ]])

Strängmanipulering är inte ERs starka sida. Jag brukar definiera Lua funktioner som jag använder i mina ER regler.
...men om man anstränger sig, Du vill also dela upp "06:30" i timmar och minuter:

Code: Select all

Starttid = "06:30"
rule([[@00:00 => 
            local time = pack(string.match(Starttid,'(%d%d):(%d%d)'));
            || fibaro.call(133,'setVariable','Dep_Hour',time[1]);
            || fibaro.call(133,'setVariable','Dep_Minute',time[2]);
            || fibaro.call(133,'setVariable','Heat_Status','Auto');
            || fibaro.call(133,'updateView','btn_standby','text','Standby');
            || fibaro.call(133,'updateView','btn_auto','text','AUTO');
       ]])

[/quote]

Vi använder string.match som man gör i Lua. Den returnerar normalt 2 värden. I ER måste vi ta båda värdena och packa ihop dem till en array med första värdet i time[1] och andra värdet i time[2]

[RH_Dreambox]

Strängmanipulering är inte ERs starka sida. Jag brukar definiera Lua funktioner som jag använder i mina ER regler.
...men om man anstränger sig, Du vill also dela upp "06:30" i timmar och minuter:

Code: Select all

Starttid = "06:30"
rule([[@00:00 => 
            local time = pack(string.match(Starttid,'(%d%d):(%d%d)'));
            || fibaro.call(133,'setVariable','Dep_Hour',time[1]);
            || fibaro.call(133,'setVariable','Dep_Minute',time[2]);
            || fibaro.call(133,'setVariable','Heat_Status','Auto');
            || fibaro.call(133,'updateView','btn_standby','text','Standby');
            || fibaro.call(133,'updateView','btn_auto','text','AUTO');
       ]])

[/quote]

Vi använder string.match som man gör i Lua. Den returnerar normalt 2 värden. I ER måste vi ta båda värdena och packa ihop dem till en array med första värdet i time[1] och andra värdet i time[2]
[/quote]

Ja, precis så ville jag ha det. Nu fungerar det att både hantera motorrvärmarens gränssnitt manuellt, eller att schemalägga den i ER.
Stort tack än en gång!

[jang]

Strängmanipulering är inte ERs starka sida. Jag brukar definiera Lua funktioner som jag använder i mina ER regler.
...men om man anstränger sig, Du vill also dela upp "06:30" i timmar och minuter:

Code: Select all

Starttid = "06:30"
rule([[@00:00 => 
            local time = pack(string.match(Starttid,'(%d%d):(%d%d)'));
            fibaro.call(133,'setVariable','Dep_Hour',time[1]);
            fibaro.call(133,'setVariable','Dep_Minute',time[2]);
            fibaro.call(133,'setVariable','Heat_Status','Auto');
            fibaro.call(133,'updateView','btn_standby','text','Standby');
            fibaro.call(133,'updateView','btn_auto','text','AUTO');
       ]])

Vi använder string.match som man gör i Lua. Den returnerar normalt 2 värden. I ER måste vi ta båda värdena och packa ihop dem till en array med första värdet i time[1] och andra värdet i time[2]
[/quote]

Ja, precis så ville jag ha det. Nu fungerar det att både hantera motorrvärmarens gränssnitt manuellt, eller att schemalägga den i ER.
Stort tack än en gång!
[/quote]

Oops, det ska inte vara || framför kommandona i regler. || >>. används som if-then. Bara ett || verkar den tyst acceptera... och på ngt sätt fungera ändå...

[Teddy215]

Hej, Har precis börjat testa mig fram i ER och det går bra!

Men jag har en sån här fibaro button hemma som jag skulle vilja få in i ER är det möjligt?
Kan man använda sig av samma sätt som keyfob?

[jang]

Hej, Har precis börjat testa mig fram i ER och det går bra!

Men jag har en sån här fibaro button hemma som jag skulle vilja få in i ER är det möjligt?
Kan man använda sig av samma sätt som keyfob?

Jag har inte använt en sådan. Fibaros keyfob skickar "centralSceneEvents" när man klickar på knappar. Därav regler som

Code: Select all

rule("keyfob:central.keyId==1 => lamp:on")

Ett centralSceneEvent är en Lua tabell {keyId=<key>, keyAttribute=<attribute} och keyfob:central returnerar den tabellen. Vi plockar ut .key och jämför med 1 etc...
"The button" är jag osäker på om den skickar centralSceneEvent eller sceneActivationEvent.
Du kan prova de här reglerna

Code: Select all

rule("buttonId:central => log('Button skickar centralSceneEvent:%s',buttonId:central)")
rule("buttonId:scene => log('Button skickar sceneActivationEvent:%s',buttonId:scene)")

och trycka på knappen oc se vad som händer. buttonId:scene returnerar bara ett tal, medan buttonId:central returnerar en tabell enligt ovan.
Den ska skicka olika koder beroende på om knappen trycks en eller fler ggr vad jag förstår.
Om det är en sceenACtivationEvent så ser dina regler ut som ex.

Code: Select all

rule("buttonId:scene==1 => lampa:on")

och om det är centralSceneEvent ser de ut som
code]rule("buttonId:central.keyId==1 => lampa:on")[/code]

[RH_Dreambox]

@jang
Har du plockat bort de här funktionerna från ER4?

Code: Select all

rule("@{catch,07:00} => dimmer:dim={300,'up',1,'linear',0,99}")
rule("@{catch,07:00} => dimmer:dim={300,'up',1,'inQuad',0,100}")
rule("@{catch,08:00} => dimmer:dim={300,'down'}")

Det skulle uppskattas om åtminstone "Linear up" och "Linear down" fanns med.
Eller går det att lösa med en fiffig regel istället?

[jang]

@jang
Har du plockat bort de här funktionerna från ER4?

Code: Select all

rule("@{catch,07:00} => dimmer:dim={300,'up',1,'linear',0,99}")
rule("@{catch,07:00} => dimmer:dim={300,'up',1,'inQuad',0,100}")
rule("@{catch,08:00} => dimmer:dim={300,'down'}")

Det skulle uppskattas om åtminstone "Linear up" och "Linear down" fanns med.
Eller går det att lösa med en fiffig regel istället?

Ok, den är tillbaka nu med samma funktionalitet som förr. v0.5fix30
linear,inQuad,inOutQuad,outInExpo,inExpo,outExpo,inOutExpo