stigvi

Jeg har satt opp disse mqtt sensorene, hvis det var det du lurte på..... "power" kommer i fra mqtt topic som en setter opp i ams2mqttbridge - platform: mqtt name: Klepp Energi Spenning L1 unit_of_measurement: V expire_after: 30 state_topic: "power/meter/l1/voltage" value_template: "{{ value_json | float(0) | round(0) }}" - platform: mqtt name: Klepp Energi Spenning L2 unit_of_measurement: V expire_after: 30 state_topic: "power/meter/l2/voltage" value_template: "{{ value_json | float(0) | round(0) }}" - platform: mqtt name: Klepp Energi Spenning L3 unit_of_measurement: V expire_after: 30 state_topic: "power/meter/l3/voltage" value_template: "{{ value_json | float(0) | round(0) }}" - platform: mqtt name: Klepp Energi Strøm L1 unit_of_measurement: A expire_after: 30 state_topic: "power/meter/l1/current" value_template: "{{ value_json | float(0) | round(1) }}" - platform: mqtt name: Klepp Energi Strøm L2 unit_of_measurement: A expire_after: 30 state_topic: "power/meter/l2/current" value_template: "{{ value_json | float(0) | round(1) }}" - platform: mqtt name: Klepp Energi Strøm L3 unit_of_measurement: A expire_after: 30 state_topic: "power/meter/l3/current" value_template: "{{ value_json | float(0) | round(1) }}" - platform: mqtt name: Klepp Energi Effekt unit_of_measurement: W expire_after: 10 force_update: true state_topic: "power/meter/import/active" - platform: mqtt name: Klepp Energi Total Energi unit_of_measurement: kWh expire_after: 4000 state_topic: "power/meter/import/active/accumulated"

Interessant. Skal kikke på det i kveld

Kunne du komme med et lite hint om hvor de er? Edit: Kikket litt på koden til Tibber integrasjonen for å se om det var en udokumentert innstilling å gjøre for å hente de, men det så jeg ikke noe av. Så jeg antar du tenker på eksempler som bruker pyTibber.

Jeg vurderte det. Integrasjonen baserer seg på pyTibber som ligger på pypi.org og tenkte at det må jo kunne brukes i appDaemon enkelt og greit. Men da tenkte jeg feil. pyTibber gjør noe på bakgrunnstråder som jeg ikke fikk appDaemon til å like og så gadd jeg ikke mer. Motivasjonen var heller ikke allverdens i og med at Nordpool integrasjonen er der og den dekker mitt behov for å finne billigste timer. Om det er i euro eller kroner betyr jo fint lite 🙂 Og nå ser jeg at ams2mqttbridge programvaren som noen her har laget vil også få støtte for å hente priser fra ENTSO-E API så det er nok alternativer.

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.