stigvi
-
Innlegg
2 638 -
Ble med
-
Besøkte siden sist
-
Dager vunnet
140
Innholdstype
Profiler
Forum
Blogger
Nedlastninger
Artikler
Regler
Hendelser
Galleri
Store
Innlegg skrevet av stigvi
-
-
Einar skrev (38 minutter siden):
Eller er det noe her jeg ikke ser/forstår?
Det tror jeg. Hvorfor blander du inn zigbee?
Ja, jeg kan i teorien laste ned kildekoden og modifisere den. I praksis er det en del jobb med dette. En skal jo forstå hva som foregår i denne koden. Og som nevnt, de har lagt inn mye som har med dette web-grensesnittet å gjøre.
Fordelen med esphome er at det er brukervennlig og noe jeg kjenner. Jeg holder en knapp på at det er den veien som er lettest å gå. -
fred skrev (21 minutter siden):
Lagde en hanleser med esp32 og noen transistorer for noen år tilbake, det er ikke veldig vanskelig, men du kommer til å slite veldig med å drive den fra hanporten. Jeg tror jeg brukte ca 10% av tiden på å lage dekoderkretsen og programmering, og de resterende 90% på å ikke dra ned to linjen. Det funket ok,men jeg endte med å kjøpe en Tibber pulse, og sette den opp til å sende mqtt pakker direkte til homeassistant
Jeg har allerede en esp32 tilkoblet HAN som går på strøm så dette er ikke en aktuell problemstilling for meg. Men takk for svar.
Som nevnt ovenfor, jeg ønsker å prosessere data i esp32. Det kan feks være å integrere opp energi ut i fra effekt som sendes på HAN porten hvert 2,5s. Slikt er ikke mulig med pulse. Da må en i så fall integrere opp i Home Assistant og da blir resultatet feil hver gang en tar en omstart på Home Assistant. -
Home Assistant virker å være populært og den har også støtte for KNX
https://www.home-assistant.io/integrations/knx/ -
OlavT skrev (6 timer siden):
Jeg laget en HAN-leser som støtter Matter over Thread basert på et Silicon Labs det kit og en slik:
En grunn til at EspHome frister er at jeg vil kjøre min egen behandling av data på esp32. Og med EspHome er det lett å oppdatere kode OTA. Støtter Silicon Labs dev kit det? Eller må du oppdatere kode ved hjelp av kabel? -
Jeg har en slik. Men det virker som om de som lager den er mer opptatt av å lage et fancy web grensesnitt enn å få basisfunksjonalitet til å virke. Jeg kunne installert en gammel versjon av amsleser som jeg vet virket, men funderer også på å lage noe selv. Får se hva jeg gjør til høsten når det er kjekkere å sitte inne å mekke sammen noe enn å være ute og nyte sommeren.
-
Jeg liker å få varsel på telefon når noe skjer i HA som jeg bør gjøre noe med. Dette har jeg forsåvidt fint fått til i pyscript, men jeg synes det har vært litt dillete å sette opp fordi det ikke alltid er like lett å vite hva triggere inneholder av data.
Nå som jeg har gått over til automasjoner i HA er det mye som er langt lettere å få til med en, etter min mening, god visuell editor.
Her er et eksempel.I den visuelle editoren ser det slik ut:
Koden for dette er vist nederst.
Det som skjer er at når stråleovn på terrasse har stått på i 33 minutter og 10 sekunder så sendes et varsel til mobiltelefon
Så venter automasjonen i opp til 6 timer på svar. Hvis ovn slås av før dette så forsvinner melding på telefon. Den forsvinner også hvis 6 timer går uten svar. Trykker jeg på "Nei" så slås ovn av.
Tidligere hadde jeg dette i flere funksjoner i pyscript. Når jeg flyttet det over til HA automasjon så ble det laget flere automasjoner, en for å sende melding og en annen som ventet på svar fra telefon.
I dag fant jeg ut jeg ville samle dette til en enkel automasjon som både sender melding og som venter på svar. Fordelen er å samle dette. Bakdelen er at en vent-operasjon ikke overlever en omstart av HA. Det klarer jeg å leve med på akkurat denne for stråleovnen, men i andre sammenhenger er det jo litt dumt.
- id: '1712999347947' alias: Spør om terrassevarmer skal slås av description: '' trigger: - platform: state entity_id: - switch.terrassevarmer from: 'off' to: 'on' for: hours: 0 minutes: 33 seconds: 10 condition: [] action: - service: notify.mobile_app_pixel_7 metadata: {} data: message: Skal den fortsatt stå på? title: Terrassevarmer data: tag: terrassevarmer actions: - action: NO_ACTION_TERRASSEVARMER title: Ja - action: SWITCH_OFF_TERRASSEVARMER title: Nei - wait_for_trigger: - platform: event event_type: mobile_app_notification_action event_data: action: SWITCH_OFF_TERRASSEVARMER - platform: event event_type: mobile_app_notification_action event_data: action: NO_ACTION_TERRASSEVARMER - platform: state entity_id: - switch.terrassevarmer from: 'on' to: 'off' continue_on_timeout: true timeout: hours: 6 minutes: 0 seconds: 0 milliseconds: 0 - choose: - conditions: - condition: template value_template: '{{ wait.trigger == None or wait.trigger.to_state.state == ''off''}}' sequence: - service: notify.mobile_app_pixel_7 metadata: {} data: message: clear_notification data: tag: terrassevarmer - conditions: - condition: template value_template: '{{ wait.trigger.event.data.action == ''SWITCH_OFF_TERRASSEVARMER'' }}' sequence: - service: switch.turn_off metadata: {} data: {} target: entity_id: switch.terrassevarmer mode: restart -
Bjørn Mork skrev (11 timer siden):
Vanskelig å si uten å vite hvilken versjon du har 😀
Du kjører update.sh scriptet. Evt leser det og utfører kommandoene som står der, evt med tilpasninger til din installasjon (f.eks. hvis du ikke bruker systemd).
Se https://github.com/Koenkk/zigbee2mqtt/blob/master/update.sh
for siste versjon. Prinsippet har vært det samme i lang tid, men jeg tror det er flikket litt på scriptet underveis.
Men hvis dette er en offisiell plugin fra Homeseer, vil den ikke da oppdateres kun når denne plugin oppdateres? -
Er det noen som har prøvd denne på norske strømmålere?
https://esphome.io/components/sensor/dsmr
Ser at noen stikkprøver på obis koder stemmer med de norske......
https://github.com/glmnet/arduino-dsmr/blob/master/src/dsmr/fields.h -
ZoRaC skrev (10 timer siden):
Gjenskapte det gode gamle kjøkken-wattmeteret. 🙂
Koden ligger her:
Hvilken hardware har du kjøpt og hvor kjøpte du den? -
I forbindelse med at jeg flytter python skript over til HA automasjoner, har jeg også kikket litt på å organisere andre typer data / konfigurasjon. Mulig at python skript har gjort meg lat i og med at denne har organisering av skriptene og at dette har vært godt nok. Det er også mulig at etterhvert som systemet utvider seg, blir en vant med at det er dårlig organisert.
I teorien kan all konfigurasjon samles i en enkel fil. Men i praksis er dette splittet opp i flere filer allerede når en installerer HA.
En kan bruke !include og splitte det opp enda mer i flere nivåer. En kan også inkludere yaml-filer rekursivt i fra en katalogstruktur og på den måten gå fra en automasjon i hver sin fil som en ytterkant til alle automasjoner i en felles fil som den andre ytterkant. Eller noe midt i mellom. Og dette gjelder ikke bare automasjoner, men alt annet også som scener, templates, sensorer, mqtt osv.
Det som var nytt for meg var begrepet "packages". Her kan en samle all konfigurasjon av forskjellige typer som naturlig hører sammen i en pakke. Dette må jeg se nærmere på.
Er det noen her som bruker "packages" i HA? -
Da er jeg oppe i 132 automasjoner og 1 blueprint. Og dette er egentlig litt kjekt. Automasjoner er egentlig lette å lage i UI og jeg synes det er lettere å få de feilfrie enn å lage feilfri Python kode.
-
1
-
-
rhunland skrev (2 minutter siden):
Ingen tvil om at trådbunden er mer solid enn trådløs kommunikasjon.
Tja, jeg har nå hørt om begrepet "brudd i ledning". Opplever ellers ytterst sjelden at radiobølger stopper opp.
rhunland skrev (7 minutter siden):Sjelden du finner noen i ett smarthus forum som klager over at knx,loxone,dupline bussen ikke fungerer
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.
-
rhunland skrev (18 timer siden):
Da har du system som er dønn solid, og vil vare i mange år.
Antyder du at zwave og zigbee ikke er dønn solid og vil vare i mange år?
-
Jesper skrev (14 timer siden):
Som i tittel, så har jeg nå kjøpt en Flexit Tradition E/F til mitt UNI 2 RER EC aggregat. Disse står ganske langt fra hverandre (på hver sin side av leiligheten), men det skal være kabel hele veien bort. Problemet er at kjøkkenhetten bare ser ut til å fungere "lokalt" altså sånn den står uten å gi signal til aggregat om å switche over til avtrekk og stille seg på "MAX"-modus den tiden jeg lager mat. Det jeg har lagt merke til at skjer er at dersom jeg steker mat nå, er at den fortsetter å sende mye av luften rett inn til aggregatet for resirkulering, noe som gjør at all osen og lukten ender opp på soverommet som er rett ved siden av tek-7 "kottet" som ligger viavi.. Dette er jo veldig ugunstig og rett og slett ubrukelig, så jeg har tatt et bilde av hvordan signal kablene er satt sammen over kjøkkenhetten, og hvor disse da går inn i kretskortet på aggregatet. Jeg mistenker at kablingen i seg selv ikke er riktig iom at automatikken ikke slår inn her.
Ønsker også tilbakemelding på om det er noe annet jeg må gjøre (må de synkes e.l. for å fungere?) Jeg sender også med bilder av modellnumre på både hette og aggregat samt kontrollpanel. Har plutselig fått for meg at det kanskje de to rett og slett ikke er kompatible til å kjøre med hverandre.
EDIT: Eneste kjøkkenhetten gjør er å åpne og lukke spjeldet og skru av og på lys, signalkablene snakker ikke. Så jeg må jo da gå inn å manuelt skru opp "MAX" og ned "NORMAL" på aggregatet hver gang hetten skal brukes fornuftig, fryktelig unødvendig.
En venn av meg mente også at kablingen inne i skapet her på P1 er feilkoblet et par steder, men vi har ikke turt å gjøre for mye med det da vi er redd for å kortslutte og ødelegge for fellesanlegget som ligger i bygget.
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. -
J-Ro skrev (9 timer siden):
Mener du her at det kan være verdt det å gå for Plejd (kontra zigbee) siden det virker som om det finnes integrasjon til Home Assistant? Eller bare til informasjon om at det finnes?
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.
-
2
-
-
https://github.com/thomasloven/hass-plejd
Å ha både zwave, Zigbee, wifi og Bluetooth i samme hus, går fint.
-
1
-
-
Gunnar-K skrev (7 timer siden):
Har et annet lite problem. Den totale solproduksjon for en dag ser ut til å stemme, men noen timer får null produksjon, mens det ser ut til å legges sammen med en senere time, se vedlagt bilde fra 8/4.
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.
-
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å.
-
SveinHa skrev (50 minutter siden):
Har du noe data på hvor pålitelig solvarselet er @stigvi? Jeg bruker data fra både https://api.forecast.solar/ og https://api.solcast.com.au som jeg vet ikke er så veldig pålitelige og manuell sammenligning med yr/storm er ikke mye hjelp...
Ingen anelse. Det er varsel som kommer i fra Yr / met.no
Kenneth skrev (49 minutter siden):Takk for raskt svar @stigvi, her har du brukt flere forskjellig card ser jeg.
Mulig du har brukt noen customer cards her, lurte på hvilke de er?
De 2 øverste og det til venstre i midten 🙂
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
-
Kenneth skrev (34 minutter siden):
Hei, dumt spørsmål kanskje. Men hvilket kort bruker du @stigvi ifra HACS?
Til hva da? Til å vise vær?
Min "værside" ser forresten slik ut som bildet nedenfor. Hva er det der du lurer på?
-
Evelen skrev (25 minutter siden):
men jeg tenker at siden jeg kjører Node-Red som add-on i Home-Assistant blir det litt som en del av samme system.
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.-
1
-
-
RVM skrev (1 minutt siden):
Skjønner hva du mener, men at simple-pid skulle forsvinne er jo ikke det farligste, kunne jo vært interessant å følge Brett Beauregard's guide for å implementere PID-kontroll selv for å lære/oppfriske litt reguleringsteknikk 🙂
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.
-
RVM skrev (40 minutter siden):
Den største "ulempen" jeg har oppdaget med å være veldig avhengig av Pyscript, er at jeg må vente ei uke eller to med å oppdatere HA til siste versjon, i tilfelle det dukker opp noen issues med Pyscript i siste HA versjon 🙂
Og så har jeg oppdaget at man lett kan ramle nedi noen dependency-problemer hvis man støtter seg på biblioteker i Pyscript som har andre dependencies enn det HA shipper. Det siste tilfellet jeg kommer på er at jeg ville bruke Pandas 2.0, men siden HA fortsatt henger igjen på influxdb-client==1.24.0 blir det en konflikt (trenger >=1.26). Pyscript er veldig forsiktig med å installere biblioteker som bryter med det HA bruker (fornuftig nok), så da må man omgå problemet på andre måter.
Jeg svarte at jeg fortsetter med Pyscript. Jeg er bare en enkel søppeltømmer og absolutt ingen programmerer, men jeg elsker å kunne skrive Python-kode rett inn smarthuset i sanntid og få umiddelbar respons på om koden funker eller ei. Men mitt utgangspunkt er at reisen er vel så viktig som målet med smarthuset, så jeg er ikke så nøye på å finne enkleste mulige løsning.
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.
Lese av HAN porten ved hjelp av EspHome
i Strømsparing og strøm-overvåkning
Skrevet
Vel, det er jo nettopp det de har, som nevnt i denne tråden.