Teknor

Dette er vel den beste langsiktige løsnignen ja. Kikket litt rundt på nye sånne NUC-er, men ble ikke helt klok på hvilke komponenter som inngikk og hvilke som jeg måtte kjøpe i tillegg. Men skal tråle finn fremover. Bra forslag! Det er omtrent helt likt oppsett som jeg har - men jeg kjører sonoff dongle e-varianten. Da vet jeg at det burde være mulig å få denne til å snurre med en god 2.4 A forsyning, så da forsøker jeg å finne en god en som den kortsiktige løsningen. Antar likevel jeg må over på en NUC variant når jeg skal inn med litt Grafana og videoovervåkning med objektgjenkjenning etterhvert.

Har to HomeAssistant løsninger - RPI 4 hjemme som får strøm via en relativt kraftig USB-C kilde - (pi, ssd, rfxtrx, sonoff zigbee) - RPI 3+ på hytta som får gjennom USB-micro fra en 2.4 A kilde (pi, ssd, rfxtrx, sonoff zigbee) Jeg klarer ikke å få hytteløsningen til å bli stabil og jeg mistenker at den ikke har stabil / nok strøm. Denne RPI3-løsningen er koblet til en SSD disk, en Sonoff Zigbee dongle og en RFTRX gateway. Så hvilke muligheter har jeg? Ideelt sett skulle jeg byttet denne med en RPI4, men de er som alle vet umulig å få tak og - også på lengre sikt. Vil feks en USB-hub med dedikert strømforskyning løse noe, eller er det et ledd i mellom som igjen kan gi utfordringer? Innspill? Risikosport å koble en slik 5V direkte på 5V og GND pin-ene på RPI-en i tillegg til strøm via USB?

Takk @cat0 Trenger jeg å legge noe slikt til i config.yaml eller finner Namron og .ota filen hverandre automagisk? HVa er i såfall da xyz i xyz_provider: zha: zigpy_config: ota: ikea_provider: true # Auto update Trådfri devices ledvance_provider: true # Auto update LEDVANCE/OSRAM devices

Har 3x Namron Zigbee termostater for styring av varmekabler. Den første jeg kjøpte er litt ustabil sammenlignet med det to andre. Muligens vil en FW oppgradering løse utfordringen. Ser Elektroimportøren har lagt ut FW på sidene sine, det hadde de ikke gjort før. Noen som har forsøkt seg på en oppgradering her? Er Namron oppdatering støttet av ZHA? Eneste jeg finner av dokumentasjon er: zha: zigpy_config: ota: ikea_provider: true # Auto update Trådfri devices ledvance_provider: true # Auto update LEDVANCE/OSRAM devices salus_provider: true # Auto update SALUS/Computime devices inovelli_provider: true # Auto update INOVELLI devices thirdreality_provider: true # Auto update 3REALITY devices #otau_directory: /path/to/your/ota/folder # Utilize .ota files to update everything else https://www.home-assistant.io/integrations/zha/

Hvilken lyskilde hadde du koblet til denne driveren?

Supert @deve87 ! En smal sak å konvertere denne til HomeAssistant også? Jeg er i ferd med å konvertere fra Domoticz i disse dager.

Hvilken funksjon brukte du for nedtelling?

Prinsipp for å unngå skytjenester er bra, men akkurat for varmepumpe har jeg gjort et unntak. Løsningen til feks Kaiteki 6600 integreres sømløst mot HA. I et år har denne funger helt stabilt. Kan jo vurdere dette opp mot stabilieten til et "dumt" IR-interface med begrensede feedback muligheter?

Denne ser interessant ut. Forhåpentligvis Zigbee. https://itavisen.no/2023/02/15/se-hva-ikea-vil-gjore-med-hjemmet-ditt-na/

Noen som har erfaring med microinvertere som har innebygget lokal strømproduksjonsmålig (helst ikke avhengig av Cloud)? Skal fortrinnsvis integreres mot HomeAssistant.

Tips til en anbefalt løsning som som et minimum av sikkerhet gjennom ekstern tilgang på en HA løsning som i dag benytter DuckDNS og enkel port-forwarding? Ser i loggen at det er noen få innloggingsforsøk som feiler hver natt.

For å få inspirasjon til "tilstrekkelig" sikring av hjemmeatomasjonssystemet så beskriv gjerne hvordan dere har tenkt og løst dette. Sikkerhet treffer mange dimensjoner, men jeg tenker i utgangspunkt på tilgjengelighet eksternt, sikkerhetskopiering og "god nok" oppetid. For å begynne selv: - Oppsett: HomeAssistant OS på en RPI4 med ekstern SSD. Zigbee og RF. - Ekstern tilgang: DuckDNS integrasjonen i HA med port forwarding. - Backup: HA standard backup med integrasjonen som automatisk laster opp backup-filen til Google Disk - Restore: Ikke testet, og spent på om det fungerer (!), spesielt med tanke på "hybrid" oppsettet med SD-kort og ekstern SSD disk... - UPS: Ingen

Har litt av det samme på et (av flere) paroramavinduer på hytta. Det er et vindu hvor det er et "belte" på tvers som ikke er duggete (gjerne på kvelden når funktigheten ute øker som følge av lavere temp), alltid på samme sted. Norsk produsent av kvalitetsvinduer. Jeg tror det er en glipp i produksjonen, noe coating som mangler uten at jeg har fulgt det noe videre.

Har lest meg opp og ned på dette, men foreløpig ikke kommet til noen løsning. Kjører HA OS på en RPI4 med ekstern SSD disk. Har et ganske enkelt oppsett med noen få integrasjoner og ca 15 Zigbee på ZHA. Utfordringen er at diskforbruket øker mer enn antall noder skulle tilsi. Sikkert med 100mb om dagen. Har også kjørt "recorder" og slettet historikk +7 dager uten effekt. Leser på div kilder at det kan være rester av containere som ligger og tar opp plass. Utfordrignen er at Portainer ble tatt ut som addon for noen versjoner siden, og jeg da ikke skjønner hvordan jeg kan få tilgang til kontainer-ne. Når jeg bruker SSH gjennom HA så ser jeg vel bare HA-containeren? Noen andre som erfarer det samme?

Takk for innspill @VikingOy. Fulgte guiden her: https://flemmingss.com/how-to-update-conbee-conbee-ii-firmware-in-windows-10/ CMD kommando: GCFFlasher -d COM4 -t 60 -f deCONZ_ConBeeII_0x26580700.bin.GCF Fra: Levert med etter kjøp: deCONZ_ConBeeII_0x26580700.bin.GCF Til: deCONZ_ConBeeII_0x26780700.bin.GCF Videre til: deCONZ_ConBeeII_0x26580700.bin.GCF GCFFlasher konkluderer med "Success" etter verifisering.

Hadde tidligere en TI CC2510 som over tid ble ustabil (er heller ingen anbefalt HW, aldrende teknologi). Oppgraderte til en Conbee II. Denne fungerte greit med ZHA, men manglet noe funksjonalitet mot mine Namron varmekabeltermostater som jeg hadde med CC2510 dongelen. Oppgraderte derfor Conbe II til nyere FW. Etter det får jeg den ikke til å fungere. Heller ikke å nedgradere til opprinngelig FW. Vil tro en FW oppgradering sletter alt i Conbee, men er ikke sikker. På ESP32 chiper må man iblant også resette EPROM for å få en ren installasjon. Kan dette være feil i dongelen eller noe som henger igjen i ZHA? Usikker på hvor jeg skal fortsette å feilsøke... Har forsøkt å installere ZHA manuelt mot Conbee - ("configure new radio"), migrate from backup, create new network etc. Med feilmeldinger som "Error" og "Unexpected error occured". Har også forsøkt Zigbee2Mqtt i stedet for ZHA, da ser ting ut til å fungere fra installasjonssiden men jeg får ikke Zigbee2Mqtt til å legge til enheter. Mistenker at det henger igjen noe krøll i Conbee dongelen. Noen som har erfart noe tilsvarende?

Morsomt prosjekt og bra prosjektbeskrivelse. Flere måter å løse det på (som over) og du kommer til å lære masse underveis. En Raspberry Pi med HomeAssistant OS og 2x DS18B20 (+ en 4.7k Ohm motstand) og et rele som kobles direkte til GPIO portene på Raspberry'en så har du en god start. Når du etterhvert får deg LL varmepumpe, så ville jeg sjekket om det finnes en standardintegrasjon mot HomeAssistant (som feks Mitsubishi Kaiteki har) så har du full kontroll på denne også gjennom samme grensesnitt. Tipper det viktigste er å få et oppsett tilsvarende noe som bekrives her til å fungere, du kommer uansett til å ønske å redesigne og sikkert endre teknologi etterhvert som du blir mer kjent med mulige løsninger og deres pros/cons.

Forsøker å unngå det... Levetiden på teknisk løsning / sky er ofte begrenset og jeg vil ikke at produktet skal bli "ubrukelig" om tilhørende teknisk løsning blir utdatert.

Har etter tips her inne funnet ut at disse to automasjonene gjør jobben for meg. Vil heller ha en "time trigger" enn en trigger når status endres, fordi det blir mer robust om jeg skulle endre VVB på/av manuelt. @haraldov satt meg på sporet. Takk. Tenker å slå de to automasjonene sammen til en nå jeg får tid. alias: VVB on description: >- Slår på VVB rele når timespris er u dagens gjennomsnitt uten kritiske timer trigger: - platform: time_pattern minutes: "1" condition: - condition: and conditions: - condition: time after: "02:00:00" before: "22:00:00" - condition: numeric_state entity_id: sensor.nordpool_today_current below: sensor.nordpool_today_average action: - service: switch.turn_on data: {} target: entity_id: switch.datek_pop2_switch mode: single og: alias: VVB Off description: Slår av VVB rele når timespris er over dagens gjennomsnitt trigger: - platform: numeric_state entity_id: sensor.nordpool_today_current above: sensor.nordpool_today_average condition: [] action: - service: switch.turn_off data: {} target: entity_id: switch.datek_pop2_switch mode: single

Denne funker for meg. Laget to automasjoner. Får vel slå dem sammen etterhvert. alias: VVB on description: >- Slår på VVB rele når timespris er under dagens gjennomsnitt uten kritiske timer trigger: - platform: time_pattern minutes: "1" condition: - condition: and conditions: - condition: time after: "02:00:00" before: "22:00:00" - condition: numeric_state entity_id: sensor.nordpool_today_current below: sensor.nordpool_today_average action: - service: switch.turn_on data: {} target: entity_id: switch.datek_pop2_switch mode: single og alias: VVB Off description: Slår av VVB rele når timespris er over dagens gjennomsnitt trigger: - platform: numeric_state entity_id: sensor.nordpool_today_current above: sensor.nordpool_today_average condition: [] action: - service: switch.turn_off data: {} target: entity_id: switch.datek_pop2_switch mode: single

Fungerte nesten... Dersom strømprisen kryper under gjennomsnittet (endrer status fra "pris_dyr" til "pris_billig" i perioden 22:00 til 02:00 (noe den oftest gjør), så trigges ikke automasjonen igjen kl 03:00 fordi entiteten "binary_sensor.pris_er_billigere_enn_gjennomsnitt" ikke endres (fortsatt har status som "pris_billig"). Noen elegant løsning på det @haraldov?

Fungerer perfekt. takker @haraldov!

Den treffer ikke helt behovet, tror jeg. Har testet ut den betingelsen, men ser ikke ut til å ta hensyn til den. Det jeg ønsker er: Slå på VVB rele når timespris er under dagens gjennomsnitt, men i perioden 22:00 til 02:00 skal den uansett være av. Hypotensen er at strømmen uansett er billigere etter kl 02:00 enn på sen kveld, selv om prisen uansett er under gjennomsnittet for døgnet. På den måten presser jeg forbruket mer mot natt, ettersom familien ikke trenger å dusje eller har behov for varmtvann sent på kvelden uansett. Virker som uansett hva jeg velger som conditions så virker det som den ikke hensyn tar det. Har også oppdatert YAML configuration reloading. Noen andre tips? alias: VVB On test description: >- Slår på VVB rele når timespris er under dagens gjennomsnitt - forsøk på unngå kveld trigger: - platform: numeric_state entity_id: sensor.nordpool_today_current below: sensor.nordpool_today_average for: hours: 0 minutes: 0 seconds: 10 condition: - condition: and conditions: - condition: time after: "02:00" before: "22:00" action: - service: switch.turn_on data: {} target: entity_id: switch.datek_pop2_switch mode: single

Betyr også at du får mindre i støtte for de foregående 24 dagene denne måneden. Støtten har falt 60-70 øre kwh for despember siste uken.

Har følgende automasjon for å aktivere VVB når timespris er under gjennomsnittsprisen for døgnet. Skulle gjerne hatt inn en betingelse som gjorde at VVB ikke ble aktivert i tidsrommet 2200-2359 eller 0000-0100 selv om timespris > gj.snittspris. Noen som kan bistå? alias: VVB On description: Slår på VVB rele når timespris er under dagens gjennomsnitt trigger: - platform: numeric_state entity_id: sensor.nordpool_today_current below: sensor.nordpool_today_average for: hours: 0 minutes: 0 seconds: 10 condition: [] action: - service: switch.turn_on data: {} target: entity_id: switch.datek_pop2_switch mode: single