Fjosepose

Løsningen er at det er en bug i HS hvor det var et tilfelle hvor mcsMQTT hadde en blindsone, og ikke hadde implementert en workaround. Det som mangler var oppdatering av devicen´ ved endring av en en subscribed string. Ellers hadde jeg også feilaktig benyttet $$STATUS: istedet for $$LABEL: på publish for non-plugin-devices, men dette fungerte jo av en eller annen grunn ganske lenge likevel. Da jeg fikk rettet til $LABEL: fungerte det likvel ikke pga bug´en, men nå skal alt være rosenrødt!

Jeg kan til enhver tid se hva som skjer på brokeren, men koblet meg opp med MQTT-explorer. Med å benytte $$STATUS i "MQTT Publish Payload Template" så ble tydeligvis ingenting publisert. Dvs om jeg feks har min/med/max eller off/on så vil første knappetrykk virke, deretter slutter hhv min og off-knappene å reagere i påfølgende trykk. Om jeg bruker $$LABEL så suser all informasjon mellom HS VS og den andre klienten helt fint. Bivirkningen er at denne informasjonen ikke kan benyttes i events da det tydeligvis kun er value eller status som er med der. Slik jeg skjønner McSharry så er det $$LABEL som trigger MQTT om man opererer VDen med knappetrykk. Det å benytte $$STATUS har fungert helt prikkfritt fram til en eller annen gang i våres...husker ikke helt da mye av tiden har gått med til å pusse opp bad og det medførte at HS ikke ble tilgodesett med tilstrekkelig omsorg. For ordens skyld så bruker jeg non-plugin-devices(de lilla) som er opprettet basert på en allerede eksisterende VD. Om dette nå skulle virke så må jeg legge inn $$LABEL i "MQTT Publish Payload Template" slik at label-verdien fra VD legges i payload ved publisering (og ikke minst trigger), men med publisering må payload legges tilbake i $$STATUS. Nederste del av MQTT-oppsettet tyder på at det muligens kan være mulig, men jeg behersker ikke "disse feltene" enda. Mistenker dog at det er gjort endringer i mcsMQTT-module som utilsiktet har tullet til noe. Jeg brukte en god del tid rundt årsskiftet for å få utvikleren til å fikse status-delen for non-plugins til å fungere på en hensiktsmessig måte, og etter det så var det bra i noen måneder.

Ser ut til at jeg allerede hadde prøvd $$VSP: uten hell, gjorde noen flere forsøk nå uten å lykkes. For ordens skyld, det er her du mente at jeg skulle dette den inn: Ser ut ut til at VDen ikke klarer å publisere til broker status når jeg trykker på knappene: Ser dog at timestamp endrer seg men "verdiene" (her står de på min) endrer seg ikke. Jeg klarer dog å endre på disse "verdiene" fra den andre klienten.

Så den replacement-variabelen, men tiggget ikke at forkortelsen kunne bety dette! Høres svært lovende ut, skal på hyttetur med familien, men har seff med laptop for situasjoner som dette[emoji3] Sent from my iPhone using Tapatalk

Hei Jeg benytter mcsMQTT i HS4 og en elller annen oppdatering enten i plugin´en eller HS gjorde at oppsettet mitt ikke lebgre fungerer like bra. Jeg har flere VDs hvor jeg lagrer "setpunkter" for vifter(min/med/max) og modier(varme/kulde) og disse har jeg overført til et smartpanel med MQTT hvor jeg kan lese og modifisere verdiene. Oppdateringer skjer begge veier. I MQTT-oppsettet har jeg brukt $$STATUS: i feltet for "MQTT Publish Payload Template" og dette har "trykket ut" tekst-verdiene på payloaden slik jeg ønsker. Oppdateringer kom tilbake som tekst-verdier også og har tydeligvis "koblet" seg opp til status-feltet i VD´en. Dette har fungert finfint i alle henseender. Nå fungerer dettte ikke like bra, og jeg klarer ikke å sette tekst-verdiene fra "kommandoknapppene " i en VD dersom jeg bruker $$STATUS:, og etter litt "teksting" på HS-forumet fikk jeg tips om å benytte $$LABEL: istedet. Grunnen til dette er at plugin reagerer på knappetrykk gjennom $$LABEL. Nå fungerer den gjensidige oppdateringen mellom VD i HS og smartpanelet...MEN...så kan jeg ikke lenger bruker VD´en i EasyTrigger events action (set device to another device). Grunnen er at EasyTrigger nok bruker value eller status og IKKE label hvor informasjonen min nå befinner seg. Det er (kanskje naturlig nok?) ikke noen automatisk aligenment mellom treenigheten value, status og label...ved oppdatering av label. Kjører jeg de gamle eventene så settes de egentlige status-verdiene som ligger "bak/under" det som tilsynelatende ser ut som status, men er label. Så nå er jeg i en liten knipe. Finnes det noen måte når man subscriber å få innkommende payload til å bli "trøkket inn i" VD´ens status (istedet for label som jeg tror er saken dersom man benytter $$LABEL på publish)? Ser at nederst i MQTT-oppsettet at det er noe som muligens kan gjøre noe slikt?

Børstet støv av en gammel Sensibo, som jeg også kom på vil dekode telegrammene fra en varmepumpe-fjernkontroll. Har nå testet hva som skjer når man setter setpunktene for hhv "cool" og "heat", og det var som jeg antok at også tilsvarende mode settes(og endres) i samme slengen. Det betyr at man egentlig ikke trenger å forholde seg mode-settingen(mm du ønsker å slå av enheten). Eneste man må holde orden på er om det skal kjøles eller varmes, og deretter sette riktig verdi i tilsvarende setpunkt-register. For min del blir det da ett mindre pip hver gang varmepumpa styres av systemet mitt.

Antakelig under z-wave? Hvordan flytter man postinger?

Ok, men hvor skulle det være? Sent from my iPhone using Tapatalk

Jeg ville tenke at "auto chageover" er automodus der varmepumpa agerer etter settingene dine og temperaturen den selv måler. Så dersom varmepumpa måler 25 grader i rommet og modus = auto changeover så vil følgende skje: 1) Auto changeover setpoint=28 ==> varmepumpa varmer 2)Auto changeover setpoint=20 ==> varmepumpa kjøler Om dette stemmer så får man klassikeren med at varmepumpa på vinteren prøver å kjøle stua fordi du fyrer i peisen😀 Eller har du erfart noe annet? Jeg kunne tenke meg å styre varming og kjøling eksplisitt, men da må styringen skje gjennom events/scrips hvor jeg først gjør sjekk på om det skal varmes eller kjøles for så å skrive til riktig setpoint, og til slutt sette modus om den er endret(mm dette settes indirekte gjennom at man allerede har skrevet til aktuelle setpoint).

Etter nærmere fundering...siden det dukker opp child-devicer for alle disse setpunktene så er vel dette høyst sannsynlig en 1-til-1 representasjon av hvordan zxt-120 faktisk fungerer....og slik den fremstod i HC2 antakeligvis var antakelig en abstraksjon. Sukk, da faller nok valget på å lage et antall events som håndterer temperaturer og modi. Slik jeg skjønner virkemåten så vil enhver endring av en "varmepumpeverdi" trigge et telegram som drar med seg alle settings (setpunkt, vifte og modus). Man kan altså ikke bare sende kommandoer for temperatur uten å måtte resende alt annet. Om varmepumpa feks står på modus "Heat" og jeg submitter et "cooling set point" på feks 20grader så kvitterer varmepumpa med et pip. Jeg observerer at child device for modus ikke endrer seg, og kan vel da anta at modus fremdeles er "heat", men hva er det da som sendes over?

Jo, men det er ett setpunkt for "Heat" og ett for "Cool". Slik det dette i praksis ser ut til å fungere så må jeg nå legge til ett ekstra sett med setpunkter, samt logikk. Problemet slik jeg nå tolker det er at om jeg "submitter" et setpunt i HS så sier varmepumpa "pip", og basert på om jeg legger verdien inn i "heat" eller "cool" så skifter varmepumpa modus i henhold til dette. Modusknappen synes da ikke å være nødventil til annet enn å skru av varmepumpa. Tidligere kontrollerte jeg gjennom denne: Over streken er direkte kontroll av varmepumpa, mens under så er det smarthuspresets for dag- og natt/borte-innstillinger. Det som ble sendt over var setpunkt(modus-agnostisk), viftehastighet og modus. Jeg kunne ønske å bruke samme tilnærming nå, men det virker ikke mulig uten en "driver"...

Jeg har en Remotec ZXT-120 koblet opp til HS4. Devicen som dukker opp etter inclusion ser slik ut mhp temperatursetpunkter: Dette er litt uvant fra tidligere da jeg kun hadde ett temperatursetpunkt som da ble "sammenstilt" med mode(heat eller cool). Her ser det ut som om jeg må sette forskjellige setpunkter basert på om jeg skal kjøle eller varme. Jeg kjører varmepumpen enten på varme eller kulde (ikke noe automatikk), og ser nå for meg å måtte lage endel ekstra logikk for å håndtere setpunktene...eller er finnes det en smart måte å gjøre dette på der jeg kun trenger å forholde meg til ett temperatursetpunkt i tillegg til vifte og modus?

Det er nok en greie dette med signed/unsigned. Skjønner på en post at selv om HS viser verdien som signed, så settes verdien likevel korrekt i device, og da er jo mesteparten av (man)dagen reddet😀 Det betyr i så fall bare at man må ha kalkulatoren klar om man får en negativ parameter-verdi ut fra HS.

Slik jeg leser det så kan registerverdiene settes, i tillegg til 0=disable, fra 1 til 65535. Dette mapper over til tidsplanet med 0 til 6553 sekunder, altså maks 1 time 48min. Mitt problem er at registeret ikke klarer å ta i mot verdier høyere enn (ca) 32000...vet ikke om dette er et device eller HS4-problem...

Jeg flikker stadig på oppsettet mitt og i dag tenkte jeg å legge inn en "auto off" direkte i devicen som er en Fibaro FGS 222 (v2.2) Double Relay Switch. https://manuals.fibaro.com/content/manuals/en/FGS-222/FGS-222-EN-A-v1.1.pdf Jeg har opplegg for nedtelling i HS4, men tenkte at det kan være fint med en ekstra sikring av sterke lyskilder som kan være sjenerende om de blir stående på om natten pga en feil. Auto off fungerte fint i HC2, men der var det også et SW-lag mellom settings og de faktiske registerne. Nå jobber jeg rett i registerne, og i utgangspunktet så burde jo dette være riktig så enkelt. Register 4 og 5 styrer hver sin kanal mhp auto off tid: Ser at forklaringsteksten er noe misvisende, men fant at det skulle være 0.1s steps. Da burde 1 timer være 36000. Men det snodige er at registeret på to byte kun tar verdier opp til 320000. Alt over dette returnerer en negativ verdi. Nå har jeg sittet i boden og knotet, og orker ikke mer. Er det noen her som har FGS222 i sitt oppsett, og som kan bringe litt lys over saken?

Dette var en Heatit z-dim...løsningen(håper jeg) var å slette det som ikke passet, og legge inn node 1 i assos. gruppe 1.

Oppdaget forøvrig (litt tilfeldig) etter å ha gjørt en "node audit" at noen devicer mangler lifeline til controller, og at enkelt av assosiasjonsgruppene hadde "pekere" til devicer som både finnes og ikke finnes(node nummer langt nøyere enn det jeg har i mitt system). Jeg kan med sikkerhet si at jeg ikke direkte har gjort noe av dette...men hvordan det har skjedd er jeg usikker på. Vet ikke helt hva dette i praksis har medført men vet at downlighten på kjøkkenet hva vært noe tricky noen ganger. Jeg antar at alle devicer skal ha lifeline tilkontroller?

Dette var en bra detox for z-wave.nettverket! Muligens placebo men gui synes å være raskere også nå. Sent from my iPhone using Tapatalk

Her er noe som stemmer sånn ca: Skaleringen i register 17 ser ikke ut til å klaffe helt, men verdi 36 gir meg omlag avlesning en gang i minuttet. Tenker at jeg prøver med på å sette registerne til 100, og sjekke hva oppdateringsraten blir i praksis. Tviler på at parameter 18 slik den er satt default påvirker avlesningsresultatet.

Jeg har ikke Heatit trm2m (som kan/kunne byttes til trm2fx), se helt til høyre på denne linken: https://manuals.heatit.com På disse kan man i praksis kun stille inn samme parametere som man kan i menyen på selve termostaten. Ser ut som om jeg er prisgitt firmwaren 1.92 og hva den gir av rapporteringsintervall... Fant en post om at det er lagt til 5 ekstra parametere...får lete litt mer.

Sannelig så er det ikke mine Heatit z-wave (første versjon) som maser mest, og hver av de har de 80 kall på ca 15 minutter. Det blir omlag en rapport tvert 10ende sekund og når jeg har 6-7 stykker av dem blir det jo noe trafikk. Resten av nodene var stort sett stille. Jeg har oppgradert FW til 1.92 men ser ikke ut til at det finnes allverden med justeringsmuligheter på disse. Mulig at det finnes noen tips her på forumet...

Har en temperatursensor som jeg vet er masete…og som jeg skal ta i ettermiddag. Er forøvrig loggen i HS et greit sted å sjekke dette? Eller må jeg rigge opp zniffer for at det skal bli en ordentlig sjekk?

Da er jeg tilbake "on-track" til det opprinnelige spørsmålet om hvorfor enkelte devicer "mister" kommandoer relativt ofte. Har lagt merke til at dette skjer med lys og setpunkt for termostat. Nå er de fleste devicer forøvrig direkte mot kontroller: Hva er grunnen og botemiddel?

Ser jo at optimize ikke er å anbefale...en men en kjapp restore ordnet det. Ser etter nærmere syn at det typisk er batterienhetene som har 4 hopp, men at litt manuell justering av rutene fikser på det.

Måten jeg ser routingen på er grafisk i dette z-seer-programmet. Sent from my iPhone using Tapatalk