Søk i nettsamfunnet

Etter hvert har jeg fått meg en del forskjellige ZigBee sensorer av forskjellig type (og muligens av varierende kvalitet?). For ikke å glemme alle de forskjellige sensorene man kan koble til for eksempel ESP’en og få data fra via MQTT (DS18B20, DHT 11 og BMP/E280 for å nevne noen). Noen har en hovedfunksjon som for eksempel: Dør / vindu sensor med temperatur i tillegg. Wall plug som måler elektrisk forbruk og temperatur, men disse har jo en egen oppvarming som gjør temperaturen vanskelig å bruke til rom temperatur styring uten justering. Andre er mer multisensorer som for eksempel: Sensor for temperatur, trykk, fuktighet. Sensor for temperatur, trykk, fuktighet, bevegelse og lysstyrke. For å nevne noen. Det jeg ser er at når et utvalg av forskjellige sensorer plasseres sammen, er det avvik mellom de avleste verdier. Noen ganger, også mellom i utgangspunktet helt like sensorer. Jeg lurer derfor på hvordan folket kalibrerer de forskjellige parametrene på sine forskjellige sensorer? Siden noen avvik kan tilskrives forskjellig oppdaterings frekvens lurer jeg på hvilke kriterier man bruker for oppdaterings frekvens? For sensorer på batteri vil jo oppdaterings frekvens direkte påvirke batteri levetid. Hva kan man anse som akseptabelt avvik for de forskjellige parametrene? Også av interesse er hvordan å holde styr på eventuelle korreksjons faktorer. Her tenker jeg at kanskje et regneark kan være brukende? Når det for eksempel gjelder styring av romtemperatur har man jo flerfoldig ganger sett i pressen: ”For hver grad du senker temperaturen, vil du spare X prosent av kostnadene til oppvarming.” Så da er det jo greit at sensorene viser sånn nonelunde riktig temperatur og at det ikke er for mye avvik mellom de forskjellige sensorene.

For de av dere som ønsker å hente in prisdata fra Tibber in i Openhab, har jeg laget denne lille guiden, bruker selv ikke Tibber (enda), men på forespørsel fra en kompis, laget jeg denne lille guiden. Håper at også andre kan ha nytte av denne.. /Ole Hvordan hente prisdata fra tibber til OH.pdf

Økonomi / begynner modell for hjemme automasjon / smart hus Hei forum. Som dere ser er jeg ny på forumet. Men jeg har med stor interesse lest mange gode innlegg en god stund. Jeg planlegger nå å ta steget inn i smarthus / hjemme automasjons verden. Som sagt har jeg lest en del og har slik tilegnet meg noe informasjon. Men jo mer jeg skjønner, jo mer skjønner jeg at jeg ikke skjønner! Slik sett er det jo betryggende at det ved flere anledninger er poengtert at man på forumet er positive til å hjelpe oss Newbies. Jeg har etter fattig evne prøvd å skrive dette innlegget på en slik måte at det forhåpentligvis kan hjelpe / inspirere andre Newbies. Etter hvert som skriveriet har tatt form ser jeg at hadde jeg sett dett i børjinga, så hadde mine frustrasjoner ved å ikke helt forstå ting vært mye mindre(for å si det mildt). Tanker rundt skriveriet og om det er interessant for forumet: Kan dette på en måte ”pinnes” slik at grønne Newbies som meg finner dette lett? Jeg håper etter å ha lest mange tråder at det også vil komme mange gode og informative svar / kommentarer som vil være til stor hjelp for Newbies. Litt om meg selv: Utsannet som ingeniør med fagfelt elektronikk, reguleringsteknikk på datamaskiner samt programmering for lenge siden. 30+ år fra offshore (på båt) med ansvar for vedlikehold av diverse over og undrevanns utstyr tilknyttet vår operasjon. Så jeg har en smule erfaring angående småvolt, storvolt(1200), grønn overledning, signal overføring(RS-232 etc) noe fiber har det også blitt, telegram format(NMEA etc) samt ikke minst hva litt feilkode / feil oppsett kan medføre av frustrasjoner. Fra utdanning til praksis har jo dette gått greit da terminologien var innenfor kjente rammer. MEN nå da jeg skulle se på dette smarthus greiene så måtte jeg lære meg en helt ny terminologi, det er interessant men det tar laaang tid å få stell på sakene. Det tok f eks mange timer på nettet for å finne ut at WAF ikke hadde noe med Web Application Firewall å gjøre. Som sagt fra mange her på forumet så ønsker også jeg å være mest mulig sky uavhengig. Litt om potensielle prosjekt(uprioritert rekkefølge) slik jeg ser det nå: *Automatisk skånsomt lys når man må opp i den mørke vinternatt for et nødvendig ærend. *Automatisk styring av varme i kjeller og varme på vannledning når det blir 10-20 blå. *Displaye / logge forskjellige temperaturer: ute, fryseboks, VVB +++ *Slå av "treige" laster når forbruket går opp pga f eks matlaging(nye effekt tariffen). Kjøpte ved juletider POW-U AMS reader, kjekk sak med MQTT mulighet. *"Alarm" når man går gjennom taket på nest trinn i den nye effekt tariffen. *Logge kWh forbruk og vise i forhold til temperatur. Temp føler på ved ovn. Skulle jeg ha fyrt mer? *Kanskje logg temperaturen i garasjen og starte motorvarmer / batt lader (om tilkoblet) når det er griskallllt. Ja, jeg har diselpurke men den har fått noen dyre overhalinger så den MÅ vare i flere år. Noen med ferdigkjøpte "duppeditter" og kanskje noen med hjemmesnekra basert på ESP-8266 familien(Wi-Fi 2,4 GHz). Tar du den så tar du den + kjekt å ha. Dashboards som viser status rundt i svingane og at alt er på stell. Så hvordan har jeg gått fram? Vel, for meg har alarm (brann, innbrudd) tilkoblet vekter stått øverst på lista og det får man ikke med et privat system meg bekjent. Som mangeårig kunde av Verisure har de ergret meg grønn med prisøkning på 2-3 ganger prisstigningen generelt, samt at med utfasingen av kobberlinja måtte noe gjøres. Etter noen timer på nettet landet jeg på Homely som benytter Develco sine ZigBee produkter. Jeg fant også at deres sensorer er kompatible med smarthus systemer. Så abonnement ble tegnet og systemet ble innkjøpt + noen ekstra sensorer (reserve + kjekt å ha). Som pensjonist har man et begrenset budsjett(ikke overtid, bonus etc.) med mindre man faktisk kan beviselig tjene dette inn igjen. Slik som overgangen fra Verisure til Homely alarm. Reduksjon på flere 100 lapper per mnd. Etter 3 år 500+ i reduksjon per mnd. Derfor må utgiftene veies mot inntjening, komfort og noe kjekt å ha. Så med dette i mente har jeg så langt kommet fram til følgende økonomi modell: Dette er etter Googling ”en masse”. Når man er grønn så tar det tid å stokke kortene i riktig rekkefølge. Denne satte ”brikkene” i sammenheng for meg: https://www.youtube.com/watch?v=ffg3_1AgtyA Særlig der han refererer til Node-Red som Data Bridge. Slik jeg forstår det er det her man plasserer smart hus systemet man bruker(Home Assistent etc). Denne var også til god hjelp: https://www.youtube.com/watch?v=JdV4x925au0 Særlig 5:08-8:25 der han går inn på InfluxDB og ”krymping” av datasett. Også denne tråden var opplysende: https://www.hjemmeautomasjon.no/forums/topic/9900-trenger-man-egentlig-noe-annet-enn-node-red/#comment-100236 *Hardware plattform: Raspberry Pi 4B 4GB med en eller annen Linux. Det sies at den kan være ustabil pga SD-minne kort men det hevdes også at ved å kjøre fra USB mem stick blir det bedre. *Sensor / aktuator SW interface: Mosquitto *Regulering / styre SW "motor": Node-red Det grafiske grensesnittet virker meget tiltalende ala Micro-Bit kanskje. *Database: Influx DB *Display / Dashboard: Grafana *I tillegg tenker jeg å ha MQTT Explorer på en PC for læring og testing. Om dette blir oppsettet tenker jeg meg følgende progresjon da jeg ikke kan noe om dette fra før: 1.1 Installere MQTT Explorer på en PC 1.2 Installere en eller annen Linux og Mosquitto på Pi’en. 1.3 Teste for å lære og se at dette spiller. 4.1 Installere Node-red på Pi’en for å lære og se at dette spiller 4.2 Kanskje ta inn MQTT fra POW-U AMS reader. 5. Installere Influx DB på Pi’en for å lære og se at dette spiller 6. Installere Grafana på Pi’en for å lære og se at dette spiller Men før jeg begynner ønsker jeg om mulig å få tilbakemelding fra dere på forumet som har erfaring med lignende oppsett. Dette for om mulig å avverge kommende små eller store frustrasjoner/fadeser. Jeg tenker også at ved å gå denne veien så tilegner jeg meg kunnskap som kommer godt med når/om det skulle bli aktuelt å gå over til en annen plattform hva gjelder SW / HW. ** Så her håper jeg på forumets hjelp. Men, det jeg ikke har på stell ennå er hvordan best å kommunisere med de forskjellige ”duppedittene” ute i huset fra Pi’en. Jeg tenker USB interface fordi da kan man bruke en USB forlenger kabel til å forbedre rekkevidden. Slik jeg forstår det: *Man må ha en "USB dings" som snakker ZigBee, Z-Wave etc. *Så må man ha ei "Software snurre" som tar telegram / verdier til/fra "USB dings" til/fra MQTT broker som så sender dette til/fra Node-Red. Men jeg er usikker på hvilke "USB dingser" som snakker best med hvilke "Software snurrer" i forhold til hvilken plattform man velger? Det er også et poeng å ikke velge slik at man er låst til en plattform. Så har jeg lest en eller annen plass at man kan ta "USB dingsen" ”mobil” for å komme nærmere f eks dørlåsen etc uten å måtte flytte HW plattformen for paring. Her tenker jeg at hvorfor ikke bruke en USB forlenger kabel? Regner med at dette kan gir power problemer eller signal krøll over en viss kabel lengde. Har Googla noe på dette med kabel lengde men har ennå ikke funnet noe med 2 streker under. Noen som har testet hvor lang kabel men kan ha før det ”går i dass”? ** Så her håper jeg igjen på forumets hjelp. Så melder jo behovet seg for å kunne ta backup av hele ”sulamitten”, og her er jeg igjen grønn. Jeg ønsker ikke å være avhengig av mnd abonnement og sky ting slik som Homey har for at man skal få tatt backup. Slik jeg forstår det får man heller ikke backup av nettverket med Homey. ** Så her håper jeg igjen på forumets hjelp. Mine tanker i utgangspunktet var at alarmsystem får være alarmsystem uten å blande dette med smarthus. Jeg tenkte at fordelen ved å bruke samme type sensorer i 2 forskjellige ZigBee nett er at om 1 sensor ”tryner” i alarm ZigBee nettet kan jeg ta en fra smarthus ZigBee nettet. Så da melder spørsmålet seg om det er en farbar vei eller om det er å be om frustrasjoner med 2 forskjellige ZigBee nett? ** Så her håper jeg igjen på forumets hjelp. Gjerne med forslag om hvordan eventuelt å angripe dette på annet vis. Homely skryter på seg noe smarthus greier, men ved å se på hvilke parametre som er tilgjengelig i Homely appen og hva Delvaco kan levere virker det som at det for noen sensorer er stor forskjell på tilgjengelige parametre i negativ favør Homely appen. Med mulighet for at jeg igjen ikke skjønner ting. En annen ting er at når man nå i godt voksen alder er avhengig av optiske armforkortere(les: briller) så er dette med å stokke pølsefingrene på et mobildisplay en plage. Jeg VIL HA min. 24” skjerm, tastatur og mus. ** Så her håper jeg igjen på forumets hjelp. Homely API betaversjons testing 7/4 -22 fikk jeg mail fra Homely at de har ute et API for betaversjons testing. Dette fikk meg til å tenke hmm, men så må jo dette læres også. Da jeg leste brukervilkårene satt jeg igjen med en følelse av at dette var sky basert og kunne ligge an til måneds abonnement. Hvorfor ikke bare la tillatte parametre bevege seg lokalt over MQTT? Eller er det noe her jeg ikke har forstått? ** Så her håper jeg igjen på forumets hjelp. Hjerte sukk fra en Newbie. Kan man i Kategorier / Nybegynner pinne en post som grafisk viser hvor i systemet de forskjellige tingene er og hvordan de hører sammen. Ala det bildet jeg har satt inn, det bør også være en indikasjon på hvilken kommunikasjon som går til / fra hvor.

Hei, Vinteren nærmer seg og dører og vinduer lukkes, da er det vel på sin plass å følge med på at Radon nivået holder seg innenfor sunne grenser, jeg har derfor "tuklet" litt med Airthings og tilpasset deres RaspberryPI script slik at jeg kan bruke og logge verdiene i openHAB. Jeg har valgt (for meg enkleste løsning) å gå via mqtt/mosquitto slik at løsningen også kan tilpasses og brukes av andre systemer. Last ned filene og følg instruksene, vær obs på at jeg kan hverken bash eller python, men ved hjelp av Google og masse prøv å feil fikk jeg det da til å virke, og løsningen har nå gått stabilt på to forskjellige systemer i et par måneders tid. Kommentarer og ikke minst forbedringer mottas med takk. read_wave.py inneholder instruksene og informasjonen du trenger. read_wave.sh er scriptet som kjøres for å oppdatere verdiene (må tilpasses din Wave). Airthings.ITEMS er et eksempel på openHAB items for bruk med scriptene over. /Ole Airthings.items read_wave.py read_wave.sh