NorthWest

"Delvis"? Med delvis mener jeg at det ikke synes som om det gjøres en direkte endring av setpunkt fra master til slave, men det benyttes andre metoder/kommandoer som justerer slavens innstillinger. Bare spekulasjoner så langt... En kommando som kan benyttes er vel setback, som muliggjør en indirekte justering av slavens setpunkt, og som også kan endre slavens reguleringsmode til eco-mode. Jeg observerer jo endringer i slavenes reguleringsmode fra normal til eco, og tilbake igjen. "Nei, det hadde jo vært overraskende." Kanskje ikke mot slaveregulatorene, men det er litt overraskende at det ikke synes å være en mer direkte kobling mot Wall Plug'en. Kun spekulasjon igjen, men min første tanke er en reguleringsalgoritme hvor assosieringen brukes av master som tilleggseffekt, og hvor assosieringen kun trigger slavene i tilfeller hvor avviket ønsket temperatur er stor, eventuelt master må bruke over en definert mengde av egen tilgjengelig effekt. Forholdsvis avansert algoritme, men forklarer i stor grad mine observasjoner. Men igjen, kun spekulasjoner fra min side... "... trodde dette ble gjort automatisk hvis Gruppe 1 var assosiert til "HomeSeer (ID 1)". Er som sagt nybegynner innen dette, så seg vet rett og slett ikke hvordan jeg skal finne denne... Har du anledning til å guide meg gjennom prosessen med å avlest denne verdien? Gruppe 1 er assosiert til "Homeseer(ID1)" for alle noder på root-nivå. Svært takknemlig for all hjelp så langt! ?

Ja, har satt det opp slik. Masteren overstyrer delvis slavenes setpunkt, det virker ikke å være noen direkte kobling mellom releutgang på master og releutgang på slaveregulatorene. Samtidig tar masteren på seg en større lastandel enn slavene. Skal prøve å lage en forbruksberegning etter modellen som var lagt inn for Multireg på en annen tråd her tidligere. Vil jo i kombinasjon med et lavt/høyt setpunkt kunne gi en pekepinn på i hvor stor grad slavene styres av master? Har du noen formening om hvordan jeg kan få avlest setback-verdien?

Har sjekket litt rundt kommandoene som er tilordnet gruppe 2 for regulatoren, og finner en som kan peke seg ut: COMMAND_CLASS_THERMOSTAT-SETBACK Er beskrevet slik: ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- public abstract class CCThermostatSetback extends This class gives access to the functionality provided by the Thermostat Setback z-wave command class. To obtain an instance of this class use ZWaveDevice.getZWaveCommandClass(int, int). The setpoint is the temperature a device will try to maintain. The setback is a deviation from the setpoint. When a setback(override) is in use, the device will apply the setback to the setpoint, resulting in a different temperature. etSetback public void setSetback(byte setbackType, byte setbackState) throws java.io.IOException Sets the setback(override) of the thermostat setpoint. Parameters: setbackType - The type of the setback (override). The correct types are: Override.TYPE_NO_OVERRIDE, Override.TYPE_TEMPORARY_OVERRIDE, Override.TYPE_PERMANENT_OVERRIDE. The temporary override provides an opportunity to implement a timer or equivalent in the device. A temporary override will, if a timer is implemented, be terminated by the timer, if no timer is implemented the temporary override must act as permanent override. setbackState - The state of the setback in 1/10 Kelvin degrees. The correct state values are: 0 --> 0 Kelvin degrees setback. From -1 to -128 --> From 0.1 to 12.8 Kelvin degrees is subtracted from the setpoint. From 1 to 120 --> From 0.1 to 12.0 Kelvin degrees is added to the setpoint. 121 --> Override.STATE_FROST_PROTECTION 122 --> Override.STATE_ENERGY_SAVING_MODE 127 --> Override.STATE_UNUSED_STATE The values 123-126 are reserved. If the device is set to an unreachable state, the device must set itself to the state which is closest possible to the requested. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Denne funksjonen kan benyttes av masteren til å justere slavenes setpunkt på en enkel måte. Og en del av kommandoen er å endre reguleringsmode til ECO. Dette betinger jo at det går kommunikasjon mellom slave og master som ikke vises i loggen. Er det noen måter å få frem kommunikasjon på "assosiasjonsnivå" mellom nodene? Hadde vært svært interessant å se... Noen som kan forklare hvordan jeg skal gå fram for å hente ut setback via script? (Har hatt C-programmering for 20 år siden, så det går ikke helt av seg selv..)

OK, har gjort en liten test: 24 grader i rommet. Setter setpunkt på Master til 28 grader, setpunkt på to slaver til 20 grader. Har også assosiert en Fibaro Wall Plug til masteren for test. Hvis slavene opererer selvstendig, skal disse ikke slå seg på, da romtemperaturen er langt over innstilt setpunkt. Hendelseliste: Master går PÅ Wall Plug PÅ etter en tid Slave 1 PÅ litt senere Slave 2 PÅ etter ytterligere 15 sekunder. Endrer setpunkt på Master til 23 grader Master går AV etter 10 sek Wall Plug AV etter ytterligere 45 sekunder Slave 1 settes til ECO mode 30 sek senere Slave 1 AV etter ytterligere 5 sek Slave 2 settes til ECO mode etter 20 sek Slave 2 AV etter ytterligere 30 sek Deretter går master kortvarig PÅ, og AV igjen litt senere. Gjentar seg noen ganger. Ingen vitenskapelig test, men jeg er overbevist om at det her er en overordnet styring av slavene fra master-regulatoren.

Takk for svar! Jeg kan helt klart gå via eventer for å oppnå målet mitt. Men hvorfor gå over bekken etter vann hvis man ikke trenger det? Ja, jeg tror at assosiasjoner vil være et element for å gjøre systemet mer robust. Jeg har riktignok ikke opplevd at HomeTrolleren har gått ned ennå. I tillegg forstår jeg ennå ikke konseptet med assosiasjoner helt, og dette må jo være en god anledning til å lære meg dette? ? Godt mulig at jeg like fullt ender opp med en eventbasert løsning, men skal forsøke å danne meg en forståelse av hvordan assosiering av disse termostatene er satt opp først.

Takk for at du forklarer meg dette ☺️. Da forstår jeg assosiering slik: Node som skal styre en annen videresender sine kommandoer/målinger til en annen node, og disse meldingene blir kategorisert i en egen gruppe (her: gruppe 2). Hvordan vet man hvilke kommandoer/målinger som benyttes av mottakeren? Er det noen måter å sjekke dette på, eller må man finne dette i leverandørens manualer? Helt konkret, hvordan skal jeg se hvilke kommandoer og målinger min masterregulator sender til en annen node (slave)? Og hvordan skal jeg vite hvilke av disse kommandoene/målingene mottakeren benytter? Her sliter jeg med å se hvordan dette henger sammen, så beklager hvis dette er elementære spørsmål...

Du har sikkert rett... Men forklar meg, på litt grunnleggende nivå, hvorfor skal man kunne bruke assosiasjon på regulatorer? Er det kun for å kunne gruppere regulatorerene?

Tabbe av meg: Hadde re-aktivert eventen "Distribuer setpunkt", det var selvfølgelig denne som endret setpunktet på slavene, ikke noe annet. Beklager... Men når termostatene har fått lov til å operere på egen hånd i dag ser jeg med jevne mellomrom denne kommandolinja dukker opp i loggen hos slavene: "Device: Node 13 Stue Mode Set to Mode v2_Energy_Save_Heat " og senere "Device: Node 13 Stue Mode Set to Mode v1_Heat "

Det er problemet mitt at jeg ikke vet eksakt hva en "assosiasjon" innebærer. Trodde i utgangspunktet at det ga meg tilgang til måleverdier og statuser fra noder som jeg sto mer eller mindre fritt til å knytte til andre noder, men det var visst ikke så enkelt... ? Har nå assosiert to slaver til masteren, og observerer at setpunkt distribueres til fra master til slaver, og at slavene av og til skifter til ECO-mode. Ved første øyekast synes det å virke som om slavene av og til slås av på denne måten. Men klarer ikke å se hele algoritmen...

Hadde vært veldig greit med mikromoduler, men har problemer med å finne noen som: 1. Er på 16 A 2. Har mulighet til begrensning av gulvtemperatur for hver sone ved bruk av dedikert gulvføler. Man kan sette kombinere en frittstående sensor og et frittstående rele, men det blir like dyrt som en egen Multireg for hver sone. Tanken var derfor å benytte en egen Multireg for hver sone, og benytte en som master. Det enkleste formen vil jo være å kun distribuere setpunktet fra masteren til slavesonene, og la hver slave autonomt få styre sin egen sone. Men det vil sannsynligvis bli en relativt ujevn effektfordeling mellom sonene grunnet små variasjoner i temperaturmålingene på hver enkelt termostat. I ytterste konsekvens vil en sone stå for det meste av oppvarmingen for hele området. Det som er ønskelig er at alle regulatorene benytter samme, det vil si masterregulatorens temperaturmåling som referanse. Men like fullt overholder begrensningene for gulvtemperatur i hver enkelt sone. Alternativt at masterregulatorens utgang styrer slavenes utgang, og overholder begrensningene for gulvtemperatur i hver enkelt sone. Jeg har for så vidt fått til en "light-versjon" med events, og en +/- funksjon på slavenes setpunkt ut fra utgangsstilling på masteregulatoren. Men hvis en assosiering kan gi like god eller en bedre løsning, så er det kanskje mye enklere når man forstår hvordan man bruker dette... ☺️

Node 3 er da Multireg-termostaten, som er tenkt som slave. Skal gruppe 2 stå tom for de nodene som ligger assosiert under andre noder?

Hvis min mastertermostat er node 2,og slaven node 3, så skal det stå følgende: Node 2: Gruppe 2 --> Homeseer (ID1) Node 3 (ID3) Node 3: Gruppe 2 --> Homeseer (ID1) Korrekt?

Her er det jeg faller ut, og årsaken er for dårlige kunnskaper... Jeg har pløyd gjennom Homeseer-guidene, men har ikke fått taket på dette ennå. Har en liten terskel jeg tydeligvis må over. Er VELDIG takknemlig om du har anledning til å forklare dette steg-for-steg. Hvis jeg legger alle termostatene i gruppe 2, hva gjør jeg videre? Jeg har lett og studert alle menyvalg og faner under HomeSeer Web Control, men blir ikke klokere på hvordan jeg går derfra.

Hei, er helt ny innenfor området, og håper på litt hjelp fra noen av dere guruer der ute. Jeg kjører med en HomeTroller ZeeS2, og har ikke helt fått forståelsen for hvordan man bruker assosiasjoner i Homeseer. Målet er å sette opp en Multireg termostat som master, og en eller flere som slave. Med andre ord la master overføre temperaturmålingen sin til slavene, eller la master direkte styre utgangen på slavene. Er dette mulig på en enkel måte? Slik jeg har lest meg til her på forumet (og andre plasser), skal master settes opp med gruppe 2 assosiert mot Homeseer. Så langt, alt vel. Men hva gjør jeg videre herfra? Hvordan relaterer jeg slavene til gruppe 2 eller på en annen måte mot master?