Gå til innhold
  • Bli medlem

gert

Medlemmer
  • Innholdsteller

    25
  • Ble med

  • Besøkte siden sist

Nettsamfunnsomdømme

6 Neutral

Om gert

  • Rang
    Nybegynner

Hjemmeautomasjon

  • System
    Annet
  1. Det bør ikke være noe problem å kjøre HA på rpi via wifi, så lenge du har en oppegående ruter og godt signal. Men vær OBS på at Yale er noen kjipe drittsekker, og at du ikke får styrt Yale fra HA via zigbee fordi de kun lar Yale-låsen snakke med produkter fra firmaer som betaler dem penger.
  2. Har du testet hvilke kommandoer den sender når den er bundet direkte til en gruppe? Jeg vurderer å bruke en som "hovedbryter" ved utgangsdøra, og binde tre av knapperekkene direkte mot grupper med lys, slik at de fungerer selv om HA-hjernen er nede. Regner med på og av sender on/off-komnandoer, men hva slags dimmekommandoer sender den egentlig? Dimmer den en gang per langtrykk med en viss %? Dimmer den så lenge du holder knappen nede (med brightness_move og brightness_stop)?
  3. Takk for tilbakemelding! Jeg trenger det ikke lenger (gikk ikke for Sonos RF Bridge), men kudos for oppdaterng likevel.
  4. Har du en lenke til instruksjonene? Portisch har en utdatert lenke til tasmotas wiki som bare videresender meg til prosjektsiden på github, og alle lenkene hos tasmota jeg finner, går til Portisch igjen. Vurderer Sonos RF Bridge i stedet for RFLink opp mot HA. Vurderer riktignok også om det er noe poeng å ha 433Mhz-støtte, da det finnes alternativer for det aller meste, selv om det blir noe dyrere.
  5. Hm, det er en interessant tanke. Det kan godt hende at det som skjer på gpio-pinnene er enklere å koble seg på. Om noen har en dongle og har lyst å se om den er enkel å åpne for å ta bilder av innmaten, er det veldig velkomment. Samme hvis noen kan sniffe trafikken med wireshark, som du nevnte. Dette er ikke et spørsmål om problemer med kompabilitet, Yale har bevisst sperret for bruk.
  6. Noe nytt som har skjedd her? Noen som har forsøkt å sniffe trafikk mellom hub og modul , eller forsøkt å jente ut firmware og nøkler fra hub eller modul? Vvis løsningen er selvlaget, tviler jeg på at den er feilfri, og med fysisk tilgang til både modul og hub burde det være mulig for noen med tilstrekkelig tid og kunnskaper å få til noe selv med en godt implementert løsning. Men det er vel kanskje mindre sannsynlig at det skjer med en ren skandinavisk løsning. Ranter litt i samme slengen: Og det blir ekstra tydelig når man kan kjøpe deres dyre og dårlige hub, som uansett krever skytilkobling, og bruke innloggingsdetaljene til dere eller Verisure sin sky i eget hjemmeautomatiseringsopplegg, noe som tilfører tre åpenbare usikkerhetsmomenter - Yale sin hub. De har neppe god nok kompetanse til å ettergå sikkerheten selv, og har sannsynligvis valgt leverandør pimært på bakgrunn av pris. - Yales skyløsning (Regner med de, som Verisure, kjører det? Eller tar huben deres den oppgaven?). Ingenting er sikkert,. - Brukerens egen implementering av lagring og bruk av innlogginsdetaljer/tokens hos Yale/Verisure, som nær sagt uansett hvilken praktisk løsning man går for, vil være mindre sikker enn en direkte tilkobling til zigbee-modulen. Hadde de hatt en snev av ærlighet og kundevennlighet hadde de i det aller minste åpnet for statusmeldinger til en hvilken som helst zigbee controller. Jeg har ikke noe stort behov for å låse døren opp eller via noe system, men jeg vil gjerne ha statusmeldinger fra den som jeg kan bruke. Har jeg låst døren med vinduer åpne? Kobler mobilen min fra wifi-nettverket uten at døren er låst? Trigges tamper sensor? osv. Skal jeg få noe av dette, må jeg betale 1500kr, og med på kjøpet får jeg dårligere sikkerhet, en fjernopplåsningsmulighet jeg ikke ønsker som attpåtil er i hendene på en tredjepart i dennes lukkede system, og en boks som trenger både strøm og ethernet og som ikke tilfører noe av verdi over hodet. Stort sett veldig fornøyd med den fysisk sett, altså, men dette ER for dårlig.
  7. Så lenge det ikke er snakk om et dimmerhjul, kan jeg like gjerne holde meg til dimmebryterne fra Ikea. Men sikkert kjekt for de som vil ha noe inne i eksisterende Elko-bokser.
  8. Ja, men det er ekstra irriterende når man vet at løsningen hadde fungert utmerket i et annet oppsett/system/språk
  9. Irritasjonsmomentet med ting som Node Red (og i og for seg andre språk eller configs enn man kan fra før) er at man må finne ut hvordan man gjøre noe som i eget hode burde være veldig enkelt. I Node Red er det jo spesielt mangelen på å hente inn info som ikke er i den eksisterende loopen som er håpløst fraværende (virker det som). Conditions i en flow som f.eks. trenger info om noe fra utenfor flowen er jo håpløst å implementere. I pseudokode kunne man skrevet noe som When motion.sensor state=true If lux.sensor < 150 and away.state=true Men i node red vil motion.sensor gi deg en output som bare kan sendes videre, og å hente inn andre parametere er så klønete at det i praksis ikke virker gjennomførbart, ettersom blokker kun kan ha én input. Googlig tyder ihvertfall på at folk ofte gir opp å gjøre sånt i node red. Men funket fint for Ikea-sonos-hjulet, da. En liten update om hjulet forresten: Om det ikke er brukt på en stund, vil det droppe tilkoblingen til nettet og bruke merkbart lang tid på å koble seg til igjen. Det kan nok være irriterende om det er primærbryter. Men Etter å ha vært i daglig bruk en stund nå, har jeg blitt veldig godt vant til Ikea av/på-bryteren. Kanskje det beste bare er å venne seg av med dimmehjul.
  10. Veldig enig her. Irriterer meg støtt og stadig når jeg er ute etter enkle løsninger på tekniske ting og de ti første treffene er 10minutter lange videoer der 4 av dem er en håpløs intro. Semiapropos mangel på skriftlig ifnromasjon, jeg så noen nevnte esphome her. Jeg har tenkt før at jeg skulle gå over fra Tasmota til esphome på et Deltaco grenuttak, og ble glad da jeg så de hadde en "Migrating from Tasmota"-guide som starter med ordene "Migrating from previous Sonoff Tasmota setups is very easy". Deretter viser det seg at den ikke inneholder NOE om å faktisk migrere en Tamota-installasjon utover "First follow the guides for the different supported devices and create a configuration file." som knapt inneholder noen enheter og gir deg NUL brukbar veiledning i å faktisk lage en konfigurasjonsfil basert på en eksisterende tasmota-installasjon. Den kunne knapt nok vært mer urbukelig, eller mindre brukervennlig, om de hadde gått helhjertet inn for det. Tasmota, derimot, gir deg en binary og sier "Flash denne, og lim inn denne tempaten her etterpå." Også har de faktisk templates til "alt". @stigvi akkurat kjøkkenbiten løste seg veldig enkelt med en automation, men jeg trenger nok AppDaemon til senere, jeg skal bla. skru på strømmen til et webkamera dersom bevegelsessensoren i gangen merker bevegelse mens jeg ikke er hjemme. Så om du har lest noen mer utfyllende guider enn tutorialen på home assistant sine sider, tar jeg gjerne imot tips.
  11. Må innrømme at jeg synes YAML er rimelig håpløst, og ikke skjønner hvorfor de ikke heller ar gått for noe mer fungerende som js eller pyhon. Men har du noen guider å anbefale? Jeg ser jo at det hadde vært hensiktsmessig å kunne gjøre mest mulig "native" i HA eller z2m, uten å måtte blande inn flere verktøy enn nødvendig. Node red har jo også en del relativt store begrensninger når det gjelder conditional actions. F.eks. er jeg ute etter å skru av kjøkkenlyset når bevegelsessensoren ikke viser bevegelse lenger, men ikke skru det av hvis det ble skrudd på manuelt. Node red har ingen god støtte for å kun kjøre flower hvisomatte dersomatte.
  12. Jada, joda, det kan sikkert være det fungerer ofte. Men mår halvparten av lampene har mer enn en pære, og jeg har hatt problemer flere ganger (riktignok ikke med nyere zwave-dimmere) har jeg lært av både egne og andres erfaringer: Brent barn skyr ilden osv.
  13. Jeg lekte litt rundt med en Ikea Symfonisk trådløs bryter for å se om denne kan brukes som dimmehjul. Gode trådløse dimmehjul vokser jo ikke på trær. Spoiler: Ja, det går, og de er slett ikke verst. Bryteren parer fint, og sender (under zigbee2mqtt) kommandoene rotate_left, rotate_right og rotate_stop, så lenge den roteres til venstre/høyre eller når den stopper. I tillegg sender den brightness- verdier, men jeg valgte å ikke benytte meg av disse. Årsaken til det er tredelt: 1: Dimmingen blir ikke jevn. 2: Brightness-verdiene går ikke opp til 250 eller ned til 0. Man vil kunne dimme opp fra avslått tilstand, men ikke kunne skru av igjen på samme måte, uten å kludre en hel del med oppsettet. Og 3: Jeg liker ikke dimmebrytere man skrur på og av ved å vri, jeg liker å gjøre det med trykk. Av oppsett i z2m, har jeg kun lagt inn "debounce: 0.1" som device option. Årsaken er at hjulet sender ut VELDIG mange kommandoer, det er ngen grunn til å håndtere alle. Det er også viktig at bryteren ikke er i samme device group som en pære, da den sender brightness-verdier som pæren antakelig vil plukke opp. Selve funksjonaliteten styrer jeg med en node red flow. Det kunne sikkert vært gjort med an automation også, men HA-syntaksen orker jeg bare ikke å sette meg mer inn i en nødvendig akkurat nå. Kjapp forklaring: Nederst er det ganske enkelt en switch som slår lyset av/på når dimmeren sender play_pause-kommandoen. Det er en musikkfjernkontroll, tross alt. Ellers lytter den etter rotate_left, rotate_right og rotate_stop-kommandoer, og ber pæren dimme ned/opp med brightness_move 85 oppover og -85 nedover eller stanse dimming med brighness_move "stop". Årsaken til reset-boblene er å unngå å sende en brightness_move-kommando til pæren hver gang bryteren sender en roate-event, dette ville ført til mye unødvendig spamming av zigbee-nettverket. Nå vil flowen kun sende en brightnes_move 85-kommando og deretter ikke sende flere før den har sendt en annen kommando. Det er den første node red flowen jeg har laget, og det kan godt hende dette kunne vært løst mye mer elegant, men her er den likevel: Selve dimmehjulet har ikke direkte premiumfølelse. Trykkbryteren ligger inn mot midten av ytterlokket, og bryteren kan derfor vandre eller vippe litt mot hver kant. Jeg synes heller ikke det rent kosmetisk sett er superpent med fingerfordypingen, men det ser faktisk helt ok ut - men det er en annen grunn til å ikke ruke brighntess-verdier til dimming. Man vil gjerne forvente at dimmerlevel er lik når bryteren står i samme fysiske identifiserbare posisjon, det får man ikke med denne bryteren. Jeg har fortsatt litt lyst å teste en Elko RF slavedimmer, men en tudenlapp for noe som kanskje ikke fungerer (spesielt) bra sitter litt inne. Men dette er en fullt fungerende dimmebryter med oppsettet over, og til prisen er det vanskelig å ikke like den.
  14. Z-wave-dimmere gir et også mareritt av inkompabilitet med pærer siden det ikke finnes noen fungerende standard for dimbare led-pærer som ikke gir problemer med flimring, brumming og diverse, selv når man kjøper pærer av samme merke og modell som man hadde sist. Øyet som ser. ? Jeg har gått over til all elektronikk i pærene, og kommer neppe til å g å bort i fra det.
  15. Nå får man kjøpt 3d printete "utenpå-blindlokk", og jeg hadde nok lett gått for disse om jeg hadde begynt nå. Men med litt hjemmemekking av vippestykker fra Elko, ser resultatet slik ut: Den originale rammen har gulnet mer, men, men. Den sitter godt når man trykker på den, men den er fullt mulig å ta av ved behov. Så langt har jeg ikke hatt behov for noen fysisk bryter de seks årene jeg har hatt trådløs bryter til stuelampen, og regner med å ikke trenge det nå heller, men går likevel for å ha fysisk bryter i reserve. Dvs. få elektriker til å bytte to dimmere med bryter, og sette slike lokk utenpå der også. Fremfor å direktekoble de øvrige punktene og bygge en zigbeefjernkontroll inn i veggboksen. Det blir litt corny med en løsbryter festet utenpå blindlokket, men det er ihvertall mye bedre enn å teipe fast bryteren i på-posisjon og ha en annen kontroll over Men jeg skal innrømme at når man kikker på vippestykket før det settes på plass, DA ser det ikke spesielt proft ut... Mulig jeg går 3d-printede deksler på de to jeg har igjen, selvom jeg har flere vippestykker liggende.
×
×
  • Opprett ny...