slippern

Har hatt en PI kjørende kaldt, opptil -20 grader, var ikke noe problemer med den. Pga endrede behov, så har jeg nå en Intel NUC i samme miljø.

Har hatt denne i 2år nå, og har fungert prikkfritt, Namron Zigbee Touch Termostat 16A Sort | Elektroimportøren AS (elektroimportoren.no) Benytter den i Zigbee2MQTT.

Det skal være slik, security er kryptering trafikken til/fra enheten. Jeg har kun inkludert dørlåsen (DanaLock v3) med security (S2).

Her er kanskje et alternativ om pumpen din støtter det? GitHub - toremick/shorai-esp32: esp32 connected to shorai heat pump Jeg har en Toshiba fra ca 2013, før WiFi var oppfunnet omtrent 😄 Denne bruker jeg Broadlink RM mini 3, har fungert prikkfritt i mange år, ulempen er at du ikke får noen status i retur fra pumpen, så har en Aeotec Multisensor i rommet for ha temperatur monitorering.

Dette har jeg også opplevd på flere NUC-er, virker som en eller annen svakhet..

Ser ut som jeg også blir og migrere fra ESXi og til Proxmox, da det ser ut til at Veeam får støtte for Proxmox i løpet av året 🙂

Kan også sette den til telenor.fwa om du ønsker IPv4 og IPv6.

Som en tommelfingerregel oppgraderer jeg aldri til en .0, de fleste alvorlige bugsene bruker å være fikset i .1 (Og les alltid release notes og bugfixes) Har aldri vært plaget med at z2m har vært ustabilt.

Har ikke noen bilder, men Intel har dokumentert headerne her: Front Panel Header for Intel® NUC Rele 1 og rele 2 på Uni-en kobles til reset og power, og ADC kan kobles til +5v dc, da kan man i HA lage seg en template sensor på om Intel NUC-en er av eller på, 0v = av, og 5v = på.

Shelly Uni er et snopt produkt, har to stk. Den ene er koblet mot headerne på hovedkortet til en Intel NUC for å kunne remote slå av/på eller kjøre restart av den. En annen er koblet til en parafinovn + DS18B20 på en hytte som kun har 12v strøm for remote kunne starte ovnen, siden tradisjonell ring hytta varm ikke funker lengre nå som 2G og 3G-nettet forsvinner.

Virker som at Telia blir værre og værre mtp CG-NAT, de har det til og med på FWA-produktene deres.. Selv har jeg Telenor og benytter telenor.fwa APN-et og får offentlig IPv4 adresse (+ IPv6). internet.public APN-et gir kun offentlig IPv4 adresse.

Fram til nå har jeg hatt en Aeotec door/window sensor 7 i postkassen, men denne har aldri funket optimalt da det blir for langt imellom huset og postkassen, og denne virker til og spise batterier når dekningen til z-wave nettverket er dårlig. Jeg kom over et innlegg i en Facebook gruppe en som hadde kjøpt 5stk av disse: https://www.espthings.io/index.php/2022/11/05/et-sw01-a-very-low-consumption-mailbox-switch/ I skrivende stund har han en igjen: ESPHome Postkasse-sensor - 1 igjen | FINN torget Mottok enheten etter noen få dager og startet testingen og løste noen utfordringer underveis som man alltids gjør med nye dippedutter 🙂 ESP-en eksponerer automatisk de nødvendige entitetene: Reset-bryter (Denne bryteren gjør at ESP-en går i deep sleep igjen) Batterispenning Status på switch 1 og 2. WiFi signalstyrke (RSSI). 3D-print kabinettet på espthings var for lite pga molex-kontakten til bryter inngangene blir for høg, så måtte lære meg litt Fusion360 for å modifisere høyden på det, la nok på ca 2cm. Det ble da også nok plass til og montere WiFi-antennen rett i boksen også. Den fjærbelastede trykkbryteren ble koblet slik at den er NO når lokket til postkassen er igjen. Når postkassen åpnes er den NC og trigger ESP-en. Neste utfordring var en liten nøtt. Jeg fikk som regel varsel annenhver gang om at postkassen var åpnet, årsak måtte finnes.. Jeg sjekket først nettverket: RSSI-en var for lav (89 dBm), så jeg flyttet aksesspunktet opp på kaldloftet, da ble den umiddelbart noe bedre (80dBm), dette er greit nok når det er snakk om såpass lave datamenger som skal over. Men fremdeles var det noe trøbbel. EIRP-en på aksesspunktet på 2,4ghz var satt til minimum 12dBm, så klienter under dette blir automatisk sparket ut for å ikke forringe WiFi-opplevelsen til andre. Satt EIRP-en ned til 0 og da funket den straks bedre, deaktiverte dermed 2.4ghz for klientene, slik at de nå kun kjører på 5ghz, så får IoT-enhetene bruke 2,4ghz/5ghz alt etter hva de velger selv. Neste utfordring var at Home-Asssistant ikke rakk og polle ESP-en før den gikk i deep-sleep etter 30 sekunder. Økte deep-sleep tiden til 60 sekunder og problemet var egentlig løst sånn sett, men med økt strømforbruk. Etter litt googling fant jeg ut at for deep-sleep enheter er ikke API-et og foretrekke, men MQTT. Da er det ESP-en selv som sender ut data til MQTT, i stedet for at HA skal polle data. Koden for dette er ganske rett fram: MQTT Client Component — ESPHome Alle entitetene dukker automatisk opp i HA også på MQTT. #api: # encryption: # key: !secret esphome_api_secret mqtt: broker: 1.1.1.1 username: esp-postkasse password: !secret esphome_mqtt_password Med MQTT fungerer enheten mye bedre, med det samme den har koblet til WiFi sender den ut data. Har testet ved og kjøre ping kontinuerlig mot enheten, og ved første ping-reply så sender den også ut data på MQTT. Jeg kan dermed putte den i deep sleep igjen etter 1 sekund og strømforbruket blir minimalt. Slik ser automasjonen i node-red:

Her i huset så har jeg kun 2,4ghz med 20mhz båndbredde (og maks dBm da jeg har en ESP-dings fryktelig langt unna) wifi for IoT-nettet, og klienter (PC-er, mobiler, nettbrett) kjører på 5ghz. ZigBee har levd helt av seg selv i mange år uten noen problemer, bor også rett attmed en boligblokk som sender ut 20-30 SSID-er uten at det har bydd på noen problemer.

Neppe noen problem å få en ekstra fiberboks, så lenge det er nok tilgjengelig fibrer i kabelen inn til huset. Men du vil neppe få benytte to routere (en på hver fiberboks) uten og ha to abonnementer.

@DeVille Forsøk og sett opp en cron-job på PI-en som pinger VPN-serveren hvert 15 min, om tunellen ramler ned, så skal også ping forespørselen være nok til og reetablere den.