SveinHa

Når en først har valgt bort Home Assistant så virker det lite logisk innføre noe som ser veldig Home Assistant ut...

Har hatt et par ESP32 gående en ukes tid med program basert på denne malen og de har så langt vært mer stabile enn andre ESP32/MQTT varianter jeg har laget tidligere, ingen stopp enda. Er der LWT funksjon (Last Will and Testament) innebygget i biblioteket og hvordan settes evt. denne opp? Jeg har en "uptime" teller som oppdateres til MQTT hvert 10 sekund så jeg vil jo se om ESPen sovner inn/mister nett...

Det er ikke noen spesiell forsikring men havariet var plutselig og uforutsigbart. Ikke noe jeg kunne gjort for å forebygge. Årsaken til havariet var varmeveksler mellom gass- og vann kretsen som fikk intern lekkasje. Gassen gikk inn i vann kretsen og ut automatisk lufter, deretter gikk vannet inn i gasskretsen og frostsprengte kompressoren/rørene i nærheten. Når en kan dokumentere dårlig økonomi i reparasjon så synes jeg det er klokt av forsikringsselskapet å støtte alternativer som ikke koster mer for dem.

Så ville skjebnen det slik at min 7 år gamle luft/vann varmepumpe totalhavarerte. Siden varmepumpehavariet for et par uker siden har jeg satt meg ned med kalkulatoren. For hele 2023 har varmepumpen generert 4863 kWh iflg energimåler på vannsiden. Varmepumpen har i samme periode forbrukt 1578 kWh og det gir en innsparelse på 3284 kWh. Om vi regner at strømprisen i 2023 har ligget på rundt kr 1.20 inkl nettleie og strømstøtte så blir da årlig besparelse/inntjeningspotensiale kr 3941. Om en skal tjene inn en reparasjon til kr 69.900 (skadetakst) så ender vi på tett oppunder 18 år og det blir da økonomisk forkastelig. Jeg har jo allerede solcelleanlegg med stor batteripakke og ser for meg at det vil bli langt mer lønnsomt å utvide dette til en kostnad rundt det samme som varmepumpehavariet koster. Jeg har de siste ukene holdt gulvene og bereder varme med strøm fra solcelleanlegget og ser at det går men må utvide om jeg skal ha energi å gå på til skyggefulle dager. Erstatninger som forsikringen dekker gjelder jo det havarerte anlegget så jeg ser en stor fordel i å heller utvide solcelleanlegget i stedet for å gjøre en økonomisk forkastelig handel med ny varmepumpe. Til info har jeg fått muntlige prisoverslag fra 2 andre varmepumpeleverandører og de antyder en reparasjonspris kr 100.000 til 120.000. Har forelagt denne problemstillingen for forsikringsselskapet og de var veldig positive til det. Har gjort avtale med forsikringsselskapet at jeg umiddelbart får utbetalt erstatningssummen uten mva og så får jeg utbetalt mva etterhvert som fakturaer med dokumentert mva sendes inn. Har allerede 9.6 kWp solceller i bestilling og disse vil bli montert på treunderstell i en skråning borte fra bygninger. De fleste MPPT regulatorene sliter med å takle såpass effekt så jeg regner med å kjøpe ny off-grid inverter som bare blir brukt til MPPT og som stand-by inverter i tilfelle den andre skulle få problemer. ...eller om jeg får liv i den inverteren som sovnet under firmware-oppgradering vil jeg bruke den... Berederen har jo varmekolben stående på midten siden varmepumpen er ment å varme nedenfra så for å få få litt varme til gulvene installerte jeg en internsirkulasjonspumpe slik at det varme vannet øverst flyttes ned til bunn. Det skal ikke mye sirkulasjon til så pumpen står på laveste hastighet og går i en 5 minutt syklus, 5 min på, 5 min av og det ser ut til å være ganske passe..

Har begynt å få til litt solvarsel slik at jeg, nå på vinteren, kan planlegge hvor mye strøm jeg må kjøpe i løpet av natten for å overleve neste dag. Er ikke kommet helt i mål med automatikken men det er nå i alle fall langt bedre enn uten solvarsel. Oversikt over hvordan solvarselet virker vises slik: Den 17.01 er et ganske stort avvik og det skyldes 3 dager med nedsnødde solceller...

Har utvidet "Solvarsel vs Reell" trendene litt: Nederste viser avvik. Er varsel og reell lik vises "0", grønn er mer sol enn varslet, rød er mindre. Den 17.01 er en stor minus og det skyldes snødekkede solceller i 2-3 dager.

Har ikke jobbet med Modbus siden -90 tallet men ser Node-RED har en haug med Modbus integrasjoner. Da burde det være nokså kjapt å gjøre et forsøk for å se hvor enkelt/vanskelig det er. Eneste stedet jeg ikke har kommet i mål er Verisure/Yale Doorman integrasjon men den er så lite viktig for meg at jeg har ikke lagt stort arbeid i den... Hadde en stund HomeSeer oppe og gå kun for Verisure men Verisure sluttet å virke i HS også... Jeg gikk over til Node-RED for noe rundt 3 år siden og har mange ganger lurt på hvorfor jeg ikke hadde hørt om Node-RED tidligere. Selv her på forumet ser det ut til at Node-RED er litt "uglesett" på en måte. En kan ikke velge Node-RED som system i profilen til tross for flere hint til adm (hint igjen @Moskus), medlemmer av andre "menigheter" gir beskjed om at de ikke vil høre om Node-RED osv. men det er nå deres tap tenker jeg... Jeg er i alle fall mektig imponert over hvor enkelt og greit det er å få til det meste i Node-RED. Der er ingen systemer som passer best for alle, folk har forskjellig ståsted på mange plan. Når jeg skal i gang med et eller annet nytt der jeg har mange veier å gå så lager jeg meg en liten og relativt enkel oppgave og ser hva som skal til for å løse denne, hvor mye nett/forumhjelp jeg trenger for å komme i mål. For hjemmeautomasjon blir oppgaven f.eks. slik: Jeg har 2 wallplugs, en til espressomaskin og en til kaffekvern. Espressomaskinen skal kunne slås på/av fra wallplug OG et eller annet skjermbasert. 10 minutt etter espressomaskinen slås kvernen på da det indikerer at espressomaskinen er gjennomvarm. Etter 1 time slås alt av igjen om det ikke er slått av manuelt. Og kanskje det viktigste: Det skal kunne herjes med, slås av/på i hytt og pine uten at timerne går i ball... (og når en leker med disse tingene så settes jo selvsagt timerene til sekunder i stedet for minutt og timer...). Når oppgaven er i boks regner jeg med at jeg har kunnskap nok til å avgjøre om systemet er passende for meg...

Har en EASunPower/Voltronic SMW8k solcelleinverter der leverandøren i Kina sendte feil firmware til meg og det medførte at den sovnet. Etter over 100 eposter til leverandøren har de vist seg å være totalt kunnskapsløse så ingen hjelp å få der. Har en kontant i Italia som kan hjelpe meg men bare frakt blir maaange tusen så håper på å finne noe rimeligere. Inverteren har innebygget oppdateringsfunksjon men den feil firmwaren har ødelagt denne også så nå er inverteren inkl display helt dødt. Noen som kan hjelpe her til lands? Prosessorkortet ser slik ut: Prosessoren er en Texas TMS 320F2809 PZA

Da begynner jeg å nærme meg noe. 172.16.0.220 er en Arduino MKR 1010 WiFi som har putlet og gått i 2-3 år. Nå har den gitt en mengde TX-Retries. For litt siden skiftet jeg UniFi aksesspunktet som den er tilkoblet uten at det endret noe og i dag kjøpte jeg nytt UniFi AC1200 og da forsvant det meste av TX-Retries i det området. Det forrige aksesspunktet var nytt og ubrukt men noen år gammelt da det ble installert. Så får tiden fortelle om dette var det hele men det føles i alle fall mye bedre nå.

Da har jeg lekt meg litt til. Resultatet er et par pythonscript som ender opp i en CSV fil som inneholder ping-statistikk for samtlige IP-adresser i nettet mitt klar for å åpne i regneark. CreatePingFile.py: Bruker nmap for å liste alle aktive IP-adresser. Produserer filen PingAllAuto.sh som er rutinen for å pinge alle enheter et valgt antall ganger (100 ping i utgangspunktet). Resulterer i filen PingAllAuto.txt. PingAllAuto.sh kan bruke veldig lang tid på bli ferdig alt etter hvor mange enheter som er i nettet og hvor mange ping på hver... (antall ping * enheter = sekund kjøretid). Linje 5 i filen må endres til IP passende ditt nett og evt annet antall ping. PingCreateCSV.py: Leser filen PingAllAuto.txt, mellomlagrer i PingAllAuto.fil2 og ender opp i PingAllAuto_yyyymmddhhmm.csv som er tilpasset norske spesialtegn (feltskille ";" og desimaltegn ","). Pythonscriptene forutsettes kjørt fra samme mappe med kommando (i denne rekkefølge): "python3 CreatePingFile.py", "./PingAllAuto.sh" og "python3 PingCreateCSV.py". Ellers er det jo en kjapp sak å legge til sti i alle filnavn. PingAllAuto.sh ser slik ut: ping 172.16.0.1 -c 100 >> PingAllAuto.txt ping 172.16.0.50 -c 100 >> PingAllAuto.txt ping 172.16.0.51 -c 100 >> PingAllAuto.txt ping 172.16.0.52 -c 100 >> PingAllAuto.txt ping 172.16.0.53 -c 100 >> PingAllAuto.txt ping 172.16.0.70 -c 100 >> PingAllAuto.txt +++ PingAllAuto.txt: PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data. 64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=1.83 ms 64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=1.19 ms 64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=1.17 ms *** 64 bytes from 172.16.0.1: icmp_seq=98 ttl=64 time=1.10 ms 64 bytes from 172.16.0.1: icmp_seq=99 ttl=64 time=1.08 ms 64 bytes from 172.16.0.1: icmp_seq=100 ttl=64 time=1.12 ms --- 172.16.0.1 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 99119ms rtt min/avg/max/mdev = 0.912/1.372/9.961/1.066 ms PING 172.16.0.50 (172.16.0.50) 56(84) bytes of data. 64 bytes from 172.16.0.50: icmp_seq=1 ttl=64 time=204 ms 64 bytes from 172.16.0.50: icmp_seq=2 ttl=64 time=1.61 ms 64 bytes from 172.16.0.50: icmp_seq=3 ttl=64 time=1.73 ms +++ Fra foregående fil hentes det ut statistikk til filen PingAllAuto.fil2 --- 172.16.0.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9009ms rtt min/avg/max/mdev = 1.081/1.165/1.420/0.092 ms --- 172.16.0.50 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9012ms rtt min/avg/max/mdev = 1.239/52.221/493.546/147.189 ms --- 172.16.0.51 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 1.276/11.196/79.029/23.370 ms +++ ..som ender opp i PingAllAuto_yyyymmddhhmm.csv: ip;transp;recvp;min;avg;max;mdev 172.16.0.1;10;10;1,081;1,165;1,420;0,092 172.16.0.50;10;10;1,239;52,221;493,546;147,189 172.16.0.51;10;10;1,276;11,196;79,029;23,370 +++ Da gjenstår bare å importere til regneark og sette på autofilter så kan der dukke opp noen overraskelser... Pythonfilene: CreatePingFile.pyPingCreateCSV.py Laget for Linux men det burde ikke kreve veldig mye å få til å gå andre platformer...

Har kjørt 1000 ping til en del utvalgte enheter og resultatet ble slik: Noen pakketap og litt lange responstider her og der så ingen gode konklusjoner enda. Foreløpig er dette en litt manuell operasjon så jeg skal automatisere litt mer. Har en scriptfil som tar seg av pinging men data må foreløpig leses ut manuelt og legges i regneark. Når jeg i løpet av dagen får litt mer gang på dette så får jeg se litt på WireShark, gode WireShark-tips mottas.

Feilsøking er noe jeg har drevet med hele livet i industrien og jeg har løst enkelte skikkelige nøtter... Jeg har en VELDIG god dag når jeg har lett etter en feil i uker og måneder og når feilen er funnet og jeg er HELT sikker på at dette er feilen FØR den er reparert... Lever lenge på slike ting... Første bud er å observere hva som VIRKELIG skjer og ikke ta snarveier og observere det du tror. Fryktelig lett å tråkke i salaten der... Dine ZWave problemer ligner på det jeg sliter med for tiden men jeg har så langt fokusert på LAN/WLAN (siden MQTT lagger noe voldsomt av og til og MQTT Explorer også faller ut i perioder) og holder på å lage meg noen PING-rutiner og analyseverktøy i Python. Prøver meg også på WireShark for å se om jeg kan tolke noe der...

Siden oppgradering av UniFi Server gjorde en godt merkbar forskjell og det muligens var forrige oppgradering som forårsaket problemene gjorde jeg en nedgradering til ver 7.5.187. Nå kan jeg jo nedgradere til alle versjoner helt tilbake til 1 men valgte siste 7.x versjon inntil videre. Nå går det jo egentlig ikke å nedgradere så hele nettet måtte slettes og settes opp på nytt men det er nå en ganske liten og kjapp jobb som består i å opprette SSID, resette og adoptere alle aksesspunktene. Finnes der noe netscanner program som kan fortelle om slike problemer på en ikke-nettverks-nerdete måte? Edit: Får fremdels disse tilfeldige hengene i nettet så UniFi server er nok ikke årsaken.

Litt tidlig å friskmelde men jeg oppgraderte UniFi Network Server fra ver 8.0.7 til ver 8.0.26 og da ble der plutselig liv og skikkelig respons i en ESP32 med MQTT som jeg leker meg med. Denne hadde en responstid på alt fra 30 sekund til uendelig i går og fram til oppgraderingen nå for en halvtime siden. Nå snakker vi millisekund. WiFiman har fremdeles veldig varierende resultat...

Det er jeg litt usikker på men det ser ut til at det kablede nettet fungerer. Merker meg dog at trafikkLEDene i alle porter har litt mer aktivitet enn jeg synes virker normalt...

Når en eller begge enhetene er på 5 GHz går det langt bedre med hastigheter i området rundt 50-100 Mbps og internethastighet på 150 (som jeg betaler for) men selv om der SER veldig bra ut med hastigheten så feiler testen ganske ofte med "Speed Test Failed, Speed Test server is unreachable". Edit: Har et gammelt aksesspunkt (nyinstallert men noen år gammelt likevel) som rapporterer en del TX-retries. Har satt dette ut av drift uten at det endret noe merkbart...

Ser jeg er tilkoblet på 2.4 ja.

VELDIG varierende resultat med WiFiman. Noen ganger rundt 50-60 Mbps, andre ganger mindre enn 5 og ender med "Speed Test Failed"... Sitter med en enhet i hver hånd og aksesspunkt bak en tømmervegg 5-6 meter unna.

Jeg oppgraderte UniFi Network Server til ver 8.0.7 for en tid siden da det var veeeeldig lenge siden sist. Mulig det kan ha noe med saken å gjøre... Finner ikke noe om meshing med ser at STP stod på RSTP så jeg satte den til STP nå. Vet ikke hva som er forskjellen i praksis...

Nytt problem. Ikke så alvorlig som det tråden startet med men ille nok... Aner egentlig ikke hvor jeg skal starte å lete... Nettet mitt ser ut til å fungere fint der det MÅ men de litt mindre viktige tingene som at VNC Viewer henger seg med ujevne mellomrom fra 1 sekund til timer plager meg mye siden jeg bruker VNC veldig mye. Noen ganger våkner VNC til live igjen av seg selv men vanligvis må den restartes og kommer da opp å gå igjen på et blunk som normalt. I NodeRed editor fryser statusoppdateringer (de tallene under noden i eksempelet). Det er ikke så veldig viktig og de livner til igjen med en refresh i nettleseren. Alt annet i NodeRed ser ut til å virke som det skal. Disse tingene har fungert skuddsikkert i årevis og problemene begynte for en måneds tid siden eller noe slikt. Jeg vet ikke at jeg har gjort noe med nettet som skulle gi slike utslag... Har nå et rent Ubiquiti nett med 4 stk Unifi trådløse aksesspunkt, noen EdgeMax switcher og EdgeRouterX. Alle UniFi enhetene er av eldre dato (slutt på fw oppdateringer for et par år siden) så et par har blitt skiftet ut til "Ubiquiti Unifi 6 LR Wifi 6 Roaming-aksesspunkt AX3000" etter problemene oppstod uten at det har gjort noen forskjell... Kjører Pi-Hole på en virtuell Ubuntu maskin og den har gått stødig i årevis. Liker ikke Ubuntu så jeg satte opp en Debian 12 maskin med Pi-Hole omtrent på den tiden problemene startet men stoppet denne og satte i drift den gamle Ubuntu maskinen igjen i dag men ingen forskjell. Noen som har glupe tips om hva som skjer?

Supert. Er dette en egen løsning for HA eller vil den kunne brukes av andre system også?

Det hadde vært supert. Abonnement på Drivstoffappen er helt uaktuelt for meg da det er kundene, altså de som legger jobb i å oppdatere priser, som er verdien i appen. En engangsbetaling på et par hundrelapper kunne vært ok men ikke kr 200/år så lenge Drivstoffappen ikke selv innhenter priser.

Det er jo litt både/og. Jeg har en haug med RPi/ESP32 som hver og en har en enkelt oppgave nettopp med tasnke på å minimere problemer om en skulle finne på å havarere. ESXI er veldig kjapp å sette opp fra scratch og med daglig backup av de komplette maskinene jeg har i drift vil det ikke ta mange minuttene før jeg er oppegående om ESXI hardware skulle streike. Har 2 identiske NUCer i drift og den ene kjører kun ESXI/Windows med BlueIris så den kan enkelt ofres om jeg må (kannibalreservedeler funker det også).

Jeg har nå havarert mange snurredisker opp gjennom tidene men de siste 15 årene kan jeg ikke huske en eneste som har havarert så noe har skjedd på den fronten... og de jeg har slitt meste med er SCSI/SAS disker, PATA/SATA disker har fungert supert selv om de mekaniske delene antagelig er like... Har snurredisker i begge NASene mine men de står jo litt bortgjemt siden diskene støyer en del...

Ser den men så vidt jeg vet er det ikke en gang mulig å kjøpe seg API-KEY, kun dyre abonnement som ikke gir meg noen særlig ekstra nytteverdi i alle fall.