Vinnerliste

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.

@Mrodseth du kan jo nevne at du aller helst vil ha dingsene Zigbee v3 sertifisert ? Om alle gjør det så vil det sive inn hos leverandørene at vi vil ha standard dingser og ikke noe annet rart. Forøvrig, status Elko: https://zigbeealliance.org/zigbee_products/?product_type=certified_product&se=Elko

Ja, fullt klar over at man må åpne for å montere. Det skal nok gå bra. Er jo ikke helt ny. Ble jo kjøpt i fjor. Vell og merke etter at sesongen var over, men men. Kortet som ble bestilt skal fungere med Smart klipperene, og Gardena sin egen app vil fortsatt fungere parallelt. Det som fikk meg til å handle var muligheten å kunne resette alarmer via Robonect. Så hvis den blir stående i en skråning eller får en lift alarm pga et hull. Så har man mulighet til å resette og starte den på nytt. På gardena så får man bare beskjed, og så må man på klipperen å taste kode for å fikse det(har jeg lest).

Bare en liten justering på noe som allerede er automatisert. På garasjeportåpneren har jeg nå mange forskjellige alternativer for å åpne den og etterhvert har jeg endt opp med å mene at det har blitt for lett. Blandt annet har både kona og jeg en widget på telefonen for å åpne og det er jo bare et uheldig trykk der som skal til. Det nye er at alarmen på huset må være avslått for at porten skal være mulig å åpne. Er alarmen påslått, så vil den ikke åpnes. For å få til dette så blir sjekk av alarmstatus gjort på den ESP32 som styrer releene og som står ved åpneren. Jeg bruker EspHome og en det ble en smal sak å ta alarmstatus inn og legge inn en ekstra sjekk på den aksjonen som trigger åpnereleet. Og så trenger jeg ikke lenger tenke på at kona når hun dobbeltrykker på mobilens skjerm for å slå den av, er et dobbeltrykk på en viss widget. text_sensor: - platform: homeassistant id: alarmstatus entity_id: alarm_control_panel.hjemmealarm cover: - platform: time_based name: "Garasjeport" id: garasjeport has_built_in_endstop: true #icon: "mdi:garage-open-variant" open_action: - if: condition: lambda: 'return id(alarmstatus).state == "disarmed";' then: - switch.turn_on: gararasjeport_opp - delay: 0.5s - switch.turn_off: gararasjeport_opp else: lambda: 'id(garasjeport).publish_state(COVER_CLOSED);' open_duration: 16s

1. Som med så mye annet betyr ikke størrelsen noe. Har du nytte av Home Assistant vil du også ha nytte av HomeSeer. 2. Sant nok, men det er mindre enn en måned til 50% salg i mai.

Ville også vurdert HomeSeer.

Jeg ville sagt det var motsatt...

Oppdatering til RobonectSeer nå klar! Akkurat i tide til våren.

Okey, det virket ikke sånn i det hele tatt ettersom du påpekte at du brukte Siri på mobilen for å slippe å måtte rope inn til HomePodden. Ser mer ut som om du prøvde å si Siri > Alexa, enn et forsøk på humor. Hadde du latt være å nevne Siri - da hadde det vært litt humoristisk skal jeg være enig i

Link? Edit: linken var der oppe frå før... ? Edit 2: utført.

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.

På Home Assistant som er ved aggregatet er det vesentlig dette: mqtt: broker: 10.0.0.181 username: mqtt password: KW7.... mqtt_statestream: base_topic: ventilasjon publish_attributes: true publish_timestamps: true Dette publiserer alle dens sensorer. På mottaker er det dette: # Sensors sensor: - platform: mqtt name: ventilasjon time_online unit_of_measurement: hours state_topic: "ventilasjon/sensor/time_online/state" - platform: mqtt name: Outdoor temperature unit_of_measurement: °C device_class: temperature state_topic: "ventilasjon/sensor/outdoor_temperature/state" Dette tar i mot utvalgte data. Jeg ville ikke ta i mot alt. For å styre ventilasjonen så er det laget noen mqtt "switch" i hoved HA som dette: switch: - platform: mqtt name: "Heru Alarm reset" state_topic: "ventilasjon/switch/alarm_reset/state" command_topic: "ventilasjon/switch/alarm_reset/set" payload_on: "on" payload_off: "off" - platform: mqtt name: "Heru Away mode" state_topic: "ventilasjon/switch/away_mode/state" command_topic: "ventilasjon/switch/away_mode/set" payload_on: "on" payload_off: "off" Og ved aggregatet noe automasjon for å ta i mot dette: - id: alarm_reset alias: Alarm reset description: '' trigger: - payload: 'on' platform: mqtt topic: ventilasjon/switch/alarm_reset/set condition: [] action: - entity_id: switch.alarm_reset service: switch.turn_on - id: away_on alias: Away mode on description: '' trigger: - payload: 'on' platform: mqtt topic: ventilasjon/switch/away_mode/set condition: [] action: - entity_id: switch.away_mode service: switch.turn_on konf.yaml