JxxxIxxx

Begge samtidig.

Har nå ekskludert og inkludert termostaten og det hadde absolutt ingen effekt, den oppfører seg på nøyaktig samme måte. Bare en masse arbeid å gjenopprette alt til slik det var før jeg ekskluderte. Så der er jeg stuck, enten "Invalid Value" og Unknown status på setpoint-devicen eller misvisende temperatur på gulvføleren. Ser ut som dette var et bomkjøp. Hadde jeg bare fått tak i et par Z-Trm2fx hadde jeg byttet tvert, de vet jeg fungerer i mitt oppsett og har vert dønn stabile etter at de fikk riktig firmware. Kjenner at jeg begynner å bli ganske trøtt av av diverse tull med Z-Wave-devicer nå.😠 Dere andre som har disse i HS, har dere samme problemene? Jeg registrerer at flere henviser til "Invalid value"-feilen, men har ikke sett noen nevne dette problemet med feil temperatur på gulvfølerdevicen.

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........