NilsOF

Hmm, jeg skjønner ikke problemet.. Er det rammeverket som vil ha gammell firmware? Det må omtrent være destruktivt.. 😕 (For jeg anntar at firmware i coordinator er oppgradert)

Jeg har vel kommet fram til at jeg mest sannsynlig lar Reolink være i fred. Det er noe tull med firmwaren som ikke klarer å levere stabile video-strømmer, om jeg skal tro div. bug-rapporter. De nyere 4K kameraene støtter ikke H.264, bare H.265. Iflg, Frigate så trengs H.264. Hvordan opplever dere at de forskjellige Reolink-modellene fungerer med Frigate? Har kikket litt på/etter Dahua og dets varianter under andre merkelapper. At Imou også hører til er nytt for meg. 🙂 HikVision er neste på lista for research. Disse Kina-varene har sine rariteter alle ihop 🙂

Jeg har prøvd å lese meg litt inn på kamera. Blir så jeg prøver å finne meg ett utendørs PoE som støtter flere video-strømmer i forskjellig oppløsning og Onvif i første omgang. Så får jeg se om Frigate er bra nok også som en NVR for meg. Om ikke så bør jeg være oppdekt for flere muligheter.

Ja, men det hører med i historien at jeg bruker gjennomsnittet av tre temperatursensorer i rommet. Den innebygde temperatursensoren i pumpa brukes ikke (med mindre openHAB slutter å mate pumpa med ekstern romtemp). Dette er bare sånn passe triggerbasert, dvs. det trigges ofte: when Item P_StueN_vedfyring_switch received update or Item P_StueN_avg_hum changed or Item P_Ute_avg_temp received update or Item PtempTargetDiff_StueN received update or Item VarmepumpeAggressiv changed or Item PVp_StueN_fanlimit changed then I tillegg så har jeg en timer på 30 sekunder som sperrer endring av varmepumpemodus. Endring av modus skjer ikke så ofte, da hysteresene ligger i "if else" -kriteriene. Når først pumpa blir satt i en modus så holdes den "litt lengre". Default -modus for pumpa er "HEAT". Dette ble ikke med i kodefnutten over. Ja, pumpa står på hele tiden, men den gjør ikke noe annet enn å røre litt i lufta når modus er "FAN"

targetTempDiff = PtempTargetDiff_StueN.state as Number // Finn riktig modus for varmepumpa if (P_StueN_vedfyring_switch.state == ON) { // Dersom vi fyrer så skal pumpa gå i viftemodus vpSetMode = "FAN" } else if (Gby_LeilN.state == ON) { // Viftemodus når vindu eller dør er åpen vpSetMode = "FAN" } else if (targetTempDiff > 2 && P_Ute_avg_temp.state > (Set_StueN_target_temp.state as Number -2 )){ // det er noe helsikes varmt vpSetMode = "COOL" } else if (Vp_StueN_mode.state == "COOL" && (targetTempDiff > 1 || P_Ute_avg_temp.state > Set_StueN_target_temp.state as Number -2 ) ) { // Hold Kjølemodus til vi har kommet ned mot setpunkt // Om høy ute-temp så beholdes kjølinga på vpSetMode = "COOL" } else if (Vp_StueN_mode.state == "COOL") { // Viftemodus er det eneste riktige etter at nedkjøling er ferdig (forhindre HEAT-modus) vpSetMode = "FAN" } else if (targetTempDiff > 1.6 && P_StueN_avg_hum.state > 50 && P_Ute_avg_temp.state > 15) { // det er klamt om kveldene når luftfuktikheten er høy vpSetMode = "DRY" } else if (Vp_StueN_mode.state == "DRY" && targetTempDiff > 1 && P_StueN_avg_hum.state > 48) { // hold tørking litt for hysterese vpSetMode = "DRY" } else if (Vp_StueN_mode.state == "DRY") { // Viftemodus er det eneste riktige etter at tørking er ferdig (forhindre HEAT-modus) vpSetMode = "FAN" } else if (targetTempDiff > 1) { // Prøv viftemodus når vi overskyter settemp vpSetMode = "FAN" } else if (Vp_StueN_mode.state == "FAN" && targetTempDiff > 0.2) { // Hold viftemodus til vi har kommet ned til setpunkt vpSetMode = "FAN" } Jeg håper kommentarene og variablene beskriver det meste.

Med Xeoma kan jeg sikkert komme i mål raskere. Men jeg av typen som uansett kommer til å dykke ned i materien for å utforske fleksibiliteten og mulighetene 🙂 Jeg starter fra bunnen av uten erfaring innen AI eller de tekniske aspektene i dagens overvåknings-kamereaer. Ser shinobi også har muligheter til å plugge inn TensorFlow med venner. Det er flere løse tråder jeg ikke har helt klart å for meg hvor passer. Som feks. å splitte video-strømmen fra ett kamera mellom Shinobi og Frigate. Det aner meg at det bor noen djevler i detaljene dær. Nåvel, jeg får bare skaffe meg et kamera og begynne. Noen tips om hvilket kamera jeg bør anskaffe?

Takker for god og håndfast info! I første omgang var det objekt-gjenkjenning jeg fisket etter, men ser nå at det er lurt å tenke litt på håndtering av video i samme slengen. Om jeg har forstått det riktig, så kan en Rpi4 da klare objekt-gjenkjenning av både innsiden og utsiden av en port. Og siden jeg uansett må ha noe til å styre porten så kan rpien likegodt få den oppgaven også.

Og da kom det enda mere å lese på 😉 Frigate er bygget over TensorFlow. Ansiktsgjennkjenning er heller ikke et must. Frigate rapporterer over MQTT, så da kan man annta at den biten er i boks. Absolutt en kandidat dette. Cuda-baserte greier tror jeg jeg hopper over inntil videre. Jeg er ikke så veldig begeistret for Nvidia. Men må man så må man.

Etter litt søking og lesing: Tensorflow ser faktisk ut til å kunne klare mye av ønskelista 🙂 Også på raspberry pi med kameramating. Åpner også opp for tilstede-deteksjon som skiller mellom person, hund og katt. Og så er det PyTorch. Må lese mere om den. Noen som har brukt/bruker disse eller tilsvarende? Her er det mye nytt å sette seg inn i..

Jeg har kommet fram til at jeg trenger noe utvidet funksjonalitet på bevegelses-detektorer :-B Utfordringen er som følgende: Husets damemennesker har kapret bil-garasjen med sine biler. Hvorav damemenneske 1 fort kan finne på å legge beslag på min bil i tillegg til sin egen om den er snøfri eller bare er laglig til for hogg. Jeg ønsker meg derfor at porten på bil-garasjen automatisk åpner seg når de to nevnte damemennesker kommer gående mot porten. Eller de kommer i en av de nevnte tre biler. I tillegg er det meg selv og gamlingen (på elektrisk rullestol) som gjerne må åpne porten om vi roter oss dit. Jeg har også andre porter som helst skulle gjennkjent traktor, snøscooter, minilaster eller også generell bevegelse framfor porten. Om naboens John Deere åpner den gjeldende porten på lik linje med min egen, bekymrer meg ikke. Det viktigste er at portene er lukket for innsyn og vær og vind til vanlig. Spørsmålene blir da: Finnes det noe billedgjennkjenningssytem som kan dekke disse behovene? Windos-baserte greier står jeg glatt over om jeg absolutt ikke må gå den veien. Til syvende og sist må jeg også på ett eller annet vis få sent noen definerte kommandoer til openHAB. Finnes det noe jeg kan ta i bruk dær ute?

- USB-stikke på forlengerkabel for å minske sjansen for interferens mellom USB-stikka og PC. - Slå av WiFi/bluetooth radioer om du ikke bruker dem. Regner med at du har sjekket kompabilitet på dingsene. Aqara er ikke akkurat kjent for å følge zigbee -standard..

Pi4 er helt ypperlig når man kan unngå mye skriving til minnekortet. Enten har man alt i RAM og buffrer logging og databaser med store og få skrivinger til kortet, Eller man putter på en SSD. Som et eksperiment har jeg en Pi4 som er router/brannvegg/VPN/DHCP/DNS-filter. Alt kjører i RAM. Det fungerer ypperlig med PoE-kort, hvilket bidrar med å holde kabelspagettien nede. En ethernet-kabel er det eneste som er tilkoplet. En sånn løsning ønsker jeg meg for openHAB også. Nå kjører jeg openHAB på en NUC og det er overkill med RAM og CPU, det kunne fint ha kjørt på en Pi4 sånn sett. Derimot, med sporadisk debug-logging, influxdb/grafana og diverse annet med litt AV i emninga ville jeg slitt med ett minnekort. Med backup og en komplett Pi i reservedelshylla så kommer man langt for en billig penge. Jeg vil ikke underslå det den ekstra leamikken og spaghettien en SSD på Pi medfører med kabler og strømforsyning. Ser det kommer produkter som mer eller mindre minsker leamikken rundt Pi-en. Men så var det situasjonen med tilgjengelighet på Pi og tilhørende komponenter..

Det kommer an på.. 🙂 Du trenger utesensor(?), innesensor for hvert rom, lyspærer, dimmebrytere og muligens noen veggplugger. Om du tenker å gå for Hue sitt system så må du ha en Hue-hub. Hue-hubben er begrenset mht. båndbredde, så det kan hende at du må ha flere hubber for ett større annlegg. Home Assistant, HomeSeer og openHAB er kapable til å kjøre ett større mere avansert system med en zigbee USB-stikke (om du vil gå den veien). Men en Hue-hub er muligens en god start. Selv finner jeg den begrenset mht. automatisering. White Ambiance belysning koster mere en vanlig ensfarget, men å ha muligheten til å justere hvit-fargen er meget behagelig. Det kjøpes inn minimalt med ensfarget hvit belysning hos meg, selv for utendørsbelysning. Og, ja, jeg blir sikkert aldri ferdig med å smartifisere, så det kjøpes inn litt og litt.

Jepp, jeg skulle også hatt disse i "White Ambiance". Selv om jeg da kun bruker slike sterke pærer i utendørsbelysninga. Innendørs er det kun "White Ambiance" som gjelder.

Mine Popp er POPE700397 og de virker iallefall særdeles dårlig for meg. Har et par stykker som ikke er defekte/ødelagte (vel, som de er fra skapelsen av) Gies bort om noen kommer og henter..

Advarsel: Nå sorterer jeg under en trangsynt kam. Jeg sikter ikke på noen av de som frekventerer hjemmeautomasjon.no 😉 Facebook- gruppene med faglig innhold er mest egnet for de med teflon-hjerne eller med bastante og fastlåste meninger. Gjerne kombinert med sviktende faglig kunnskap og gangsyn. De svarene du får på spørsmål kan være direkte farlige! Eksempel: Gruppe for hjemmelading. Gud bedre! Men duverden så godt egnet de er for å trolle litt. Man kan være både for og imot både ulv og sau bare man venter fem minutter mellom hver gang man skifter vinkel så ditt forrige innlegg får litt tid på seg til å scrolle av skjermen 😄

Sjekk denne også. Mine har dårlig radio og vaklevoren firmware. Den er desverre ikke egnet som router i meshet pga. dette. z-wave sin integritets-sjekk på pakkene i meshet er ikke av den bombesikre typen heller. Så med litt spredte dingser og mindre bra dekning kan mye rart skje. Jeg har ett rele på en utelampe som noen ganger slår seg av når Poppen slåes av. (samt også noen ganger når den rapporterer at status er OFF. Tror jeg. Uansett når jeg trekker Poppen ut fra uttaket så oppfører utelampa seg som den skal).

Siden trådstarter kjører openHAB så bør det være en stikke med "ember" chipsett fra Silabs. Dette er absolutt ett krav for openHAB-zigbee bindingen. For andre rammeverk som zigbee2mqtt så støttes TI chipsett også. Felles for alle rammeverk er følgende: Dess nyere chip og firmware, dess bedre! Litt gammelt spørsmål, men fortsatt like aktuelt.

Det høres ut som om Hue kan være en god start. Jeg fant Hue-huben og tilhørende App begrensende mht. litt mere detaljstyring. Men det virker og er stabilt. Og investeringen er ikke bortkastet om du velger å gå videre til feks. Home Assistant, HomeSeer eller openHAB. Om/Når du flytter så tar du med deg dingsene som da kan taes ut av sokklene.

Kanskje ingen av dem...? Aeotec Gen5+ er kompatibel med rpi4. Aeotec Gen5 ( uten pluss er IKKE) Personlig ville jeg gått for en USB-stikke i tilfelle oppgradering til et Amd64 -system. Siden det er snakk om rpi4 regner jeg med at det er Linux som Os. Da kan UZB1 være ett bedre alternativ da det eksisterer ett kommandolinje-verktøy for å ta backup av stikka (alle nodene på z-wave er lagret i stikka). Dessuten batteriet og knappen på Aeotec-stikkene er å annse som en gimmikk og unødvendig mikkmakk. Z-wave noder bør inkluderes via meshet på det stedet de skal brukes. Dette fordi Z-wave kan være ulidelig treg til å få med seg at noder flytter seg i meshet, med ustabilitet som resultat. 🙂 Og man bør ha to USB-stikker. Shit happens og man må restore stikka fra backup. (har hatt to defekte Aeotec Gen5 og en def UZB1)

Duverden, mao: "Vårt produkt er sertifisert. At produktet er vanskelig i bruk er ikke en produktfeil". Heatit: skjerp dere 😉

https://www.kjell.com/no/produkter/smarte-hjem/fjernstrombryter/fjernstrombryter-zigbee/osram-smart-zigbee-fjernstrombryter-for-utendorsbruk-p51049 Ja det er den. Og, ja strømmåling er meget unøyaktig. Om den ser belastning så sender den "6400" (eller noe sånt). Ellers null.

Jeg hadde fire sånne z-wave Popp: kun to virker nå på tredje vinteren. Disse har en dårlig radio og tvilsom kvalitet på firmwaren. Virker kun ok når det er mange noder i nærheten. Videre her jeg suppelert med to zigbee Osram Smart+ for erstatte Poppene. Disse router IKKE i meshet. I tillegg vil de ikke være "parent" for Hue sine dimmer-fjernkontroll eller bevegelse/luminans/temperatur -sensor. Om det da ikke er alternative noder som kan stille opp som "parent", sa faller Hue-sensoren ut av meshet. Jeg anntar at dette kan være tilfelle for andre sensorer også. Begge disse skavankene hadde også en Osram Smart+ lyspære som nå er arkivert i "hall of shame". Så lenge det ikke er noen noder som er avhengig av å route via Osrampluggen, så er den ok. Ikke all verdens radio på den heller, menn sånn passe "tja". I nøden har jeg brukt Ikea sin 16A veggplugg og også en Namron z-wave 16A plugg. (Namron -pluggen opplever jeg som meget bra!) Begge disse er innendørs -utstyr.. Jeg har ikke funnet noen utendørs alternativer. Må vel bygge noe inn i en boks om jeg vil ha noe stabilt utendørs..

@TomJacobsen Det er iallefall noen som prøvde seg. Kan være vanskelig å finne ut om de lyktes.. @MrEoisann, du har lagt opp en virkelig stor angrepsflate for banditter å boltre seg mot. Strakstilltak er ett stikkord 😉 Om man åpner port forwarding inn fra internet så må man være forberedt på trøbbel. Slike ting er kun fornuftige når man trenger en offentlig tilgjengelig webserver feks. Og den må stå i en DMZ. Og aktivt driftes. VPN er nok det mest fleksible. Men er det bare en ting man trenger og en reverse proxy er tilgjengelig, så bruk den. Jeg liker også Wireguard 🙂 Bere husk på at nå er den den offentlige tilgjengelige tjenesten som skal driftes. Om noen/noe kommer seg inn den veien så har de ofte tilgang til alt, så fallhøyden kan bli desto større. Det samme gjelder forøvrig alle VPNer.

Iot WiFi-enheter vil kople seg opp mot "routeren" og forhåpentligvis kommunisere med Homey-boksen som også er koplet opp mot "routeren". Bluetooth, zigbee,z-wave -enheter vil kople seg opp mot Homey-boksen på sine respektive interfacer. Mesteparten av trafikken som disse enhetene produserer vil derfor ikke påvirke det lokale nettet (som WiFi). Antall enheter som en typisk hjemme-"router" støtter vil variere. Det kommer an på minne, cpu og hvordan radio-delen er konstruert. De boksene som Internet-leverandørene typisk har levert ut kan være svært begredelige. Alt er skrudd samen etter kostnad. Resultatet er en dings dær alt er tynet ned til minimum. Jeg antar at det er slike ned-tynede bokser som er hoved-årsaken til advarslene/anbefalingene mot antall Iot WiFi-dingser. Når det er sagt: Zigbee og z-wave er laget for formålet. Det er ikke WiFi.