teeko

Mitt råd til gode venner er å vente litt, men bygger man nytt osv. er jo ikke det en god plan. Jeg er ikke kjent med noen like gode alternativer. Det beste hadde vært om Thermo-Floor fortsatte å engasjere seg på forumet her. Jeg synes produktet både har høy WAF og fungerer kjempebra når det fungerer - bare synd det (AFAIU) har en bug som gjør at det blir "dead" som beskrevet etter noe tid. Jeg har virkelig en bismak i munnen når jeg prater ned et norsk smarthomeprodukt fra et selskap som jeg virkelig vil alt vel og som i utgangspunktet fyller et hull i markedet med et godt produkt. Selv kommer jeg nok å fortsette å feilsøke Z-TRM3 (lærer jo litt av det om ikke annet) og følge med på nye produkter (chip/matter-basert etterhvert kanskje, selv om et subgig zwave produkt hadde vært flott). Elko produktet du nevnte ser ut til å fungere med zigbee2mqtt, og sånn sett hadde vært interessant for meg, men jeg er usikker på WAF og hvor stabilt det egentlig er. Kanskje noe å opprette en egen tråd om?

Z-TRM3 lager fort trafikkstormer, så jeg er nødt til å isolere det for å ikke oversømme hovednettet. Det fine er jo at alt annet av z-wave hos meg er "rock solid" når det får være i fred for Z-TRM3. Trafikkstormene kommer av det som fremstår som håpløse valg av trafikkruter. RSSI på trafikken er ikke så gal (når jeg måler signalstyrke på ulike punkter i nettet), men selv etter "Healing" innen for et veldig lite område (få meter mellom enheter) kan nettet ha topologi som vist. Da skal det ikke mange pakkene til før repeaterne mangedobler trafikk og oversømmer alt som er.... Trist syn å sitte å se på i Zniffer. Uten å være radioekspert forestiller jeg meg at dette tar mye duty cycle plass, og vil ihvertfall ikke belemre annet utstyr med å måte prosessere trafikken. Nesten alle andre enheter jeg har kjører heldigvis direkte assosiasjon mot kontroller over såpass små avstander.

Manuell kontroll over Z-TRM3 vil heldigvis fungere og reduserer klagestormen fra resten av huset. Familien vil også sette pris på at lysstryken kan justeres og evt. slås helt av på soverom osv. Estetisk slår de også an i huset her. Når det er sagt anbefaler jeg på ingen måte den termostaten, og frykter at feil i smarthus-funksjonaliteten til produktet vil ta bort mye av gleden rundt smarthus som hobby. Største feilinvesteringen jeg har gjort ihvertfall.

Jeg benytter på Z-TRM3 : Parameter 18: Temperature report interval - 180 sek (default: 60 sek) Parameter 20: Meter report interval - 270 sek (default: 90 sek) Det blir likevel mye trafikk, og kan nok reduseres enda mere. De 8 stk Z-TRM3 genererer nesten 20x (!) trafikken som de øvrige ca. 30-z-wave enhetene mine gjør tilsammen.

Jeg har 8 stk Z-TRM3-termostater og hadde dessverre ikke valgt Z-TRM3 i dag. De to store utfordringene (setpoint + rele) er adressert med FW.2 og støtten i zwavejs. Problemet hos meg i dag er at termostatene blir "dead" etter noe tid. Jeg må slå av og på strømkursen for å få dem online igjen. De kan bli dead i løpet av et par dager eller det kan gå to måneder, men det fremstår bare som et spørsmål om tid. Jeg tror problemet i noen grad er relatert hvor mye trafikk de må behandle. Dersom de er repeatere for andre z-wave enheter opplever jeg at de går dead veldig raskt. Har isolert Z-TRM3 på egen z-wavekontroller/nettverk, redusert datamengden ift. default, og plassert kontroller slik at termostatene har direkte kontakt (1 hop). Da fungerer det noenlunde greit. (Feilen er lett å reprodusere (tar bare noen timer) dersom man plasserer flere termostater slik at de ruter mye trafikk (2-3 hop). Da mangedobles også trafikken. Har benyttet Zniffer i timesvis for å analyser z-wavepakkedata, men klarer ikke se feilen. Plutselig stopper enhetene bare å sende pakker - blir helt døde.) Kommer til å bytte så snart jeg finner noe bedre. Har tidligere på dette forumet anbefalt ZTRM3 på det varmeste. Var litt for raskt ute med den anbefalingen...

Oppdaterte til zwavejs2mqtt 5.0.1, zwave-js 7.7.3 og HA core 2021.6.4 i dag: Og nå virker det! 1. Temperatur som vises på climate termostat justeres dynamisk til den sensor som er satt i parameter 2. Endres sensor mode så endres også hvilken temperatur som vises automatisk. Artig. 2. Multichannel assosiasjoner har også begynt å virke - så nå bør det gå bra å styre z-water o.l. En liten snag når det gjelder automatikken rundt valg av temperatursensor: Det er implementert slik at internal sensor alltid settes til sensor som er i bruk. Hvis man bruker gulvsensor så er dermed ikke internal sensor like lett å få tak i lenger.

Oppdatert til core 2021.6.2 Status for meg med zwavejs2mqtt 4.5.1 og zwave-js 7.7.1: 1. zwavejs2mqtt setter opp Z-TRM3 nesten helt korrekt. Alle endpoints er tilgjenglig over MQTT. Men det ser ut som den settes opp med singel channel assosiasjon til kontroller... Det er ok i mitt setup, men kanskje en utfordring for de som ønsker å styre en z-water eller liknende direkte. 2. Dersom jeg oppretter en mqtt climate HVAC entity manuelt i HA fungerer alt. Velger da også korrekt temperatur sensor manuelt. 3. Dersom jeg oppretter en mqtt climete HVAC entity automatisk via MQTT discovery fungerer alt dersom jeg benytter intern temperatur sensor (default) eller dersom jeg manuelt i zwavejs2mqtt editer "HASS device json" som brukes i MQTT discovery til å peke på korrekt sensor. 4. Det som ikke evt. fungerer helt ennå er at zwavejs2mqtt automatisk velger korrekt sensor i discovery koden dersom annen sensor enn intern default benyttes. Hjelper ikke med re-interview eller å fjerne enheten og inkludere den på nytt. Ser zwave-js 7.7.2 kom i kveld, men ser ingen endringer på heat-it produktene ut fra kildekoden der. Kanskje det er zwavejs2mqtt som må oppdateres til å lage korrekt hass kode basert på hvilken sensor som brukes, og at fiksen som har kommet kun hjelper når HA kjører på samme maskin og HA oppretter enheten selv?

Takk for svar @haraldov Nettopp begynt å teste Z-TRM3 med wavejs2mqtt 4.5.1 og zwave-js 7.7.1 på en RPi4. HA 2021.6.0 kjører på en annen maskin via mqtt/mqtt discovery. Kan editere hass device discovery koden manuelt til å peke på riktig temp sensor, men tror ikke det ligger noen logikk inne for å håndtere dette automatisk. Usikker på hvordan dette fungerer når det fungerer som det skal... tilpasser termostaten seg automatisk hvis man eksempelvis bytter fra internal til floor temp sensor? Kommer kanskje med zwave-js 7.7.2?

Noen som vet om den nye funksjonaliteten for Z-TRM3 fungerer hvis man benytter zwavejs2mqtt og termostater som opprettes i HA via mqtt discovery?

Ja, jeg sliter med dette, men har ikke hatt tid til å feilsøke eller sende spørsmål til Thermo-Floor. De går offline etter litt tid, men virker igjen etter at jeg tar sikringen. Frykter at dette er et tredje problem med Z-TRM3 som jeg først har blitt oppmerksom på etter at de andre to er løst...

Hei! Er det et tredje problem knyttet til "Z-TRM3 going offline" - ref. diskusjonene på SmartThings forum? Har opplevd det samme med Z-TRM3 4.2 og Fibaro HC2 4.600, og det virker som feilen ligger på Z-TRM3. Noen kommentarer?

- selv har jeg tatt en pause fra OZW og benytter isteden Fibaro integrasjonen - da er det ikke behov for å bytte firmware OTA - ja, jeg fikk det, så vil tro det bare er å spørre. - nei, jeg kan ta feil, men jeg tror ikke OZW har utberedet Thermostat Setpoint classen ennå, men med uoffisiell OTA-firmware virker Setpoint Set likevel .

Jeg installerte 4.2 firmware med kabel i dag. Overraskende enkel og grei å oppdatere - hadde trodd det var mere knot. Nå virker alt hos meg, jeg er kjempefornøyd og kan anbefale Z-TRM3 på det varmeste.

Oi! Dette var spennende! Takk for at du deler status.

Jeg kan endre setpoint, men reléet slår ikke inn hvis romsensor benyttes - med mindre jeg har brukt termostaten fysisk det siste minuttet i forkant. Med gulvsensor fungerer alt 100%. Ekspertene hos ThermoFloor har så langt jeg forstår reprodusert problemet og jobber med en løsning. De har bekreftet at relé-problemet virker å være en separat sak fra setpoint-problemet, så det blir spennende å høre mer når en fix forhåpentligvis kommer. Nyttig at du rapporterer at det fungerer bra hos deg med konfigurasjonen du har beskrevet - kanskje det er flere versjoner av HW... Når det gjelder OZW så er saken at OZW benytter tall-formater Z-TRM3 ikke har sagt de støtter i kapabilitetsintervjuet når setpoint skal justeres? Ref. loggene. I den uoffisielle FW så godtar de flere formater og derfor fungerer den bedre mtp. setpoint. Når dette er sagt virker det som relé-problemet ved bruk av romsensor er "neste sak" også i OZW, selv om man får setpoint til å virke med uoffisiell FW. Min forståelse at setpoint-problemet er knyttet til Z-wave implementeringen i OZW og andre kontrollere som ikke er iht. Z-wave spesifikasjon, mens at relé-problemet kan være knyttet til en feil med Z-TRM3 firmware eller maskinvare. Når det gjelder sistnevnte om feil med Z-TRM3 firmware eller maskinvare er det bare spekulasjon fra min side - og ikke noe Thermo Floor at hintet til utover at de jobber med en fix.