OlavT

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.

Ordinær firmware støtter oppdatering av setpoint. Om du trenger uofisiell firmware så må det være relatert til noe Homeseer eller annet tror jeg. Jeg kjører med vanlig firmware som levert fra butikk.

Bytter gjerne en TRM2fx mot en TRM-3 om du er interessert.

"Men at den ikke kan stilles over Z-Wave anser jeg som en bug." Temperaturen på HeatIt Z-TRM3 kan definitivt settes over Z-Wave. Jeg gjør dette hele tiden fra min egen kontroller software. Det er i såfall Homeseer som ikke gjør dette.

Takk for korrigeringen. Da har jeg fått fikset en bug i koden min (Z-Wave controlleren) ved mapping fra BASIC_REPORT til SWITCH_BINARY_REPORT som gjorde at tilstanden til switchen ble strippet av og det førte til at den alltid ble rapportert til å være av. Nå fungerer det bedre (og uten polling)!

Det ser ut til at den sender BASIC_REPORT til tross for at det ikke er annonsert i Association Group Information command class.

Forklar! Får du BINARY_SWITCH_REPORT meldinger automatisk fra Z-Water via Lifeline?

Du kan starte med 1 HeatIt Z-Water og 1 TRM-3, men du synes kanskje det blir for dyrt?

Jeg har 2 stk Z-Water og de rapporterer: Kunne jo vært greit om 3.1 hadde vært tilgjengelig for nedlasting også da!

Et lite irritasjonsmoment ved HeatIt Z-Water er at den ikke har mulighet til å sende SWITCH_BINARY_REPORT til kontroller ved endring av rele-tilstand. Burde vært mulig å sette opp en association for det. Litt irriternede å måtte polle for å få oversikt over tilstand på releene. Oppdatering: Etter mer testing viser det seg at Z-Water faktisk sender BASIC_REPORT ved endring av tilstand til releene. Dette til tross for at dette ikke er spesifisert i kommando-listen for Assocation Group Information command class som vist her: Jeg antok derfor at den ikke støtte dette.

Her er en Zniffer log over trafikk som er relatert til "død" Namron dimmer: Konklusjonen er nok enkel: Den svarer ikke på meldinger i det hele tatt. Er nok en bug i firmware. Har en sak gående med Elektroimportøren for å se om det er mulig å fremskaffe nyere firmware.

Da stoppet den ene dimmeren hos meg å respondere. Hvilken versjon av firmware har dere? Min har denne: Litt merkelig at de har 1.12 da Z-Wave sertifiseringsdokumentet henviser til 1.17. Får sjekke med Elektroimportøren om de har nyere firmware.

Jeg har skrevet kontrolleren min fra bunn av i c#, så feil her er selvsagt utelukket. Dimmerene har faktisk oppført seg ok en stund nå. Husker ikke helt når jeg tok sikringen på de sist. Har nå flashet opp en UZB3 med Zniffer firmware så da kan jeg sjekke meldingene som går i det trådløse Z-Wave nettverket uavhengig av kontroller-software.