ATWindsor

Evig er optimistisk å forvente, men man kan gjøre vurderinger av hva som er sannsynlig å være varig, og hva som er mindre sannsynlig.

Altså, admin-grensesnittet er ikke bra det heller, men snakker om brukergrensesnittet.

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.

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.

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.

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.

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?

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.

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.

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".

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å.

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.

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

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

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

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)

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?

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

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

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.

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.

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.

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?