Assosiere Multireg

[NorthWest]

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?

 

[Moskus]

Er det ikke bare å legge til den andre noden i Gruppe 2 også? Slik tolker jeg manualen.

[NorthWest]

49 minutter siden, Moskus skrev:

Er det ikke bare å legge til den andre noden i Gruppe 2 også? Slik tolker jeg manualen.

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.

 

[Moskus]

14 minutter siden, NorthWest skrev:

Hvis jeg legger alle termostatene i gruppe 2, hva gjør jeg videre?

Du legger ikke noen termostater i gruppe 2, det er motsatt. For én enkelt termostat, så åpner du root (den øverste) -> Z-wave -> Associations (nederst). Der skal du legge til HomeSeer i Gruppe 2. Da velger du først Gruppe 2, og så "HomeSeer (ID 1"), og velger "Add".

 

Så gjør du det samme med den enheten du vil styre. Velg først gruppe 2, bla så nedover i nedtrekksmeny nr to til du finner noden du skal styre, og trykk på "Add".

 

 

[NorthWest]

38 minutter siden, Moskus skrev:

Du legger ikke noen termostater i gruppe 2, det er motsatt. For én enkelt termostat, så åpner du root (den øverste) -> Z-wave -> Associations (nederst). Der skal du legge til HomeSeer i Gruppe 2. Da velger du først Gruppe 2, og så "HomeSeer (ID 1"), og velger "Add".

 

Så gjør du det samme med den enheten du vil styre. Velg først gruppe 2, bla så nedover i nedtrekksmeny nr to til du finner noden du skal styre, og trykk på "Add".

 

 

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?

 

[Moskus]

9 timer siden, NorthWest skrev:

Node 2: Gruppe 2 --> Homeseer (ID1)

                                   Node 3 (ID3)

.. er korrekt.

 

9 timer siden, NorthWest skrev:

Node 3: Gruppe 2 --> Homeseer (ID1)

... behøver ikke være korrekt. Vanligvis brukes den første gruppen som "Life line" for Z-wave Plus enheter, og den siste gruppen for vanlige (forrige generasjons) Z-wave enheter.

 

Hvilken modul er node 3?

[NorthWest]

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?

 

Endret 10. januar 2017 av NorthWest

[Moskus]

Ah, først NÅ begynner jeg å forstå hva du vil. Hvorfor skal en termostat styre en annen?

Da ville jeg heller byttet ut slave-termostatene med rene mikromoduler.

[NorthWest]

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

[Moskus]

Jeg har imidlertid problemer med å se at en termostat kan styre en annen termostat via assosiasjon. Her er det mulig at min begrensede erfaring ikke strekker til, men jeg tviler på

 

 

1 time siden, NorthWest skrev:

Det enkleste formen vil jo være å kun distribuere setpunktet fra masteren til slavesonene, og la hver slave autonomt få styre sin egen sone.

Det tror jeg nok er det beste.

 

1 time siden, NorthWest skrev:

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. 

Dette problemet er nok en mulighet uansett.

 

 

1 time siden, NorthWest skrev:

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

Dette er jo enkelt å teste. Forsøk å assosier en annen node til en "slave" termostat, og prøv å skru den av og på. Se hva som skjer. Jeg tror ikke det vil skje noe fordi det ikke er mulig.

[NorthWest]

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

[Vitellius]

19 minutter siden, NorthWest skrev:

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

 

Interessant! Så i det du setter et setpoint på masteren overføres dette umiddelbart til slavene?

Dersom du setter masteren til "Off", slår de andre seg av også?

[NorthWest]

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 "

[Moskus]

Jeg tror fremdeles at termostatene opererer selvstendig, men motbevis med gjerne.  

[NorthWest]

Et øyeblikk siden, Moskus skrev:

Jeg tror fremdeles at termostatene opererer selvstendig, men motbevis med gjerne.  

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?

 

[Moskus]

Et øyeblikk siden, NorthWest skrev:

Men forklar meg, på litt grunnleggende nivå, hvorfor skal man kunne bruke assosiasjon på regulatorer?

Er det kun for å kunne gruppere regulatorerene?

Det var mens jeg trodde du hadde én termostat, men skulle styre en annen micromodul.

 

Assosiasjon har med hvor en node sender beskjedene sine. Men det betyr ikke at de blir "syncet" eller noe slikt.

 

En bevegelsessensor kan settes opp til å styre en lampe via assosiasjon, slik at den for eksempel går på når det er bevegelse, og av når det ikke er. Men du får for eksempel ikke assosiert en bevegelsessensor til en annen bevegelsessensor uten videre av den grunn.

[Vitellius]

Med forbehold om at jeg har satt meg godt nok inn i problemstillingen din:

Dersom du ikke lykkes med assosiasjoner, så oppnår du vel det du ønsker (og vel så det...) vha eventer? (Ref "Distribuer setpoint"-eventet du nevner).

 

Er det med tanke på mindre "sårbarhet" du ønsker å gå via assosiasjoner?

[NorthWest]

5 minutter siden, Moskus skrev:

Det var mens jeg trodde du hadde én termostat, men skulle styre en annen micromodul.

 

Assosiasjon har med hvor en node sender beskjedene sine. Men det betyr ikke at de blir "syncet" eller noe slikt.

 

En bevegelsessensor kan settes opp til å styre en lampe via assosiasjon, slik at den for eksempel går på når det er bevegelse, og av når det ikke er. Men du får for eksempel ikke assosiert en bevegelsessensor til en annen bevegelsessensor uten videre av den grunn.

 

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

 

[NorthWest]

1 time siden, Vitellius skrev:

Med forbehold om at jeg har satt meg godt nok inn i problemstillingen din:

Dersom du ikke lykkes med assosiasjoner, så oppnår du vel det du ønsker (og vel så det...) vha eventer? (Ref "Distribuer setpoint"-eventet du nevner).

 

Er det med tanke på mindre "sårbarhet" du ønsker å gå via assosiasjoner?

 

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.

[NorthWest]

2 timer siden, Moskus skrev:

Jeg tror fremdeles at termostatene opererer selvstendig, men motbevis med gjerne.  

 

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.

 

[NorthWest]

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

[Moskus]

9 timer siden, NorthWest skrev:

OK, har gjort en liten test:

Og det er med "Wall Plug", "Slave 1" og "Slave 2" assosiert til "Master" sin gruppe 2?

 

Vel... "if it looks stupid but works, it isn't stupid".  

[NorthWest]

47 minutter siden, Moskus skrev:

Og det er med "Wall Plug", "Slave 1" og "Slave 2" assosiert til "Master" sin gruppe 2?

 

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?

[Moskus]

7 minutter siden, NorthWest skrev:

Masteren overstyrer delvis slavenes setpunkt

"Delvis"?

 

7 minutter siden, NorthWest skrev:

det virker ikke å være noen direkte kobling mellom releutgang på master og releutgang på slaveregulatorene.

Nei, det hadde jo vært overraskende.

 

 

7 minutter siden, NorthWest skrev:

Har du noen formening om hvordan jeg kan få avlest setback-verdien?

... trodde dette ble gjort automatisk hvis Gruppe 1 var assosiert til "HomeSeer (ID 1)".

 

[NorthWest]

24 minutter siden, NorthWest skrev:

Masteren overstyrer delvis slavenes setpunkt

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

 

41 minutter siden, NorthWest skrev:

det virker ikke å være noen direkte kobling mellom releutgang på master og releutgang på slaveregulatorene.

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

 

52 minutter siden, NorthWest skrev:

Har du noen formening om hvordan jeg kan få avlest setback-verdien?

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