Teknor

Takk - da får jeg sette meg inn i den tråden og entso-e.

Jeg har i dag en HomeAssistant-automatikk som aktiverer VVB når timesprisen er rimeligere enn gjennomsnittet for døgnet basert på følgnde YAML kode: binary_sensor: - name: "Pris er billigere enn gjennomsnitt" state: > {% set average = state_attr('sensor.nordpool_kwh_krsand_nok_2_10_025', 'average') | float(default=0) %} {% set timeprice = states('sensor.nordpool_kwh_krsand_nok_2_10_025') | float(default=0) %} {{ timeprice < average }} Har funnet ut at min varmvannsbereder må være aktiv i 4-6 timer i løpet av døgnet for varme opp varmtvannsbehovet, så en løsning hvor VVB aktiveres når prisen er blant de seks billigste timene ville vært enda mer optimalt. Og når ingen er hjemme burde automatikken kun aktivere VVB i den timen prisen er billigst (som burde være nok for å varme vannet til 78 grader en gang i løpet av døgnet). Har noen tips til YAML kode som gir meg template sensorer som inkluderer en sånn rangering? Vil tro behovet også er relevant for en del andre HA brukere.

Har 3x Namron zigbee termostater. TIl baderom, gang og vaskerom. Synes spesielt den på baderommet faller for ofte ut og blir utilgjengelig i ZHA (en gang i måneden?), den i gangen kan også falle ut (annen hver måned?). Når jeg manuelt legger dem til igjen (re-pairing) så fungerer det som normalt igjen. Zigbee enhetene står med ikke spesielt mange meters mellomrom og jeg har noen få andre enheter også som fungerer som repeatere. Kan det være en løsning å gå over til Zigbee2MQTT i stedet for ZHA? Evt andre steder å feilsøke? Har Sonoff Zigbee Dongle på forlengelseskabel og isolert SSD disk/kabel. Logbook May 29, 2023 Varmekabler bad HVAC action became unavailable 03:51:49 - 6 hours ago Varmekabler bad Thermostat became unavailable 03:51:49 - 6 hours ago Varmekabler bad Identify became unavailable 03:51:49 - 6 hours ago Varmekabler bad Zha Event was fired 03:51:49 - 6 hours ago

Kan virke som det ikke var strømforsyningen som var problemet, men et hikk i ZeroTier One / VPN løsningen som ødela for meg remote. Uansett gode innspill her.

Kan ikke så mye om konsekvensene av "ripple" @arneolav . Men har det noen praktisk betydning for strømkvaliteten som vil påvirke RPI-en negativt?

Ja... men å kutte den ene delen av USB kablen og koble denne direkte på +/ - på en sånn strømforskyning som kan gi inntil 5 A (på 5V) vil vel være en løsning? Med mindre strømtrekket på RPI-en blir for lavt? Har tidligere erfart at det kan komme en summelyd på disse omformerne ved lavt strømtrekk (men det var 12v variant).

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