Fjosepose

Jeg kjører HS4(sannsynligvis ikke så viktig i denne sammenheng) og har en UZB1 USB-stick som jeg bruker. I denne sammeheng tenkte å oppgradere til Aeotech Z-stick 5+. Jeg klarer å ta backup av min UZB i backup-programmet til Aeotech, så da er det store spørsmålet om jeg også vil klare å restore til Aerotec Z-stick 5+? Jeg ville tro at dette er fullt mulig, men er det noen her som har forsøkt dette eller vet at det faktisk er mulig?

Ja, nå er det på tide å skrote tastafonen😃

Se der ja! Akkurat som bestilt👍

Hei Er det noen som kan fortelle om og hvordan man endrer på rekkefølgen til "child devices" i HS4? Jeg ønsker feks å flytte opp nederste "Gang........delay(2093)" etpar hakk opp. Har klart å stokke om knappene internt i en child device, men ikke seg i mellom.

Auda, ser jo dette nå....her kan jeg vel bare skylde på at øynene står i veien😀

Hei @Moskus Der kan se ut som om Homeseer plug-in for postlevering har feilet. Skal jeg tippe så har vel posten gjort en endring etsteds?

Takk for oppskrift. Da kan det se ut til at jeg heldigvis bare har taztet feil tre ganger ved inkludering. Regner med at en exclude/include må til, eller finnes det andre og smartere metoder?

Hei Jeg tok meg selv i å inkludere en device «secure» i HS4 noe som jeg har skjønt ikke alltid er bra verken for devicen selv eller systemet. Finnes det noe triks for å liste ut devicer som har «secure inclusion»?

Det er mulig at det ligger der...har skjønt at plugin til Verisure fungerer på HS4 dersom den er migrert til HS4 fra HS3, men direkte på HS4 er det noe mer vanskelig. Hos meg ser det ut til at Windows ikke vet at jeg har en UPS. Det kommer ikke noe batterisymbol i systemtray og jeg ser heller ikke noens spor av UPS-innstillinger i feks power plans eller andre steder. I Device Manager så kommer et bare opp to intetsigende deivcer under HID. Softwaren som er anbefalt til min UPS er ViewPower. Hvordan ser dette ut hos deg?

@Byelektrikeren fikk du noen gang UPSen fra PowerWalker til å fungere på HS4?

@Andreaz ser ut til at du har en BlueWalker som fungerer med plugin? Hvilken programvare bruker du?

Hei Jeg kjøpte meg en BlueWalker PW UPS VI 800 SW her om dagen. UPSen fungerer tilsynelatende fint sammen med anbefalt software ViewPower. Problemene begynner dog når jeg skal "koble" UPS til HS4. Etter litt graving og testing så virker det som om følgende kan være problemet: 1) UPS installerer seg som "HID-compliant vendor-defines device" and "USB Inout Device" i Device Manager, og ikke eksplisitt som UPS. Jeg antar at HS4 ser etter UPS-ressurser gjennom Device Manager? 2) Programvaren?

Hei....jeg klarte selvfølgelig ikke å vente særlig lenge før jeg måtte prøve. Jeg har satt opp backup-løsningen til å ta en full backup annenhver dag som dumpes ned til OneDrive. Det fungere tydeligvis helt fint å bare kopiere tilbake rubbel&bit fra backup😀 Eneste man må huske er å stenge ned applikasjonen.

Hei Lynet slo ned i pipa til et nabohus her om dagen og det gjorde at jordfeilbryteren vår slo ut. Den heller ukontrollerte nedstengningen av HS4 har tydelig forårsaket feil i HS-databasen, kunne se en feilmelding som tydet på det ved første oppstart, samt noen vedvarende kryptiske feilmeldinger. Uansett så er de fleste devicer borte så det taler vel for seg selv, men heldigvis har jeg kjørt full daglig backup. På meg ser det ut til at backup i praksis er en kopi av hele HS4 katalogen. Er det så enkelt at en restore er bare å kopiere siste ok backup ut til HS4-katalogen og overskrive alt der?

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