deve87

Nei. Det er selvsagt. Har kun hentet assosiere i info fra Z-therm 2 pga like assosiere for de to etter firmware oppdatering. Bruker forsatt xml for Z-therm v1. Men den gir ikke status på rele eller setpoint

Ja. Det stemmer. Fortell gjerne hvordan termostaten oppfører seg etterpå ang tilbakemeldinger på rele. Jeg får det kun til hvis jeg poller enheten med 60sek intervaller

Jeg opplever trøbbel selv. Trur det har noe med at de nye endringen ikke finnes i noe Z-Wave config file. Men vet ikke https://www.hjemmeautomasjon.no/forums/topic/3539-z-therm-ingen-tilbakemelding-etter-firmware-v192-oppgradering/

Ved å aktivere polling (60sek interval) av enheten. Fungerer den bedre og reléstatus oppdaterer seg. Men er vel ikke det som er helt meningen. Er det noe feil med config filen for enheten?

Fikk endret litt på .xml filen for termostat i OpenZwave. Hentet info fra Z-therm 2 .xml Hentet da: <CommandClass id="133" name="COMMAND_CLASS_ASSOCIATION"> <Associations num_groups="5"> <Group index="1" max_associations="7" label="Lifeline"/> <Group index="2" max_associations="7" label="On/Off switch of internal relay"/> <Group index="3" max_associations="7" label="Multilevel sensor reports - Internal sensor"/> <Group index="4" max_associations="7" label="Multilevel sensor reports - External sensor"/> <Group index="5" max_associations="7" label="Multilevel sensor reports - Floor sensor"/> </Associations> </CommandClass> <!-- COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION_V2--> <CommandClass id="142" ForceInstances="true" /> <!--COMMAND_CLASS_MULTI_CHANNEL_V2 Map endpoints to instances --> <CommandClass id="96" mapping="endpoints" /> </Product> Den originale har da: <CommandClass id="133" name="COMMAND_CLASS_ASSOCIATION"> <Associations num_groups="2"> <Group index="1" max_associations="1" label="Lifeline"/> <Group index="2" max_associations="8" label="On/Off control"/> </Associations> </CommandClass> </Product> Nå fungere ting bedre. Slipper å assosiere kontroller mot alle gruppene + at det kun kommer opp en bryter denne gangen. Tilbakemelding på relé kommer forsatt ikke. Får som sagt styrt det fra kontroller, men ingen reaksjon når det trigger internt i termostat Edit: Kan legge til at det kun er temperatur som oppdaterer seg og ikke setpoint eller reléstatus. Hvis jeg inkluderte termostat når relé er på! Kommer relé statusen som på også. Men som sagt, videre oppdatering, skjer ikke.

Ja, men mener den fikk ny ID og ny type. Slikt at OpenZwave ikke fant noe device/config fil for en. Den gamle hadde en Type = 0x0001 ID = 0x0001 Men med ny firmware fikk den Type = 0x0003 ID = 0x0201 Manufacturer listen til OpenZwave, har ikke noe fil for den typeinfoen. Så enheten kommer opp som Unknown device (med selvfølgelig alle tempenhetene og navnet på selve termostat). Så tvang den til å hende filen for termostat før firmware oppdateringen

Etter at jeg linket alle gruppene mot kontroller. Oppdaterer temp og setpoint seg. Rele status gjør ikke det! Etter at jeg inkluderte den på nytt. Fikk enheten en helt ny ID. Måtte legge den nye IDn inn mot config filen til termostaten, sånn at jeg kunne endre på parametre. Vet ikke om det er ting som har endret seg etter v1.92?

Ja. Lifteline er automatisk linket mot controller. Har i tillegg gruppe 2 (on/off), 3, 4 og 5. Gruppe 2 har bestandig vært der. Men de siste gruppene har kommet nå. Uten at jeg vet hva hvem gjør.

Etter å ha inkludert den igjen. Får jeg opp 2xbrytere, 3xtemperatur osv. Noen som virker riktig. Men ingen tilbakemelding lenger på noe. Verken relestatus, setpoint, tempratur. Får satt av og på rele og en ny temp osv. Termostaten fungere som normalt ellers. Noen som har prøvd det ny firmware og har opplevd det samme?

Ikke noe mer avansert enn at den er skrudd fast bak. Med 2par kabel til en ESP8266 via I2C bus som står inne. Skal lage en tett luke fra baksiden med tiden. Akkurat nå, er det limt et plast lokk bak ? Den får 5V. Siden 3.3V ble for svakt pga lengden på kabelen. ESPn sender den unike koden fra kortet til Domoticz som igjen har et lite script som tar seg av logikken.

Smartifisert Danalock dørlås i dag. Idé med dørbrytere fikk jeg fra @Actibus Siden Danalock i utgangspunktet er litt dårlig når en skal bruke flere løsninger enn kun den! Så monterte jeg dørbrytere (kablet mot ESP8266) slik at jeg vet når døren er lukket og låst. Jeg vil ikke at Danalock skal sender sin låsestatus, for da blir det bare krøll ? Så nå ser jeg status på døren uansett om den er låst med nøkkel eller Danalock. Får altså da ikke lov å låse døren igjen. Hvis den allerede er i låst med nøkkel (liten logikk inn i bilde selvfølgelig) Døren låser seg heller ikke før den faktisk er lukket. Slik at ikke låsen plutselig bare spretter ut ved åpen dør og en har satt den til lås Bruker for det meste Alt AV lysbrytere i gang for å låse døren. Pluss en RFID leser (PN532) bak kledning . Resultater er i videoen ? Laget også en brikke som viser hvem som låste opp døren sist

Nei. Viften styrer bare et vanlig vekselrele, som skifter mellom NC og NO når motor får spenning. Skulle jeg detekterer vedfyringen, måtte det vært en CO måler montert et sted. Kanskje litt vanskelig å montere en i toppen av pipen ? Men noe i den duren Eller selvfølgelig bare ha en bryter en trykker på når en skal fyre opp! Er der jeg sliter.

Ja. De fungerer bra de. Var overraskende for prisen.

Spjeld: https://m.aliexpress.com/item/32716259080.html?

Hei. Fant akkurat ut at det bare er "Dummy devicer" som den ikke logger. Alle zwave temperaturer blir logget som før

Etter siste stabile oppdatert, ser jeg ikke lenger loggen over temperatur siste året osv.

Sliter med at ventilator på kjøkkenet suger fra vedovn. Har balansert ventilasjon. Monterte da en spjeld i veggen som åpner å lukker seg når ventilator er på. Blir spennende å se når fyringssesongen kommer igjen.

Egentlig, så ble det aldri noe ordning på problemet. Timeout fra noder og diverse lagg i nettverket var så å si likt. Etter diverse feilsøking og mye tid brukt. Søkte jeg etter litt info angående UZB1. På databladet for kontrolleren, fant jeg en liten info. "Using the device right on a notebook ore other heavy devices may partially degrade the signal significantly. Applying a USB-USB extender cabel of min 10cm will always provide the best radio experience" Jeg tenkte at en Raspberry ikke gikk under kategorien "heavy devices" men prøvde uansett som et siste forsøk på å få vekk tregheten i nettverket (kun ved scene valg) Etter en 20cm lang USB forlenger og en heal network senere forandret mye seg. Nå ser UZB1 dobbelt så mange noder som før den sto direkte i Raspberry. Og tregheten er helt borte. Ved et scene valg på ca 9 noder, kommer alle på momentant! Tydeligvis hadde det å få kontroller litt vekk fra Raspberryen mye å si for signalstyrken.

Hei. Da er 2stk Sandisk High endurance 32GB bestilt ??

Har du en ESP. Kan du bruke ESPEasy på disse som har en direkte støtte mot Domoticz. Enklere blir det ikke ?

10A grensen er satt i forbindelse med anlegg i England.. Der alle støpsler har innebygd sikring. Kursen rundt i huset er gjerne på 25 - 32A. Spiller noen rolle om Fibaro sin dimmer/rele er tilkoblet 10 eller 15A. Da den ikke klarer å trekke mer en 250W (1A) Kortslutningstrømmen det går på. En 10A-C automat. Har en I5 verdi (elektromagnetisk utkobling/momentant utkobling) på 100A. En 15A-B har en I5 på 75A Det blir noe helt annet vis en tilkoblet 15A på en rele node som tåler 8A lar den styre en stikkontakt. Da kan man tilkoble laster i stikken med opp til 15A Elektriker.

Fungerer nå. Det hjalp å aktivere polling av termostatene. Satt tiden til 60minutters intervall.. Skal en legge til ZMNHID1 i Domoticz. Vil den av en eller annen grunn laste opp feil fil til denne. Domoticz laster opp ZMNHIDxS1 da den riktige config filen er ZMNHIDxS2 Navnet på xS2 må endres til xS1 ( da må selvfølgelig eksisterende xS1 endres eller slettes ) Hvis en ikke gjør det.. Fungerer ikke termostaten i Domoticz..

Hastigheten er mye bedre (nesten momentant) etter endring av 'RetryTimeout' i filen config/options.xml til Domoticz. Er standard 40sekunder og nå satt til 4 sekunder. Samtidig som jeg også endret rekkefølgen i hvem node som skal starte i scene valget. Fant ut at det var greiest å starte med nodene i det rommet bryteren faktisk var i. Startet omvendt tidligere... Så nå er det fix fix ?

Kjører siste stabile versjon av Domoticz på en Raspberry UZB1 med for det meste Fibaro enheter samt noen Nexa plugger og Qubino termostater. Når jeg kjører en scene i Domoticz. Kan det til tider være store forsinkelser i nettverket. Den sender feks AV til omtrent 20 noder. Da førstemann i rekkene på scene går av med en gang, mens de resisterende feks 15 nodene henger igjen. Går på det verste 30 sekunder før resten skrur seg av. I loggen står det at den får timeout fra neste node i køen. Det kan variere fra node til node. Andre ganger, kan det gå nesten momentant.. Bilde viser hvem kontroller ser Effekt rapportering i Fibaro nodene er deaktivert. Kjørte tidligere Domoticz på en Windows maskin med færre noder enn hva jeg har i dag. Da var UZB1 stikken også plassert et annet sted. Det kunne være like store forsinkelser da også.

function timedifference(s) year = string.sub(s, 1, 4) month = string.sub(s, 6, 7) day = string.sub(s, 9, 10) hour = string.sub(s, 12, 13) minutes = string.sub(s, 15, 16) seconds = string.sub(s, 18, 19) t1 = os.time() t2 = os.time{year=year, month=month, day=day, hour=hour, min=minutes, sec=seconds} difference = os.difftime (t1, t2) return difference end function trim1(s) return (s:gsub("^%s*(.-)%s*$", "%1")) end commandArray = {} debuglevel = 0 local function update(idx, value1, value2) local cmd = idx.."|"..value1.."|"..value2 --local cmd = string.format("%d|0|%f;%f", idx, value1, value2) table.insert (commandArray, { ['UpdateDevice'] = cmd } ) end for i, v in pairs(otherdevices) do timeon = 240 tc = tostring(i) --v = i:sub(1,4) v = string.sub(i, -5) if (v == '(VOS)') then if (debuglevel > 0) then print("Timer Device Detected:".. i) end tc2 = string.len(i) --print("Len:".. tc2) vname = trim1(tostring(string.sub(i,1,tc2-5))) if (otherdevices[vname] == 'On') then if (debuglevel > 0) then print("Timed Device:".. vname) end print("Timed Device Detected ON:" ..vname) if (debuglevel > 0) then print("Timer Dev Idx:".. otherdevices_idx[i]) end if (debuglevel > 0) then print("Timed Dev Idx:".. otherdevices_idx[vname]) end if (debuglevel > 0) then print("Current Value:".. otherdevices[i]) end newvalue = otherdevices[i] +25 --newvalue = 1 if (debuglevel > 0) then print("New Value:".. newvalue) end --commandArray['UpdateDevice'] = otherdevices_idx[i]..'|1|'..newvalue update (otherdevices_idx[i], 1, newvalue) end end if (v == 'PIR----') then difference = timedifference(otherdevices_lastupdate[tc]) if (difference > timeon and difference < (timeon + 60)) then tempdiff = tostring(difference) c = i:sub(4) tempmessage = c.." Light Off - after at least " .. (timeon+1) .. "secs up - actually - " .. tempdiff .. "seconds" print(tempmessage) commandArray[c] = 'Off' end end end return commandArray Skulle finne et script som beregnet effekt ved å ta tiden på hvor lenge en bryter var inne med fast ohms last. Som varmtvannstank, varmekabler, varmovner, etc.. Fant da skriptet over. Dette fungerer ved at en lager en dummy kWh teller. Telleren må hete nøyaktig det samme som den bryteren en skal måle. Bare med 3 blokkbokstaver i parentes. Den kan endres her if (v == '(VOS)') then Scriptet må settes som Time. Da kjøres det en gang i minuttet. Dummy kWh teller legger til en kWh verdi hvert minutt så lenge bryter en måler ligger inne. For å endre den effekten en legger til dummy devicen. Må en endre på newvalue = otherdevices[i] +25 Her måler jeg en varmeovn på 1500W. Verdien 25 finner jeg da på følgende måte: 1500W / 60 = 25