Utveckling av RAXA, öppet hemstyrnings och automation system

[Pajn]

Jag har tidigare utvecklat en webbaserad applikation för att styra belysning i hem,
http://elektronikforumet.com/forum/view ... 13&t=66288 Dock var det en del problem, dels är det väldigt bökigt
att dra igång. Men framför allt har det ingen central punkt utan delar körs endast
vare gång sidan laddas vilket skapar problem vid t.ex. automatisering.

Därför vill jag börja om med nått som är mer genomtänkt från grunden och blir lättare
att arbeta med. Något jag ser idag när man bygger nån typ av automatisering hemma
är att det alltid grundar sig i ett stängt system, vilket jag tycker är väldigt tråkigt.
Därför skulle det vara kul att skapa ett öppet alternativ.

För att lyckas med en lösning som passar för flera behövs det input från flera håll och
därför vill jag driva utveckling på ett sånt sätt att alla kan kommentera och bidra.
Förhoppningsvis finns det tillräckligt många intresserade på detta forum för att det
ska kunna bli något bra

Jag har börjat lite smått på en server i Java och försöker nu få till en bra grund som
är lätt att bygga vidare på. Som utgångspunkt har jag skapat en hierarki med
interface för att föröka hitta så många gemensamma punkter som möjligt i varje
steg i djungeln av enheter som man skulle vilja ha in. Just nu ser den ut såhär
men ska såklart utökas vartefter. Dock vill jag inte slänga på för mycket på
en gång så det finns massor med tomma utan vill utöka dessa lite försiktigt i takt
med utveckling av plugin och gränssnitt.

Servern i sig ska inte göra jättemycket utan stöd för olika enheter kommer bestå
av plugin. Och gränssnitt mot användaren kommer antingen också vara plugin eller
helt externa klienter.

Plugin som jag håller på med just nu är stöd för Tellstick, samt Nexa och kommer
först och främst utökas med främsta anledning att ha något att testa med. Här
är ett klassdiagram med på dessa plugin för att ge en ide om hur plugin skrivs
http://yuml.me/d333da33 Som ni ser implementerar man helt enkelt bara de
interface som passar bäst för enheten. Som ni också ser har jag inte kommit till
att kunna ta emot signaler än.

Gränssnittsmässigt är jag på en del punkter väldigt nöjd med "förra versionen av
RAXA" så jag kommer troligtvis att återskapa nånting liknande.

Är det några som har tankar eller funderingar redan nu så är det såklart väldigt
kul. Jag ska försöka få upp en demoversion av "gamla RAXA" för att höra vad
andra tycker om gränssnittet då jag är lite sugen på att börja med det för att
kunna testa lättare.

Puh vad mycket text det blev. Hoppas att någon orkade ner hit

[Lennart Aspenryd]

Visst orkar man de!
Att läsa om slika projekt är gott, men sedan att ta tag i det är en annan sak.
Jag har nog inte gett mig tid att koppla upp ett antal Nexa enheter.
Men jag följer din väg, och sänder länk till en som är intresserad till Max.

[Glenn]

Klart intressant, jag har samlat på mej ett antal nexa och andra brytare (mest uttagsmonterade men även en del dosmonterade) som njag tänkte styra centraklt, men har inte riktigt tagit tag i det där.

[blueint]

Skulle valt ett språk som kräver mindre hårdvara än Java. Det riskerar att bli slött och få en massa garbage-collection samt exceptions.

[Pajn]

Kul att det finns intresse

Ang. språket som jag funderade på rätt länge innan jag började så har jag svårt att
se ett bättre val p.g.a.
Java går att köra på allt som har en JVM, vilket är ganska mycket. Rent
prestandamässigt är det få språk som är så portabla och samtidigt slår Java i
prestanda (nu räknar jag med en bra JIT som t.ex. Oracles). Sen är det ju så att
prestandan beror mer på hur koden är skriven än språket i sig
Hur Java hanterar Exceptions ser jag också som en fördel då det blir lättare att
ta hand om felen än i språk som gömmer dem.

[Lennart Aspenryd]

Kör på. Det är inte läge att fundera på det snabbaste systemet utan det som man kan och är flexibelt. dvs går att köra i olika Os.
Sedan behövs bra beskrivningar. Dels hur man bygger upp nomenklaturen och definitioner över vad man kan göra.
Så skal det till scenario där ett antal cases beskrivs.
Förutsättningar och så här gör du!

Då kommer flera att kunna testa och för projektet framåt.

[Pajn]

Nu har jag satt upp en demo av den äldre versionen som går att nå på http://demo.raxa.se
Tyvärr ansluter datorn som kör det genom en riktigt kass brygga så det går tyvärr
toklångsamt Jag stänger även av datorn på natten då jag vill ha mörkt och tyst.

Personligen gillar jag upplägget med karta och snabb åtkomst till scenarion. Skulle
dock vara kul att få lite input och kanske även om det finns demon på andra system.
Det är så lätt att bli hemmablind

Saker som dock måste fixas i en ny version är:
Responsiv design som funkar bra ner till telefon, men gärna uppåt också.
Enheter måste synas direkt även innan något rum är valt.
Måste skala till olika antal våningar.

Vad händer om man inte har någon karta?

Jag funderar även lite på hur händelser ska fungera och hur systemet ska hantera
t.ex. knapptryck. Är det någon som har bra exempel på detta eller kanske några
användarfall som man kanske inte tänker på?

Vad som har hänt sen sist är framförallt:
En restserver som hittills kan CRUD:a enheter, köra dem (exekverbara enheter) samt
lista medlemmar (grupper).
Ett smidigt sätt att lägga till egenskaper och åtgärder på enheter som även stödjer
multipelt arv (så att en enhet t.ex. kan vara både utgång och ingång eller liknande).

[Lennart Aspenryd]

Ser riktigt bra ut. Håller med om att scenarios är rätt.
Det är ju en funktion man är ute efter.
Jag ser fram emot att få en möjlighet att testa.

[Pajn]

En liten uppdatering. Jag har nu skrivit om det hela i Dart. Detta för att jag hade lagt mycket tid på att fundera på hur jag ska få det att fungera bra med många olika enheter och mindre tid på implementation och kände därför att det är bäst eftersom jag kan ta med mig de5 som var bra och tog tid så jag förlorar inte så mycket. Att det blev Dart beror på att det kändes som att jag motarbetade Java genom att köra mycket reflection eftersom jag behöver mer dynamik. Dart passar då bättre därför att det går att ha det statiskt när det är bäst och dynamiskt när det krävs. Dessutom kan jag dela kod på server och klientsidan vilket alltid är uppskattat.

Just nu kan plugin installeras och startas dynamiskt och jag har till stor del crud på inställningar, enheter, enhetsklasser, interface och plugin. Enheter implementerar interface för att beskriva sin funktion (som i framtiden är så självbeskrivande att klienter inte behöver ha stöd för dem för att visa kontroller för). Plugin kan ha egna interface och det är också så plugin pratar med varandra, vilket gör att ett plugin för Nexa kan använda vilken 433MHz sändare som helst bara den implementerar interface för att skicka ut en egen puls.

Just nu funderar jag på hur jag ska lösa våningar, rum och scenarion. Våningar och rumfunder jag på att inte ha stöd för i server utan bara ha grupper som användaren kan lägga upp för rummen och våningarna eller på något annat sätt om hen vill. Scenarion är dock svårare, ska jag ha specifikt stöd for de eller nått mer generellt? Finns det andra use case, finns det use case för plugin att skapa egna typer av liknande upplägg? Scenarion kanske bara ska vara grupper som implementerar ett interface?

[robertholmberg]

Hej,

Det är lovande, tyvärr kan jag inte bidra så mycket men kommer följa ditt projekt och håller tummarna för att det inte ska bli några större svårigheter.

Försökte dock kolla in på din demosida och fick då ett fel:

You are accessing the server from an untrusted domain.
Please contact your administrator. If you are an administrator of this instance, configure the "trusted_domain" setting in config/config.php. An example configuration is provided in config/config.sample.php.

/Robert

[Pajn]

Den datorn har fått lite andra uppgifter sen jag skrev sist. Jag har inte möjlighet att
fixa den nu men tog en screenshot på den för vårt hus istället (vill inte dela ut den
adressen eftersom andra här i huset kan bli lite griniga om det blinkas i lamporna).

Planen för gränssnittet nu är att göra widgets (lite som Androids hemskärm) som man
kan placera ut på sidan. Detta är vad jag bäst kommer på för att stödja olika antal
våningar samt utan karta alls. Layouten i bilden skulle då alltså bestå av:
2st Kart-widgets
1st Enhetslista-widget
1st Scenariolista-widget

Jag har nu börjat lite smått på det nya gränssnittet men har inget att visa upp än.

[toffie]

Snyggish! Som ovan, har inte så mycket att bidra med, men följer tråden sen tidigare

[Pajn]

Nu finns ett tidigt gränssnitt för att ändra enhets-inställningar och skapa enheter.
Gränsnittet skapas dynamiskt utifrån manifest-filer för enhetsklassen. Ett exempel
för Nexa Code Switch

Kod: Markera allt

name: NexaCodeSwitch
plugin: Nexa
config:
  sender:
    type: deviceId
    interface: 433MHzPulse
  house:
    enum:
      - A
      - B
      - C
      - D
      - E
      - F
      - G
      - H
      - I
      - J
      - K
      - L
      - M
      - N
      - O
      - P
    value: A
  device:
    enum:
      - 1
      - 2
      - 3
      - 4
      - 5
      - 6
      - 7
      - 8
      - 9
      - 10
      - 11
      - 12
      - 13
      - 14
      - 15
      - 16
    value: 1
implementedInterfaces:
  - Lamp
  - Sync
requiredInterfaces:
  - 433MHzPulse

Vilket ger en inställningsskärm där man kan välja vilken enhet som det skickas ifrån
samt hus och enhets-kod (allt med dropdown, deviceId är en specialtyp som hämtar
alla enheter som impellementerar specificerat interface och presenterar dem i en
dropdown med namn).

Interface är hur gränsnittet kommunicerar med enheter samt plugin mellan varandra,
ett exempel på ett interface är DimLevel (som implementeras av Nexa Dimmable SelfLearning):

Kod: Markera allt

name: DimLevel
methods:
  level:
    arguments:
      level:
        type: integer
        maximum: max
        minimum: min
status:
  level:
    type: integer
    maximum: max
    minimum: min
variables:
  max:
    type: integer
  min:
    type: integer

DimLevel specificerar alltså en metod som tar ett argument (en int med ett maxvärde
och minvärde), en status och två variabler.
Metoder är saker som kan kallas, metoder utan argument (på, av) representeras av en
knapp medans en int med max och minvärde t.ex. kan representeras av en slider.
Status är som det låter statusen på enheten, även här specificeras ett max och minvärde
vilket gör att den t.ex. kan presenteras som en progressbar istället för bara en siffra.
Variablerna specificeras av enhetsklassen (för Nexa Dimmable Selflearning är det 0 till 15).

Detta ger ett system som bör vara väldigt flexibelt men ändå tillräckligt självbeskrivande
för att gränssnitt inte ska behöva stödja vara specifikt interface (även om de såklart kan
välja att göra det för en bättre integration).

Som ni kanske ser har jag inspirerats mycket av JSON schema och kommer även att använda
det för att validera manifest, restanrop, databasobjekt och liknande (det är mycket som använder
JSON )

[Pajn]

Vad som hänt denna vecka:
Jag har gjort en enkel EvenBus där meddelanden broadcastas till alla lyssnare, b.la.
WebSockets Api:et eller alla plugin. Jag vet inte om den kommer bli mer avancerad
i framtiden, det beror på om det kommer att krävas eller inte.
Det gör att om man ändrar, skapar eller tar bort en enhets så uppdateras det
direkt hos alla som har sidan uppe. Samma bus kommer även att användas för att
ta emot temperatur och liknande så att den uppdateras i realtid.

Jag har även sett till att fixa testerna (lät de släpa efter då det var så mycket
ändringar ett tag) samt gjort några nya. Nu finns även en CI som kör testerna för
varje push så att koden hålls i ett bra skick https://travis-ci.org/Pajn/RAXA.

[Pajn]

Liten update igen.
Nu finns det stöd för positioner. En position kan antingen ligga på top level eller
under en annan position. Det gör att man kan sortera upp i bara rum, våningar
och rum eller i ännu fler steg om man nu vill det. En enhet kan bara befinna sig i
en position.

Scenarion har jag kommit fram till (efter lite diskussion med andra) att de passar
bäst i en externt Plugin som vilken enhet som hellst, så de är implementerade så
nu. Däremot har gränssnittet specifikt stöd för scenarion och visar de som egna
då jag som användare inte tycker att ett scenario är en enhet.

Testmässigt har jag utökat med E2E tester som startar servern och sen gör anrop
mot APIet. Detta ger flera fördelar, dels så testas stora delar av servern eftersom
det är så många berörda delar, dels så vet jag om API breakage introduceras och
som en extra bonus kan även testerna läsas för att se hur APIet ska användas.

Jag vill även skapa plugin för enklare automation (Timers samt reaktion på ingångar
(att en fysisk knapp tryckts på eller skymningsrelä tycker att det blev mörkt)) samt
ha anpassade gränssnitt för dessa för att göra de enkla att använda även för icke
teknikintresserade. Längre fram ska det gå att göra program i from av logikscheman
för mer avancerad automation men dessa kräver av naturliga skäl mer av användaren.

Är det fler saker än Timers och Ingångsevent (bra namn någon?) som bör finnas?