xibriz

Armas skrev (1 minutt siden):

 

Det scriptet sparer deg vel bare for økte kostnader til fastleddet, det hjelper ikke til med å bruke mindre strøm?

Jeg gjorde noen raske overslag og mener å huske at det var mer lønnsomt for meg å flytte strømforbruk til billige timer, en å holde meg under 5kwH-grensen.  Du ser ut til å ha gått motsatt vei?

Det er korrekt, jeg har kun fokusert på effektleddet.

Det som i realiteten skjer er jo at strømforbruket begrenses, spesielt på oppvarming. Boligen min har ett umettelig oppvarmingsbehov så all besparelse er pga. at komforttemperaturen i år nok er litt lavere enn i fjor.

En annen effekt er at jeg ofte skrur av unødvendige ting for å få mer strøm tilgjengelig til oppvarming, og prioriterer hvilke rom som skal varmes opp. Det er nok her besparelsen ligger.

Nå er året snart omme, og jeg ligger an til en besparelse på mellom 4 og 5000 kWh på hele året pga. skriptet som prøver å holde forbruket under 5 kWh siden fastledded dobles fra 2-5 kontra 5-10 kWh.

200 kvm ende-rekkehus fra 1970:

2021: 28 000 kWh

2022: 23 000 kWh

Det som er irriterende er jo at jeg ikke har styring på absolutt alt, så hvis det sniker seg inn en time der det ikke er mer å slå av, så havner jeg likevel over 😡

Den toppen kostet 150 kr:

Jeg holdt mye på med radiostyrte biler og lipo-batterier før. En gang koblet jeg feil på pluss og minus til laderen, og når jeg skjønte det etter 1.5 sekund så var ledningene så varm at jeg måtte ofre en del hud for å dra ut ledningene. Der snakker vi om farlige greier 🤯

Etter litt reasearch på sofaen:

En pir-sensor har gjerne 2-4 felter som detekterer bevegelse når ett objekt flytter seg fra ett felt til ett annet på sensoren.
Plasttypen polyethylene (finnes i plastposer) slipper gjennom riktige bølgelender.

En "skyggelinse" er en fattigmannsversjon av frensel 😛

En kjapp test viser at jeg er inne på noe her

Lesestoff for de intereserte: http://www.glolab.com/focusdevices/focus.html

Ja det var vel det jeg fryktet. Jeg må se om jeg kan finne noe brukende å demontere her hjemme.

Har jobbet med en multisensor (lys, temperatur og bevegelse) de siste dagene.

Jeg hadde ikke lyst til å ha den vanlige "domen" som er forran PIR-sensoren så jeg har prøvd noen materialer (transparent PLA, utklipp fra noe emballasje) uten hell.

Slik jeg skjønner det så må jeg finne noe materiale som slipper gjennom de riktige IR-bølgelengdene. Noen som har noen tips til materialvalg?

For scale

Det er litt misvisende for jeg har panelovner på 800w og konvektorovner på 2000w, varmekabler på henholdsvis 500w (sov), 700w (gang), og 800w (bad).

Så min gamle elbil hadde ett strømforbruk på:

3x konvektorovn

+ varmekabel sov

+ varmekabel bad

- varmekabel gang
= 6.6 kW

Siden jeg bare har 2 konvektorovner så blir dette vanskelig å forholde seg til 🤣

Jeg synes hele nettleiediskusjonen er veldig uoversiktlig og minner om propaganda fra alle kanter.

I det ene øyeblikket så sies det at hvis man ikke foretar seg noe så kommer man dårligere ut med ny nettleie enn med dagens modell.

I neste øyeblikk så taper kundene på at den nye nettleiemodellen nå utsettes.

Hva som er fakta er ikke lett å finne ut av.

I tillegg så har min kraftleverandør (Arva) ikke publisert noen priser om ny modell selv om det knapt 2 uker til den skal innføres. Nå skylder de på regjeringen men de hadde ikke publisert noen info før fredagen heller.

Dere burde roe ned bruken av å starte en topic med /

Det gir ingen mening og best practice er at man ikke bruker "leading slash".

Det er så vidt man ser C# der nede på listen 

Ref https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages

Er det effektrapportering på disse dimmerene?

Jeg plugget nettopp i 4 stk aeotec switch 6 og opplever at z-wave-nettverket ble betraktelig mye tregere.

Jeg antar at dette er pga. effektrapporteringen. Det må sikkert bare tunes litt så blir det vel bra, men det irriterer meg ikke foreløpig  

4 minutes ago, stigvi said:

Det er vel dette netteiere prøver å unngå. Det blir et problem hvis alle skal gjøre som du. Bortsett fra at da blir det ikke billig strøm lenger, men dyrest på natten når alle skal lade.

For meg personlig passer det ypperlig med billigere strøm på dagtid siden det er da jeg bruker mest 😉

Helt enig. Jeg føler at de eneste som driver med smarte løsninger for strøm er nettselskapene. Det er helt håpløst å bruke mest mulig strøm når den er billigst samtidig som man holder seg under en maksverdi på timen.

Tok en kjapp kikk på dokumentasjonen: https://www.home-assistant.io/integrations/sensor.mqtt/ og https://www.home-assistant.io/docs/configuration/templating/#attributes

Og det ser ut som det skal være `value__json` og ikke  `value.json`.

Vi får vente til en kar fra ett kraftselskap med litt teknisk kompetanse stikker innom tråden  

1 minute ago, ArnieO said:

Godt spørsmål! Jeg minnes å ha lest noe om det der.

 

Der er ingen data på HAN-porten som (så vidt jeg kan forstå) kan brukes til å detektere jordfeil. Så enten er dette en måling som kun går til nettselskapet, eller så bruker de en kombinasjon av mange målinger til å avdekke hvor i et nabolag jordfeilen er.

Grunnen til at jeg spør er at en slektning ble kontaktet av kraftselskapet om at han hadde jordfeil og måtte fikse det. En elektriker fant jordfeil i en skjøteledning etter 3-4 timers feilsøking.

Også leser jeg her: https://www.tromskraftnett.no/privat/ams

Quote

• Med AMS installert vil vi kunne oppdage jordfeil og varsle kunden. Vi vil også kunne bistå online med å detektere jordfeil når installatør eller kunde tester kurser i anlegget. 

Så da tenkte jeg at kanskje man kunne være preventiv hvis man visste dette så fort som mulig (kanskje man akkurat hadde plugget i noe).

En annen ting, jeg vet at nettselskapet kan bruke AMS-måleren til å se jordfeil. Er dette noe man kan dra ut av HAN-porten?

Dette har vært svært effektivt for oss som ligger helt i grenseland når jeg ser på den timen med høyes forbruk på en gitt dag.

Men jeg ser at dagsforbruket (kolonnen til venstre) holder seg svært likt. Det har bare jevnet seg litt mer ut.

8 hours ago, Ontrack said:

 

Du må huske å justere tallene (4500, 4800, 6000 osv) til noe nærmere 10000 hvis du satser på 10kWh.

55 minutes ago, ArnieO said:

 

Hvordan beregner du timesgjennomsnittet? (Jada, koden din ligger der oppe, men det er enklere å spørre... 😄)

 

Jeg forventer at det som går ut fra måleren er differansen mellom to heltimes-avlesninger, basert på klokka i måleren. Er du sikker på at du leser av på rett tidspunkt?

Firmwaren AmsToMqttBridge sender "package timestamp" til MQTT. Dersom det er den du bruker så pass på at du har siste versjon; jeg mener å huske at det har vært noe kluss med den parameteren underveis i utviklingen.

https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats

Jeg lagrer verdien når jeg får den og bruker timestamp på serveren og ikke fra måleren. Men forsinkelsen er vel ikke værre enn at det blir +- ett par målinger.

Så tar jeg å leser alle verdier innenfor gjeldende time, summerer de sammen og deler på antall verdier.

Jeg bruker den versjonen fra da jeg var med på å lage den, og den er vel fra 2018 eller eldre  

Kanskje jeg må legge inn en bestilling hos deg siden min krever stikkontakt. Det gikk bra i det forrige huset fordi der hadde jeg kontakt på DIN-skinnen, men her må jeg strekke en lang kabel til nærmeste stikk 😛 

Jeg lurer på om det er litt tidsforsinkelse på dataen som nettleverandøren bruker. Jeg fikk en differanse på over 4% en time der det var høyt effektbruk i timeskillet. Det er helt i grenseland av hva som er håndterbart dersom mine beregninger hadde vist 4800kWh.

Det værste er at det ikke er mange minuttene man må slå av varmekilder/store laster på en time for å kompansere. Maks 5-10 minutter har jeg erfart siden jeg begynte på søndag 

2 minutes ago, ArnieO said:

(Jeg får ikke lov til å trykke flere "Like" i dag - men liker dette veldig!) 👍

 

Jeg står foran boligbytte, og det er ikke umulig at jeg benytter anledningen til å konvertere fra Domoticz til OpenHAB eller HomeAssistant.

Uansett veldig aktuelt å se på en slik automatisering snart, og dette er et flott utgangspunkt.

 

Godt jobbet!

Jeg vurderte å gå over til HomeAssistant, men openHAB er blitt så bra at jeg ikke orket

Det jeg liker best med openHAB er at man kan skrive alt i tekstfiler. Ja, man hadde sikkert klart å lage regelen over i GUI, men kan man programmere er det kjappere å bare bruke nano i bash  

Jeg tenkte å ta en kjapp wirte up på hvordan jeg har begrenset effektleddet med openHAB. Jeg ser at det skrives noe om PID andre steder men det ble for avansert for meg å sette meg inn i  

Før man begynner må man ha inn ActiveImportPower fra HAN-porten på en eller annen måte. Jeg bruker kortet jeg lagde i 2017/18 som blant annet @ArnieO har tatt til nye høyder.

Først lagrer jeg alle verdier i InfluxDB for enkelhets skyld med følgende dette python-script. Det kjører som en service.

# -*- coding: utf-8 -*-

import random
import time
from datetime import datetime
from paho.mqtt import client as mqtt_client
from influxdb import InfluxDBClient

broker = 'openhabian.localdomain'
port = 1883
topic = "esp/ams/activeimportpower"
client_id = f'python-ams-mqtt-influx-{random.randint(0, 1000)}'

dbname = "ams"
dbuser = "ams"
dbpass = "ams"

def connect_mqtt():
    def on_connect(client, userdata, flags, rc):
        if rc == 0:
            print("Connected to MQTT Broker!")
        else:
            print("Failed to connect, return code %d\n", rc)
    # Set Connecting Client ID
    client = mqtt_client.Client(client_id)
    client.on_connect = on_connect
    client.connect(broker, port)
    return client

def subscribe(client: mqtt_client, dbclient: InfluxDBClient):
    def on_message(client, userdata, msg):
        print(f"Received `{msg.payload.decode()}` from `{msg.topic}` topic")
        store(dbclient, msg.payload.decode())

    client.subscribe(topic)
    client.on_message = on_message

def store(dbclient: InfluxDBClient, power):
    json_body = [
        {
            "measurement": "activeimportpower",
            "time": datetime.now(),
            "fields": {
                "value": int(power)
            }
        }
    ]
    dbclient.write_points(json_body)

def run():
    dbclient = InfluxDBClient('localhost', 8086, dbuser, dbpass, dbname)
    client = connect_mqtt()
    subscribe(client, dbclient)
    client.loop_forever()

if __name__ == '__main__':
    run()

Deretter kalkulerer jeg gjeldende kWh-forbruk hver andre minutt med dette scriptet. Det kjører som en cron-jobb (*/2 * * * *).

# -*- coding: utf-8 -*-

import random
import time
from datetime import datetime
from paho.mqtt import client as mqtt_client
from influxdb import InfluxDBClient

broker = 'openhabian.localdomain'
port = 1883
topic = "esp/ams/avaragewh"
client_id = f'python-avarage-wh-{random.randint(0, 1000)}'

dbname = "ams"
dbuser = "ams"
dbpass = "ams"

def connect_mqtt():
    def on_connect(client, userdata, flags, rc):
        if rc != 0:
            print("Failed to connect, return code %d\n", rc)
    # Set Connecting Client ID
    client = mqtt_client.Client(client_id)
    client.on_connect = on_connect
    client.connect(broker, port)
    return client

def publish(client, dbclient):
    avarage = avarage_wh(dbclient)
    # If avarage is None we probably don't have enough data to calculate the avarage
    if avarage is None:
        return

    result = client.publish(topic, avarage)
    # result: [0, 1]
    status = result[0]
    if status != 0:
        print(f"Failed to send message to topic {topic}")

def avarage_wh(dbclient):
    hour_start = str(datetime.now().replace(microsecond=0, second=0, minute=0)).replace(' ', 'T')

    result = dbclient.query(f"SELECT * FROM activeimportpower WHERE time >= '{hour_start}Z'")
    count = 0
    sum = 0
    try:
        for val in list(result)[0]:
            count += 1
            sum += val['value']
    except:
        return None
    return round(sum / count)

def run():
    dbclient = InfluxDBClient('localhost', 8086, dbuser, dbpass, dbname)
    client = connect_mqtt()
    publish(client, dbclient)
    client.disconnect()

if __name__ == '__main__':
    run()

Da får vi gjeldende kWh ut på mqtt-topic "esp/ams/avaragewh" som vi kan bruke i openHAB til å gjøre noen beslutninger med disse reglene:

var high_kwh_threshold = 4800 // Turn off items if kWh is above this number
var low_kwh_threshold = 4600 // Turn on items if kWh is below this number
var min_current_w = 4500 // If we need to turn off items, turn off enough items so that the current watt usage is below this number
var max_current_w = 6000 // If we can turn on items, turn on enough items so that the current watt usage is below this number

rule "high kwh"
when
        Item AMS_AvarageWh changed
then
        // If the avarage is above 4800 kWh we need to bring the current usage below 4500w
        if ((AMS_AvarageWh.state as Number) > high_kwh_threshold) {
                var current_w = AMS_ActiveImportPower.state as Number

                // Turn off office
                if (current_w > min_current_w && OfficeHeat_Switch.state == ON) {
                        OfficeHeat_Switch.sendCommand(OFF)
                        current_w -= OfficeHeat_Electricmeterwatts.state as Number // Subtract current usage
                }

                // Turn off hallway
                if (current_w > min_current_w && (HallwayFloor_Thermostatmode.state as Number) == 1) {
                        HallwayFloor_Thermostatmode.sendCommand(0)
                        current_w -= HallwayFloor_Electricmeterwatts.state as Number // Subtract current usage
                }

                // Turn off bath room
                if (current_w > min_current_w && (BathRoomFloor_Thermostatmode.state as Number) == 1) {
                        BathRoomFloor_Thermostatmode.sendCommand(0)
                        current_w -= BathRoomFloor_Electricmeterwatts.state as Number // Subtract current usage
                }

                // Turn off living room
                if (current_w > min_current_w && LivingHeat_Switch.state == ON) {
                        LivingHeat_Switch.sendCommand(OFF)
                        current_w -= LivingHeat_Electricmeterwatts.state as Number // Subtract current usage
                }
        }
end

rule "low kwh"
when
        Item AMS_AvarageWh changed
then
        //logDebug("ams", "LOW KWH START")
        // If the avarage is below 4600 kWh we can start to bring the current usage up
        if ((AMS_AvarageWh.state as Number) < low_kwh_threshold) {
                var current_w = AMS_ActiveImportPower.state as Number

                // Turn on living room
                if (current_w < max_current_w && LivingHeat_Switch.state == OFF) {
                        LivingHeat_Switch.sendCommand(ON)
                        current_w += 1200 // Based on experience
                }

                // Turn on bath room
                if (current_w < max_current_w && (BathRoomFloor_Thermostatmode.state as Number) == 0) {
                        BathRoomFloor_Thermostatmode.sendCommand(1)
                        current_w += 800 // Based on experience
                }

                // Turn on hallway
                if (current_w < max_current_w && (HallwayFloor_Thermostatmode.state as Number) == 0) {
                        HallwayFloor_Thermostatmode.sendCommand(1)
                        current_w += 700 // Based on experience
                }

                // Turn on office
                if (current_w < max_current_w && OfficeHeat_Switch.state == OFF) {
                        OfficeHeat_Switch.sendCommand(ON)
                        current_w += 700 // Based on experience
                }
        }
end

Her er det en del tall jeg bare har tatt rett ut av luften. F.eks. så ønsker jeg at kWh holder seg under 4800. For å klare det har jeg gjettet på at effekten må under 4500w for å komme under 4800kWh dersom man har kommet over.

Deretter når man har kommet under 4600kWh så gjetter jeg på at man kan slå på ting helt til man er på maks 6000w.

Det er bare 4 aktører jeg har lagt inn (alle varmekildene) i min prioriterte rekkefølge.

Her ser man hvordan scriptet har jobbet seg gjennom natten med VVB og oppvaskmaskin i sving:

Her er når vi våknet i dag. Som man ser så er det ugunstig å gå inn i timen med høy effektbruk:

Middagslagingen i går gikk bedre fordi da startet jeg tilfeldigvis på halv time:

Her er mine beregninger opp mot hva nettleverandører mener. Ser greit ut med +- 2% avvik på det meste.

9 hours ago, Bjonness said:

 

Er ikke skeptisk til at wallplugen tåler 16A, er derimot det at schuko kontakten ikke er beregnet for mer enn 8A last over tid (flere timer) som er problemet  

Dette er det beste svaret så langt