stigvi

Ja, jeg forstod etterhvert det. Det betyr ikke noe for min del i og med at jeg er kun interessert i billigste timer. Men ser at andre kan synes dette er ergelig. Tibber har disse prisene i NOK i sitt api. Rart at de ikke drar de inn i Home Assistant integrasjonen. Det er jo tydeligvis et behov for det når noen (du) går til det skrittet og lager en Nordpool integrasjon.

Pass forresten på at du har nok desimaler. Ser at Nordpool opererer med 6 siffre på prisene sine.

Og det er et minus i og med at det er diverse som krever 32 bits os

@gskjold, programvaren din (AmsToMqttBridge) har mulighet for å synkronisere klokke mot en NTP tjeneste. Hvorfor det? Kan ikke se at dette er brukt noe i det som sendes til en MQTT broker.

Ok, greit å vite. Det er ikke mange kronene å spare på en esp8266 🙂 Jeg satte selv opp en slik med esp32 og samme programvare på lørdag. Har lagt inn en "issue" på git der jeg spør om å kunne sette retain flagg på noen meldinger på mqtt sånn at en slipper å vente opp mot en time for å få kWh verdien :-)

Hvorfor det?

Fordelen med smarte pærer er at de kan styres individuelt. Det er ikke lett å få til med en dimmer og når lyskildene er på en skinne. En kan ha flerpolt skinne, dog......

I loggene finner jeg pris fra api som virker 10 ganger for lave pr MWh enn forventet så jeg antar det er Nord pool som roter.

I dag ble de nye prisene for i morgen helt feil. Vet du årsaken @hellowlol ? current_price: 0.7147 average: 0.6522 off peak 1: 0.5483 off peak 2: 0.6196 peak: 0.7066 min: 0.5022 max: 0.8283 unit: kWh currency: NOK country: Norway region: Kr.sand low price: false tomorrow_valid: true today: 0.5159, 0.5076, 0.5022, 0.5055, 0.5218, 0.5507, 0.5663, 0.7164, 0.7487, 0.7308, 0.7196, 0.7369, 0.7158, 0.7147, 0.6181, 0.7078, 0.7091, 0.7914, 0.8283, 0.7668, 0.7155, 0.6143, 0.5893, 0.5592 tomorrow: 0.0583, 0.0581, 0.0581, 0.0576, 0.058, 0.06, 0.0727, 0.0912, 0.1008, 0.1008, 0.1, 0.0919, 0.0816, 0.0869, 0.0877, 0.0898, 0.0888, 0.0988, 0.1, 0.0925, 0.0812, 0.0708, 0.0696, 0.0626 raw_today:

Hvis du vil bruke sensor.time så gjøres det slik: binary_sensor: - platform: template sensors: billigste_4_timer: value_template: >- {% set x = states("sensor.time") %} {% set l=state_attr('sensor.nordpool_kwh_xxxxxx_xxx_x_xx_xxx', 'raw_today')|sort(attribute='value') %} {{ (now() >= l[0].start and now() <= l[0].end) or (now() >= l[1].start and now() <= l[1].end) or (now() >= l[2].start and now() <= l[2].end) or (now() >= l[3].start and now() <= l[3].end) }} Da lurer en Home Assistant til å tro at sensor.time brukes i denne malen og den vil oppdateres hver gang sensor.time endres. Maler blir bare evaluert når en entitet brukt i malen endrer seg. Her settes x til tid, men x brukes ikke videre til noe. Istedenfor sensor.time kan du bruke en annen sensor som endrer seg slik du vil. Men skal du ha full kontroll så bruk heller automasjonen som vist i et innlegg ovenfor. Da tvinges malen til å kalkulere på nytt selv om prisen er uendret.

Et annet alternativ er å tvinge en oppdatering hver time med en service som er laget for dette. Se her: Template - Home Assistant (home-assistant.io) En automasjon som kjører et minutt over hver hele time kan se slik ut. - id: '1612783644465' alias: Oppdater mal-entiteter description: '' trigger: - platform: time_pattern minutes: '1' hours: '*' condition: [] action: - service: homeassistant.update_entity data: {} entity_id: - binary_sensor.billigste_time_1 - binary_sensor.billigste_time_2 - binary_sensor.billigste_time_3 - binary_sensor.billigste_time_4 - binary_sensor.billigste_time_5 - binary_sensor.billigste_time_6 mode: single

For å tilfredstille nerdedelen av meg, men også for å få et mer bevist forhold til strømforbruket så hadde det vært utrolig bra å fått tilbake status fra ovner og termostater hvor mye de står på. Både ovner og termostater regulerer varmen trinnløst med å endre på / av forholdet. Ovner gjør dette med en periodetid på få sekunder, mens gulvvarmetermostater har en periodetid på 5 minutt. Hadde en fått tilbake dette på / av forholdet så hadde det vært topp. Men jeg innser at det er bortimot utenkelig. Antar at programvare i ovner og termostater må oppdateres for sånn funksjonalitet og vet ikke engang om det er teknisk mulig i Nobø systemet med OTA oppdatering av dette.

Da er Tibber Pulse lagt i skuffen for godt og jeg har fått på plass en esp32 "dings" med denne, gskjold/AmsToMqttBridge: Minimalistic system to read AMS/HAN data from electrical meter (github.com) , programvaren. Så får vi se på sikt om det var et lurt valg. Men Tibber Pulse bekreftet bare det jeg egentlig viste - at slik funksjonalitet ikke har noe i en skytjeneste å gjøre. Det ble for mange avbrudd og stopp som jeg selv ikke hadde noe kontroll på.

Hva som skjer i fremtiden er ikke godt å si. Men status pr i dag er at Nobø har dokumentert sitt api mot sin hub og det er laget en integrasjon som virker mot Home Assistant og OpenHAB. Vet ikke noe om at det er støttet i andre smarthussystemer.

De skriver at bekvemmeligheten ikke må gå på bekostning av sikkerheten og derfor er det valgt zigbee. Men jeg tror det er en skrivefeil. Det skulle stått "bekvemmeligheten må ikke gå på bekostning av inntektene våre"

Alternativet kan jo være å bruke en treg sensor på et sted der det ikke betyr så mye og heller gå for en bedre der du trenger oppdateringer ofte. Aqara sine sender data med 30s interval hvis endringene tilsier det.

Som kanskje er en underdrivelse. Jeg har en kontaktor som styrer bereder og den første jeg prøvde hørtes ut som et rifleskudd. Så kjøpte jeg en mindre og som skulle være støysvak. Det ble bedre, men den smeller fortsatt.

Er det noen her som har laget kode for å tolke data fra en Aidon (Aidon 6483SE) og som kjører dette på esphome. Og som er villig til å dele koden.......

I dag døde forbindelsen hos meg klokken 15:34 og nå, 20:34 er den ikke i gang igjen. Antar jeg må ta en full omstart av HA. 2021-02-03 15:34:36 ERROR (MainThread) [graphql_subscription_manager] Connection error Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 827, in transfer_data message = await self.read_message() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 895, in read_message frame = await self.read_data_frame(max_size=self.max_size) File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 971, in read_data_frame frame = await self.read_frame(max_size) File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 1047, in read_frame frame = await Frame.read( File "/usr/local/lib/python3.8/site-packages/websockets/framing.py", line 105, in read data = await reader(2) File "/usr/local/lib/python3.8/asyncio/streams.py", line 721, in readexactly raise exceptions.IncompleteReadError(incomplete, n) asyncio.exceptions.IncompleteReadError: 0 bytes read on a total of 2 expected bytes The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/graphql_subscription_manager/__init__.py", line 101, in running msg = await asyncio.wait_for(self.websocket.recv(), timeout=30) File "/usr/local/lib/python3.8/asyncio/tasks.py", line 494, in wait_for return fut.result() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 509, in recv await self.ensure_open() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 803, in ensure_open raise self.connection_closed_exc() websockets.exceptions.ConnectionClosedError: code = 1006 (connection closed abnormally [internal]), no reason 2021-02-03 15:34:59 ERROR (MainThread) [graphql_subscription_manager] 502 - "<!DOCTYPE html>\n<html>\n<head>\n<title>Error</title>\n<style>\n body {\n width: 35em;\n margin: 0 auto;\n font-family: Tahoma, Verdana, Arial, sans-serif;\n }\n</style>\n</head>\n<body>\n<h1>An error occurred.</h1>\n<p>Sorry, the page you are looking for is currently unavailable.<br/>\nPlease try again later.</p>\n<p>If you are the system administrator of this resource then you should check\nthe error log for details.</p>\n<p><em>Faithfully yours, nginx.</em></p>\n</body>\n</html>\n" 2021-02-03 15:34:59 ERROR (MainThread) [graphql_subscription_manager] Connection error Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/graphql_subscription_manager/__init__.py", line 101, in running msg = await asyncio.wait_for(self.websocket.recv(), timeout=30) File "/usr/local/lib/python3.8/asyncio/tasks.py", line 494, in wait_for return fut.result() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 509, in recv await self.ensure_open() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 812, in ensure_open raise self.connection_closed_exc() websockets.exceptions.ConnectionClosedError: code = 1011 (unexpected error), no reason 2021-02-03 15:35:15 ERROR (MainThread) [graphql_subscription_manager] 502 - "<!DOCTYPE 2021-02-03 20:21:57 ERROR (MainThread) [graphql_subscription_manager] Connection is closed, too many concurrent sockets for token 2021-02-03 20:21:57 ERROR (MainThread) [graphql_subscription_manager] Connection error Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/graphql_subscription_manager/__init__.py", line 101, in running msg = await asyncio.wait_for(self.websocket.recv(), timeout=30) File "/usr/local/lib/python3.8/asyncio/tasks.py", line 494, in wait_for return fut.result() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 509, in recv await self.ensure_open() File "/usr/local/lib/python3.8/site-packages/websockets/protocol.py", line 812, in ensure_open raise self.connection_closed_exc() websockets.exceptions.ConnectionClosedError: code = 1011 (unexpected error), no reason

Det er veldig enkelt å finne toppen som ikke er lenger enn 3 timer. Istedenfor de 4 billigste så kan du endre dette til de 3 dyreste

På mandag hadde Kristiansand regionen (som Tysklandskabelen er landfast i) normale priser og ikke disse toppene som resten av landet hadde. Det var fordi denne regionen fikk billig strøm fra utlandet. Jeg synes det er positivt.

Min bereder slås av i 22 timer og da faller temperaturen fra 75 grader til et sted mellom 60 og 65 grader. Så jeg bruker ca 3-4kWh hver dag på å varme vannet og det gjøres i de to billigste timene som vanligvis er rundt om 03:00. Når det varierer så mye som nå så blir det noen få kroner av det. Men alt er relativt. Det er smuler i forhold til det jeg bruker på bilen f.eks.

Jeg har brannvarsler i garasje, men tenkte på om en slik VOC sensor kan brukes til å varsle før det er begynt å brenne. Noen som har peiling på om biler eller det som en normalt stuer vekk i en garasje, genererer skumle gasser som slår ut på en VOC sensor dersom en har varmgang i et eller annet?

Jeg vet ikke om noen termostater som kommuniserer direkte med Google Home. Det enkleste for deg er nok heller å gå et skritt videre og satse på et smarthjem-system. I de kan du integrere det du allerede har og ønsker du talestyring så kan du integrere tjenester som Alexa, Siri eller Google

De har en app som er ganske funksjonell og hub'en tar seg av ukeprogrammer opp og ned i mente. Og de har et dokumentert api for lokal aksess. Et greit system hvis en ikke har smarthus, har Home Assistant eller har OpenHAB. Men det lar seg ikke lett integrere med noe annet og det er en svakhet. Nobø har vel innsett det også og har en serie panelovner med wifi og skyløsning. Men jeg synes det er et skritt i feil retning. Edit: det var kanskje dårlig forklart, men appen virker eksternt. Men den kommuniserer direkte med hub. Sannsynligvis går det via en proxy hos Nobø, men den trenger ikke det. Hub og app kan i samarbeid åpne en port i ruter for inngående trafikk og bruker Nobø sin server for å utveksle ip adresser og portnummer. Men det er ikke viktig hvordan det gjøres. Poenget er at app henter og lagrer sine verdier direkte i hub, enten en er på lobalt nett eller eksternt.