teeko

Såpass - den varianten har jeg ikke hørt om før.. Hvordan ser ThermostatSetpointCmd_Set linjene ut i loggen for eksempelvis 22,5?

Jeg kjøpte en ekstra løs Z-TRM3 for å teste dette, og dessverre ser det ut til at denne teorien ikke leder frem. Situsjonen er helt lik for meg med min nyinnkjøpte Z-TRM3 med kun romføler -- når jeg bruker romføler og justerer fra HC2 - slår reléet bare inn bare det første minuttet etter at jeg fysisk har justert setpoint på panelet.... Mon tro på hvilken måte oppsettene våre er forskjellige.... Har du mulighet til å dele "Template" for enheten i HC2? Du kjører nyeste HC2? v4.600?

I utgangspunktet burde det være nok med en MCA assosiasjon fra EP0 GR1 til HC2. Det er rart om det skulle være nødvendig med ytterligere assosiasjoner med mindre Z-TRM3 skal styre andre enheter - som et relé i en Z-water eller Wall Plug. For meg er derfor også bruksanvisningen til den opprinnelige Z-TRM2 vanskelig å forstå - jeg ser rett og slett ikke logikken i at det skal flere MCA assosiasjoner til HC2, og heller ikke hvorfor det for Z-TRM2 skal være en SCA (og ikke MCA) assosiasjon til Z-water. Nesten så jeg ikke tror det jeg leser... men så langt jeg kan se har heller ikke Z-TRM2 offisiell sertifisering. Når det gjelder Fibaro integrasjonen til HA så har jeg også lagt merke til at det blir litt rot man forsøker å rette opp dobble assosiasjoner til kontroller. Har en drøm å få tid til å kikke litt på kildekoden til integrasjonen. Tenker at det beste hadde vært om Fibaro HC2 kjente igjen Z-TRM3 og satt den opp korrekt med kun en termostat, slik at kun en termostat ble med over til HA, men kanskje det hadde gått an å gjøre noen avbøtende tiltak i selve integrasjonen.

Dette ble en vegg av tekst, men siden det virker som du har interesse for detaljene under panseret.... Så langt jeg kan forstå av loggen er dette den berømte setpoint feilen. Problemet er at z-wave kontrollere skal intervjue termostater for å finne ut i hvilke tallformat de kan motta temperatur. Z-TRM3 vil alltid ha temperatur med 1 desimal presisjon. Mange Z-wave kontrollere gjennomfører ikke dette kapabilitets intervjuet korrekt - og på disse kontrollerene oppstår situasjonen. Fibaro HC gjør dette kapabilitetsintervjuet slik Silicon Labs ønsker - og derfor fungerer setpoint fint der. Min persepsjon er at de fleste andre kontrollere ikke har denne evnen ennå - og Thermofloor gir derfor på forespørsel ut en uoffisiell FW som virker med disse kontrollere. I loggen ser vi at HA (OZW) bruker et format som Z-TRM3 ikke støtter når den forsøker å justere setpoint til 24 grader: 24 grader: 2020-08-24 16:29:31.627 Detail, Node013, Queuing (Send) ThermostatSetpointCmd_Set (Node=13): 0x01, 0x0c, 0x00, 0x13, 0x0d, 0x05, 0x43, 0x01, 0x01, 0x01, 0x18, 0x25, 0x4e, 0xd9 De sentrale dataene her er 0x01, 0x18 => sender 24 grader (0x18) som 1 byte heltall uten presisjon/desimaler. Det korrekte skulle vært 0x22, 0x00, 0xF0 26.5 grader: 2020-08-24 16:29:39.160 Detail, Node013, Queuing (Send) ThermostatSetpointCmd_Set (Node=13): 0x01, 0x0d, 0x00, 0x13, 0x0d, 0x06, 0x43, 0x01, 0x01, 0x22, 0x01, 0x09, 0x25, 0x50, 0xf6 0x22, 0x01, 0x09 => sender 26.5 grader som 265 (0x0109) som 2 byte tall, med 1 desimal presisjon Dette er på et format Z-TRM3 forstår og gikk fint. Så kortversjonen er at man for HA må vente til OZW evt. kommer med korrekt z-wave støtte eller legge inn modifisert FW på Z-TRM3.

Så langt jeg kan se har jeg helt likt oppsett som deg - med unntak av at jeg også har gulvføler installert. Jeg får som kjent satt setpoint, men reléet slår fortsatt bare inn det første minuttet etter jeg har benyttet fysisk panel. For gulvsensor slår reléet inn som det skal hele tiden. Det får meg nesten til å tro at feilen oppstår når både gulvsensor og romsensor er installert. Hva du tror om den teorien? Kanskje @Kim123 har noen tanker rundt dette? For at HC2 skal se mer enn bare EP0 må det være minst en MCA til HC2. Men jeg forstår ikke hvorfor den må være fra EP2 GR2. Stusser også på at det må være en bakoverkompatible SCA assosiasjon for EP0. Det er ikke lett å unngå siden HC2 automatisk lager denne SCA assosiasjonen (hender også hos meg), men det resulterer jo i to delvis funksjonelt overlappende termostate-enheter.. Det hadde vært spennende å justere 320.0 EP0 GR1 fra SCA til MCA assosiasjon, og slette MCA assosiasjonen fra 320.2.1 (da vil jo også EP0 GR3 automatisk slettes), og se om det fortsatt fungerer hos deg da. Dersom det ikke fungerer så indikerer jo det at assosiasjonene må være slik de er satt opp - som hadde vært interessant å få bekreftet. Når det er sagt må jeg bare igjen takke deg for alle testingen du har gjort -- og forstår godt om du ikke har tid og lyst til mere knot.

Tusen takk som tar deg tid til å hjelpe. Vi er en del som sliter med å få reléet til å slå inn. Thermofloor feilsøker selv etter hva jeg forstår. Løser du dette burde de sendt deg en premie. Testet å justere assosiasjonene like dine. Skulle nesten tro det var flere hardware revisjoner av TRM3 - for jeg får ikke reléet til å virke med assosiasjonene slik heller. Bare for å ha dobbeltsjekket at jeg har gjort det likt som deg: - Det er kun de to assiasjonene over for EP0 ? - Det er ingen assosiasjoner fra EP1, EP3 eller EP4 til HC2 ? - Det er en MCA assosiasjon for EP2 GR2 til HC2 - en automatisk "mirror" av EP0 GR3 ? - FW er versjon 4.0 ? - Den er inkludert "secure" i HC2 ? - Parameter 2 er satt til 1 (for meg virker alt når denne er 0, men ikke når den er 1) ?

Spennende! Øyner jo et lite håp her... Guiden er for Z-TRM2, men du har satt opp Z-TRM3 på samme måte? Jeg har i utgangspunkt kun justert blandet SCA/MCA assosiasjon for EP0 / Gruppe 1 til en ren MCA assosiasjon. Alt fungerer for gulvføler, men med feilen som beskrevet over for romføler. Prøvde å justere assosiasjonene (sett opp EPx / Group 2 med MCA til kontroller) som beskrevet i guiden for Z-TRM2, men reléet slår fortsatt bare inn for romføler det første minuttet etter at fysisk panel er benyttet. Hvordan ser assosiasjonene ut for EP0 / root hos deg?

Jeg benytter HC2 (gjennom Fibaro integrasjonen til HA) og kan endre setpoint og lese alle verdier, men med romføler slår reléet kun inn dersom man fysisk har trykket på termostaten det siste minuttet. Med gulvføler fungerer alt. Er det slik hos deg også eller slår reléet alltid slår inn når romføler benyttes i HC2? Så langt jeg forstår har Thermofloor klar å reprodusere relé problemet ved bruk av romsensor, og bekreftet at det ikke har noe med setpoint å gjøre som har vært en separat sak. Hvis du har en konfigurasjon der reléet slår inn normalt ved bruk av romsensor er dette interessant.

BMP390L - den siste sensoren til Bosch som ble sluppet i sommer - virker interessant. Relativ nøyaktighet på +/-3 Pascal. Om noen få uker kan den leveres på shuttle board.

Nå har jeg fått orden på Tibber Pulse og MQTT. Med litt triksing fungerer autentisering gjennom sertifikat som ønsket . Flytter fokus over på ElWiz Et par første tilbakemeldinger 1) pulse/status og pulse/notice - ser ut til å fungere, men har ikke testet mye 2) pulse/meter må som du indikerer kanskje ha tilpasset datatolkingen. Jeg har Aidon_V2. Rådata i buf[2] er ikke 39, 121 eller 155, men 42... 1) En bagatell: Måtte justere "userName:" i pulse.mqttOptions til "username:" med kun små bokstaver for at pålogging skulle fungere.

Noen som har hørt noe mer fra Thermo-Floor / HeatIt? En ny firmware må kanskje ha ny sertifisering av Z-Wave Alliance (?), men det hadde vært artig med en status. Håper julen kommer tidlig i år...

OK - use_identity_as_username fungerer hos meg nå etter litt triksing 1. Slå av SSL-støtten som settes opp gjennom brukergrensesnittet til Mosquitto add-on. Dette gjøres ved å spesifisere sertifikatfiler som ikke eksisterer: logins: - username: elwiz password: hemmelig_passord anonymous: false customize: active: true folder: mosquitto certfile: no_such_file_server.crt keyfile: no_such_file_server.key require_certificate: true cafile: no_such_file_ca.crt 2. Lag en alternativ konfig for SSL-støtte Ved å gjøre dette utenfor brukergrensesnittet fungerer use_identity_as_username mosquitto $ pwd /root/share/mosquitto mosquitto $ ls accesscontrollist acl.conf alt_ssl.conf mosquitto $ cat alt_ssl.conf listener 8883 protocol mqtt cafile /ssl/ca.crt certfile /ssl/server.crt keyfile /ssl/server.key require_certificate true use_identity_as_username true mosquitto $ 3. Sett opp tilgang for aktuelle brukere. Det ikke behov for å legge til brukernavn og passord, da autentisering gjøres gjennom sertifikatet Eksempel: "tibber" under er en identitet hentet fra CN i klientsertifikatet (self-signed) jeg benytter for Tibber Pulse. mosquitto $ cat accesscontrollist user homeassistant topic # user tibber topic write tibber topic read tabber user elwiz topic read tibber topic write tabber That's it... Slik ser det ut ved oppstart: [20:09:46] INFO: Setup mosquitto configuration [20:09:46] WARNING: SSL not enabled - No valid certs found! [20:09:46] INFO: Found local users inside config [20:09:46] INFO: Initialize Hass.io Add-on services [20:09:46] INFO: Initialize Home Assistant discovery [20:09:46] INFO: Start Mosquitto daemon 1596996586: Loading config file /share/mosquitto/acl.conf 1596996586: Loading config file /share/mosquitto/alt_ssl.conf 1596996586: mosquitto version 1.6.3 starting 1596996586: Config loaded from /etc/mosquitto.conf. 1596996586: Loading plugin: /usr/share/mosquitto/auth-plug.so 1596996586: |-- *** auth-plug: startup 1596996586: ├── Username/password checking enabled. 1596996586: ├── TLS-PSK checking enabled. 1596996586: └── Extended authentication not enabled. 1596996586: Opening ipv4 listen socket on port 8883. 1596996586: Opening ipv6 listen socket on port 8883. 1596996586: Opening ipv4 listen socket on port 1883. 1596996586: Opening ipv6 listen socket on port 1883. 1596996586: Opening websockets listen socket on port 1884. 1596996586: Warning: Mosquitto should not be run as root/administrator. Endelig kunne jeg slå av anonymous tilgang igjen....

Siden konfigurasjonsfilene leses i alfabetisk rekkefølge prøvde jeg å døpe om test.conf til a.conf. Da ble den lest før acl.conf som antatt, men feilmeldingen til slutt var den samme. Det er fristende å prøve å editere mosquitto.conf i Docker-kontaineren, men det hadde vært artig å få dette til på en måte som gjorde at Home Assistant fungerer "supervised".

Ja, godt tenkt. Prøvde å opprette en fil test.conf med linjen "use_identity_as_username true" i customization-katalogen /share/mosquitto mosquitto $ pwd /share/mosquitto mosquitto $ ls accesscontrollist acl.conf test.conf mosquitto $ cat test.conf use_identity_as_username true mosquitto $ Og test.conf leses inn under oppstart at Mosquitto-addon [10:44:12] INFO: Setup mosquitto configuration [10:44:12] INFO: Found local users inside config [10:44:12] INFO: Initialize Hass.io Add-on services [10:44:12] INFO: Initialize Home Assistant discovery [10:44:12] INFO: Start Mosquitto daemon 1596962652: Loading config file /share/mosquitto/acl.conf 1596962652: Loading config file /share/mosquitto/test.conf 1596962652: mosquitto version 1.6.3 starting 1596962652: Config loaded from /etc/mosquitto.conf. 1596962652: Loading plugin: /usr/share/mosquitto/auth-plug.so 1596962652: |-- *** auth-plug: startup 1596962652: ├── Username/password checking enabled. 1596962652: ├── TLS-PSK checking enabled. 1596962652: └── Extended authentication not enabled. 1596962652: Opening ipv4 listen socket on port 1883. 1596962652: Opening ipv6 listen socket on port 1883. 1596962652: Opening websockets listen socket on port 1884. 1596962652: Opening ipv4 listen socket on port 8883. 1596962652: Opening ipv6 listen socket on port 8883. 1596962652: Opening websockets listen socket on port 8884. 1596962652: Opening ipv4 listen socket on port 1883. 1596962652: Error: Address in use ...men det ser ut som det blir en kollisjon mot slutten Uten test.conf ser det slik ut: [11:10:36] INFO: Setup mosquitto configuration [11:10:36] INFO: Found local users inside config [11:10:36] INFO: Initialize Hass.io Add-on services [11:10:36] INFO: Initialize Home Assistant discovery [11:10:36] INFO: Start Mosquitto daemon 1596964236: Loading config file /share/mosquitto/acl.conf 1596964236: mosquitto version 1.6.3 starting 1596964236: Config loaded from /etc/mosquitto.conf. 1596964236: Loading plugin: /usr/share/mosquitto/auth-plug.so 1596964236: |-- *** auth-plug: startup 1596964236: ├── Username/password checking enabled. 1596964236: ├── TLS-PSK checking enabled. 1596964236: └── Extended authentication not enabled. 1596964236: Opening ipv4 listen socket on port 1883. 1596964236: Opening ipv6 listen socket on port 1883. 1596964236: Opening websockets listen socket on port 1884. 1596964236: Opening ipv4 listen socket on port 8883. 1596964236: Opening ipv6 listen socket on port 8883. 1596964236: Opening websockets listen socket on port 8884. 1596964236: Warning: Mosquitto should not be run as root/administrator. ...og fungerer ellers som det skal :-)

Noen MQTT-klienter benytter som kjent ikke brukernavn og password, men autentiserer seg kryptografisk basert på sertifikat. I disse tilfellene kan det være nyttig å benytte identiteten i klientsertifikatet som brukernavn i Mosquitto som vist i diverse guider på nettet. Mosquitto støtter dette gjennom å sette "use_identity_as_username true" i mosquitto.conf. Siden mosquitto.conf ikke er direkte tilgjenglig for justeringer når Mosquitto kjøres som "add-on" under HassOS prøvde jeg å sette "use_identity_as_username: true" via brukergrensesnittet. Opsjonen satt via brukergrensesnittet hadde tilsynelatende ingen effekt, og resulterte i følgende oppføring i systemloggen til Home Assistant: "WARNING (MainThread) [supervisor.addons.validate] Unknown options use_identity_as_username" Noen som kjenner til en smidig måte å sette "use_identity_as_username true" når Mosquitte kjører som "add-on" under HassOS?

Kommer med flere tilbakemeldinger, men vil bare sikre MQTT brokeren først. Vil gjerne ha brukerautentisering og aksesskontroll, og da må Tibber Pulse logge seg på som en bruker. Tenkte det kanskje ville gå hvis jeg benyttet TLS, "use_identity_as_username" og lage en bruker "tibber" gjennom å sette CN i klientsertifikatet til "tibber". Men... feilsøking...

Ja, har mye å lære. Tittet på mosquitto.conf under https://github.com/home-assistant/hassio-addons/tree/master/mosquitto og det så ut som korrekt path var /ssl. La filene rett under /ssl og nå er ihvertfall SSL-feilmeldingen/advarsel ved oppstart borte og den lytter på 8883

Et nybegynnerspørsmål Tester ut Home Assistant. Kjører HassOS 4.11 på en RPi4. Har installert Mosquitto som "add-on" og skulle gjerne satt den opp slik at det ble benyttet sertifikater. Har fått laget de serifikater og nøkler jeg trenger (håper self-signed er ok), men må legge dem riktig sted. Ser guider på nettet vise hvordan man spesifisere path i mosquitto.conf, og Mosquitto broker add-on rapporterer "Config loaded from /etc/mosquitto.conf" ved oppstart, men ser ikke ut som denne filen er tilgjenglig i /etc når jeg logger inn med ssh. Mye under panseret i HassOS. Hvor legges sertifikater for bruk med Mosquitto når denne kjører som "add-on"?

Endelig fått meg en Tibber Pulse. Den sender rådata til egen Mosquitto MQTT broker etter å ha blitt satt opp som anvist i ElWiz guiden (uten SSL/TLS). Jeg slo av autentisering i Mosquitto midlertidig - for så langt jeg kan se logger ikke Tibbe Pulse seg på med et brukernavn (?). Antar jeg må sette opp autentisering med sertifikater for at Tibber Pulse skal logge seg på som en bruker?

Takk for at du deler dette. Ser veldig bra ut. Ble inspirert til å teste - har Aidon Tror jeg løper og kjøper en Tibber Pulse med det samme Tibber Pulse i Home Assistant m.fl. enkelt og lokalt er jo helt rått. ElWiz trenger en egen tråd?

Jeg har testet litt med standard 4.0 firmware på TRM3 i HC2, og alt fungerer (!!!) dersom jeg kun bruker gulvsensor (para 2 = 0). Reléet slår inn som det skal. Men dersom jeg benytter romsensor+gulvbegrenser (para 2 = 2), så oppfører den seg likt som ved kun romsensor (para 2 = 1) -- dvs. at reléet ikke slår inn ved justeringer fra UI. Jeg må bort å trykke fysisk på termostaten, og deretter slår relé inn og jeg kan fra det tidspunktet også justere fra UI i ca. 1 minutt fremover (reléet slår inn) -- før det slutter å virke igjen. Slik jeg forstår det fungerer alt for deg med med para 2 = 2? (med unoffical mod fimrware)

Dette var spennede og nyttig. Takk for at du deler dette. Har de mulighet til å dele grafen fra en "kald uke" fra vinter også?

Kjempespennende - hjelper gjerne til med testing

Slik jeg forstår det endres tykkdifferansen spesielt av temperatur. Det er grunnen til at jeg ønsker å måle den og lage en automasjon som tar hensyn til den. Tipper dette kommer på privatmarkedet om noen år. Mitt inntrykk er at proffløsninger i økende grad finjusterer ventilasjonen basert på måling av luftkvalitet og trykkdifferanse. Jeg antar man tar utgangspunkt i en systemkurve tilpasset byggets størrelse og estimert antall personer, og så finjusteres den absolutte luftmengden eksempelvis etter CO2 nivå, mens trykkdifferansen finjusteres etter målt differensialtrykk.

Takk @Kim123! Dette var veldig nyttig - hadde ikke fått med meg forskjellen på vanlige og selvregulerende varmekabler