stigvi

Elimportøren og Kjell & Company har, men de har ikke samme utseende som Elko (noe som ikke er et krav hos meg, i alle fall) En trenger ikke nødvendigvis å bruke smartpærer med rgb hvis en føler det masete. Uansett slipper en flimremaset med dimmere som ikke helt er kompatible med lysteknologien....... Edit: For ikke å snakke om problemstillingen hvis det dukker opp pærer med enda lavere strømforbruk som dimmerene ikke takler. Da røyk den investeringen og det er bare å begynne på nytt med å skifte ut utstyr

Jeg vil jo tro du vet det finnes zigbee brytere og de kan også knyttes opp til lyset direkte slik at det kan styres selv om sentraleenheten skulle falle ut

Har litt problem med å skjønne hvorfor dette er populært ? Fordelen med smartpærer er så mange og åpenbare at for meg er det et helt soleklart valg. Og i armaturer der en ikke kan skifte pære er det ofte mulig med andre løsninger. En led-driver med zigbee ligger på rundt om 600 kroner, den også. Eller skifte hele armaturen som fortsatt kan koste mindre enn 650+montering av dimmer. Philips sine Hue taklamper er faktisk ganske gunstige på pris. Hva med alt lysutstyr som ikke er fastmontert, da? Stålamper og bordlamper er ganske normalt å ha. En kan selvfølgelig sette på dimmer der også, men å skifte pære er veldig mye lettere og gir mer funksjonalitet.

I en annen tråd spør du om zigbee pærer vs zwave dimmere. Fordelen med zigbee pærer er jo at du slipper sånne ombygginger.......

Jeg byttet ut led driveren bak mitt speil til en som har zigbee. Alt er mulig hvis motivasjonen er høy nok. Det eneste ikke dimbare lyset hos meg er i kjøleskapet, mikroen og stekeovn. Ventilatorhette f.eks. har jeg bygd om pluss speil på to bad

Å komme inn på badet om morgenen uten å bli blendet av lys er faktor #1 for at kona synes det er greit at jeg sysler med hjemmeautomasjon.

Jeg er blitt litt hekta på bayesiske sensorer (ref varmestyring) og vurderer om jeg skal bruke en eller flere slike på lysstyring også. Den analoge attributten på denne som angir sannsynlighet kan muligens direkte angi lysstyrke. Eventuelt at den multipliseres med solens høyde som en utledet faktor. På den bayesiske sensorens innganger kan en da ha: Sovetid Våknetid Om en har besøk Hverdag eller helg Lysstyrke ute/vær ute og det fantasien måtte komme opp med

Kommer jo an på hva som er målet. 1. Kun av/på 2. Endre lysstyrke 3. Endre hvitbalanse/fargetemperatur 4. Endre farger fra hele spekteret Mine krav er på punkt 3 og da nytter det sjelden med noe annet enn smartpærer ?

Elko impulsfjær bak bryterknappen løste det problemet hos meg.

Min løsning på akkurat denne dimmebryteren var å fortelle den hvilket lys den skal styre. Jeg bruker Home Assistant og DeConz. I deconz valgte jeg on/off clusteret for dimmeren og satte at dimmeren skal styre en spesifikk lysgruppe. Når det var gjort, forsvant problemene. Tror også at det er dette Philips sin hub gjør når du setter opp systemet der. Philips sin hub sender en "beskjed" til dimmer om hvilket lys den skal styre. Det virker som om denne dimmeren krever en direkte kobling til lys.

Med smarte pærer får du jo litt mer som f.eks mulighet til å endre fargetemperatur. Circadian lysstyring er kult ? https://community.home-assistant.io/t/circadian-lighting-custom-component/61246

Zigbee (og z-wave) er et mesh nettverk og rekkevidde er ikke noe problem. Jeg har f.eks en liten temperaturføler i fryseren som akkurat har nok sendestyrke til å nå ut til en lyspære i boden. Og så tar lyspæren jobben med å sende data videre til hub.

Det finnes vel ikke så mye zwave lys? Og Fibaro dimmer 2 kan vel ikke styre noe zigbee enheter i det hele tatt? Edit: Ok, skjønner nå hva du vil fram til så det jeg skrev over er lite relevant. Men du skriver at Fibaro dimmer 2 er nesten enerådene. Med Philips, Osram og IKEA inne på zigbee så er nå inntrykket mitt at det er zigbee som dominerer på lysstyring.

Fordel med zigbee lys OG zigbee brytere er at du kan (hvis du vil) knytte brytere og lys sammen slik at bryter styrer lys direkte uten å være avhengig av en sentral enhet. Den sentrale enheten får også bryterhendelsene så det er fortsatt fullt mulig å lage rutiner som kjøres. For meg er det "et must" at jeg via zigbee brytere kan slå på/av lys selv om Home Assistant boksen er nede og ute av drift.

Produkter med begrenset levetid er jo drømmen til produsentene. Er vel derfor det knapt finnes en telefon å få kjøpt med byttbart batteri

Du kan lage hull. Men du må tette hullet med en kabelmuffe / kitt / gummipropp. Og de som kontrollerer elektriske anlegg kan være pirkete på slikt. En vil ikke at gnister eller plast som brenner i sikringsskapet, lett skal finne en vei ut derifra.

Ta en omstart. De første minuttene etter en omstart får du mulighet til å nullstille passordet

Om det er noen her som har erfaring med å sette innetemperatur som funksjon av sesong (sommer/vinter) eller utetemperatur? Eller vet om lesestoff om emnet?

Det er egentlig ganske enkel matematikk bak dette. Hver kolonne (B til G) er like og hvis en vil ha flere "innganger" så er det bare å legge til videre etter G. Prior på B må legges inn manuelt og er samme som prior konfigurasjonen på bayesian sensor. Prior på C hentes fra probability på B, altså foregående. Så det en endrer er B7 og rad 8. Utgang er G12 hvis en bruker alle 6 kolonnene. Bayesian.xlsx

Er en feil, ja. Det skal være 35% (Har ikke funnet en god måte å skalere sensorer på i forbindelse med visning i brukergrensesnittet)

Siste 24 timer ser slik ut

Jeg følger jo med ? Det dreier seg om å sette riktige sannsynligheter på inngangene. Slik at en inngang ikke bidrar for lite til å ha noen virkning eller bidrar for mye og overstyrer andre innganger. Sånn sett er simulering med regnearket et must. Nå treffer det 100% prosent hos meg, men av og til stusser jeg på hvorfor varmen står på når den kanskje skulle vært av fordi jeg har glemt at strømpris er en faktor.

Har brukt det en god stund (siden i fjor sommer) og synes det fungerer bra

I mitt system bruker jeg innganger til styringen som f.eks. dette - entity_id: binary_sensor.preheat_day prob_given_true: 0.66 platform: 'state' to_state: 'on' preheat_day er en sensor som fører til at varmen slås på automatisk før vi er hjemme. Den er kun tidsstyrt og jeg tar den (og de andre) med her for eksempelets skyld binary_sensor: - platform: template sensors: worktime: entity_id: sensor.time_online value_template: >- {{ now().hour*3600+now().minute*60 + 2400 >= (state_attr("input_datetime.worktime_start", "timestamp") | int) and now().hour*3600+now().minute*60 - 1200 < (state_attr("input_datetime.worktime_end", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on"}} soonsleeptime: entity_id: sensor.time_online value_template: >- {{ (now().hour*3600+now().minute*60 + 60*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.normal_bedtime", "timestamp") | int) or now().hour < 4) and now().strftime("%w") != "5" and now().strftime("%w") != "6" and states("input_boolean.sleeptime") == "off" }} preheat_day: entity_id: sensor.time_online value_template: >- {{ now().hour*3600+now().minute*60 + 60*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.worktime_end", "timestamp") | int) and now().hour*3600+now().minute*60 - 3600 < (state_attr("input_datetime.worktime_end", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on" }} preheat_night: entity_id: sensor.time_online value_template: >- {{ (now().hour*3600+now().minute*60 + 120*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.wakeuptime", "timestamp") | int) and now().hour*3600+now().minute*60 - 600 < (state_attr("input_datetime.wakeuptime", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on") or (now().hour >= 6 and now().hour < 9 and states("binary_sensor.workday_sensor") == "off") }} heatlimit_morning: entity_id: sensor.time_online value_template: >- {{ now().hour*3600+now().minute*60 + 900 >= (state_attr("input_datetime.wakeuptime", "timestamp") | int) and now().hour*3600+now().minute*60 < (state_attr("input_datetime.worktime_start", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on" }} extended_preheat: entity_id: sensor.time_online value_template: >- {{ (now().hour*3600+now().minute*60 + 120*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.worktime_end", "timestamp") | int) and now().hour*3600+now().minute*60 + 60*(states("input_number.heatingtime") | int) < (state_attr("input_datetime.worktime_end", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on") or (now().hour*3600+now().minute*60 + 180*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.wakeuptime", "timestamp") | int) and now().hour*3600+now().minute*60 + 120*(states("input_number.heatingtime") | int) < (state_attr("input_datetime.wakeuptime", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on") or (now().hour >= 5 and now().hour < 6 and states("binary_sensor.workday_sensor") == "off") }} Og da har jeg synliggjort en svakhet med Home Assistant. Beregning av tidspunkter og i det hele tatt, styring basert på tidspunkt, blir fort komplisert og uoversiktlig. Men jeg har i det minste klart å separere de forskjellige delene godt. Jeg trenger ikke rote med en kompleks varmestyringslogikk for å endre på tidstyringen når jeg setter forskjellige sensorer av eller på og deretter bruker sensoren som inngang til den bayesiske sensoren

Det kommer senere i dag eller i morgen