Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

Vinnerliste

Populært innhold

Viser innholdet med mest poeng fra 31. jan. 2024 i alle områder

  1. Min VVB er styrt av en esp8266 og den får stadig ny funksjonalitet. I sommer byttet jeg ut to DS18B20 sensorer med Oso sin sensorstav med 3 temperaturfølere. De 3 sensorene bruker jeg til å prioritere oppvarming av vannet. Hvis bunntemperatur kommer under ønsket temperatur, så varmes vannet med lav effekt og typisk rundt om 100W. Kommer sentertemp. under ønsket temperatur, så økes effekten "passelig" og hvis topptemperatur er under ønsket temp. så er det 100% effekt og 2kW. På den måten klarer jeg å stoppe at temperatur synker enda lavere uten å utfordre nettleie og å bruke minst mulig strøm når pris ikke er optimal. Temperatur settes til middels en gang i døgnet og på billigste timer. Til høy hver 11. dag på billigste timer. I det siste har jeg lagt inn nøyaktig beregning av oppvarmingstid slik at jeg treffer bedre på den billigste timen istedenfor å utnytte nest-billigste og 1/3 av den billigste. Effekten på varmeelementet er via en SSR så jeg kan styre effekt trinnløst vha puls-bredde modulering og dette er effektivt for å holde seg under effekttrinn på nettleie. Psnitt/Pmaks er snitt effekt på siste oppvarming delt på 2000W. Da får jeg et forholdstall som jeg bruker til å beregne oppvarmingstid på neste døgns syklus. Det gir ikke nøyaktig tid, men det er en god indikasjon når VVB blir nedprioritert i forhold til lading av biler. Esp8266 er selvsagt programmert ved hjelp av Esphome. Kodefilen er ikke mer enn 360 linjer.
    2 poeng
  2. Denne lille rakkeren har gjort at smarthuset mitt har fungert svært dårlig i et par uker nå! 😞 Vi rakk å gå inn, ta av oss yttertøy og sette oss i sofaen før lyset på stua slo seg på! Utrolig irriterende, særlig når huset har fungerte relativt problemfritt i 7 år! Så hvordan fant jeg synderen, lurer du da sikkert på? 😉 Det hele startet rundt juletider. Det ble merkbart tregere respons på kommandoer, særlig på lys. Prøvde selvsagt de vanlige tingene, som å restarte HomeSeer-serveren, installere de siste Ubuntu-patchene, restarte RasberryPi som Z-wave USB-pinnen kjører på, osv, men ingenting hjalp. Noen dager kunne det fungere "ok" og andre ganger helt i sirup. Visste liksom ikke helt hvor jeg skulle begynne feilsøkingen og med lite ledig tid så ble det egentlig ikke gjort stort med det på et par uker. En dag oppdaget jeg tilfeldigvis at en "pyntelampe" ikke lyste og den lot seg verken slå på med Z-wave eller ved å trykke på bryteren. Tenkte at bryteren trolig hadde gått i stykker og det slo meg at kanskje en del Z-wave-trafikk ble forsøkt rutet via den, så jeg tok en "remove bad node" i HomeSeer, slik at den ikke lengre skulle være en del av Z-wave-nettet. Men, det hjalp ikke. 😞 Et par uker senere satte jeg med ned for å feilsøke mer grundig. Jeg hadde sjekket litt logger og sånt tidligere, uten å se noe unormalt. Jeg benyttet selvsagt også @Moskus sin debug-guide og programvare: Men, det var heller ikke noe som skilte seg ut med mye trafikk der heller. For en del år siden kjøpte jeg Z-seer på tilbud, så jeg fyrte i gang den for å feilsøke og det ble fort klart at det var noe som ikke var som det skulle! Hver gang jeg restartet programmet ble 2-4 tilfeldige noder markert utilgjengelige (rosa). Kjørte jeg en "test all", så var det også mange noder som den feilet å kommunisere med ("B=1" nederst på noden betyr at command eller respons mot noden feilet i testen): Jeg valgte en tilfeldig Fibaro Dimmer 2 (som hadde direkte rute til UZB1) og kjørte command og respons-test: Masse pakketap og utrolig lang tidsbruk! Noen noder var kjappe og ga ingen pakketap, klarte egentlig ikke å se noe mønster i hvem som funket og hvem som ikke gjorde det. Det virket også som den samme noden kunne funke fint i en ny test noen minutter etterpå. Min konklusjon var at min 7 år gamle UZB1-pinne trolig hadde begynte å feile og at jeg måtte bytte den ut. Jeg har en reserve UZB1 liggende et sted og vurderte å lete etter den og forsøke å overføre backup fra gammel til ny og se om det hjalp, evt kjøpe meg en ny USB-pinne (med 700-chipset, for å "oppgradere" litt). Jeg begynte å skrive en epost til HomeSeer-support, for å bare få en slags bekreftelse på at min teori trolig stemte og at det ikke var noe annet jeg hadde "oversett". Skulle avslutte eposten med å skrive at jeg ikke hadde gjort noen endringer i det siste, helt til jeg da kom på denne Swiid-bryteren som hadde feilet og som jeg hadde fjernet fra nettverket. Da slo det meg at jeg hadde ikke trukket ut støpslet til den lampen, så selv om den ikke lengre var en del av Z-wave nettverket mitt, så var det fortsatt "på lufta" og kanskje kunne skape støy. Før jeg sendte eposten gikk jeg derfor og trakk ut støpslet, bare for å i hvertfall ha utelukket det (og rent brannvernmessig er det sikkert også lurt å koble fra elektronikk som har sluttet å fungere som det skal, just in case...). Og vipps, så begynte lysbrytere, osv å fungere lynkjapt igjen! 😮 😄 Jeg tok en ny test med Z-seer: Og bare minutter etter jeg trakk ut kontakten så var ingen noder lengre "rosa" og bare et par termostater meldte om pakketap ("B=1")! 😄 Neste morgen slo alle lysene seg på før jeg rakk å gå ned trappa! Deilig! 😄 Så hensikten med denne posten er rett og slett og vise hvor "sårbart" et Z-wave-nett kan være. Det skal ikke mer enn én trøblete node til for å "ødelegge" for alle andre og gi en svært dårlig/elendig brukeropplevelse (og WAF!). Men å finne denne ene noden er ikke alltid så enkelt! 😞 Jeg var heldig at det var en Swiid på en lampe med støpsel, for da tok det null tid å koble den ut for å teste. Hadde det vært en dimmer-pille f.eks så hadde det vært vesentlig verre - ikke har jeg lov å koble de ut selv, det er mer knotete å komme til, og man er som regel litt mer avhengig av det lyset som drives av en slik sånn at man gjerne ikke ønsker å koble den fra heller (i hvertfall så lenge lyset fungerer da). Og å ta sikringen kurs for kurs vil også kunne gi uante følgefeil, ved at noder som mye trafikk normalt sett rutes igjennom blir koblet ut og man får andre typer feil pga rutingproblemer oppå det hele og vil få problemer med å skille det opprinnelige problemet fra evt rutingfeil pga utkobling av "friske" noder. Så har du et tregt/ustabilt Z-wave nett så ønsker jeg deg lykke til i feilsøkingen... 😛
    1 poeng
  3. Jeg har også tenkt den tanke, men takk for at du (og @ArnieO ) minner meg om det. Det bør absolutt lages en "kloss" for OTA. Men først må jeg lære den selv (og helst den siste mest oppdaterte måten å gjøre det på) Men det ligger litt lavt i prioriterings bunken akkurat nå så om noen har lyst til å bidra med en kloss så er jeg bare glad for det.
    1 poeng
  4. Inspirert av @Fermate sine ESP32 byggeklosser kom jeg på tanken med OTA. Så først en video som ga grunnleggende info men var litt halvhjertet. Ny video ga hele pakken... Da begynner ESP32 virkelig å bli gøy!
    1 poeng
  5. Har nå 2 egenutviklede Matter over Thread devicer lagt til i nettverket for testing. Kjører nå en kontroller med støtte for Matter, varmepumpe med Modbus over TCP og Z-Wave. Oppsettet for Matter er: - Raspberry PI 4 - Nordic Semiconductor nRF52840 Dongle som Radio Co-processor for OpenThreadBorder Router - OpenThread Border Router Software - Python Matter Server (i Docker container) Har skrevet noen guider / huskelister her: olavt/open-thread-border-router-rcp-nordic-semiconductor: How to prepare a Nordic Semiconductor nRF52840 Dongle to run as a RCP for Open Thread Border Router (github.com) olavt/open-thread-border-router-silicon-labs (github.com) olavt/matter-sensor-thread (github.com) Guidene er ikke helt ryddige og egner seg kanskje mest som huskelister for meg selv akkurat slik de er nå.
    1 poeng
Vinnerlisten er satt til Oslo/GMT+02:00
×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.