stigvi

Tja, jeg har nå hørt om begrepet "brudd i ledning". Opplever ellers ytterst sjelden at radiobølger stopper opp. Sannsynligvis en veldig god grunn til det. Helt sikkert et stabilt system, men også veldig få brukere. Zigbee og zwave har til sammenligning en stor mengde brukere og mange av disse har ikke kvalifikasjoner til å sette opp et stabilt system. En kan ikke av den grunn påstå at zigbee og zwave er lite stabile systemer. Det blir et stråmann-argument.

Antyder du at zwave og zigbee ikke er dønn solid og vil vare i mange år?

Jeg vil anbefale å ta det opp med de som har montert det eller Flexit hvis du har gjort det selv. Har vanskelig for å se at noen her er synske og kan finne ut hva som er galt med ditt anlegg.

Bare til info. Jeg ville aldri valgt Plejd. Jeg har hus kun med smarte pærer, bevegelsesensorer og Zigbee knapper på batteri. Alle gamle Elko lysbrytere er tatt vekk. Satt litt på spissen - det er ikke et smarthus verdig å ikke ha et smart lys. Jeg har full kontroll på hvert lyspunkt og har definert over 100 forskjellige scener for lys som setter lys i forskjellige tilstander. Tror ikke de som kommer på besøk har problem med det. Ingen har behov for å trykke på en lysbryter. De er der bare for å være en nødløsning hvis Home Assistant eller zigbee2mqtt skulle stoppe.

https://github.com/thomasloven/hass-plejd Å ha både zwave, Zigbee, wifi og Bluetooth i samme hus, går fint.

Da antar jeg at du leser av verdien på en energiteller for hver time? 2 ting kan skje: At denne telleren ikke blir lest av hver time og mengden energi forskyves til neste time. At det er en klokke i enheten som du skal lese energi i fra som ikke er synkronisert med klokke i Home Assistant. Enheten du leser fra oppdaterer sin verdi når Home Assistant allerede har skiftet til ny time.

Denne artikkelen beskriver forskjellene på DS18B20, DS18S20 og DS1820: https://www.analog.com/en/resources/design-notes/1wire-protocol-pdf-of-ds18s20-vs-ds18b20-digital-themormeters.html

Status er at det går overraskende lett å flytte fra pyscript til Home Assistant Automasjoner. Syntaksen i automasjoner er litt lite effektiv. En må bruke mye tekst og flere linjer der en i python får det ned på en enkel linje. Men fordelen er at automasjoner er veldig likt mal-entiteter. Mal-entiter kan også ha triggere og aksjoner som er det samme som i automasjoner. Jeg begynte med det lette og fortsetter med mer avanserte skript etterhvert. Jeg kommer garantert til å lage noen blueprints også.

Ingen anelse. Det er varsel som kommer i fra Yr / met.no Jeg tok med hele siden...... views: - icon: mdi:weather-partly-cloudy path: vær badges: [] cards: - type: conditional conditions: - entity: binary_sensor.meteoalarm state: 'on' card: type: markdown content: >- # **{{ state_attr("binary_sensor.meteoalarm", "event") }}** **{{ state_attr("binary_sensor.meteoalarm", "severity") }}**, **{{ state_attr("binary_sensor.meteoalarm", "certainty") }}**, {{ state_attr("binary_sensor.meteoalarm", "headline") }} **{{ state_attr("binary_sensor.meteoalarm", "effective") }}** **{{ state_attr("binary_sensor.meteoalarm", "expires") }}** ___ {{ state_attr("binary_sensor.meteoalarm", "description") }} - type: vertical-stack cards: - type: custom:clock-weather-card entity: weather.orstad_utsyn sun_entity: sun.sun weather_icon_type: fill animated_icon: true forecast_rows: 6 hide_today_section: false hide_forecast_section: false date_pattern: DDDD hourly_forecast: false use_browser_time: false - type: custom:hourly-weather entity: weather.orstad_utsyn icons: true offset: '0' label_spacing: | {% set segments = 24 - now().hour %} {{ 4 if segments > 13 else 2 }} name: Vær resten av dagen show_wind: barb-and-speed show_precipitation_amounts: true num_segments: | {% set segments = 24 - now().hour %} {{ segments if segments > 2 else 2 }} show_precipitation_probability: true show_date: 'false' - type: markdown content: >- ### Temperaturen føles som {{ states('sensor.temperatur_foles_som', with_unit=True, rounded=True) }} Minimum siste 8t var {{ states("sensor.ute_temperatur_statistikk", with_unit=True) }} Sist endret: {{ as_timestamp(states.sensor.textweather.last_changed)|timestamp_custom('%d.%m.%Y %H:%M') }} {{ state_attr("sensor.textweather", "#text") }} <br> {%- if states('sensor.vindstyrke_i_morgen')|float(0) >= 16 %}**{%- endif -%}Framover de neste dagene er det meldt vindkast på {{ states('sensor.vindstyrke_i_morgen') }} m/s som er {{ states('sensor.vindstyrketekst_i_morgen') }}{%- if states('sensor.vindstyrke_i_morgen')|float(0) >= 16 %}**{%- endif -%} <br> Vinden kommer i fra {{ states('sensor.vindretningtekst') }}. {%- if states('sensor.timer_med_opphold')|float(0) > 0 %} Det er meldt {{ states('sensor.timer_med_opphold') }} timer med opphold og {{ states('sensor.timer_med_sol') }} timer med skyfritt. {%- endif -%} <br> Inne er det {{ states('sensor.aq9_temperature', with_unit=True) }} i 2. etg og {{ states('sensor.tv_stue_temperature', with_unit=True) }} i 1. etg. - color_thresholds: - color: '#bb0000' value: 1020 - color: '#666666' value: 1000 - color: '#0000ff' value: 970 entities: - color: green entity: sensor.ute_temperatur name: Temperatur ute show_state: true y_axis: secondary state_adaptive_color: true - entity: sensor.garasjeport_trykk name: Trykk show_state: true state_adaptive_color: true height: 250 hour24: true icon: mdi:weather-partly-rainy lower_bound: ~970 lower_bound_secondary: ~-5 name: Trykk og temperatur ute show: labels_secondary: true labels: true extrema: true type: custom:mini-graph-card upper_bound: ~1050 upper_bound_secondary: ~20 - type: entities entities: - entity: sensor.regn_i_dag icon: mdi:weather-pouring type: custom:multiple-entity-row state_header: 24t name: Regn historikk format: precision1 entities: - entity: sensor.regn_intensitet name: Intensitet format: precision1 - entity: sensor.regn_siste_time name: 1t format: precision1 - entity: sensor.timer_med_opphold icon: mdi:weather-rainy type: custom:multiple-entity-row state_header: Opphold name: Fremtidige skyer entities: - entity: sensor.timer_med_sol name: Skyfritt show_header_toggle: false title: Nedbør - chart_type: bar period: hour days_to_show: 1 type: statistics-graph entities: - sensor.regn_intensitet stat_types: - mean - type: entities entities: - entity: sensor.phone_sun_bla_time_slutter_kveld icon: mdi:weather-sunset-down type: custom:multiple-entity-row state_header: Blå name: Gylden time kveld format: time entities: - entity: sensor.phone_sun_gylden_time_starter_kveld name: Start format: time - entity: sensor.phone_sun_gylden_time_slutter_kveld name: Stopp format: time - type: divider - entity: sensor.phone_sun_gylden_time_slutter_morgen attribute: tomorrow icon: mdi:weather-sunset-up type: custom:multiple-entity-row state_header: Stopp name: Gylden time morgen format: time entities: - entity: sensor.phone_sun_bla_time_starter_morgen name: Blå format: time attribute: tomorrow - entity: sensor.phone_sun_gylden_time_starter_morgen name: Start format: time attribute: tomorrow - type: divider - entity: sensor.phone_sun_setting_azimuth format: precision0 state_header: Ned name: Sol, retning icon: mdi:sun-compass type: custom:multiple-entity-row entities: - entity: sensor.phone_sun_rising_azimuth format: precision0 name: Opp - entity: sensor.phone_sun_daylight attribute: tomorrow_hms state_header: I morgen icon: mdi:sun-clock name: Daglengde type: custom:multiple-entity-row entities: - entity: sensor.phone_sun_daylight name: I dag attribute: today_hms - entity: sensor.pixel_7_geocoded_location name: ' ' title: Fototid - type: custom:horizon-card title: Orstad time_zone: Europe/Oslo fields: elevation: true azimuth: true moonrise: true moonset: true moon_phase: true

Til hva da? Til å vise vær? Min "værside" ser forresten slik ut som bildet nedenfor. Hva er det der du lurer på?

Både ja og nei. Du får med node-red når du kjører en backup av HA. Det er en stor fordel. Node red og HA snakker sammen via websockets og rest-api. Det er ikke den mest effektive måten å gjøre det på, men samtidig greit nok. Men det er to separate systemer og ingenting endrer på det, selv om det er gjort enkelt å installere via en add-on. Nå kjenner jeg ikke til node-red, annet enn at det er et grafisk system. Hvor fort tar det til seg Home Assistant sin nye funksjonalitet? Kan du slå av / på lys basert på område, etasje eller merkelapp.

Min plan er å implementere det i Home Assistant automasjon. Jeg lider også litt av at reisen er vel så viktig som målet og jeg ser på det som en utfordring. Men om det blir i 2024, 2025 eller 2026, det vet jeg ikke.

Et bra og interessant svar. Dette med umiddelbar respons er jeg enig i og det er en fin egenskap med pyscript. Når det gjelder avhengigheter så er det dette jeg misliker. Jeg bruker biblioteket simple-pid. For hver oppdatering av HA så ser jeg i loggen at dette biblioteket lastes ned i fra pypi.org. Hva om noen sletter dette biblioteket fra pypi.org? Finnes det det måter å lagre biblioteker permanent i pyscript? Det står på planen at det må undersøkes.

Jeg har svart at jeg kommer til å bruke automasjoner mer. Faktisk kommer jeg til å flytte en del vekk i fra pyscript og over til automasjoner. Grunnen til dette er at jeg vil ha minst mulig avhengigheter i HA. Jeg liker ikke å være avhengig av pyscript. Tidligere brukte jeg AppDaemon og jeg gikk over til pyscript med noe av den samme argumentasjonen. AppDaemon er et frittstående system (som også Node-RED er) og som kommuniserer med HA ved hjelp av rest-api. Jeg valgte pyscript fordi denne er tettere integrert med Home Assistant og går direkte mot HASS objektet. Fordelen ble en bedre ytelse, men også en forenkling av systemet. Det er kode jeg har laget i pyscript som blir svært vanskelig å flytte så noe kommer jeg allikevel til å beholde i pyscript, men jeg ser etterhvert hvor veien går. Kanskje jeg skulle flyttet de app'ene jeg har laget i pyscript over til custom integrasjoner.

Nå som Home Assistant endelig har fått gode muligheter for å kategorisere og merke automasjoner, kommer du til å bruke dette mer?

https://www.home-assistant.io/integrations/alexa.smart_home/ Det er mange veier til Rom, altså. Har en Home Assistant Cloud er det en kort vei til mål I tillegg har Home Assistant sin egen: https://www.home-assistant.io/voice_control/ Kjenner ikke -hstouch, men du har uanz muligheter til å lage slike grensesnitt og som er unike for akkurat denne padda. Jeg har ikke slike selv, men skulle jeg hatt en så hadde jeg startet med å opprette en egen brukerkonto for denne og lagd et brukergrensesnitt som gjelder for denne brukeren.

Nei. I et zigbee-nett kan det bare være 1 koordinator Kjenner ikke til Styrkar. Hva er det? Men i utgangspunktet er det kun lys, bryter/knappepanel og bevegelse/lyssensorer du kan koble til Philips Hue.

https://rc.home-assistant.io/blog/2024/03/27/release-20244/ Det er ikke så mye mer å si enn JUHU!!!! Endelig muligheter for å kategorisere automasjoner og så flesker de til med å kunne kategorisere og merke hva som helst annet. Jeg tenkte på min egen PID regulering som holder huset i rette effekttrinn på nettleie. Her er listen over gulvvarme og andre varmekilder hardkodet i et skript for å få rett prioritering. Men det kunne vært løst mer elegant med å sette en merkelapp på hver varmekilde som angir prioritering. Da kan skriptet lages universelt og blir lettere å dele.

Jeg ville trodd at en skal lese pow-u sin nettside utenfra. Denne er på port 80 og tcp

Jeg driver med fotografering når jeg får tid til å unslippe husets automatiseringer. Da er det nyttig å vite når gylden og blå time starter og stopper så jeg har lagd et kort i Home Assistant som viser meg dette. Men dette har vært basert på hjemmeposisjon. Det er jo mindre interessant når en er på reise så jeg endret dette til å være basert på telefonens posisjon. Sun2 er navnet på en integrasjon som jeg bruker for å hente klokkeslett når solen er i bestemte høyder. Og telefonens posisjon kommer i fra Home Assistant appen for Android. Jeg setter en ny posisjon når jeg selv har flyttet meg mer enn 50km. alias: Ny posisjon til sun2 description: "" trigger: - platform: state entity_id: - device_tracker.pixel_7 condition: [] action: - service: sun2.get_location data: location: phone response_variable: location - if: - condition: template value_template: >- {{ distance(location.latitude, location.longitude, 'device_tracker.pixel_7') > 50 }} then: - service: sun2.update_location metadata: {} data: location: phone latitude: "{{ state_attr('device_tracker.pixel_7', 'latitude') }}" longitude: "{{ state_attr('device_tracker.pixel_7', 'longitude') }}" time_zone: "{{ state_attr('sensor.pixel_7_current_time_zone', 'time_zone_id') }}" mode: single

Jeg hadde lyst å ha en temperaturføler på kontor/arbeidsplass som rapporterte måleverdier til min egen Home Assistant. Her er et innlegg om hvordan det ble løst. Jeg bestemte meg for å bruke en esp32 sammen med en BME280 sensor. På esp32 har jeg brukt esphome. På arbeidsplass er det et gjestenettverk som denne kan bruke. I esphome settes wifi opp slik som vist nedenfor. Hvis den ikke kommer på nett innen 1 minutt, vil den opprette et lokalt wifi nett som en kan koble seg til med mobil og deretter legge inn hvilket wifi nett sammen med passord som esp32 skal bruke. Esphome kaller det et "Fallback hotspot". Dette er en engangs-konfigurasjon. wifi: ssid: "hjemmenett" password: !secret heime_wifi domain: .lan power_save_mode: none ap: ssid: "Kontordings Fallback Hotspot" password: "et eller annet passord" Og så har jeg tatt vekk api: i fra yaml-filen fordi jeg ikke vil at esp32 skal prøve å sende data til en Home Assistant som ikke er der via standard api. Deretter laget jeg en time komponent der en hvert 15. minutt sender temperatur, fuktighet og trykk via en https post til en webhook. time: - platform: sntp id: sntp_time timezone: Europe/Oslo servers: - 0.pool.ntp.org - 1.pool.ntp.org - 2.pool.ntp.org on_time: - seconds: 0 minutes: /15 then: - http_request.post: url: https://hooks.nabu.casa/en_eller_annen_url.......... verify_ssl: false headers: Content-Type: application/json json: |- root["kontortemperatur"] = id(temp).state; root["kontorfuktighet"] = id(hum).state; root["kontortrykk"] = id(pres).state; Så gjenstår bittelitt konfigurasjon i HA En lager en ny automasjon som har en webhook trigger. Data som esp32 sender, kan en hente ved hjelp av {{ trigger.json.navnpåsensor | float(0) }} Webhook ID som automasjonen foreslå, lar en være uforandret. Trykk på tannhjulet bak webhook ID og ta vekk avkrysningen på "kun tilgjengelig fra det lokale nettverket" Så må en inn på oppsett for Home Assistant Cloud. Nederst der er det en seksjon for Webhook'er. Her trykker en "Administrer" på den webhook som automasjonen har opprettet og kopierer url som står der. Denne url skal en bruke i sin helhet i esp32. Så det var egentlig det hele. Dataene tikker inn hver 15. minutt. Har en ikke Nabu Casa sin skytjeneste så er det andre måter å sette opp denne url'en på, men har en først gått denne veien så har en vel kontroll på hvordan en får aksess til sin HA utenfra via en webhook. Oppsettet for BME280 er her, men ikke så veldig relevant for dette med webhooks. Den er standard esphome.... sensor: - platform: bme280_i2c temperature: name: "${devicename} Temperature" id: temp oversampling: 16x filters: - offset: -3.3 pressure: name: "${devicename} Pressure" id: pres filters: - offset: 7.0 humidity: name: "${devicename} Humidity" id: hum address: 0x76 iir_filter: 16x update_interval: 60s

Kommer an på om knappen sender event for hold og slipp.......

Hvis en skal snakke om en vinner, så tror jeg zigbee er det på lys. Jeg ser ikke noe problem med å blande og mikse. Velg det som passer for deg. Du har jo allerede Philips Hue og den går det å fortsette med hvis du ender opp med Home Assistant. Ingenting endrer seg på 6 måneder. Sannsynligvis ikke de neste 6 år, heller. Matter og Thread er nytt, derfor finnes det lite. Det er heller ikke gitt at de konkurrerer ut zigbee eller zwave. Kanskje konkurrerer de ut proprietære løsninger som Home Connect til Siemens og Bosch.

Ja, du deler info om økonomi i dette og det er bra. Men jeg må innrømme at det er lite jeg forstår av regnearket ditt. Hva er feks "Cost installed" og "Total installed"? "Savings" er 9226 og "Estimate savings" er 435238. Enten har du gått på en solid smell når det gjelder faktisk spart i forhold til forventning eller så misforstår jeg betydningen av disse to 🙂 Men det er ikke viktig for meg å vite hva alt betyr i ditt regneark. Som du skriver og som jeg nevner lenger oppe - jeg er vet at det finnes andre behov enn kun å spare penger. Men i det siste har massemedia hatt flere artikler om anlegg som er tatt av vinden, anlegg som har ført til husbrann, som har ført til vannlekkasje fra tak og en rekke andre problemer. Samtidig er det en del cowboy-virksomhet i bransjen. En kan få inntrykk av at "menig mann" som ikke setter seg grundig inn i dette, bare hiver seg på en hype. Jeg mener det er feil. Folk som bare vil spare penger, bør holde seg langt unna og heller spare pengene på noe som gir større avkastning og mindre risiko.

Alle produkter en kjøper inn har en eller annen funksjon og som forhåpentligvis skal dekke et behov. Dimmere er jo veldig konkrete på akkurat det. Det som er spesielt med solcelle er at de skal konkurrere med ledningen inn til huset som også leverer strøm. Så da, med få unntak, har en ikke noe behov lenger. Ja, det er noen her på forumet som ser andre behov enn kun å produsere strøm, men de aller fleste kjøper solcellepanel kun for å spare penger. Da synes jeg det er ekstra viktig å regne ærlig og redelig på dette. En må ta med ALLE utgiftene også. Det gjelder selvsagt kapitalkostnaden, men også årlige vedlikeholdskostnader og uventete reparasjoner som en bør sette av penger til. Jeg mener det er å kaste blår i øynene på oss andre når en forteller om alt en sparer uten å ta med hele regnestykket. Jeg vurderer solcellepanel selv, men det har så langt stoppet opp på vurderingsstadiet. Jeg klarer ikke å se at det er noen fornuftig økonomi i dette og så langt har jeg ikke sett noen andre som har det heller (av private anlegg).