JxxxIxxx

Hvilken versjon av Z-wave-plugin har du? Jeg hadde veldig lignende problemer med versjon 3.0.10.0 av Z-Wave på HS3, og disse problemene forsvant når jeg nedgraderte til 3.0.9.0. Bruker HS4 samme Z-Wave plugin som HS3?

En liten korreksjon på dette siste, dette har faktisk en effekt på temperatursensor-problemet, det ser ut som det faktisk er det som forårsaker det: Jeg tok vekk igjen assosiasjonen uten endpoint i gruppe 1 og da forsvant tilsynelatende problemet med at gulvsensor-devicen blir overskrevet av internsensor-verdien. I alle fall har nå temperaturen vært stabil på det som ser ut som gulvtemperatur i over en time nå, ingen hopping fram og tilbake mellom to ulike temperaturer lenger. Men da kommer jo problemet med "Invalid Value" i loggen og "Unknown" status på setpoint tilbake. Og det er vel verre. Mye verre egentlig. Jeg forstår ikke nok av Z-Wave og HS til å skjønne hva denne assosiasjonen i gruppe 1 uten endpoint gjør. Men det ser ut til den fikser et problem og introduserer et annet Frustrasjonen vokser kjenner jeg.......😕 Vil det ha noe for seg å ekskludere og inkludere på nytt? Kjenner at jeg kvier meg for akkurat den operasjonen, da enten z-wave senderen eller termostaten må flyttes.

Det hadde jeg allerede gjort, basert på info fra deg i en tidligere tråd. Det fikset problemet med "Invalid value"-meldingene, men ser ikke ut til å ha noe effekt på dette andre problemet. Kanskje jeg forklarte meg dårlig: Jeg ønsker ikke å bruke den interne sensoren, jeg bruker gulvsensoren. Sensortype er satt til "F". Problemet er at det ser ut som om gulvsensor-devicen i HS blir "overskrevet" med verdien fra den interne sensoren. Untatt når jeg poller den, da får den sin egentlige verdi, for en liten stund. Det virker også som om problemet er likt på begge de to nye termostatene, de oppfører seg på samme måte ser jeg. Som en siste utvei skal jeg prøve å se om jeg får til å ekskludere en av dem og legge den til på nytt. Siden jeg ikke gjorde dette i etterkant av firmware-oppdateringen.

Enda en oppdatering: Hvis jeg poller gulvsensordevicen så går den opp til det jeg antar er korrekt gulvtemperatur. Men etter en stund (alt fra sekunder til flere minutter) oppdateres denne til å bli lik med den andre sensoren igjen. Virker som "noe" overskriver verdien i gulvsensor-devicen med verdien fra den andre sensoren.

Ytterligere oppdatering: Jeg stilte den ene termostaten opp til 30 grader mens målt temperatur på gulvsensor (i alle fall det jeg tror er gulvsensor) var ca 25. Oppvarming startet tilsynelatende, og Operating State gikk til "Heating" som forventet. Men etter å ha fulgt med på logger en stund ser jeg at den har tilsynelatende slått seg av igjen etter en stund. Og det uten at målt temperatur har nådd noe i nærheten av 30 grader ser det ut til. Og så slår den seg på igjen noe senere. Men det ser ut som den ene sensoren (den jeg tror er gulvsensoren) har korte "peaker" på 30 grader, og det kan se ut som dette får termostaten til å slå seg av. Dette er utrolig frustrerende hvis det er dete som skjer. vis den fortsetter å oppføre seg sånn så vil jeg aldri nå 30 grader i gulvet. Logging av den andre sensoren viser at den følger den første sensoren stort sett, på deismalen, men uten disse plutseilge peakene som kommer. En annen mulig tolkning av det som skjer er at gulvsensor-devicen av en eller annen grunn feilaktig viser temperaturen på luftsensoren, men at den av og til (når disse peakene kommer) viser gulv-temperaturen en kort stund. I så fall så når gulvsensoren target-temperatur og slår seg av, men jeg kan stort sett ikke se det fordi devicen feilaktig viser lufttemperaturen mestparten av tiden. Jeg er ikke hjemme akkurat nå, så kan ikke fysisk sjekke på termostaten hva den viser som målt temperatur der, det vil kanskje være oppklarende. Det slo meg at jeg har oppgradert firmware uten å ekskludere og inkludere termostaten etterpå, kanskje jeg burde prøve å ekskludere og legge den til på nytt? Vil helst unngå dette, da det er litt trøblete å flytte z-wave senderen og termostaten nær nok sammen, men dete er så mystisk at jeg ikke kan la være å prøve alt. Kanskje prøve en rescan først? Dette blir visst en lang monolog: Kjørte en rescan, uten at det ser ut til å ha endret noe. En kort stund viste gulvsensoren 30 grader, men nå er den tilbake på samme temperatur som den andre sensoren. En annen ting jeg stusser på er at når jeg kjører rescan så sier loggen til slutt: "15 out of 15 Child devices of node 87 were created successfully." Men det er bare 10 devicer totalt for denne enheten? Beklager hvis dete er et dumt spørsmål, mine kunnskaper om Z-Wave er bgerenset.

Kommentar til min egen post over: Det har slått meg like etter at jeg skrev posten over at det kan tenkes at jeg ha byttet om gulvføler-device og luftføler-device i HS og at det kan forklare den tilsynelatende ustabile temperaturen over tid. Så langt hadde jeg bare satt logging på det jeg trodde var gulvføleren, nå har jeg satt logging på den andre også for å se bedre hvordan den oppfører seg i forhold til den første. Det jeg uansett stusser på er at de tilsynelatende følger hverandre så tett, uten store avvik. Ville trodd at det skulle være vesentlige avvik mellom luf og gulv i noen situasjoner.

Jeg har ganske nylig anskaffet 2 stk Heatit Z-trm3 for bruk med Homeseer (HS3) hjemme, etter å ha hatt gode erfaringer med Z-TRM2fx på hytta. Etter en del innledende fikling har jeg nå (nesten) fått dem til å virke, men det er noen ting jeg stusser på. Jeg vet at det finnes flere tråder om denne termostaten, både under HS og andre, og jeg har lest og lest og lest og studert, og har funnet ut av noen ting, men er ennå ganske forvirret, det er en veldig stor mengde info i disse trådene og ikke alt er relevant for HS og noe er kanskje utdatert, så jeg er ikke sikker på at jeg har fåt med meg alt. Det jeg har gjort så langt: Mottok termostatene og kloblet dem på. Display viste "42" ved oppstart, vet ikke om dette er relevant, om det refererer til firmware versjon? Thermostatene er koblet med gulvføler. Inkluderte i HS og det så i utgangspunktet greit ut, men tilsynelatende fikk jeg ikke satt setpoint fra HS. I HS viste firmware som "4.0". Fant den "uoffisielle" firmwaren i en tråd her (Therm3_slave_enhanced_232_OTA_ZW050x_EU_SETPOINT_MOD_UNOFFICIAL.otz). Har oppdatert OTA fra HS, i alle fall tror jeg det. HS sa "Finished". Firmware i HS viser fortsat "4.0". Men nå fungerte det i alle fall tilsynelatende å sette setpoint fra HS. So far so good. Jeg la merke til at jeg i loggen fikk en "INVALID VALUE" melding hver gang "Operating State" endret seg, og at setpoint-devicen viste en feilstatus etter det. Det så likevel ut til å fungere. Fant dette problemet også nevnt i en tråd her og med info fra den tråden la jeg til en assosiasjon i Gruppe 1 til Homeseer uten endpoint. Da forsvant feilmeldingene. Samtidig forsvant også rapportering av Volt og Watt, det kan jeg leve med. Det som jeg nå stusser på er følgende: Det er tre temperatur-devicer for målt temperatur. Antar at de er henholdsvis gulvføler, luftføler og ekstern føler. En av dem viser ingen ting, antar at det er den eksterne føleren, som jeg ikke har tilkoblet. Det jeg stusser på er at de to andre tilsynelatende viser samme verdien hele tiden. Luftføler og gulvføler burde ikke vise likt nødvendigvis? Mestparten av tiden viser de nøyakig samme temperatur ned til desimalen, noen ganger er det litt avvik, noen tidels grader. Jeg vet ikke om det lille avviket er en følge av ulik rapporteringstidspunkt, for det ser ut som de følger hverandre tett over tid. Jeg har ikke sett dette nevnt i noen av de andre trådene. Siden den rapporterer så likt er jeg også nå blitt veldig usikker på hvilken av de to devicenen som er gulvføler og hvilken som er luftføler. Jeg har også satt logging på verdiene (logger til en fil hvert 10.min.) og det virker som temperaturen heller ikke er stabil over tid, den hopper av og til opp og ned ganske umotivert og har "spikes" opp og ned som jeg aldri har sett på en gulvføler tidligere. I dag tidlig var badegulvet tilsynelatende ikke kommet helt opp i full temperatur når jeg stod opp, til tross for at den burde ha hatt plenty med tid til det ift det tidspunktet på natta temperturen ble skrudd opp. Loggen på målt temperatur viser att tempeaturen har hoppet opp og ned ujevnt i stedet for å vise en jevn progresjon. Jeg vet ikke om det betyr at termostaten også har koblet ut og inn. Jeg har nå satt logging på Operating State også for å se når den kobler til og fra varmen. Det ser ut som det jeg nevner over gjelder for begge termostatene. Har sjekket at termostaten står i gulvfølermodus (F).

Takk for det, det så litt komplisert ut 😃 Jeg har allerede fått til en kode som virker med å sparke i gang en curl-prosess. Og akkurat når jeg hadde fått til det oppdaget jeg at APIet har en annen mulighet til å hente setpoint-temperaturen som jeg ikke hadde sett før nå. GET/control-status returnerer en samling med ulike parametre fra ovnen, deriblant også setpoint, og denne har ikke noen request body. Så det løser det umiddelbare problemet uten noen kompliserte programmerings-triks.

Den query-stringen APIet krever at man sender over i "request body" for å spesifisere hvilken "type" temperatur man ønsker returnert er jo forsåvidt formatert som JSON. (f.eks. {"type":"Normal"} ) Ellers så forstår jeg jo hvorfor man har valgt å spesifisere type av temperatur vha en parameter i en request body i dette tilfellet. Hvis man skulle brukt GET uten request body måtte man lage 6 forskjellige varianter av "set-temperature" (det er 6 uilke verdier av "type" definert). Så da måtte det blir GET/set-temperature-normal, GET/set-temperature-comfort, GET/set-temperature-sleep, osv. Men det ville jo løse problemet for Homeseer sin del slik det framstår nå. Kanskje man kan kan høre med Mill om de kan tenke seg å legge til disse 6 variantene uten request body i APIet. Hvis de gjør det så vil de ikke lenger "ekskludere" Homeseer (og andre klilenter som benytter .net framework) fra å bruke APIet. Det er bare denne (GET/set-temperature) pluss en til (GET/config-parameter) som bruker kombinasjonen av GET og request body så det er ikke så mye å endre.

Takk for at du bekrefter det jeg mistenkte. Jeg har også fått tilbakemelding av kompetente folk på Homeseer forumet som i allefall delvis bekrefter det samme. En måte å komme rundt dette på er å la scriptet starte en curl-prosess for å utføre spørringen, men det er jo en ganske klomsete måte å gjøre det på. Det jeg også ser er diskutert flere steder er at GET med request body ikke er helt "stuerent" i et REST API, men at det er mange som benytter det. POST er vel ikke helt "stuerent" det heller i akkurat dette tilfellet, ettersom jeg oppfatter det slik at POST er beregnet på å endre noe på serversiden, ikke å bare hente en parameter. Men det ville jo løst problemet i dette tilfellet hvis de støttet POST i stedet for GET.

Den koden jeg viste over var bare en av mange varianter jeg har prøvd. Jeg prøvde flere varianter med NameValueCollection slik du skisserer, uten at det så ut til å ha noen effekt på resultatet. Jeg har ikke tilgang til å teste mer før senere i dag, men kan jo prøve dette igjen, det kan jo være at jeg har gjort andre feil i min kode, tror ikke jeg gjorde det nøyaktig slik du har gjort det her. Mener jeg gjorde det omtrent slik: Dim queryString = new NameValueCollection() queryString.Add("type", "normal") client.QueryString = queryString altså at jeg ikke brukte Add på den siste, og det blir vel ikke helt det samme. Jeg tror jeg fant noen eksempler der det var gjort slik.

Har prøvd det også, men det blir POST så vidt jeg har forstått, og interfacet godtar ikke det ser det ut til.

Etter mange søk rundt omkring har jeg kommet til den foreløpige (usikre) konklusjon at det ser ut som .net frameworks standard metoder ikke støtter en GET request med "request body". Hvis det stemmer så er jeg usikker på hvordan jeg kan løse dette. Famler havveis i blinde her.

Jeg mener at dette var noe av det første jeg prøvde tidligere, men det fungerte ikke. Så vidt jeg husker fordi DownloadString bare tar en input-parameter, ikke to.

Jeg tillater meg å bumpe denne. Jeg har prøvd mer og mener jeg har forstått litt, men er ikke i mål. Det jeg tror jeg har funnet ut er at jeg må bruke DownloadString, og at inputparametrene ( {"type":"Normal"} ) må ligge i Webclient property Querystring. Da blir koden i scriptet noe sånt (ikke komplett): Dim source As String = "" Dim urlFunction As String = "set-temperature" Dim url As String = "http://" & IP & "/" & urlFunction Using client As New System.Net.WebClient client.Headers.Add("Content-Type", "application/json") client.QueryString.Add("type", "Normal") source = client.DownloadString(url) ........... ...... Dette gir imidlertid fortsatt "(404) Bad Request" som svar. Er det noen som kan si om jeg er på rett spor eller ikke?

Jeg vet at det jeg nå skal spørre om ikke er spesifikt for Homeseer-script, men jeg prøver likevel å legge det her, siden det er i et slikt script jeg prøver å få til en spesifikk funksjonalitet. I forbindelse med at jeg prøver å lage noen enkle små script for å kommunisere med en Mill panelovn vha lokalt API (i mangel av en plugin) trenger jeg hjelp med å forstå hvordan jeg skal sende JSON til ovn-APIet vha visual basic. Se ellers tråd: og https://github.com/millheat/Generation_3_REST_API Mine veldig banale programmeringskunnskaper strekker ikke helt til i dette tilfellet. Jeg er generelt i stand til å lage enklere HS script, men dette ser ut til å være et stykke forbi min simple kompetanse. Jeg har sett på et par andre script, bl.a. twinkly.vb som @Moskus har skrevet, og prøvd å bruke dette som utgangspunkt, men det blir ganske raskt åpenbart at jeg ikke skjønner heeelt hva jeg driver med, så jeg må krype til korset og be pent om noen har anledning til å hjelpe meg. Jeg har forstått at jeg kan bruke System.Net.WebClient. Og jeg klarer å få til de enkleste API-kallene, slik som f.eks.det som i curl-versjon er slik: curl -X GET -H "Content-Type: application/json" http://192.168.xx.xxx/status I vb blir dette noe sånt (ikke hele scriptet): Dim source As String = "" Dim urlFunction As String = "status" Dim url As String = "http://" & IP & "/" & urlFunction Using client As New System.Net.WebClient client.Headers.Add("Content-Type", "application/json") source = client.DownloadString(url) End Using Dette fungerer, og API-kallet returnerer en string som forventet. Videre har jeg også klart å få til API-kall som invovlerer POST, slik som f.eks. dette for sette innstil temperatur (i curl-versjon): curl -X POST -H "Content-Type: application/json" -d "{\"type\":\"Normal\", \"value\": 15}" http://192.168.xx.xxx/set-temperature I vb blir dette noe sånt (ikke hele scriptet): Dim urlFunction As String = "set-temperature" Dim query As String = "" Dim url As String = "http://" & IP & "/" & urlFunction Dim data As New System.Collections.Generic.Dictionary(Of String, Object) data.Add("type", "Normal") data.Add("value", 16) query = Newtonsoft.Json.JsonConvert.SerializeObject(data) Using client As New System.Net.WebClient client.Headers.Add("Content-Type", "application/json") source = client.UploadString(url,"POST",query) End using Dette fungerer også, og jeg er i stand til å sette innstilt temperatur på ovnen vha dette scriptet. Men, det jeg ikke får til er de kallene som involverer GET med data-input, slik som f.eks å hente innstilt temperatur. I curl-versjon er det slik: curl -X GET -H "Content-Type: application/json" -d "{\"type\" : \"Normal\"}" http://192.168.xx.xxx/set-temperature Her stopper det for meg, jeg skjønner ikke hva slags metode jeg skal bruke i vb-versjonen av dette. Har prøvd ulike ting med UploadString og DownloadString og annet, men får bare feilmedlinger eller krasj, så nå er jeg helt "lost".

Jeg tenkte bare for ordens skyld å gi en tilbakemelding på status på denne saken: Det er nå over to uker siden jeg fjernet den ene Popp-røykvarsleren som jeg mistenkte for å forårsake problemet. Systemet har så langt vært helt stabilt, ingen nye tilfeller av problemet. Siden feilen ikke skjedde så ofte så kan jeg vel ikke være helt sikker på at det er løst, men det har i alle fall ikke vært en så lang periode uten feil siden det begynte, så jeg krysser fingrene for at problemet nå er løst. Så må jeg bare finne en erstatning for den ene røykvarsleren jeg tok vekk ...... Siden jeg har egentlig gode erfaringer med Popp-røykvarslerne ellers, de jeg har i den andre HS-installasjonen min har fungert krikefritt i flere år, og jeg allerede har lagt opp 12V-tilførsel med plugg til der røykvarseleren skal være hadde det vært fristende å sette opp en av samme type. Men disse finnes tilsynelatende ikke i salg lenger, i stedet er de ersattet av en ny modell ser jeg. Antar denne har omtrent samme funksjonaliteten?

Jeg var visst litt for rask til å erklære at alt fungerer. Når jeg prøver å kjøre gjennom og teste de fleste API-kommandoene som er definert i dokumentasjonen så er det noen som ikke fungerer. Det gjelder spesifikt alle kommandoer som inneholder opsjonen "-d" og en påfølgende datablokk. Hvis jeg kjører disse i henhold til det som står i dokumentasjonen så returerer de konsekvent "Failed to parse message body". Dette er likt for alle kommandoer som inneholder -d. Eksempel, hente setpoint-temperatur: curl -X GET -H "Content-Type: application/json" -d '{"type":"Normal"}' http://192.168.xx.xxx/set-temperature Er det noen andre som har prøvd disse og fått det til å virke? Kan det være en eller annen feil i API-dokumentasjonen? Eller er det jeg som gjør noe galt (det er jo den mest sannsynlige forklaringen). Er det noen som ser noen åpenbare syntaks-feil i kommandolinjen over? Dette er kopiert mer eller mindre direkte fra API-dokumentasjonen. @servercookie kan du bekrefte at det som er i dokumentsjonen stemmer? De eneste endringene jeg har gjort er å sette inn IP, pluss at jeg har tatt vekk et mellomrom som var etter kolonet mellom "type" og "Normal". Så lenge dette var der fikk jeg en feilmelding fra curl: "unmatched close brace/bracket in URL position 7". ------------- Edit: Igjen ser det ut som jeg kan jeg kan svare selv: Etter litt leting angående curl-feilmeldingen fant jeg følgende: Det som ser ut til å være problemet er at curl på windows ikke støtter "single quotes" ('). Hvis jeg bytter ut kommandolinjen med dette fungerer det: curl -X GET -H "Content-Type: application/json" -d "{\"type\" : \"Normal\"}" http://192.168.10.107/set-temperature

Takker for svar. Jeg kan greit leve med at den er oppsatt med både cloud og lokalt API for øyeblikket, så jeg lar den bare være slik. Når det gjelder fast IP så er jeg klar over at jeg normalt kan "reservere" en allerede tildelt IP på en ruter. Desverre så har jeg av ulike grunner ikke denne muligheten på den spesifikke ruteren jeg har på dette nettverket for øyeblikket, så hvis jeg skal være sikker på at IP ikke byttes over tid må jeg helst sette fast IP på enhenter som krever en stabil IP. Jeg har en plan om å få fikset dette (bytte ruter), men det har ikke vært prioritert så langt siden jeg ellers enkelt har kunnet løse problemet ved å sette fast IP på de enhetene der jeg har hatt behov for det. Neste steg blir å se om jeg klarer å knytte ovnen mot Homeseer uten en eksisterende plugin. Så vidt jeg forstår eksisterer det ikke ennå noen plugin for dette i Homeseer, og jeg har ikke nok programmeringskompetanse og Homeseer-kompetanse (elller tid for den del) til å lage en plugin selv. Men jeg ser for meg at jeg inntil videre kan lage en enkel kvasi-løsning som gjør at jeg kan sjekke status og sette temperatur fra HS med noen events og noen scripts i HS. Jeg tror jeg har såvidt nok scripting-kompetanse til å klare å lage noen script som kommuniserer med ovnen vha APIet (bare jeg finner ut hvordan jeg sender/mottar API-kommandoene i visual basic).

Oppdatering: Etter å ha slettet panelovnen i appen og prøvd å legge den til med opsjon for både cloud og lokalt API så ser det ut som det fungerer. Så det kan se ut som opsjonen for "bare lokalt API" ikke virker (eller at jeg har misforstått noe her). Det er forresten litt upraktisk at man etter å ha lagt til ovnen ikke kan se hvilken modus den er lagt til i (dvs. med/uten lokalt API, cloud etc.) Et lite spørsmål til @servercookie : Jeg antar at det ikke er noen mulighet for å konfigurere den til fast IP?

Er det noe spesielt man må gjøre for å aktivere lokalt API ut over å velge dette under advanced når man setter opp Wifi? Jeg kjøpte en 600W Mill Gen 3 panelovn i dag med tanke på å bytte ut en gammel panelovn på "kontoret" hjemme. Siden jeg hadde sett denne tråden tenkte jeg at jeg skulle kjapt teste APIet "manuelt", med tanke på senere kanskje å koblen den til Homeseer på en eller annen måte. Jeg fikk greit koblet til ovnen fra appen (Android) og oppgraderte firmware. Ved tilkobilng til WiFi valgte jeg "Local API, no cloud" (eller noe sånt) under Advanced. Jeg fant IP adressen til ovnen på ruteren og bekreftet at jeg kan pinge den og at mac-adressen stemmer med det som står i appen, så jeg er sikker på at det er den korrekte adressen jeg prøver å sende til. Så prøvde jeg å sende en kommando til den vha curl. Jeg bare kopierte en av eksemplene i API-dokumentasjonen: curl -X GET -H "Content-Type: application/json" http://192.168.xx.xxx/status Responsen jeg får er denne: curl: (7) Failed to connect to 192.168.xx.xxx port 80 after 2522 ms: Connection refused Jeg må innrømme at jeg ikke har veldig god greie på nettverk og APIer og JSON og alt dette, har bare vært borti sånt litt sporadisk tidligere. Er det noe jeg gjør galt her?

Det stemmer, det er vel bare på "masteren" at det viser hvilke som er assosiert. Men alle enheter er vel assosiert til Homeseer på gruppe 1.

Det kan jo være noe sånt. Jeg har kjørt audit på alle enheter mer enn en gagn i løpet av de siste ukene. Nå siste når jeg fjernet den enen røykvarsleren så kjørte jeg audit på alle andre enheter og optimize på de som rapporterte en "invalid node" (den noden jeg hadde fjernet. Det som taler i mot en fast assosiasjon er at det ikke nødvendigvis er de samme enhetene som blir påvirket hver gang. Nå er den første mistenkte på lista mi (den ene Popp-røykvarsleren) fjernet, så får vi se........

Jada har sjekket sånne ting både en og fire ganger 🙂 Har gått gjennom alt av eventer og script for sikkerhets skyld. Det er ingen assosiasjoner som ikke skal være der og loggen ser ut til å bekrefte at det ikke er eventer eller kommandoer fra HS som trigger dette, da hadde den sett annerledes ut. Flere av de enhetnee som trigges er ikke del av noen automasjoner i det hele tatt, mange er ikke lys, men alle er enheter som kan settes i ON eller OFF. Det som skjer er også såpass "random" når det gjelder hvilke enheter som blir aktivert, at det er vanskelig å se for seg hvordan dette kunne være forårsaket av noe som var satt opp i HS. Så det er nok svært sannsynlig at det er en defekt enhet som av og til sender ut tilfeldige "skurer" av "ON"-kommandoer. Det vanskelige med denne er at det tilsynelatende skjer i løpet av ett sekund, og så kan det gå dagesvis før det skjer igjen neste gang. Som du sier så er sånne feil noe av de vanskeligste å feilsøke.....

Jeg tenkte det samme selv, noen sekunder etter at jeg hedde skrevet det 🙂 Jeg har hatt en Aeotec.plugg som hadde en tendens til å blåse sikringen på kursen den var koblet til når jeg slo den på. Den ble brukt som "hovedbryter" for en stasjonær PC som jeg bruker til bildebehandling. Den andre som feilet var en av to plugger som var assosiert til en SRT-321-termostat på hytta. Det skjedde en to-tre ganger at termostaten tilsynleltende ikke "fant" denne ene pluggen og den pluggen ble ikke slått på når termostaten slo inn. Det som var verre var at når dette skjedde så gikk termostaten tom for batteri i løpet av mindre enn ett døgn. Og da mistet jeg varmestyringen, noe som ikke er så praktisk på en hytte to timers kjøring unna når det er ti minus ute. Heldigvis hadde jeg laget noen temperaturalarm-eventer som slo inn når temperaturen ble unormalt lav, så det ble oppdaget ganske raskt. Tilsynelatende så opererte termostaten slik at når den ikke klarte å trigge pluggen så prøvde den igjen og igjen inntil batteriet var tomt. Hvis jeg tok plugggen ut av kontakten og satte den inn igjen så virket alt ok igjen. Så den pluggen ble pensjonert. Erstatteren (samme type) har fungert uten slike problemer. Akkurat det har jeg også innsett.😟 Når det tar dager mellom hver gang det skjer så er det ikke lett å debugge, spesielt når dette er på hytta der vi ikke er hele tiden. Status nå er at feilen skjedde igjen i en gang i går kveld, da var det tilsynelatende bare en bryter som ble slått på. Så skjedde det igjen i dag tidlig, da var det mange brytere som ble slått på, pluss sirenen på den ene Popp-røykvarsleren. Jeg slo av alt som var slått på og trodde jo at alt var av. Hs indikerte ikke noe unormalt som var på. Men nå i ettermiddag så reiste vi til hytta og når vi kom fram så var det første jeg registrerte at den ene røykvarsler-sirenen (bare sirenen ikke selve røykvarsleren) stod og hylte. Men i HS så var status på sirenen OFF 😲 Det gir grunn til å mistenke at denne enheten ikke er helt frisk tenker jeg, da den tilsynelatende ikke rapporterer tilstanden sin til HS. Og når jeg sjekker loggene over de gangene dette har skjedd, så er det alltid den andre røykvarsler-sirenen som har vist som ON i HS, ikke den som stod på i dag uten at det var registert i HS. Kankje har da den andre vært på hver gang uten at det har vist i HS? Når jeg tenker meg om så er denne røykvarsleren den første av de to jeg inkluderte, og det var litt problemer første gangen, feilmeldinger i HS og manglende devicer. Så jeg ekskluderte den og prøvde å inkludere den en gang til og da gikk det tilsynelatende bedre. Men det kan jo være en indikasjon på at denne ikke er helt frisk kanskje. I første omgang vil jeg prøve å fjerne denne ene røykvarsleren. Disse problemene begynte jo relativt snart etter at jeg installerte de to røykvarslerene. Det kan jo være tilfeldig og det kan være en av den andre enhetene som har begynt å fuske, men det er en viss sannsynlighet for at det er en av røykvarslerne som er synderen mener jeg. Lurer på å fjerne denne røykvarsleren fra systemet i første omgang og se om feilen fortsatt er der.