OlavT

Ja, det er slik jeg tenkte.

Du ser på prisforskjellen før strømstøtte. Du må se på prisforskjellen på den prisen du faktisk betaler etter strømstøtten. På diagrammet er prisen etter strømstøtte den røde kurven.

Kan jo bruke Silicon Labs PC controller til å gjøre denne operasjonen da. Om det er en flyttbar USB-stick som er kontroller.

Jeg tviler på at problemene løses med reboot / reset av Z-TRM3. Tror nok mest sannsynlig problemet ligger andre steder. Hva slags Z-Wave controller benyttes, firmware versjon? Den enkleste rebooten av Z-TRM3 uten reset er strøm av / på.

Silicon Labs PC Controller er et PC-program du kan kjøre for å få opp en basic Z-Wave controller som snakker med USB-sticken og Z-Wave nettverket. Da kan du sjekke hvilke noder som er inkludert, gjøre Add / Remove etc. på noder og sende kommandoer til nodene. Nyttig for å sjekke tilstanden på Z-Wave stick / nettverk.

Har du en USB-basert Z-Wave stick? I så fall ville jeg testet den med en PC med Silicon Labs PC Controller for å se hvordan Z-Wave nettverkets tilstand ser ut. Dersom det ser ut til å fungere så ligger feilen andre steder.

I disse dagene med ekstreme prisvariasjoner er det nok smartere å bruke mer strøm i de timene strømprisene er lavest enn å optimalisere for lavest effektledd. Prisen på de høyeste timene har typisk ligget på 10x prisen til laveste time. Det kan se slik ut (rød kurve er pris etter beregnet strømstøtte basert på gjennomsnittet for 1-16 desember): Her er effektiv gjennomsnittelig strømpris ca 1,56 kr per kWt inkludert alle avgifter og nettleie etter at strømstøtten er trukket fra. Uten å flytte forbruk hadde nok gjennomsnittet ligget over 1kr høyere per kWt. Med et forbruk på ca 70 kWt per døgn vil det si at et trinn opp på nettleien er spart inn på et par dager.

Det er ofte bedre å gjøre en "Replace failed node", så slipper en at den får en ny node id.

Det er alltid en mulighet for at assosiasjoner kan komme ut av sync. Dersom for eksempel termostaten slår av varme og så sendes en kommando fra termostaten til Z-Water forå slå av varmekursen på gulvvarmen. Så slår termostaten på varmen igjen, men kanskje send kommandoen fra termostaten til Z-Water nå feilet av en eller annen grunn. Da kan en risikere at termostaten har varme på, men Z-Water kursen er av. Termostaten vil ikke sende flere kommandoer til Z-Water for å få den på. Den sender bare første gang. Mulig at HA gjør det på en annen måte fra kontrolleren.

Jeg synes Aeotec Heavy Duty fungerer meget bra. Du må selvsagt ha noe som styrer den. Fordelen er at en har full kontroll selv og er ikke avhengig av noe annet som typisk det kan gå ut av support.

Jeg har bra erfaring med disse: Namron LED Pære WarmDim 6W hvit GU10 | Elektroimportøren AS (elektroimportoren.no) Hva slags dimmer bruker du? Bergenet for LED?

Hva er det du egentlig forsøker å oppnå? Styre en termostat (Z-TRM3) basert på temperaturen mål av Multisensor 6 (som da sannsynligvis er et annet sted enn temperatursensoren til Z-TRM3)? Det eneste du evt. kan gjøre for å få det til er å kjøre script / kode som leser temperaturen til Multisensor 6 og som har logiikk for å endre setpoint til termostaten, slik at den skrur seg av / på. For eksempel du måler temperatur til 20 grader og vil at termostat skal slås på. Da må du sette setpoint for termostaten til over termostatens måler. Går for eksempel temperaturen opp til 22 grader og du ønsker termostaten av, så setter du setpoint til under temperaturen til termostatens måler.

Det lukter mange kuldegrader kanskje?

Jeg ønsker å se nærmere på muligheten for å beregne økonomisk effekt av å øke / senke temperaturen i rom basert på strømpriser. Utgangspunktet er en antakelse om at det kanskje kunne lønne seg å øke temperaturen noe ved lave strømpriser og senke noe ved høye strømpriser. Dersom en skal styre etter dette, vil det være nødvendig å kunne beregne eventuell gevinst og styre deretter. For å komme i gang med dette, så tenkte jeg å validere noen hypoteser. Den første hypotesen er grunnlag for å kunne beregne hvor mye ekstra energi det krever å varme opp fra X grader til Y grader for så å la temperaturen falle til X igjen. La oss anta følgende data basert på observasjoner: Tid Ute Inne 1 Inne 2 Diff 1 Diff 2 Temp diff Varmetap 1 Varmetap 2 Økning prosent T0 -15 6.4 6.4 21.4 21.4 T1 -15 6.4 9.5 21.4 24.5 22.95 1 1.072429907 7.24% T2 -15 6.4 7.95 21.4 22.95 23.725 1 1.10864486 10.86% T3 -15 6.4 7.325 21.4 22.325 22.6375 1 1.057827103 5.78% T4 -15 6.4 6.9 21.4 21.9 22.1125 1 1.033294393 3.33% T5 -15 6.4 6.4 21.4 21.4 21.65 1 1.011682243 1.17% 5 5.283878505 5.68% Tabellen fra regnearket viser temperaturer ute / inne ved to forskjellige scenarier: 1) Inne 1: Konstant temperatur X = 6.4 grader 2) Inne 2: Øke temperaturen til Y = 9.5 grader for deretter å senke til X = 6.4 grader igjen. Inne 2 kolonnen inneholder observerte temperaturer ved gitt tidspunkt (for eksempel hver time). Denne modellen tar utgangspunktet i at varmetap er en lineær funksjon basert på forskjellen mellom inne- og utetemperatur. Kolonnen "Temp diff" er gjennomsnittelig temperatur forskjell mellom inne og ute i forrige tidsintervall. Økningen i varmetap skal etter det jeg har lest være lik økningen i temperaturforskjell. Det vil si at om temperaturforskjellen øker fra 21.4 grader til 22.95 grader, så blir varmetapet 7.34% større. Regnestykkene viser i mitt tilfelle at ekstra effektbruk ved å øke temperaturen fra 6.4 til 9.5 grader for så å la den falle til 6.4 grader igjen utgjør 5.68% sammenlignet med konstant temperatur på 6.4 grader. Det gjenstår selvfølgelig å sjekke opp dette ved å måle og sammenligne faktisk effektbruk, men det har jeg ikke kommet til enda. Er det noen som har erfaringer eller teoretisk kunnskap om dette? Holder hypotesen min i utgangspunktet vann?

Jeg har en support-sak gående med Silicon Labs. Når en kontroller sender en melding til en node i Z-Wave nettverket rapporteres det tilbake til kontroller software hvor lang tid det tok å sende meldingen. Dette er beskrevet i spesifikasjonene: 4.2.10 Tx Status Report (N bytes) When a Z-Wave transmission has been completed, the Z-Wave API Module can issue a Tx Status Report providing details about the transmission that was carried out. Et av feltene i Tx Status report er: Transmit Ticks (16 bits) This field is used to indicate the transmission time in multiples of 10ms. For example, the value 30 MUST indicate that the transmission took 300ms. Problemet jeg opplever er at av og til (etter feil i overføringer), så rapporteres det ugyldige verdier for Transmit Ticks. Med det mener jeg at rapporten viser en tid som er lenger enn det er siden kommandoen ble sendt. I min egen sw fanger jeg opp dette ved å legge inn en spesifikk sjekk for dette og logger det: if (transmitMilliseconds > totalExecutionTimeMilliseconds) { // Data does not make sense LogInvalidTransmitTime(currentCommand, response); } Dette går sannsynligvis under radaren for de fleste da forekomsten er relativt sjelden. Den er sannsynligivis hyppigere for større nettverk da sannsynligheten for kollisjoner og feilsendinger øker. Kunne du tenke deg å bidra med informasjon om denne feilen? Så vidt jeg vet er det en del som kjører Z-Wave løsninger med Z-Wave JS i bunn. Dette gjelder vel for eksempel Home Assistant. Mulig det finnes informasjon om Z-Wave detaljer i logger for andre kontrollere også, men det har jeg ikke sjekket. I logger fra Z-Wave JS fremgår Transmit Ticks slik: transmit status: OK, took 80 ms Det hadde vært fint om noen hadde hatt mulighet til å sjekke litt i loggene for sitt nettverk (gjerne de med 10-20 noder og oppover). Det jeg ville sett etter er først å søke etter forekomster av transmit status med "Fail" (søke på "Fail, took"). I meldinger rett etter dette har jeg sett at det ofte rapporteres et antall millisekunder som ikke kan stemme basert på timestamps for når meldingene er sendt. Noen som har sett noe slikt? Det finnes forøvrig en del bugs i Z-Wave knyttet til meldinger med måleverdier. Dersom noen av og til får inn merkelige verdier for måleverdier, så skyldes det kankje disse feilene og at kontroller software ikke sjekker før det rapporteres videre. Et eksempel på dette er meldingen: SOF Length=0x14 REQUEST FUNC_ID_APPLICATION_COMMAND_HANDLER_BRIDGE Single 01 SourceNodeId=0x19 PayloadLength=0x0b 56 01 31 05 04 22 00 e9 15 dc 3f 00 c0 Checksum=0xca (her CRC OK, og det er faktisk feil i meldingen som sendes fra noden, dette er sjekket med Zniffer). Her er problemet: SensorMultilevelReportCommand: Sensor Value field length mismatch. Expected length 2. Actual length 3.

Solgt.

Dersom noen ønsker å se nærmere på trafikk / meldinger på sitt Z-Wave nettverk så finnes det et verktøy som heter Zniffer som kan fange opp meldingene som sendes på det trådløse nettverket. Jeg selger en Silicon Labs UZB3 stick med Zniffer firmware: Silicon Labs UZB3 Z-Wave USB stick, EU | FINN.no

Ja, men beste estimatet er nok ut fra det en vet i øyeblikket. Så kan selvsagt det bildet endre seg en god del i løpet av en måned.

Denne viser at det kan være viktig å styre etter strømpris justert for strømkompensasjon: Spotpris 30.11 kl. 23-00: 3.39kr per kWh, etter strømstøtte: 2.93kr per kWh. Basert på faktisk strømstøtte for november. Spotpris 01.11 kl. 00-01: 3.46kr per kWh, etter strømstøtte: 0.32kr per kWh. NB! Basert på estimert strømstøtte for desember. Det er da penger å spare på å flytte forbruket. Her er resultatet (grønn kurve viser totalpris etter strømstøtte inkludert nettleie):

Hvilken temperatur rapporterer ovnen? Er det 21 grader som du nevner, eller måler du den på en annen måte?

Liten vits å tviholde på 5kW grensen i vintermånedene. Like greit å guffe på med mer effekt de timene som er lavest priset.

Hva vil du med den ekstra sensoren på baded? Du må vel nesten bestemme deg for om du vil la gulvtemperaturen danne grunnlaget for varme av / på eller noen annet.

Fungerer akkurat som beskrevet i Z-Wave spesifikasjonene. For alle som følger den.

Her er bevis på at det fungerer (Hardware version: 3, Firimware version: 4.0, 4.0): [17.11.2022 10:10:16.731 INF] Sending Z-Wave command (waited 0.094s): Id=6207 SOF Length=0e REQUEST FUNC_ID_ZW_SEND_DATA NodeId=0x000d PayloadLength=0x06 command=[THERMOSTAT_SETPOINT Set SetpointType=Heating 22 00 d2] 25 SessionId=0xf6 Checksum=0x89 [17.11.2022 10:10:16.755 INF] SerialDevice.ReadBytes: 06 01 04 01 13 01 e8 [17.11.2022 10:10:16.755 INF] Response: ACK [17.11.2022 10:10:16.755 INF] Response: SOF Length=0x04 RESPONSE FUNC_ID_ZW_SEND_DATA Success Checksum=0xe8 [17.11.2022 10:10:16.757 INF] ACK sent [17.11.2022 10:10:16.784 INF] SerialDevice.ReadBytes: 01 1d 00 13 f6 00 00 01 00 a7 7f 7f 7f 7f 00 00 03 00 00 00 00 03 01 00 00 7f 7f 7f 7f 7f df [17.11.2022 10:10:16.785 INF] Response: SOF Length=0x1d REQUEST FUNC_ID_ZW_SEND_DATA SessionId=0xf6 OK TxMs=10 Repeaters=0 RSSI=[-89,127,127,127,127] Route=[0,0,0,0] Speed=100k RouteTries=1 Checksum=0xdf [17.11.2022 10:10:16.786 INF] ACK sent [17.11.2022 10:10:16.829 INF] ProcessCommand: Z-Wave command finished executing (ResponseComplete 96.9352ms): Id=6207 SOF Length=0e REQUEST FUNC_ID_ZW_SEND_DATA NodeId=0x000d PayloadLength=0x06 command=[THERMOSTAT_SETPOINT Set SetpointType=Heating 22 00 d2] 25 SessionId=0xf6 Checksum=0x89. [17.11.2022 10:10:16.830 INF] Sending Z-Wave command (waited 0.189s): Id=6208 SOF Length=0b REQUEST FUNC_ID_ZW_SEND_DATA NodeId=0x000d PayloadLength=0x03 command=[THERMOSTAT_SETPOINT Get setpointType=Heating] 25 SessionId=0xf7 Checksum=0x7b [17.11.2022 10:10:16.851 INF] SerialDevice.ReadBytes: 06 01 04 01 13 01 e8 [17.11.2022 10:10:16.851 INF] Response: ACK [17.11.2022 10:10:16.851 INF] Response: SOF Length=0x04 RESPONSE FUNC_ID_ZW_SEND_DATA Success Checksum=0xe8 [17.11.2022 10:10:16.853 INF] ACK sent [17.11.2022 10:10:16.869 INF] SerialDevice.ReadBytes: 01 1d 00 13 f7 00 00 01 00 a6 7f 7f 7f 7f 00 00 03 00 00 00 00 03 01 00 00 7f 7f 7f 7f 7f df [17.11.2022 10:10:16.869 INF] Response: SOF Length=0x1d REQUEST FUNC_ID_ZW_SEND_DATA SessionId=0xf7 OK TxMs=10 Repeaters=0 RSSI=[-90,127,127,127,127] Route=[0,0,0,0] Speed=100k RouteTries=1 Checksum=0xdf [17.11.2022 10:10:16.870 INF] ACK sent [17.11.2022 10:10:16.889 INF] SerialDevice.ReadBytes: 01 14 00 a8 00 00 01 00 0d 06 43 03 01 22 00 d2 00 a6 00 7f 7f 5e [17.11.2022 10:10:16.890 INF] Response: SOF Length=0x14 REQUEST FUNC_ID_APPLICATION_COMMAND_HANDLER_BRIDGE Single DestNodeId=0x0001 SourceNodeId=0x000d PayloadLength=0x06 command=[THERMOSTAT_SETPOINT Report 01 22 00 d2] 00 RSSI=-90 SecurityKey=0 7f 7f Checksum=0x5e [17.11.2022 10:10:16.891 INF] ACK sent [17.11.2022 10:10:16.891 INF] ThermostatSetpoint.HandleReport: setPointType=Heating size=2 scaleId=0 setpointValue=21 [17.11.2022 10:10:16.929 INF] ProcessCommand: Z-Wave command finished executing (ResponseComplete 98.6214ms): Id=6208 SOF Length=0b REQUEST FUNC_ID_ZW_SEND_DATA NodeId=0x000d PayloadLength=0x03 command=[THERMOSTAT_SETPOINT Get setpointType=Heating] 25 SessionId=0xf7 Checksum=0x7b.

Men, det er ikke et Z-Wave problem. Open Z-Wave har sannsynligvis noen problemer på sin side.