psv021

Lange, super-kryptiske passord er vel ikke nødvendigvis sikrere (?) De er i alle fall nesten håpløse å bruke når passordet befinner seg på en annen enhet, f.eks på mobilen. Vanlige ord er derimot mye mer kompatible med kortidshukommelsen, og man "parser" det på brøkdelen av et sekund. Eksempler sjekket med Bitwarden sin passordsjekker: 23knef3_dj)h1:2 ("strong", >10 år å knekke) er dette lett å huske? ("strong", >10 år å knekke) mine 4 tilfeldige ord ("strong", >10 år å knekke) nittenseksti 1960 ("strong", >10 år å knekke) Den eneste forskjellen mellom de er at det kryptiske er vanskeligere å lese for et menneske. Men det er ikke så relevant. Så jeg påstår at ved å velge kryptiske passord så gjør man egentlig bare seg selv en bjørnetjeneste. Det gjør livet litt vanskeligere, og påvirker ikke sikkerheten. Man kan evt gjøre noen egne vurderinger om hvor avanserte passord man vil ha på ulike tjenester. Dersom man selv vurderer f.eks. hjemmeautomasjon som ikke særlig kritisk, så står man jo fritt til å velge et lettere passord. Jeg tipper den 15-minutters karantenen primært er et tiltak mot boter, ikke mennesker.

Tenkte kanskje det kunne være noen form for konflikt mellom HomeBridge og Homeseer eller noe sånt. Homebridge høres ut som det som er "annerledes" her. Men har ingenting å faktisk bygge en slik teori på altså. Hvordan ser dette eventet ut? Var det bare et enkelt event som gikk amok? Jeg tolker kanskje resten av innlegget som at det gjaldt flere eventer. Dersom det er tilfelle, så må (?) jo årsaken ligge i noe som påvirker flere/alle eventer. Hva er fellesnevneren? Er den f.eks. z-wave, så ville jeg zoomet inn på z-wave. Har alle de aktuelle eventene trigger på tid, f.eks.? Kan det være noe kødd med klokken på PC'en der HS kjører? Å gjenskape dette er kanskje tricky. Ellers gjelder det kanskje å klare å backtracke hva man har gjort før problemet oppstod.

Hvordan brukes Homebridge her? Har opplevd noe lignende med HS4 et par ganger, men det har utelukkende vært pga feilkonfigurering av eventer. Eventer som jobber mot hverandre, osv.

Byttet nettopp ut en av mine eldre IDlock 100 med en nyere 150 pga (svak) krakellering i panelet. Morgensol, og relativt værutsatt - og generelt brukt mye. Hos meg var det en mer jevn, mye svakere, krakkelering over hele skjermen. Men ingen åpenbare bruksmerker. Og på ingen måte så ille (ikke i nærheten en gang) som disse bildene. Generelt veldig fornøyd med låsene. Med unntak av litt rusk med z-wave, så har de vært dønn stabile til tross for mye juling gjennom årene. Kan det ha vært noe Antibac eller noe slikt involvert?

Jeg har temperaturovervåkning på totalt 4 kjøleskap og 3 frysere fordelt på 2 hus, syntes det er veldig praktisk. Alarm med pushvarsel ved avvik, alle data til InfluxDB/Grafana. For det første er det kjekt med data sånn generelt, for det andre er det kjekt å ha kontroll på temperaturen der man ikke er til stede, og for det tredje vil det bli lett å se dersom et skap begynner å oppføre seg utenfor normalen. Bruker små trådløse Zigbeemålere fra Aqara, som quackyo også nevner. Har vært litt ymse kvalitet på dem, og sikkert også på batterier, så har opplevd at de ryker ganske fort - spesielt i fryseren. Som jo ikke er så veldig rart. Andre holder lett i over et år før de ryker. Så det er litt bingo - sikkert også relatert til dekning, og hvor mye nettverkstrafikk de må generere (?) I "gamle dager" brukte jeg 433 MHz-termometre med ekstern føler. Føleren var koblet til måleren via en 2 meter lang, tynn ledning (sikkert ment for å henge ut gjennom vindu for å måle utetemperatur?). Det var ganske gull, siden all elektronikk og batteri da kunne plasseres utenfor kjøleskap. Ledningen var så tynn at det ikke var noe problem å snike den inn i kjøl/frys.

Får denne feilen fra Tibberseer på begge mine HS-instanser, startet midnatt: TibberPrice, Device updated failed for devtype =100, msg: Indeksen var utenfor området. Den må være ikke-negativ og mindre enn størrelsen på samlingen. Parameternavn: index Noen tips? Noe jeg kan fikse selv? Er på versjon 0.0.3.2. Ser det er noen nyere versjoner, men såvidt jeg kan se av changelog er endringene ikke relevante (?) Edit: Det gikk over. Men nå spammes loggen av denne: TibberConsumption, Daily time sum failed ...kanskje følgefeil? I så fall ordner kanskje dette seg også etter midnatt.

Litt off-topic, men tenkte jeg kunne gi andre som evt dukker opp her via søk en vei videre. Jeg burde jo forstått at det at et system forteller et annet system at det er i live (åpenbart) er et løst problem. Anbefaler https://healthchecks.io/ (betalt tjeneste, men opp til 20 checks er gratis - det bør holde for de fleste av oss). Du setter opp en sjekk, den får en unik URL, du pinger den URL'en jevnlig fra systemet som skal monitoreres. Reglene setter du selv. Jeg har satt begge mine HS-instanser til å treffe hver sin URL hver 10 minutt. Dersom det går mer enn 15 minutt går sjekken i advarsel, og etter totalt 25 minutter går det varsling. Dermed får jeg melding dersom mine HS-instanser er nede 25 minutter. Gode integrasjoner (jeg bruker Pushover + epost). Har brukt tjenesten noen uker nå, så langt fungerer det veldig bra. (Dermed er hele JSON-problematikken blitt irrelevant for min del nå.)

Opplevde det samme med en tidlig versjon (101) av ID Lock. (Disclaimer - dette er mange år siden, og jeg har hatt totalt 5 ID Lock siden den gang, alle har fungert glimrende og fungerer glimrende, så ikke tolk dette som en "ikke kjøp ID Lock"-anbefaling. Heller motsatt.) Det er ikke måte på hvor utrolig effektivt 1 dårlig node kan sette hele nettverket ut av spill. 7-8 minutters forsinkelse på lys, etc, slik du beskriver. Det jeg konkluderte med den gang var at den respektive låsen oppførte seg som om den var på faststrøm, men sendte ikke videre meldinger (for den går jo batteri).

Jeg håper også fortsatt på at Noen(TM) tar tak og lager en plugin. Jeg kan sikkert bidra med både testing og innspill, og potensielt også en PR eller to. Men å starte på en Plugin fra scratch, i C#, blir litt for høy terskel for meg akkurat nå. En vakker dag, osv... (Her hadde det vært kjekt å se koden til f.eks Tibberseer. Hadde nok kommet et stykke ved å kopiere og tilpasse derfra. Kanskje...) Hvis jeg skal beskrive et minimumsprodukt/startpunkt her, så ville det være sånn ca: - Lager, initaliserer og legger til/fjerner devicer i HS4 slik at det er 1:1 med anlegget. Det blir fort en del devicer, i alle fall konkluderte jeg med det når jeg laget noe i fjor. - Etablerer og holder på forbindelse til Homely via websocket. - Oppdaterer de respektive devicer når de endres i Homely.

Har ikke forsøkt selv, men ser at flere er fornøyde med HSBuddy (https://hsbuddy.avglabs.net/#/README). Er det noe å se på? Ellers kan du jo evt se på f.eks. Tasker (dersom du bruker Android) (du kan kontrollere HS-devices via HTTP-requests, jeg antar at Tasker kan fyre av en slik basert på location, men stikkordet her er "antar"). (For trigging av garasjeport - er det ikke, til syvende og sist, like enkelt å gjøre det low-tech med en tradisjonell fjernkontroll?)

Henger meg på og anbefaler varmt InfluxDB + Grafana. Bruker den løsningen på 2 separate lokasjoner. For det ene huset bruker jeg et script for å skrive fra Homeseer til InfluxDB, på den andre bruker jeg plugin Influx DB Persistence (den kan også lese tilbake fra Influx DB inn til HS for de som måtte ønske det). Begge deler funker fint, men anbefaler plugin. Uansett løsning, så anbefaler jeg at du konfigurerer hver device du vil speile til Influx for å unngå falske verdier. E.g noen devicer går til -999 som "undefined" osv. Angående mengde data osv. Jeg speiler sikker 200+ devicer til InfluxDB på den ene lokasjonen, og kanskje 150 på den andre. Plugin skriver kontinuerlig, mens scriptet er satt opp til å skrive hvert 10 sek eller noe sånt. I tillegg drar jeg ut masse metrics fra serverne HS kjører på (minnebruk, diskforbruk, etc) som logger hvert sekund minst. Alt dette har stått og tikket i snart 5 år på den ene lokasjonen, og i snart 2 år på den andre. Null stress.

Har en primærkonto, som har tilgang til begge systemer. Det er den jeg normalt bruker med MyHS. Den funker, f.eks. via connect44. Da går den på det primære systemet. Jeg antar at dersom jeg bytter primærsystem, så vil den gå på det andre. Problemet mitt oppstår når jeg ikke bruker primærkontoen. Jeg trenger, for det første, tilgang til begge systeme. For det andre ønsker jeg ikke å ha kontodetaljer for primærkonto liggende i klartekst... Kanskje dersom gjestekontoene har tilgang til begge systemer, men ulike primærsystemer...? 🤔 Edit: Nei, funker ikke det heller. Jeg tror jeg må konkludere med at JSON via MyHS fungerer kun for primærbruker mot primært system. Så det er jo litt håpløst langs flere dimensjoner... (Kan ikke være første gang noen forsøker å få to installasjoner av HS til å snakke sammen?)

Fungerer dette fortsatt - og med HS4? Jeg har klødd meg i hodet i ukesvis nå. Har 2 instanser av HS4 kjørende på hver sin lokasjon. Ønsker at de snakker sammen, for å fortelle hverandre at de er i live. Så ideen er å sende et "heartbeat" fra hvert system til det andre systemet f.eks hvert 10 minutt - da kan jeg plukke opp fra begge systemer om det andre systemet er nede, og varsle. Anyways, jeg tenkte dette skulle være relativt enkelt å løse via JSON, men det var på ingen måte trivielt. Nå har jeg gitt opp ca 27 ganger, men klarer liksom ikke helt å slippe det. Siden jeg har 2 systemer, kan jeg ikke bruke min primærbruker. Det vil kun fungere på primærsystem (default). Derfor har jeg laget dedikerte gjestebrukere for dette, som kun har tilgang til hvert sitt system. Å sende brukernavn/passord som en del av query fungerer for primærbruker på primærsystem, men det er åpenbart ikke innafor å lagre/sende det passordet i klartekst. Å sende brukernavn/passord som en del av query fungerer ikke for gjestebruker (401 Unauthorized). (Med HS4 kom det et krav om at en bruker må finnes også lokalt + MyHS - det gjør det hos meg.) Jeg begynner å mistenke at dette kun fungerer for primærkonto dersom man skal gjøre dette via MyHS - dermed er > 1 installasjoner støttet (?)

Fikk gode svar fra Bert. Og etter hvert fikk jeg også mottatt rå signaler på 433 MHz med RFXcom (utdatert firmware, utdatert software...). Plukket opp masse rart, men jeg tror ikke det jeg ser faktisk kommer fra min sensor. Vanskelig å si, vet ikke hvor mye forsinkelse jeg skal påregne. Og jeg spammes ned av andre sensorer som RFXcom ikke kjenner til. Sendt noe til Bert med forbehold, men han fikk ikke noe ut av det. Tipper at en nabo har en dings som prater litt mye. Kan det være at disse sensorene polles med en form for autentisering/kryptering...? Altså at de er stille inntil de mottar korrekt poll? 🤔 Uansett, det ser ikke ut som om jeg kommer særlig lengre. Moralen er: Aldri gi masse penger til et selskap som selger deg alarmsystem uten tilgjengelig API. Selv om de lover at et API kanskje kommer...

Melding sendt 👍