psv021

Ja, det hadde vært kjekt! 🙂 (Slenger på en oppfordring til å gjøre det open source og community-driven, e.g. Github og permissiv lisens, så har jeg sagt det 😉 ) Jeg konkluderte med at de aldri kommer tilbake, basert på gut feeling og på hva selgerne sier. Den gamle integreringen var vel litt hacky via scraping av Min Side, mener jeg? Anyways, jeg byttet fra Verisure. Anlegget var etter hvert blitt 8-ish år gammelt, og det var på tide. Både Homely og Atlo er betydelig billigere enn Verisure. I mitt tilfelle betaler jeg mindre per måned med Homely enn Verisure til og med når mesteparten av summen faktisk er nedbetaling av selve anlegget, som jeg da eier etter noen år. Alle de Zigbee-sensorene (røyk, bevegelse, vann, sirener, etc) kan jeg da bruke fritt med f.eks. DeConz dersom Homely ikke er kult lengre om 2-3 år. Så er det alltid en diskusjon om man skal betale noe som helst til et sikkerhetsselskap, og her har jeg sikkert litt slagside etter å ha jobbet i den bransjen tidligere. Men jeg står fast på å overlate akkurat den biten til profesjonelle. Så kan jeg ture rundt med mine egne ting på alt annet mindre viktig, der det ikke er kritisk at det alltid fungerer. Men integrering forventer jeg skal være mulig i 2023. I verdens rikeste land, osv 🙂

Jeg har tilfeldigvis både Homely (hjemme) og Atlo (på hytta). At Atlo bruker Zigbee (det gjør vel begge to) er ikke så relevant, da det er et eget lukket nett. Tilsvarende hva Philips Hue setter opp og andre. Den eneste (?) måten å integrere med HS (eller andre ting) på er da å få et form for interface mot alarmanlegget (API). Atlo har såvidt meg bekjent ikke dette. Litt irriterende, siden det var en av tingene de lovet å få på plass da jeg kjøpte anlegget for ~1 år siden. Jeg vet ikke om noen måte å integrere med Atlo på, dermed må man ha dobbelt opp av alt. Mens jeg irriterer meg over å måtte ha 2 sensorer oppå hverandre over hele huset fordi de ikke har åpent API, sier Atlo at de er "Smarhuskompatible". Homely virker litt mer oppdaterte her, og har faktisk et fungerende API (beta). Jeg har fått beta-tilgang og har tittet litt på det. Det er ganske greit å programmere mot. Å lage et VB-script som snakker med API'et og oppdaterer devicer, og kjøre det fra HS som et event, virker greit nok men en plugin ville være betydelig bedre. Jeg har imidlertid ikke kunnskap nok til å bygge en fungerende plugin. Når HS får native støtte for Python skal jeg heller vurdere det, men C# orker jeg ikke 🙂 Kanskje noen vil bygge en, en gang. I så fall håper jeg vedkommende gjør det med åpen kildekode og en fornuftig lisens på Github slik at alle kan bidra. Jeg ville i alle fall bidratt. Merk også at APIet kun tilbyr lesing av informasjon. Man får ut "alt" fra alle sensorer og selve anlegget, men man kan ikke (såvidt jeg har sett) kontrollere anlegget via APIet, e.g. slå av/på alarm. Jeg forstår godt at terskelen for å tillate det er litt høyere enn å kunne lese data. Jeg vet heller ikke hvilke planer Homely har, og i hvor stor grad man kan stole på at API'et forblir tilgjengelig og stabilt. Så svaret blir: Integrasjon mot Atlo virker å være en glemmesak. Man kan integrere mot Homely, men ikke uten betydelig egen innsats og programmeringskompetanse. Og uten en plugin, blir det litt halv-shitty. Men gjennomførbart. Kan også nevne at jeg er bare sånn halvveis fornøyd med Atlo, og vurderer å bytte til Homely også på hytta. Appen (Android) er langt under den standard jeg forventer, meldingene som kommer fra anlegget er ofte uforståelige, sensorene er ikke spesielt pene, og jeg har hatt masse problemer med oppsettet. Jeg har f.eks. et betjeningspanel som jeg enda ikke har klart å parre med sentralen, selv om jeg anser meg selv som relativt greit kompetent på det å få en Zigbee-dings til å registrere seg selv. En liten rant på slutten her: Jeg er så dritt lei av alarmselgere som ikke forstår hva man egentlig mener når man snakker om å integrere med smarthus. Hadde noen på døra her om dagen (husker ikke selskapet, helt ukjent navn), som insisterte på at de var kompatible med smarthus og at de var et veldig "fremtidsrettet" system. Begrunnelsen var at de hadde en egen app (!) der du kunne se temperaturene på røykvarslerne (...). Når jeg forsøkte å fortelle dem at "det er fint, men jeg vil lese av alle temperaturene hvert 5 sekund, døgnet rundt, hele året. Og jeg vil integrere med mitt anlegg, slik at mitt hus går i borte-modus når alarmen slås på, slik at jeg får en pushmelding dersom jeg har glemt å skru av tørketrommelen." Da blir selgerne helt stille i ca 10 sekunder (lurer på om de bare rebooter?), før de begynner på nytt å snakke om at de "har en app".

Takk for tips om tråden fra @berland Jeg tester litt på Homely sitt API nå, både med Postman og med kolaf sin kode (takk for den!). Men responsen fra f.eks. /locations er annerledes hos meg enn det som virker å være antatt i koden. Jeg mangler gatewayserial (får kun name, role, userId, locationId) for min ene lokasjon. Finnes det noe dokumentasjon på Homely sitt API?

Jeg har slik funksjonalitet på hytta, der vi typisk ligger og vaker rundt 5 kWt-grensen. Dette er off-topic for tråden, så nevner bare kort omrisset av dette: - En timer som starter hver hele time, og teller hvert minutt - En device som viser forbruk i inneværende time (jeg bruker TibberSeer, AccumulatedConsumptionLastHour) - En device som settes til ønsket terskel, f.eks. 5 (kWt) (hos meg har den valgene 0 ("Off"), 5, 10, og 15 kWt - Events som sjekker og reagerer. F.eks dersom terskel ikke er "Off", dersom timer er 50, <strømforbruker> er på, forbruk er større enn (terskel - <verdi>) - slå av <strømforbruker> i 40 minutter. Jeg endte opp med et event per strømforbruker (kun for de store forbrukerne), fordi at man må ha kontroll på state/tilstand slik at man kan slå ting midlertidig av. (Da må man vite hva man har slått av.) Så kan man justere litt rundt på dette til man får ønsket oppførsel. Men som Moskus så har jeg også mistet litt interessen for akkurat den biten der. Det er omtrent ingen penger å spare, så det er ikke proporsjonalt med den kompleksiteten jeg påfører systemet og den tiden jeg må legge i det for at det skal funke.

Kanskje helt på siden av det du spør om, men har du vurdert/forsøkt f.eks. JowiHue som gir deg alle enheter og scener fra Hue som devices i Homeseer slik at de kan integreres lett? Jeg har brukt den i mange år og er i alle fall godt fornøyd. Verdt pengene i mitt tilfelle.

Homeseer + Deconz + Philips Hue + InfluxDB + Grafana på Windows på to lokasjoner (hus og hytte). Tilgjengelighet eksternt er en liten nøtt. Jeg har valgt å bruke nginx som revers-proxy, med whitelisting på IP (kun tilgjengelig fra "mine" IP-adresser - så jeg må VPN'e hjem). Da har jeg ekstern tilgang til Grafana og HS. HS har jeg også ekstern tilgang til via MyHS. Det innebærer likevel at jeg har en port åpen mot verden. På den ene lokasjonen har jeg whitelisting av IP direkte i router, mens på den andre er det nginx som stopper. Ellers bruker jeg TeamViewer ganske aktivt for tilgang til begge serverne, det fungerer veldig bra. Backup: Standard HS backup til OneDrive. Oppetid: Jeg har valgt å la Windows styre sine egne oppdateringer, dermed må jeg håndtere restarter i ny og ne. Starter alt i riktig rekkefølge med Startup Delayer for Windows. Begge PC'ene er satt opp til å boote etter strømbrudd. Så langt har det gått relativt greit. Har ikke UPS. Kjente svake punkter hos meg: - Backup (og restore) av z-wave. Har med skrekk lest en del andre tråder der folk har seriøse problemer med dette. - HS kan visstnok være litt sårbar for brutale nedstenginger (som f.eks. når Windows rebooter), men foreløpig har det gått greit. (Håper jeg ikke jinxer det nå.) - Litt usikker på om det ER et svakt punkt, men det føles som et svakt punkt at trafikk på port X går helt inn til min Windows-maskin før den sjekkes av nginx som aksepterer eller avviser trafikk avhengig av IP den kommer fra. Nå har jeg riktignok også noen andre mekanismer for å blokkere, men skulle gjerne ha stoppet det før det kommer så langt. Har vurdert å sette nginx på en RPi og la ekstern trafikk treffe den først. Men om det betyr noe er jeg usikker på.

Klarer du å legge til 2 x pulse i 1 x TibberSeer plugin? Såvidt jeg ser må man legge inn HomeID, og den vil jo være forskjellig i de to lokasjonene (antar jeg?). Jeg har også 2 hus med 2 Pulse, men jeg har også 2 Homeseer-instanser, så da blir det "som normalt" begge steder.

Kjenner ikke home assistant, så dette blir kun basert på yaml ovenfor - men slik jeg tolker det, er calibrate_linear en liste over punkter i en kalibreringskurve. Så dersom du skal kalibrere jevnt 2.5 grader over hele spekteret vil jeg _tro_ (basert på kommentaren som står der) at følgende blir riktig å skrive: filters: calibration_linear: - 2.5 -> 0.0 - 12.5 -> 10.0

Startup Delayer har fungert bra for min del (jeg kjører HS på Windows 11). Sørger for at HS, Deconz, og alt annet som skal starte automatisk (ikke bare HS for min del) starter opp etter strømbrudd eller Windows update.

Og, et ønske - dersom det passer sånn en dag du er i koden likevel: Hadde vært fint dersom den nedtellingen hver gang RealTime ble flyttet til debug-logging. (Jeg mener det bærer mer preg av debug enn av info - det hadde kanskje vært mer nyttig å få info-logging dersom den ikke starter etter 30 sek.)

Takk, ser ut som om 0.0.3.2 funker bedre. Et annet relatert spørsmål - har det skjedd noe annet enten med API'et eller med hvordan TibberSeer håndterer realtime forbruk? Grønn kurve er realtime forbruk lest fra Pulse via TibberSeer. Hullet i kurven er nedetiden i går. Oppdaterte fra 0.0.3.0 til 0.0.3.1, og ser at kurven etterpå har betydelig flere spikes enn tidligere. Er ikke relatert til midling av kurvene i Grafane (midlet over 1 s på bildet, må opp i ca 5 minutter før kurvene ser like ut). Henter TibberSeer data hyppigere nå enn før?

Realtime funker fortsatt ikke for min del. Har Tibber i 2 hus og begge stoppet kl 11:54:48 i dag. Får forøvrig også loggen full av disse "sum failed"-meldingene. Versjon 0.0.3.0 i begge hus.

Takk for svar, da er det bare å konkludere med at problemet er der - ikke her. Så da legger jeg meg nedpå igjen og venter til det går over

Mistet signalet fra Tibber i dag kl 1317. Ikke så uvanlig det, må ofte restarte TibberSeer. Men denne gangen får jeg den ikke opp igjen. StartLiveMeasurementListener FAILED! Ex.Message: web socket initialization failed: {"type":"connection_error","payload":{"message":"Cannot read properties of undefined (reading 'newRelicLicenseKey')"}} Flere som har problemer, eller må jeg lete mer her? (Jeg har 2 hus, begge har samme feil.)

Slenger meg på med anbefaling av Aqara-sensorene, hovedsakelig pga pris og størrelse. Jeg har de "overalt", inkludert inne i kjøleskap og utendørs. Det eneste stedet jeg har hatt litt problemer med de, er inne i fryseren - som jo selvsagt er forventet. Batteridrevne enheter i en fryseboks er jo ikke smart. Har kjøpt IKEA signalforlenger for å utvide nettverket litt, det funker også bra. Jeg bruker disse med deConz, og så via JowiHue til Homeseer 3 og 4.

Jeg har disse: https://www.eldirekte.no/danfoss-radiator-termostat-z-wave/cat-p/c/p10636525 ...som virker å være utsolgt overalt. Evt gått ut, kanskje? Kanskje erstattet av en nyere modell. Anyhow, de fungerer ganske greit syntes jeg. Jeg bruker de via z-wave, men man kan fint bruke de direkte/lokalt også. Det er digitalt display, og justeringsknapper for temperatur opp/ned. Helt uproblematisk å bytte ut de gamle med de nye selv. Går på batteri, som hos meg må byttes kanskje 1-2 ganger i året.

Siden du allerede bruker Grafana høres det jo gjennomførbart ut å åpne for den. Du kan f.eks kjøre nginx foran som en reverse proxy, eller du kan bruke Apache som du skriver. Det innebærer selvsagt å åpne porter med den risiko det medfører, men med både nginx og Apache kan du sikre deg til en viss grad (passord, SSL, IP-whitelisting, etc, men det er ikke helt rett frem for oss som ikke har dette som yrke... Kanskje Dash fra Plotly kunne være noe for deg, men det er også en terskel - og du får stort sett de samme utfordringer som med Grafana. Da vil Grafana nok være bedre. Utfordring med å kjøre noe eksternt er vel at du har dataene lokalt. Så da trenger du eventuelt en tjeneste som syncher/sender data til en ekstern tjeneste, som da plotter de.

Denne filen er delt spesifikt med deg, så den lenken fungerer ikke for andre. Har du mulighet til å dele selve filen?

Hvilke feilmeldinger? Hva er det som går sakte? Selve homeseer, eller komponenter i huset? Det første du bør sjekke er om du har noe som pumper ut ting i loggen kontinuerlig eller noe slikt, og få stoppet det. Et bra sted å lete er f.eks. dersom du nettopp har lagt til noen events eller lignende.

Du kan jo legge dem i veggen og lage hullene når du vet hvor du vil ha dem. Får kanskje ikke FULL fleksibilitet, men i alle fall noe. I praksis så legger du (ferdig trukket!) rør i ca bokshøyde bortover. Når du bestemmer deg for plassering, borer du opp hullet, fisker ut røret, setter inn en tabbeboks og så CAT6-veggboks som vanlig. Tror ikke jeg ville gjort dette overalt, men dersom du har f.eks et rom der boksen er veldig styrt av møblering kan det være en utvei. I alle fall ingen problem å lage seg litt valgmulighet innenfor et par meter i hver retning. Du kan også kombinere i tilstøtende rom. Altså, dobbel CAT6 kan avgi en kabel til naborommet i ettertid om du trenger det.

Har akkurat bygget. La opp relativt rikelig med CAT6 fra svaktstrømskap til diverse steder i huset trodde jeg - men skulle lagt opp flere. Man har selvsagt ikke alt detaljert planlagt når man legger opp, så ting er ikke plassert helt der jeg trodde de ville plasseres. Skulle lagt opp flere tomme rør fra uteskapet inn til teknisk rom. Bestilte 2, fikk 1, trenger 3-4 stk. Fiber inn ble lagt i det ene som faktisk ble lagt. Skulle gjerne hatt CAT6 til uteskapet for å få tilgang til HAN-porten innefra. Veldig fornøyd med å ha husket på accesspkt i taket i siste liten, og fikk lagt opp CAT6 til den. (PoE.) 3 stk røykvarslere ble kablet med 230V, mens resten er på batteri. Dette for å tilfredstille kravene i TEK17. Med ubegrenset budsjett hadde jeg nok kablet alle. (Google Nest.) La opp 3x2xCAT6 til TV-plasseringer. Tanken var å slippe ekstra switcher bak TV osv. En baktanke her var også at det kunne bli aktuelt å plassere router utenfor teknisk rom. Bruker Amplifi hjemme, og den hadde fungert fint utenfor teknisk rom (pen å se på, osv.) Nå ble det Unifi i det nye bygget, og alt plassert på teknisk rom. Men, det var nyttig å kunne hjemme Hue bridge og slikt i TV-benken der den har bedre dekning. Savner flere CAT6-punkter utendørs. Jeg ønsket ikke å ta ansvar for gjennomføringer av yttervegg selv, så her ble det et kostnadsspørsmål også. Fikk elektriker til å legge opp 3x2xCAT6 utendørs, men savner 2-3 stk til. Disse brukes til kamera, og i de verste tilfellene har jeg endt opp med kamera en hel huslengde unna utepunktene. Så mye utvendig ekstra-kabling for min del nå. Veldig fornøyd med at jeg la opp doble CAT6 til alle punkt. Ferdig trukket rør med 2xCAT6. Så trenger man ikke bruke begge, men da har man muligheten til det - og man har en reserve dersom noe skjer med den første. Når rørene ender i et trangt svakstrømskap er det ikke sannsynlig at jeg klarer å trekke de på nytt noen gang. Jeg skulle gjerne hatt mer fleksibilitet på belysning. I de tilfeller der vi ikke visste nøyaktig plassering på lampepunkt (f.eks. over spisebord), la elektriker rør kveilet frem og tilbake bak gipsen. Så boret hun opp og satt inn boks når vi visste nøyaktig hvor punktet kom. Dette ble gjort flere steder, men skulle gjort det ENDA flere steder - da hadde vi hatt muligheten til å sette inn mer belysning ved behov. Trakk ut ringeklokke fra leveransen. I ettertid skulle jeg ønsket meg et trekkerør dit i alle fall. Kommer til å savne CAT6 evt tomt rør fra svakstrømskap til ventilasjonsanlegg når jeg finner tid til å begynne på den automatiseringen... La opp 40 mm (eller var det 50?) fra teknisk rom i kjeller til knevegg på loft. Tanken var at dersom det i fremtiden kommer solceller på taket, skal det være mulig å kable til de. Blir sikkert aldri noe av. Men uansett er det kjekt å ha et stort rør fra loft til kjeller, tror jeg. Anbefaler også noen tomme rør ut for fremtidige ting. Kanskje trenger du en elbil-lader på en ny plassering, eller lys i oppkjørsel, eller strøm til en garasje eller en bod eller noe. Eller bare et nytt utestikk.

Det er helt fint å gjøre det slik du gjør det her. I dette tilfellet er det nok overkill å gå via en virtuell device.

Jeg hadde samme tanker da vi bygget hytte i fjor. Gikk mange runder på dette. Elektriker stod knallhardt på at det var en veldig, veldig dårlig ide. Nå skal det sies at de ikke var spesielt drevne eller interesserte i smarthus. Diverse svar på ulike nettforum var vel i samme leia som elektrikerne: Don't do it. Så da valgte jeg å stole på disse. Argumentet jeg brukte for meg selv var at det er bedre å ha en bryter jeg ikke trenger, enn å trenge en bryter som ikke er der. Så nå står jeg der med lysbrytere som ikke skal brukes, og Hue-bryteren festet rett over, i et splitter nytt hus. Og det irriterer meg hver dag Hjemme har jeg erstattet selve bryterlokket med 3D-printede deksler her og der, samt at jeg har fjernet et par brytere helt (rammen står igjen, men kun med dekklokk). Funker greit selvsagt, men skulle jo helst sett at bryterne var helt borte der Hue blir brukt. Samtidig er det jo selvsagt argumenter FOR å ha tradisjonelle brytere også. I mitt tilfelle var dette veldig farget av de gode erfaringene med Hue, og Zigbee generelt. Skal du ha tradisjonelle lamper (ikke Hue), vil det gi mening å bruke vanlige brytere med pille bak. Det KAN du forsåvidt gjøre med Hue også, uten at jeg har testet de pillene. Men alt annet fra Hue er så bunnsolid kvalitet at jeg ville ikke hatt betenkeligheter med å satse på det sånn i ettertid. Et ekstra tips som kanskje er aktuelt for deg: Dropp i alle fall brytere til utelys. Noe mer ubrukelig skal man lete lenge etter. Er det noen lys som skal automatiseres, så er det i alle fall utelys Elektriker hos meg satte alle utelys på samme kurs med servicebryter i sikringsskapet. Så bruker jeg Hue på alle utelys.

Med EasyTrigger plugin vil du få litt mer valg enn hva HS native gir. Men jeg vil anbefale deg å lage en virtuell parameter (Av/På) som du justerer ut fra strømforbruk på stereoanlegget. Så baserer du videre automatiseringer på den virtuelle parameteren, ikke direkte på wallplug. (Dersom [Virtuell] har vært AV i exactly 5 minutes, kutt strøm) og (dersom strømforbruk er mindre enn 15 W, sett [Virtuell] til AV). Da isolerer du logikken din litt og slipper at mye hviler på 1 stk hardware. Jeg gjør det samme med kaffetrakter som du planlegger for stereoanlegget. Via en virtuell parameter trenger du heller ikke EasyTrigger (selv om det er en fantastisk nyttig plugin. Ja, det har jeg også savnet ved flere anledninger. Det blir alltid litt tankefeil med eventer av typen "before [klokkeslett]". F.eks. når du vil at eventer som trigges av noe skal skje på nattestid, men aldri på dagtid. En løsning her kan også være virtuelle devicer (variabler). E.g. du har en virtuell device som er enten NATT eller DAG, og så har du egne eventer som justerer på disse ved faste klokkeslett. Så bruker du de som kriterie i eventer som skal skje om natten/om dagen. Jeg har en HUSTID-parameter som justerer seg gjennom [NATT, MORGEN, FORMIDDAG, DAG, ETTERMIDDAG, KVELD] med en kombinasjon av faste klokkeslett og hendelser i huset, kombinert med en BORTE/HJEMME-parameter. Det er riktig nok ikke helt perfekt alltid, merker jeg.

Forsøk trikset under 👇