ATWindsor

1 hour ago, ZoRaC said:

Min samboer har ingen problemer med å bruke HomeSeer sitt brukergrensesnitt:

Jeg har aldri fått noen klager på brukergrensesnittet fra henne. 

For å være helt ærlig, om man er litt objektiv, så vil jeg si det er ganske åpenbart at grensesnittet på homeseer langt fra er programmets sterkeste side, jeg vil hevde det er ganske dårlig. Betyr ikke at man ikke skal velge det, men det er en definitiv ulempe.

1 hour ago, anaxyd said:

Nå plukker du jo bare av trådstarter sitt innlegg slik det passer deg, han skriver eksplisitt i samme innlegg du plukker fra at det skal være brukervennlig:

 

 

Et annet ønske han kommer med er at det  også skal være enkelt for andre å bruke. Utifra de ønskene kan vi jo ikke anbefale Homeseer, alle er vel egentlige enige om at Homeseer sitt brukergrensesnitt ikke er optimalt. 

 

Hadde han ikke hatt de ønskene, hadde jo muligens Homeseer vært ett bedre valg enn Homey.

Jeg synes for å være helt ærlig, at det er du som gjør det mest, dette er hans utsagn:

Ønsker en fremtidsrettet løsning som støtter "alt" av produkter og som har "alle" muligheter. Samtidig ønsker jeg at det skal være så enkelt og brukervennlig som mulig (enkelt å sette og/enkelt for andre å bruke).

Primære krav: Fremtidsrettet, støtter alt, har alle muligheter

Sekundære krav: så enkelt som mulig innenfor begrensingene av de primære kravene.

Dette er den naturlige tolkningen i mine øyne.

3 hours ago, anaxyd said:

Det er bare å sjekke tallene i Github, så ser du om Python eller Javascript har høyest popularitet.

 

Spørsmålet er hvilke integrasjoner man egentlig savner i Homey, som Hass har. Jeg har pr idag klart å erstatte mitt Hass oppsett i Homey helt fint. Jeg føler Hass har mange integrasjoner, men mange av dem er ikke relevante for meg.

 

Jeg sier ikke at Homey har flere integrasjoner enn Hass, jeg sier at Homey er et sabla godt alternativ som har en veldig bred devicestøtte og bra brukervennlighet. Den beste komboen jeg har sett hittil. Man er oppe og går på 10 minutter etter man har åpnet esken, og det er veldig enkelt å lage og endre automasjoner. Det at Homey snakkes så mye ned her forundrer meg. Homey er jo perfekt for de som ønsker noe enkelt, og som ikke ønsker å bruke unødvendig mye tid på konfig, på lite bekostning av device støtte. Jeg tror folk her bør prøve Homey før man uttaler seg for mye.

Ja, og der er det ca det samme, med javascript på vei ned og python på vei opp...

Ja, i praksis er det det viktigste, for meg er det flere som mangler i homey.

29 minutes ago, Join said:

Hei!

 

Har hus med Schneider KNX. 

Pc med homeseer 3(og lisens til 4)

Hager TH120 KNX ip-interface http://www.hager.no/e-katalog/styringsteknikk/byggautomasjon-knx/knx-system-ets/system-knx-ip-knx-router-og-gateway/54989.htm

Zwave Uzb-stick 

 

Har ikkje ETS, huset er satt opp. Ønsker å bruke homeseer til logisk styring av KNX-delen i huset og å utvide funksjoner og integrasjon mot zwave, zigbee og automatisering. 

 

Ip-interface er kjøpt inn men ikkje kobla til i sikringsskapet. 

 

Korleis går man fram for å opprette kommunikasjonen mellom Homeseer og KNX-nettverket?

 

Og kan man oppdage enheter på nettverket automatisk, eller må alle adresseres manuelt?

 

Med vennlig hilsen 

 

Hei, det finnes en KNX-plugin til Homeseer, men den blir ikke utviklet lenger, så det er ikke det beste systemet for KNX, om det fortsatt kreves en lisens for pluginen kan du få min, jeg trenger den ikke lenger.

1 hour ago, anaxyd said:

Poenget er at det er vesentlig større andel Javascript utviklere enn Python utviklere. Det å komme igang med utvikling av en app til Homey tar ekstremt kort tid, da de har gjort det såppass enkelt å komme igang. Jeg er selv Javascript utvikler, og lagde en Airthings integrasjon til Homey på få kvelder.

 

Så det er redselen for at Homey plutselig skal bli lukket en gang i fremtiden som hindrer deg? Det blir for meg tullete å tenke over. Eksakt det samme kan vel skje med Hass også? Homey er helt avhengig av åpenhet for å overleve, nesten alle integrasjoner er laget av communitiet, og har kildekoden åpen og tilgjengelig på Github. Jeg tror ikke du innser hvor likt Hass og Homey er på akkurat dette.

 

Uansett vil ikke den vanlige mannen i gata gå på med Hass eller Homeseer, de vil velge Homey, Fibaro, Vera osv, da det er mye lettere å komme igang med. Det er realiteten. At man skal begynne å blande inn ideologisk tankegang når man skal foreslå ett system for folk, blir plutselig ganske komplisert.

 

Jeg har ikke noe problem med å anbefale Hass til riktig person, eller Homey til riktig person. Men jeg tror ikke at Hass passer for alle, eller Homey passer for alle. 

Spørs vel hvordan man måler, det er data som viser de er ca likt, pg python er på vei opp og javascript på vei ned også. Det framstår som en rimelig teoretisk fordel, enn så lenge det er mye flere integrasjoner på HA, og python ikke akkurat er upopulært. Langt mer teoretisk problemstilling enn at ting ikke er åpent ihvertfall.

Hva skjer om Homey-bedriften legger ned i dag, eller selger til noen som vil endre det? Hva skjer om det samme skjer med HA? Dette er høyst relevant i praksis, det legges ned ikke-åpne systemer hele tiden (eller de lukkes mer uten at folk kan gjøre noe med det). Jeg tror det er en dårlig ide å ikke vurdere dette.

Jada, folk er opptatt av enkelhet, og dessverre brenner de seg på dette hele tiden. Dette er et problem som ikke forsvinner av å stikke hodet i sanda, virkeligheten er like komplisert på denne fronten uansett om man ikke tenker på det for å gjøre det enkelt.

Det er det vel forhåpentligvis ingen som tror?

4 minutes ago, anaxyd said:

Skal vi begynne å diskutere uoffisielle apper blir dette som sagt vanskelig å sammenligne. Jeg aner ikke hvor mange uoffisielle integrasjoner Hass eller Homey har. Jeg klarte ikke søke opp disse på Hass sin offisielle oversikt, så da må de være uoffisielle hvis ikke jeg har brukt feil søkeord.

 

Hvor har du det fra at det er lavere terskel å utvikle en Python app til Hass, vs en Javascript app til Homey? Har du prøvd det selv?

 

Måten du argumenterer på nå stiller Homey i det lyset at den ikke har støtte, fleksibilitet eller fremtidsrobusthet. Er det korrekt?

Jeg tenker på når smarthus skal bli mer utbredt hos vanlige folk i gata, og da går ikke Hass eller Homeseer. Så ærlige må vi bare være mot oss selv. Da vil Homey, Futurehome osv vinne hardt, da de er så lette å komme igang med, selv om du har 0 kunnskap fra før. Alle her på forumet bør ha interesse av at smarthus blir mer utbredt, for det betyr også flere devices vi kan kose oss med.

Poenget mitt er at jeg ikke forstår argumentet "det er lettere å utvikle javascrip til homey enn HA fordi fordi homey er javascript-basert.", joa, det er det, men det er lettere å utvikle python til HA enn tile homey, fordi det er python-basert. Skjønner ikke helt at det er noe argument hverken den ene eller andre retningen?

Ja, at homey er dårligere på det er det ikke tvil om i mine øyne, det støtter mindre ting, det er mindre fleskibelt, og sannsynligheten for at det går samme retning som utallige lukkede systemer før det er definitivt til stedet.

Det kan nok dessverre være, det går knapt en måned uten at man leser om nok et lukket og enkelt system som går dukken og alle kundene sitter med svarteper, nok et api som er lukket osv. Jeg er ikke uenig i at brukervennlighet er viktig, men skulle ønske folk verdsatte åpenhet litt grann mer. Fragmentering er et enda større problem enn brukervennlighet per i dag spør du meg. Det er en av grunnen til at jeg har et system basert på en åpen standard som har vært støttet i tiår, der alt utstyr garantert funker med hverandre.

Just now, anaxyd said:

Jeg kan ikke finne noen av de du savner i integrations oversikten i Hass heller, eller søker jeg på feil nå? Opplys meg gjerne.

 

Det er korrekt at Hass har mange custom components som ikke er published ja, men sånn er det også med Homey. Mange som installerer ikke publiserte apper på Homey også. Det er fryktelig vanskelig å måle dette.

 

For ett år siden var ikke Homey interessant for meg heller, men det siste året har det virkelig kommet mange integrasjoner, så det kommer seg veldig. Fordelen er at Homey er Node.js basert, og ikke Python slik som Hass. Vesentlig lavere terskel å utvikle en Javascript applikasjon til Homey, enn vice versa med Hass.

Jeg har ihvertfall alle disse, husker ikke om de er offisielle eller ikke.

Er det ikke også vesentlig lavere terskel å utvikle enn python-basert app til Home Assistant? 

Men blir selvfølgelig en prioritering, for meg er støtte, fleksibilitet og framtidsrobusthet viktigere enn at det er enklest mulig (det er mange som har brent seg på ymse ikke-åpne systemer i denne "bransjen"), men andre kan ha andre prioriteringer.

2 minutes ago, anaxyd said:

Ja, nå har Hass 1000+ components/integrations, og Homey har 500+. Så selvfølgelig har Hass bredere støtte. Men når det gjelder device støtte på f.eks Zwave og Zigbee, syntes jeg Homey er like god, om ikke bedre en Hass. Og hvilke integrations savner du på Homey som Hass har?

Hva Homey hadde eller ikke for 1 år siden er irrelevant, vi snakker om her og nå. Hass var ganske forskjellig for 1 år siden det også.

Uten at jeg er helt oppdatert på Homey, så savner jeg personlig Art-Net/DMX, miele@home, grohe ondus feks. Og joda, det er status i dag som teller, men det illustrerer at ting henger litt etter på integrasjoner. Hass har nesten 1500 "godkjente" integrasjoner, og et utall til, antakelig langt flere som ikke er "godkjent".

33 minutes ago, anaxyd said:

Jeg må også supplere ang. Homey generelt.

 

Jeg føler mange her snakker Homey veldig ned. Hvorfor det? Har dere prøvd Homey selv? Eller er det bare rykter dere spinner videre på?

 

Homey har etter min mening en mye bedre Z-wave stack en Hass, siden Hass baserer seg på OZW. Den har ett noe frynsete rykte stabilitetsmessig. Jeg endte faktisk opp med å kjøre en del Fibaro devices på min Fibaro HC2, men som Hass styrte via API. Dette pga. Hass ikke taklet disse godt, det var ganske ustabilt. Men blir tullete når man skal kjøre både Hass og Fibaro HC for at det skal funke.

 

Homey har dårlig Z-wave signal? Det er også et tullete rykte, noe man fort avkrefter når man prøver Homey selv. Homey har etter hva jeg har testet samme range som Fibaro HC2 eller Aeotec Z-stick. "Problemet" er mer at Homey som default gjør secure inclusion, som by design har kort rekkevidde når du includer. Da må du fort ha devicen innen 1-2m fra Homey når du includer.

 

Homey er begrensende? Man får det til å høres ut som man ikke får gjort noe i Homey inne her. Det finnes hundrevis av apper som er gratis, som dekker de fleste behov. Og automasjons-motoren til Homey føler jeg er omtrent like god som Hass sin, og Hass sin må være den beste pga alle mulighetene du har der. Alle som har prøvd den kjenner til hva jeg mener der.

 

Etter å ha prøvd mange forskjellige systemer syntes jeg Homey er helt klart det mest spennende som har kommet på markedet i det siste. Det som er interessant er det gode UI-et kombinert med en veldig bred device-støtte, som gjør at jeg kan bruke mindre tid på knote, og mer tid på å lage automasjoner. Jeg personlig var lei av å knote, og ville bare ha et smarthus som funket, og var lett å endre automasjoner og ting on the fly. Vil jeg har mer fleksibilitet, går jeg bare tilbake til Hass igjen. Men pr nå er det ikke stort jeg savner etter å ha gått fra Hass til Homey.

Jeg vil si device-støtten i homey er vesentlig dårligere enn i feks HA, er jo bare knapt et år siden de støttet KNX feks. Men for all del, det har sin verdi at ting er enkelt også.

Enig i at det ikke er spesielt nybegynnervennlige systemer (hovedproblemet i mine øyne er førstegangsoppsettet, det er overraskende tungvindt å sette opp et grunnleggende system som funker, mens å legge til nye funksjoner synes jeg er ganske greit personlig). 

Men jeg er enig i at man må ta hensyn til "kunden", jeg tror ikke jeg er alene om å ha opplevd at man burde gått for noe mer komplisert som utgagnspunkt, istedet for den "lette løsningen" først og deretter endre ting. Avogtil tror man kanskje i litt for stor grad at det vil skje med andre også.

2 hours ago, Tukun said:

Hvordan lager man automasjoner i yaml uten å kunne noe som helst om det? Jeg vet de har kommet med muligheter til å lage automasjoner i ui'et men dette er meget begrenset. Umulig å lage lange og\eller kompliserte automasjoner der. 

Er virkelig yaml programmering? Jeg vil si det er å trekke det langt, men skal man lage kompliserte automasjoner så vil jeg si det uansett er greiere med et slikt oppsett som er "nærmere programering", man har alltids muligheten for node-red også, om man liker det bedre.

9 minutes ago, Tukun said:

Nei, begge deler er ikke innafor hva som går under begrepet "enkelt og brukervennlig som mulig (enkelt å sette og/enkelt for andre å bruke)".

 

Man trenger ganske mye datakunnskaper i både Homesser og Home Assistant da begge deler krever programmering. 

 

Jeg vil ikke si Home Assistant krever programmering, selv om det absolutt kunne vært enklere. (men det er en fordel å kunne programmere).

22 minutes ago, SveinHa said:

Nope, greit med litt datakunnskaper med HomeSeer også men OpenHAB er på en annen planet i så måte... Du KAN lage f.eks. VBScript i HomeSeer og det er jo et rimelig greit språk (selv om VB er blitt en smule mer avansert enn slik det var tenkt fra starten av) men jeg har klart meg veldig greit med KUN events. Ikke det at jeg ikke kan bruke VB, har brukt BASIC på jobb siden -80 tallet også et par tiår med VB men så langt har standard events gjort jobben helt greit. Da jeg begynte å leke meg med OpenHAB måtte jeg ha MYE hjelp fra OH-forumet for å få til det mest grunleggende som en kaffetrakter-timer.

Enig i at at OpenHAB definitivt kunne vært enklere, men ser ikke akkurat på VB som noe greit språk heller.

16 hours ago, xibriz said:

Hvorfor kommer aldri openhab opp i slike diskusjoner? ?

Fordi ingen har lyst til å velge det om de skal begynne fra scratch igjen?

11 minutes ago, ZoRaC said:

Så lenge du ikke bridger dem så er det to virtuelle interface, ett pr VLAN. Iht RFC, så må IP-adressen være unik og man kan ikke ha samme IP på to interface:

https://tools.ietf.org/html/rfc5889#section-6.2

Så om du har tagged vlan inn til en PC med vlan 20, 30 og 40 så skal den ha en IP per vlan? Hvorfor? Jeg er ikke sikker, men jeg synes det høres ut som du snakker om untagged vlan, jeg snakker om tagged vlan.

Se her feks: https://www.techopedia.com/definition/27008/trunk-port

Begge er på interface 192.168.0.1, ruteren når begge to, siden begge vlanene går tagged inn til den. (eller om du vil bruke fra lenken 192.168.0.0/24)

6 minutes ago, ZoRaC said:

Nei, hvordan vet den det? DHCP-tjeneste vet det, men ikke routeren. Ruting skjer på IP-nivå, ikke Mac-adresse. Så med to nett med samme nettadresse så kan ikke ruteren vite om IPen finnes på interface for VLAN 10 eller 20. 

Nei, men på lag 3, så vet du hva som er ipen, hvorfor er det relevant om det er på 10 eller 20? Du kan nå IPen, da kan du route til IPen?

2 minutes ago, NilsOF said:

Jepp, sånn er det.

Denne headeren er plassert i det utaggede nettet som ligger i bunnen når det går ut fra boksen.

Nei? Untagged har jo ikke en header, derav navnet (og støtter derfor kun et vlan per port) 

1 hour ago, ZoRaC said:

 

Forskjellen er at utstyret på de 2 switchene kommuniserer helt fritt med hverandre, routeren foretar ingen routing, den bare switcher trafikken mellom portene.

 

Med VLAN så tror jeg ikke den bare switcher mellom, siden det er tagget trafikk som kommer inn så ser routeren at dette er to forskjellige "nett". Trafikken må dermed routes og det får den ikke til når begge VLAN har samme subnett. Hvis jeg tar feil og den likevel får til å switche trafikken mellom to VLAN med samme subnett, så er det ingen routing/brannmur mellom dem og alt er helt åpnet (akkurat som med 2 fysiske switcher) - hele poenget med VLAN forsvinner jo da.

 Hvorfor får den ikke til det? Den får en pakke som skal til en ip. Den vet hvor ipen ligger. 

1 hour ago, NilsOF said:

Alle vlan må ha en ren port å "ligge i" når de taes ut av en boks over en patcheport.

Man kan gjerne referere til denne rene porten som untagged.

Jeg skjønner ikke hva du mener. Tagged og untagged har jo I utgangspunktet ikke noe med det fysiske nettet å gjøre? Det er tydelig definert hva som er forskjellen på tagged og untagged. Tagged må støttes av utstyret og har en egen header med informasjon om hvilke vlan den tilhører og støtter flere vlan på samme kobling. 

Just now, ZoRaC said:

 

Ja, men på routernivå så må den lese ett og ett VLAN, altså se det som et virtuelt interface. Routeren må jo nødvendigvis ha en IP-adresse i samme VLAN selv, for at klientene skal kunne kommunisere med den. Så i praksis får den jo da eth0.10 og eth0.20, med hver sin (eller samme, om det er mulig?) IP-adresse.

 

Spiller ingen rolle om du har 2 switcher tilkoblet hver sin port på GW, hvor ene porten er VLAN 10 og andre er VLAN 20 - du kan ikke få ruteren til å sende pakker fra den ene switchen og over til den andre så lenge begge bruker samme nettadresse (192.168.0.1/27).

Ja, den må være i samme vlan, men det er den jo om du kjører alle vlanene tagged in til ruteren. Vlan er jo lag 2. Hvorfor skal routeren gjøre noe forskjell på vlan mtp ip sålenge trafikken når den? 

Tenk to switcher som er helt unmanaged, de støtter ikke vlan. Du kobler begge til routeren. Hva er forskjellen på det og to vlan nettverksmessig? Førstnevnte funker jo fint. 

4 minutes ago, NilsOF said:

 

Er det eksempelet fra Ubiquiti du lenket til over du refererer til?

Freste fort igjennom det. De nevner vlan 100 på to switcher dær de to vlanene på hver sin switch er helt urelatert til hverandre.

I praksis er dette rett og slett farlig å gjøre. Altfor mye kan missforståes .

En glipp og vipps så har man patchet samen to helt urelaterte nettverk.

En switch ser bare taggen (dvs. nummeret) på vlanet. Den vet ikke noenting om hva som er inni vlanet.

 

Eneste grunnen til å gjenbruke vlan-nummer jeg kan tenke meg som er ok er om man vil ha likt oppsett på flere geografiske lokasjoner.

 

Har enda tilgode å plukke på ett Ciscoprodukt som ikke støtter vlan.

Antallet mulige vlan pr. interface har variert.

Jeg referer til tagged vs untagged. Tagged clan Har en egen header og gjør at du kan føre fram mange clan til samme port. Har man untagged er det bare et vlan på porten. 

2 hours ago, ZoRaC said:

 

I Linux-kjernen (som de fleste routere er basert på), så er det virtuelle interface pr VLAN. Si du har ett fysisk interface (eth0), da vil du få ett virtuelt pr VLAN (eth0.10 og eth0.20).

 

Hva gjør du når du trenger å stille klokka på webkameraet du har i VLAN 10 med IP 192.168.0.2 og du har en PC i VLAN 20 med IP 192.168.0.3? Jeg åpner da i brannmuren for at TCP port 80 skal få lov å passere fra PCen sin IP til kameraet sin IP. I ditt oppsett så vil disse to nettene være 100% isolert og umulig å få routet trafikk mellom - verken med eller uten brannmur, siden de har samme nettadresse (192.168.0.1/27 f.eks). 

Selv når du kjører tagged? Snakker ikke om untagged vlan her. Switchen min feks kan kjøre flere vlan tagged per interface. Og rimelig sikker på at det var tilfellet med feks ciscorouterene jeg har sett også. 

I eksemplet så løses jo det som om man har to switcher koblet til routeren? Om man vil kan de ha kontakt?

4 minutes ago, ZoRaC said:

Kan hende det vil fungere i teorien - så lenge VLAN 10 og 20 har samme broadcast domain så kan det hende den klarer å tildele IP fra samme scope. I pfSense, som jeg kjører, så tror jeg ikke det er mulig, for da må to interface ha samme nettadresse. Om du setter det opp slik da, så vil du kunne få broadcaststorms, ustabil kommunikasjon mot ruteren (den sender trafikk til feil VLAN) og du vil heller ikke kunne få trafikk mellom to enheter som står i hvert sitt VLAN (ikke routbart). 
 

Men, nå er vi langt på siden av det opprinnelige spørsmålet som jeg svarte på - nemlig hvorfor man bør ha VLAN i tillegg til forskjellige subnett, i stedet for bare å dele opp nettet i subnett. 

Vel, påstanden min er at (om utstyret støtter det), så er det greiere å legge opp alt dette med VLAN, at man ikke tjener noe på å drive med subnetting, utover å forenkle ting litt for seg selv organisatorisk.

Men igjen, snakker ikke om to interface, snakker om å tagge to vlan inn på samme interface. (og å skille trafikken er jo hele poenget nesten med vlan?)

8 minutes ago, ZoRaC said:

Enig. 
 

Jeg har aldri vært borti DHCP-servere hvor man kan bruke samme scope mot to interface...

 

 

Et tagget VLAN er ett interface, så VLAN10 og VLAN20 er to forskjellig interface (på én kabel). Jeg tror ikke du kan konfigurere DHCP-serveren til å bruke samme scope mot begge disse interfacene, dermed må du jo ha to identiske scopes i så fall. 
 

Ble litt usikker på om ARP kanskje vil klare å holde orden på hvilke adresser som er i bruk på hvilket interface (for routing), men det tror jeg vil være veldig varierende fra router til router. DHCP tror jeg den vil slite med, om du da ikke har en DHCP-server som kan betjene flere interface. 

Mulig jeg ser på dette "for enkelt", men sånn jeg ser det så bestemmer vlan hvilken pakke som slipper igjennom, om pakke X kjøres over en kabel med vlanet den er på, så kommer den igjennom, om ikke så kommer ikke pakka igjennom. Så en maskin på vlan 20 da ( i eksmeplet over) sender dhcp-discover, den når fram til ruteren, de forhandler, og ruteren sender beskjed til maskinen hva slags adresse den skal benytte. Senere tar en maskin på vlan10 å gjør det samme, og pakken kommer igjennom (siden både vlan 10 og 20 er kjørt fram), og ruter/dhcp-server mottar pakka, og bare kjører forhandling på samme måte. At det er et lag2-hinder som gjør at de to maskinene ikke ser hverandre er irrelevant for ruteren, den mottar dhcp-discover pakker som vanlig, bryr seg ikke om virket vlan det kommer fra, og deler ut, uten å gi samme ip til forskjellige mac-adresser?

Det er ihvertfall sånn jeg tenker det funker i mitt hode. Men er ikke det riktig?