Styra relä via spotpris, någon som har kod att utgå ifrån?

[P-solver]

Hej, jag har ett mindre hyreshus där jag skulle vilja styra en signal till min pelletsanläggning baserat på spotpris.

Det jag i första hand vill göra, och som jag skulle vilja komma igång med relativt snabbt, är att "stänga ett relä" om nästa timmes spotpris är över 80 öre.

Reläet styr bara en signal från en tempgivare, så ingen högspänning.

Min fråga är om någon har en befintlig kod att dela med sig av för att komma i närheten av en färdig lösning av detta?

Jag har en respberry pi och lite arduino-delar liggandes här hemma.

Kodspråk spelar ingen roll.

[Klas-Kenny]

Blir lite onödigt omständligt kanske, men jag använder HomeAssistant för att göra liknande.

Finns plugins för att hämta elpris ifrån NordPool, sen är det en rätt smal sak att skriva ett script som körs varje timme och kontrollerar om det är över 80 öre.
Men det skulle kunna köras på en Raspberry Pi.

[RDX*]

Eller node-red med https://powersaver.no/.

[P-solver]

Node Red och en Raspberry Pi fick det bli!

Nu har jag laddat ner "Nordpool API +" och ska försöka fördjupa mig i hur jag ska skapa inställningarna i resp. nod.

Det här blir intressant

[P-solver]

Nu har jag kört fast och detta kanske inte är rätt forum, men jag frågar iaf;

Jag kan hämta dagens spotpris till en array på 24 positioner via en nod i node-red, och arrayen ser ok ut när jag debuggar den.

Men hur ska jag enklast hämta "näst timmes elpris" som jag vill använda för senare styrning av mitt relä?

Finns det någon nod för det, eller är det en funktionsnod med javascrip som gäller isf?

Det jag vill göra är att varje timme läsa "nästa timmes elpris" och om det är högre än t.ex 60 öre så skall signal skickas att sätta GPIO pin 40 till "true" i min raspberry PI. (Hur jag styr GPIO på RPI har jag kolla på)

[MiaM]

Det där låter som en fråga för t.ex. stack overflow, eller kanske Kodapor på Facebook.

Jag måste erkänna att jag inte riktigt förstår frågan. Är problemet att avgöra vilken position i array:en som är "nästa timme" eller är problemet att göra jämförelsen?

(Jag har väldigt lite koll på dessa moderna webbmässiga programmeringsmetoder. Jag hade skrivit allt i C).

Sidospår: tänk på problemet med midnatt. Du lär vilja ha utrymme för en array som rymmer minst 48 timmar och ett sätt för att på rätt sätt hantera wrap-around.

P.S. dela gärna med dig av resultatet!

[Mickecarlsson]

Läs in arrayn med spotpriser, och gör dig själv en björntjänst, förutsätt inte 24 rader, det är 25 rader 2 ggr om året.
Arrayn är då från spotpris[0] 00:00 till 00:59, spotpris[1] är från 01:00-01:59 etc etc
Läs in vilken timme du är på och gör det till en int, tex. kallad nutid, vill du ha reda på aktuell timmes nypris har du det i spotpris[nutid], vill du ha reda på nästa timmes spotpris är har du det i spotpris[nutid+1]

[MiaM]

Bra varning angående antalet timmar.

Men det är väl 25 timmar en dag per år och 23 en annan dag, eller?

(Som kvällspigg så önskar jag att det vore 25 timmar per dygn ett par gånger per år och aldrig 23 timmar per dygn )

(Också: "björntjänst" i detta fall vore väl att hårdkoda tabellen till att rymma 24 timmar - björntjänst betyder ju att göra något med avsikt att det ska vara bra men det i praktiken blir dåligt. En typisk björntjänst är att bjuda någon svältande på mat men där det visar sig att den svältande är allergisk mot matens innehåll).

Vet inte vad som tekniskt sett vore bäst men tänker en array som rymmer 64 timmar och man adresserar den genom att räkna timmar enligt UTC från när nu tidsräkningen för ens system börjar (1970 för unix osv) och bara kapar de övre bitarna (som används för att räkna fler timmar än 0-63). Tabellen kanske med fördel bör ha ett fält som innehåller några av de ytterligare bitarna för att räkna timmar, för att kunna avgöra hur långt framåt tabellen innehåller data för ögonblicket och också för att koden som läser ur tabellen ska kunna larma ifall hämtning av data misslyckats, och också för att kunna felhantera detta på lämpligt sätt (t.ex. köra på en förprogrammering som utgår från att elen är särdeles dyr på morgon och eftermiddag och på vardagar är halvdyr mellan morgon och eftermiddag).

[Mickecarlsson]

Tänker du rätt nu MiaM? Det är alltid 24 timmar, det kan vi vara överens om. UTC är alltid rätt.
Men, för att hålla reda på det dygn vi går in i sommartiden så måste det adderas en timme för att hålla reda på den timme som ”försvinner”.
Sak samma när vi går ur sommartid, en timme läggs till för att hålla reda på timmen som läggs till.
Mitt skript havererade då jag förutsatte 24 timmar, så jag gjorde om det och kör en sizeof() på arrayn så jag vet hur många rader arrayn har.

[MiaM]

UTC-dygn är alltid 24 timmar.

Dygn räknade med lokal sommartid/vintertidväxling har en gång 23 och en gång 25 timmar per år.

Jag tänker att måste vara enklast att ens lokala tabell rymmer avsevärt mer data (därav mitt förslag på 64 timmar) dels för att kunna hantera sommar/vintertid och dels för att hantera att hämta data för nästa dygn utan att skriva över nuvarande dygn. Och alltså köra allt på UTC i koden.

Kom just på att fallbackkod som använder nån strategi typ "det är dyrt på morgon och eftermiddag" då data saknas måste hålla koll på sommar/vintertid.

Tror att i användarinterface, då man gör detta för egen användning, bör man med fördel presentera allt tid både som UTC och lokal sommar/vintertid. Det blir lättare dels att se buggar och dels hålla koll på vad man gör när man ska uppdatera fallbackstrategi och/eller när man tittar på rådata i tabellen.

Som tur är så angående fallbackkod så är elen nog att betrakta som billig under hela perioden då växlingen sker mellan sommar/vintertid på småtimmarna på natten.

[Mickecarlsson]

Jag gissade att Nordpool måste ha detta definierat, och det hade dom: https://www.nordpoolgroup.com/en/pages/ ... dard-time/

Du hade rätt, det är bara 23 timmar när vi går in i sommartiden, och 25 när vi går ur