teeko

46 minutter siden, sahansen skrev:

Men, da burde jo 22,5, 23,5, 24,5 osv. også fungere..? Hos meg er det kun 26,5 og 30,5 som fungerer, så skjønner ikke helt hvorfor bare de to verdiene går gjennom.

Såpass - den varianten har jeg ikke hørt om før..

Hvordan ser ThermostatSetpointCmd_Set linjene ut i loggen for eksempelvis 22,5?

22 timer siden, teeko skrev:

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?

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?

20 timer siden, sahansen skrev:

EP0, GR1 endret til MCA 

EP2, GR2 fjernet.

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.

15 timer siden, sahansen skrev:

Har nå inkludert den ene termostaten direkte i HA.

Nå kan jeg plutselig endre settpunkt til 26,5 og 30,5, men ingen andre verdier.. Skjønner ikke helt!?

Lagt ved logg.

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.

3 timer siden, sahansen skrev:

På romføleren 320.2.1 skal man aktivere MCA under EP2, GR2.

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.

2 timer siden, sahansen skrev:

Oppsett:

EP0, GR1, SCA mot HC2.

EP0, GR3, MCA mot HC2.

 

Ser jeg ikke brukte samme oppsett som i guide, men det fungerer slik det er satt opp.

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

1 time siden, sahansen skrev:

Gjort det som står i denne guiden? 

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?

14 timer siden, sahansen skrev:

Inkluderte termostaten inn i HC2 igjen, der fungerer alt som det skal. Kan endre settpunkt og lese av alle verdier.

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.

På 21.7.2020 den 10.49, NilsOF skrev:

Hvilke sensorer er aktuelle, dvs. billige og nøyaktige nok?

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.

På 6.8.2020 den 17.31, iotux skrev:

Du må gjerne avgi rapport om hvordan det funker for deg. Hvis du bruker annen måler enn Kaifa, vil det også være interessant informasjon.

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.

På 31.7.2020 den 12.05, Kim123 skrev:

Heatit er informert om problemet med sensor mode og skal undersøke saken. 

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?

1 time siden, iotux skrev:

Du trenger ikke nødvendigvis sertifikater med autentisering. Uten sertifikater går trafikken ukryptert. Det kommer an på hvordan du setter opp mosquitto

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

40 minutter siden, stigvi skrev:

Den kjører vel som en egen Docker så du må vel bruke et verktøy for å kopiere de inn der. ssh med litt høyere rettigheter, for eksempel

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?

På 1.8.2020 den 13.21, iotux skrev:

Programmet kan lastes ned her: https://github.com/iotux/ElWiz

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?

6 timer siden, Kim123 skrev:

ja, de 10-15 gangene jeg har endret den virker det hver gang

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

6 timer siden, MrE skrev:

Lufttrykket mellom ute og inne vil vel alltid være et samme antar jeg - med tradisjonelle ventiler i vegg og med balansert ventilasjon. Eller?

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.

14 timer siden, Kim123 skrev:

Vanlige varmekabler er ren ohmsk last, noe som betyr at  de ikke har startstrøm. Har du selvregulerende varmekabler gir de en del startstrøm

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