Teknor

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

Nydelig. Takk! Da har jeg litt å se på frem til våren. Bra ikke Domoticz-miljøet er helt dødt.

Har en slik lås og for et par måneder siden sluttet kommunikasjonen å fungere. Har en slik verisure hub som kobles direkte i stikkontakten og LAN kabel i denne til router. Er en knapp også på denne verisure hub-en. Mange år siden jeg satte opp denne og finner ikke noe dokumentasjon på hvordan sette opp kommunikasjonen eller feilsøke. Noen som har tips å komme med?

USB porten er ttyACM0 og jeg tror den har vært det hele tiden. Usikker på hvor jeg sjekker det i ZHA. Husker jeg la inn adressen da jeg satt det opp, men finner ikke noe sted å sjekke det nå.

Får ikke aktivert ZHA på Home Assitant OS. Har fungert stabilt i et par måneder, men siste to dagne begynt å bli trøblete. For nå å ikke starte i det hele tatt. Har en RaspberryPI 4 med SSD. Zigbee dongelen er koblet til en 1 meters forlengelseskabel. Kan dette være den beryktede inferens utfordringen mellom Zigbee og SSD, HW feil som plutselig slo til, eller noe SW greier? Logger: homeassistant.components.zha.core.gateway Source: components/zha/core/gateway.py:172 Integration: Zigbee Home Automation (documentation, issues) First occurred: 21:25:53 (3 occurrences) Last logged: 21:26:40 Couldn't start ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2 coordinator (attempt 1 of 3) Couldn't start ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2 coordinator (attempt 2 of 3) Couldn't start ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2 coordinator (attempt 3 of 3) Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 664, in _skip_bootloader result = await responses.get() File "/usr/local/lib/python3.10/asyncio/queues.py", line 159, in get await getter asyncio.exceptions.CancelledError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 172, in async_initialize self.application_controller = await app_controller_cls.new( File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 144, in new await app.startup(auto_form=auto_form) File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 124, in startup await self.connect() File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 106, in connect await znp.connect() File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 706, in connect self.capabilities = (await self._skip_bootloader()).Capabilities File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 663, in _skip_bootloader async with async_timeout.timeout(CONNECT_PROBE_TIMEOUT): File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 129, in __aexit__ self._do_exit(exc_type) File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 212, in _do_exit raise asyncio.TimeoutError asyncio.exceptions.TimeoutError

Kjøp deg litt hjelp til å basis-konfigurere denne som stigvi linker til så vil jeg tro det er en grei løsning som er brukervennlig når den er satt opp. KNX - Home Assistant (home-assistant.io)

Jeg forsøkte å kjøre image restore fra sd-kortet til ssd-en. Burde muligens gjort en restore etter å ha installert ha os fra scratch på ssd-en, ja.

Takk @haraldov . Mistet alle termostatene mine etter overgang til USB3 SSD. Litt justering på plassering av SSD-en og forlengerkabel til Zigbee dongelen gjorde susen. Sparte meg for timesvis med feilsøk her.

Målet er å - unngå feil på sd-kort - økt fart og responstid gjennom USB3 / SSD - enkel backup - enkel restore Antok da det ville være enkelst med å alt på SSD disken, men mulig jeg må gå for en "hybrid" løsning.

Løfter denne tråden siden spm fortsatt er relevant. Er det slik at å boote fra HomeAssistant OS direkte fortsatt ikke er støttet? Kun logger og DB som kan ligge på ekstern disk (SSD)? Dette må i såfall være en stor grunn til å ikke brukke HA OS men HA på RPI OS. Håper på innspill her for å unngå mye bortkastet prøving og feiling.