JxxxIxxx

Jeg har tidligere påpekt at det virker som om ovnene har inkonsistens mellom lokalt API og cloud og har to ulike setpoint-innstillinger internt, og at disse ikke alltid er synkronisert. Altså et setpoint for lokalt API og et for appen. Jeg styrer ovnene mine primært vha lokalt API (ikke fra HA, men fra et hjemmesnekret interface i Homeseer), og observerer inkonsistens i setpoint avhengig av om jeg setter eller forespør vha lokalt API eller cloud-appen. Eksempel: Hvis ovnen er satt til 20 grader i appen og jeg setter ny temperatur til 14 grader vha lokalt API, så oppdaterer displayet på ovnen seg til 14 grader, men appen oppdaterer seg ikke, den står forsatt på 20 grader. I tillegg: hvis jeg berører pluss/minus-tastene på ovnen for å stille manuelt så hopper temperaturen tilbake til app-temperaturen (20 grader). Motsatt så mener jeg at hvis jeg stiller temperaturen fra appen og så forespør om temperatur vha lokalt API så får jeg returnert den nye temperaturen, så det fungerer den veien. Jeg har tatt dette opp tidligere (tror det var i denne tråden), og mener å huske å ha fått bekreftet fra Mill sin representant at der var noe som manglet med samkjøring mellom lokalt API og cloud. Dette forklarer jo ikke helt den oppførselen du ser, med mindre det finnes to ulike måter (API-kall) for å forespørre om setpoint temperatur i lokalt API, og disse gir ulike svar avhengig av om temperaturen er satt vha lokalt API eller app. Og kanskje også to ulike kall for å sette temperatur. I så fall spørs det hvilken av disse kallene HA sin integrasjon bruker for å sett og forespørre ovnens setpoint temperatur.

Jeg hadde noe litt lignende for et par år siden, men ikke helt det samme. Hos meg så var symptomene at mange Z-wave-devicer slo seg plutselig på samtidig, helt tifeldig uten noen tilsynelatende årsak eller kilde. Lysbrytere, strømbrytere og til og med sirene på røykvarsler. I mitt tifelle var det sannsynligvis en "korrupt" z-wave enhet som tilsynelatende av og til sendte "on" kommandoer til alle andre enheter i nettverket. Jeg fikk aldri slått helt fast hvilken enhet det var, da jeg fjernet flere "mistenkte", og problemet forsvant da helt. Mest sannsynlig var det enten en av flere eldre Telldus Z-wave strømbrytere eller en termostatenhet som var satt opp til å styre panelovner av/på via direkte assosiasjon. Veldig vanskelig å debugge, da det skjedde kanskje en til to ganger i uka med ujevne mellomrom.

Så vidt jeg kan se så finnes det fortsatt en Free versjon av myHS, begrenset til ett system og en bruker (som før), men nå uten tilgang til Google/Alexa/IFTT gjennom myHS. Så forskjellen er da at de har fjernet støtten for Google/Alexa/IFTT, ellers er ting som før for gratisversjonen? Jeg bruker hverken Google eller Alexa eller IFTT på den måten så jeg vet ikke hvilke konskvenser dette vil ha for andre brukere. Hvis jeg forstår dette riktig så er tilgang via myHS bare nødvendig i de situasjoner der man ikke befinner seg i samme lokalnett som HS serveren? Så hvis man ikke har behov for å benytte Google/Alexa/IFTT når man er borte fra hjemmet så har vel dette ikke noen direkte konsevenser? Ellers så har det vel eksistert en betalingsversjon av myHS lenge, den gikk vel under betegnelsen myHS Premium og jeg har betalt for denne tjensten i en 3-4 år. Jeg har to separate installasjoner av HS, og hvis man ville ha tilgang via myHS til mer enn ett system på samme konto måtte man abonnnere på Premium. Tror den har kostet ca 25 dollar mesteparten av tiden jeg har hatt den, økte til ca 30 dollar sist jeg betalte hvis jeg husker rett. Jeg ser at i min myHS konto så står jeg fortsatt oppført med myHS Premium som produkt, til tross for at dette ikke eksisterer lenger på nettsidene deres. Jeg ser at min "gamle" Premium er cirka det samme som det nye nivået "Pro", men altså til en langt lavere pris. Jeg vet ikke hvor lenge de lar meg beholde min "gamle" plan, kanskje ikke lenger enn til neste betaling forfaller (i November), vi får se. Dersom jeg blir tvunget over på ett av de nye nivåene så vil dette representere en betydelig prisøkning for å få det samme. Hvis jeg går ned ett nivå, til Plus (klarer meg vel såvidt med det akkurat nå, har bare to aktive system) så er det fortsatt en ikke ubetydelig prisøkning. At man må betale for en løpende tjeneste som går gjennom en server driftet av Homeseer er vel kanskje ikke helt uventet, så kan man gjerne diskutere hva som er riktig prisnivå.

@Nettopp, prøver en gang til å vekke opp denne tråden. Det ser ut som jeg virkelig trenger hjelp til å sette opp mcsMQTT plugin. Har studert manualen i lang tid nå, men skjønner fortsatt lite av hvordan jeg konfigurerer den som broker og hvordan jeg får den til å hente data fra amsleser. Jeg har satt opp amsleser slik: der IP er HS4 serveren der mcsMQTT plugin kjører Men hvordan plugin i HS4 skal settes opp er ikke så greit å forstå for meg sånn uten videre.

Prøver å vekke opp igjen denne tråden. Jeg har litt ledig tid og tenkte å sette opp mcsMQTT plugin til å hente data fra amsleser til Homeseer. Jeg har installert plugin'en, men nå innser jeg at jeg nok likevel kommer til å trenge en detaljert oppskrift for å komme i gang, for dette var nok mer komplisert en jeg trodde, brukermanualen på mcsMQTT er over 600 sider lang, og jeg aner ikke hvor jeg skal begynne. Hvis jeg forstår det rett så kan jeg sette opp mcsMQTT plugin til å være "Broker" (har jeg forstått dette korrekt?), men jeg klarer ikke helt å se hvordan jeg skal gjøre dette. Oppsettet av mcsMQTT i HS framstår for en utvitende amatør som meg som en jungel av uforståelige parametre over utallige sider. Jeg er også usikker på hvordan jeg skal konfigurere Amsleser, er det nok å sette inn IP-addressen til HS-serveren? Og hva skal jeg sette inn i "payload", Client ID of Publish topic? Jeg hadde satt umåtelig pris på om noen kunne forbarme seg over meg og gi meg en liten oppskrift på hvordan jeg skal sette opp dette spesifikke caset. I første omgang er jeg mest interessert i å ha en device i HS som viser momentant effektforbruk. I neste omgang forbruk siste time/dag/måned.

@servercookie, jeg foretrekker å ha både lokalt API og cloud-tilkobling, det er mest fleksibelt, selv om jeg stort sett bare bruker lokalt API til daglig. Jeg vil helst slippe å omkonfigurere alle ovnene på to lokasjoner til bare lokalt API, det blir mye ekstrabeid tror jeg. Så det hadde vært fint om dere kunne sørge for at det ikke er noen uheldige interaksjoner mellom cloud og lokalt API (eller mangel på interaksjon kanskje heller i mitt tilfelle). Så langt så ser det ikke ut til at jeg har problemer med at cloud overstyrer lokalt api slik @quackyo har, vet ikke hvorfor dette ikke er likt hos oss. Hos meg er det bare problem at cloud temperatur ikke blir oppdatert med ny temperatur ved endring via lokalt API. Den andre lille "snag'en", det at ovnen "husker" tidligere temperatur satt manuelt eller via cloud og hopper tilbake til den når man trykker på pluss/minus-tastene eksisterte forøvrig også i den gamle versjonen. Dette er bare et mindre problem i det daglige, det er litt forvirrende hvis noen prøver å endre temperatur manuelt på ovnen, men det er ikke en showstopper. Men fint om dette kunne vært eliminert også. Jeg antar at de to problemene kanskje har en sammenheng i den nye versjonen.

Jeg har akkurat blitt migrert over til ny plattform, det gikk i utgangspunktet tilsynelatende stort sett greit. Jeg kontrollerer ovnene stort sett med lokalt REST API, men de er også tilknyttet cloud-løsningen, men alle ovner er satt opp som "indepentdent devices". Men det er en ting jeg stusser på: Det mangler nå "koordinering" mellom lokalt REST api og appen/cloud. Med det mener jeg følgende: Etter migrering viser appen en temperatur, mens lokalt api gir en annen temperatur, og disse er tilsynelatende uavhengig av hverandre. Eksempel: La oss si at ovnen i utgangspunktet står på 12 grader. Jeg setter den så til 22 grade via lokalt API. Displayet på ovnen skifter til 22 og ovnen slår på varme. Så langt alt ok. Men i appen står ovnen fortsatt til 12 grader. I tillegg så skjer dette: Hvis jeg trykker på pluss/minus på ovnens panel så hopper temperaturen direkte ned til 12 grader (pluss/minus en halv grad) på displayet. Så her er det tilsynelatende to ting: - Appen blir ikke oppdatert hvis man skifter tempertur med lokalt API. - Ovnen "husker" tilsynelatende to ulike setpunkt, det som blir satt med lokalt API og det som blir satt med cloud (eller manuelt på ovnen). Andre observasjoner: - Noen av ovnene har fått mac-adressen lagt til i navnet på ovnen i appen. - PID var slått på for alle ovner etter migrering. Jeg hadde disablet PID på alle ovner i det ene huset tidligere, da det tilsynelatende forstyrret lys som var kontrollert av dimmere og gjorde wifi-forbindelsen ustabil. Etter migrering var PID slått på igjen.

Kan ikke si at jeg har merket dette som noe problem. Tror kanskje jeg kan huske at det har skjedd en gang med en av dem, men da tror jeg det var relatert til at det begynte å blir dårlig batteri. Jeg bruker dem forøvrig ikke med HA, men med Homeseer (HS3).

Hvis du bruker events som termostat i stedet for å bruke den innebygde termostaten og direkte assosiasjoner til pluggen så er det enda mindre grunn til at dem skulle dra mye strøm, tror jeg. Jeg hadde tidligere satt opp flere av disse til å styre plugger på dumme ovner med direkte assosiasjon mellom Z-TEMP2 og pluggene, og de fungerte stort sett helt greit i et par års tid. Jeg har siden byttet til Mill Gen3 ovner og bruker nå Z-TEMP2 bare som "informasjonspanel" og som lokalt kontrollpanel for å styre Millovnenes setpoint manuelt ved behov. Det stemmer nok at det er ganske enkelt å koble inn strømlederne fra en USB-kabel direkte til batteriholder-polene, det burde fungere.

Jeg har flere av disse og har ikke hatt noen store issues med batterilevetid, i alle fall ikke noe i nærheten av det du beskriver, men jeg har måttet skifte et par ganger pr. år på de som er mest aktive. På en av dem har jeg eksperimentert med å delvis maskere bevegelsessensoren slik at den ikke slår på displayet bare noen er i samme rom, men bare når noen er ganske nær. Etter litt eksperimentering med matt tape på sensoren fikk jeg til en passelig sensitivitet. Ellers finnes det vel også en DC adapter fra Heatit som tar 12-24 V input, hvis du har mulighet til å legge strøm fram til enheten. https://heatit.com/produkt/10216/heatit-z-temp2-dc-adapter På en annen type termostat, et eldre design, som jeg brukte tidligere hendte det noen få ganger at enheten mistet fullstendig kontakt med pluggene den skulle styre og da gikk den tom for batteri i løpet av noen timer siden den tydeligvis fortsatte å sende kommandoer kontinuerlig uten å få svar.

1) Finnes det noen generelle enkle elektriske aktuatorer m ZWAVE eller Zigbee? Skal potensielt brukes til å åpne en liten luke/deksel, ikke store krefter og bare to posisjoner, helt lukket og helt åpen. Fortrinnsvis noe som går på 12 eller 24V. Det eneste jeg finner er aktuatorer for å åpne/lukke ventiler, men de kan vel kanskje tilpasses til å bevege andre ting enn en ventilarm? Noe sånt som dette: https://www.tronika.no/no/smarthus/zwave-produkter/z-wave-motorstyring/auto-ventil-gr-105-zw7.html 2) Og som en forlengelse av dette spørsmålet: Hvor komplisert er det å bygge en zwave eller zigbee enhet som styrer en vanlig servo (dvs en slik servo som brukes i radiostyrte modeller)? Finnes det noen byggebeskrivelser for noe slikt? Da er det snakk om å styre posisjon på servoarmen mer eller mindre "trinnløst". Antar at dette kunne lages vha f.eks. en Z-Uno og noe ekstra elektronikk? Dette er uansett langt over min kompetanse å designe selv, men hvis det finnes byggebeskrivelser så tror jeg nok jeg ville være i stand til å sette det sammen.

@servercookie hva er status på migreringen til ny plattform? Jeg har mine ovner satt opp både med lokalt REST API og Cloud, men bruker sjelden appen til annet enn å sjekke status og se at alt er oppe og går, ellers er all styring via lokalt API. Jeg har ikke sett noen meldinger i appen om at ovnene har migrert, skal migrere eller er oppdaterte, skal jeg få det eller går alt "behind the scenes"? Er det noen måte jeg kan sjekke status mhp or mine ovner?

Mine ovner ser ut til å ha versjon 0x230516, så det ser ut som en nyere versjon enn den som er dokumentert i github-linken ovenfor.

@servercookie Takk 🙂

Beklager min grunnleggende uvitenhet her. Jeg oppfatter det slik at dette er et cloud-basert API og ikke et lokalt API? Vil dette på noen måte påvirke det eksisterende lokale REST APIet for Gen3 som jeg baserer min egen "integrasjon" med Homeseer på? https://github.com/Mill-International-AS/Generation_3_REST_API Av forskjellige grunner er det viktig for meg (spesielt i det ene "huset") at jeg har en API som fungerer uten å være avhengig av å gå utenfor mitt lokale netverk. for hver eneste liten kommunikasjon med ovnene.