VikingOy

802.11ac,b,g,n er en relativt tung protokoll med mye overhead, laget for overføring av store datamengder. Package Frame size alene er større en selv komplekse meldinger som utveksles mellom IoT enheter. I de aller fleste tilfellene er IoT meldinger helt enkle av/på meldinger. Man trenger altså ikke en lastebil for å frakte matpakka si. Årsaken til at enkelte produsenter allikevel lager WiFi baserte IoT enheter, tror jeg ganske enkelt skyldes markedsførings- og salgsbeslutninger. "Alle" har hørt om WiFi, men nesten ingen har hørt om ZigBee og ZWave. Så når en nybegynner på hjemmeautomasjon skal handle sine første duppedingser, så tror jeg nok at de føler seg litt mer på trygg grunn når de velger WiFi. Det har de jo tross alt hørt om før. Vi mennesker er enkle sjeler.....

AliExpress er kun en handelsplatform, akkurat som eBay og Finn. Verken verre eller bedre enn noen andre. Jeg har kjøpt elektriske artikler via AliExpress i mange år og har selv aldri blitt "lurt", men jeg har hørt om folk som har blitt det. Men når det er sagt, - det er risikabelt å kjøre bil også (men vi gjør det allikevel) 🙂

Det er muligens en god ide, og da er rette stedet å legge inn en forespørsel under https://community.home-assistant.io/c/feature-requests Men det betinger jo at y-aksen på begge er noenlunde likt skalert. I ditt bilde ser det ut som om individuelle enheter er årstotaler (year consumption), mens energigrafen er for en dag ?

Vel, da virker det ikke hos meg. Jeg satte Antall Timer =2, idag morres, og sensoren har aldri vært "on" i dag.

Vel, da må jo det bety at om man setter Maks Pris høyt nok, så er sensoren on uansett hva timeantallet settes på?

Det er vel ikke helt presist? Skal Maks Pris variabelen ha noen mening i ligningen må det vel være slik at: Om man setter Antall Timer = 1, så vil Lav Spotpris aktiveres for den første timen hvor prisen er under Maks Pris. Altså at Maks Pris er det som bestemmer hva som er "billig" ?

Supert. Og mitt "problem" løste seg da jeg forstod hva du mente med : Så nå ser det slik ut: Jeg ser at det virker, men jeg forstår ikke helt hvordan. I formiddag måtte jeg flytte "antall timer" til 13 før sensoren gikk "on", mens nå i kveld må jeg helt opp i 21 timer før den går "on" (uansett hvilken "Max Pris" som er valgt). Hvordan skal dette forstås (utnyttes) ?

Ja, men det gjelder nok kun for forbruksenheter, fordi måleintervallene kan variere veldig mye mellom alskens ulike produkter. Jeg tror nok at consumption-verdiene er tilgjengelige i sann-tid.

Oj, hvor har du den opplysningen fra? Kanskje det er forklaringen på at jeg fikk verdien 0 når jeg prøvde? Jeg ventet ikke i det hele tatt. Bare registrerte at verdien ble 0 og gikk deretter direkte tilbake til den jeg hadde (som da forøvrig viste kroneverdien igjen - umiddelbart)

Jeg mener at min også heter sensor.nordpool Men hva med bruken av states.sensor.nordpool.attributes.xxxxx i forhold til denne "advarselen":

..... og hva får du om du bruker accumulated consumption current hour isteden da?

Om jeg setter inn accumulated consumption slik du viser, så blir prisen alltid = 0 Men om jeg setter inn accumulated consumption current hour så vises prisen korrekt:

Interessant. Men kan du forklare litt nærmere hva hver enkelt kodelinje faktisk gjør? Jeg droppet koden inn i template editoren og fikk kun som resultat: UndefinedError: 'None' has no attribute 'state' (Hvilket helt sikker bare viser at jeg ikke skjønner hva jeg gjør)

HA vil nok aldri vise korrekt totalforbruk med mindre den har målt over eksakt samme periode som måleren i skapet. HA beregner summen av det forbruket HA har sett mens HA var aktiv. Har du slått av HA i en periode, så kommer selvsagt ikke den perioden med i målingen. Hos meg stemmer verdien av sensor.last_meter_consumption eksakt med den verdien som står på måleren, mens HA viser totalen side forrige gang jeg slettet SQL databasen, minus de korte stoppene som skyldes nedetid under oppdateringer.

Som det står i linje 2 i lista de; Du kjører Core versjonen. I denne finnes det ikke noen "Supervisor" mode (og det er slik det skal være).

Du er ikke begrenset til kun små bokstaver for FriendlyName, men spesialtegn (kolon etc.) bør du aldri benytte noe sted. Du bør også etablere en organisert navnestruktur der alle FriendlyNames og EntityID's følger samme struktur for en og samme device. Du kan antagelig gjøre bulk rename ved å gå direkte inn i fila core.entity_registry og bruke global search replace vha en egnet editor. Jeg har ikke prøvd dette selv, men det bør gå. Husk uansett å ta en kopi først. Gjør du noe feil i slike filer, så bryter hele HA sammen, for godt!

Her er min forecast - den er jeg godt fornøyd med (bortsett fra at jeg foretrekker varmegrader) 🤣 type: custom:apexcharts-card graph_span: 5d span: start: hour offset: '-2d' header: show: true title: Temperature Forecast show_states: true now: show: true label: now apex_config: legend: show: false series: - entity: weather.home name: Temperature unit: °C attribute: temperature fill_raw: last extend_to_end: false group_by: func: avg duration: 12h - entity: weather.home type: line extend_to_end: false unit: °C show: in_header: false data_generator: | const res = entity.attributes.forecast.map((entry) => { return [new Date(entry.datetime).getTime(), entry.temperature]; }); return [[new Date().getTime(), parseFloat(entity.attributes.temperature)], ...res]

Feilen du får er fordi du bruker store bokstaver i ID navnet. Sent fra min SM-G996B via Tapatalk

Nei, der er nok forskjellen. Mine er ZigBee. WiFi er ikke laget for IoT og bør absolutt ikke benyttes til dette heller. Du gjør klokt i å droppe WiFi og heller gå for ZigBee og/eller Zwave produkter.

Den er - så vidt jeg kan se - den samme som de jeg har, og alle mine gir akkumulert forbruk som egen verdi rett i HomeAssistant;

Hvilke Tuya plugger er det du har?

Jeg må nok dessverre føye meg til de som er skuffet over at pluggen til @Datek Harald nok ikke er så smart allikevel. Datek pluggen er den dyreste av de jeg har, og den eneste som jeg ikke klarer få inn i forbruksoversikten som Energy i HA viser: Mulig at det er meg som ikke evner, men inntil videre er de andre pluggene jeg kjøpte - i god tro - fra Datek, bare blitt liggende uåpnet. Kanskje ligger løsningen her: https://www.home-assistant.io/more-info/statistics/ men det er litt langt over mitt hode.... Kanskje trengs det en firmware-oppdatering, men jeg har ikke funnet noen. (P.S. Yellow er bare mitt navn på Tuya's nye model, fordi den har en slik fancy gul ring og bryter) Her er det jeg får ut av Datek pluggen: Mens fra f.eks Aqara får jeg følgende:

Tja, men HA er slik at når man gjør dette, så registreres alle sensorer, items og devicer opp med nye identer og navn, og derved slutter alle etablerte automasjoner og lovelace cards å fungere, og alt må gåes igjennom og re-etableres på nytt. Dette er fremdeles en av de største manglene ved HA; At løsningen ikke har en fungerende Device/Entity database- management løsning der man kan drive manipulering, configurering, oppdateringer og mappinger på enhetsnivå, mellom Back-end og Front-end.

Ja, det var vel akkurat det jeg var redd for. Har man først valgt "nye" måten, så er man effektivt helt avskåret fra å gjøre tilpasninger. Ikke skjønner jeg hvorfor det må være slik i 2021. (Vi sendte folk til månene allerede i 1969)

Hei, jeg har installert Nordpool Integrasjonen og opprettet custom folders etc, og alt fungerer greit. Men jeg har ingen "nordpool" seksjon eller settinger verken i min configuration.yaml eller i sensors.yaml i det hele tatt. Kan jeg ganske enkelt opprette dette (manuellt) i uten at dette forstyrrer selve integrasjonen som jeg allerede har?