MrE

Produktet krever elektriker. DSB krever elektriker. I norge har vi register over godkjente elektrikervirksomheter. TS er ikke elektriker, og har gjort dette selv. Når produkter feiler, og TS ikke kan fremvise at produktet er monter på lovlig vis, frafaller garanti og reklamasjon. Så enkelt er det. Det er lov å prøve å få det på reklamasjon, men hvis butikken godkjenner reklamasjonen er det kun på godvilje. Om butikken er elektroimportøren, så opplyser de til og med nederst på sin side hva som er lovlig å gjøre selv og ikke (henviser til DSB). (L-A hadde et lengre svar på hva EI opplyser om.)

Svært mange produkter beskriver i monteringsanvisningen at produktet skal installeres av godkjent elektriker. Hvis du ikke er det og har gjort det selv, så har du i praksis brutt monteringsanvisningen, og krav og garanti og reklamasjon frafaller. De har nok jussen på sin side. Hvordan vet butikken at du som privatperson har nok kompetanse til å koble produktet riktig?

Hvis den ikke er montert iht. monteringsanvisning / bruksanvisning, får du ikke dekket dette på garanti eller reklamasjon.

Tipper det er Reolink Doorbell WiFi. Den kan kobles til eksisterende ringeklokke opplegg (i noen tilfeller). Ellers så har man PoE-versjon.

Hvilke fysiske enheter har du? Jeg tipper det er noe med entiteten du bruker på switch.

Du må sette KAM foran nummeret du ser på måleren. På måleren står det S/N: xxxxxxxx / zz / yy. På Kamstrup sin side trykker du på Register oppe til høyre. I det første feltet taster du KAMxxxxxxxx, og i neste felt taster du zz. yy er produksjonsåret. edit: Jeg har Multical 403, ikke 302 som jeg sa tidligere. edit2: For bildeeksempelet under blir da serienummeret 79800141 og device code JH. På Kamstrup sin side blir serienummeret KAM79800141.

Veldig bra. Ser det finnes flere guider på https://www.kamstrup.com/en-en/my-kamstrup-guides

Multical 302 er plombert ettersom det er leverandør av fjernvarme sin måler. Den kan leveres med trådbunnen m-bus, eller wireless m-bus. På wireless m-bus har den 2 moduser den kan settes i, enten modus for drive-by-avlesning eller for lokal avlesning. Jeg antar min står i lokal avlesning, så jeg skal først prøve og se om jeg får hentet ut nøkkel fra kamstrup istedenfor leverandør av fjernvarmen. Vi må lese av måleren manuelt hver måned, derfor håper jeg det ikke er drive-by modus som er aktivert. Om det er drive-by så er nok håpet ute om få lest av dette selv, da det vil nok ikke gis ut nøkkel som medfører at jeg kan lese av naboen sitt forbruk.

Hva er egentlig forskjellen, med tanke på personvern, på strømmåleren, vannmåleren, og energimåleren (fjernvarme)? Har bestilt en W-Mbus USB stick, så går jeg igang med samme opplegget når jeg får den. I mitt tilfelle er det fjernvarmen jeg ønsker å lese av (Lyse Neo). Måleren er en Multical 302.

Zigbee2MQTT støtter switch_type

Aqara T1 fungerer med impulsbryter.

Kodetastaturetver på innsiden, ellers så hadde det vært et topp produkt. secuyou har som kommuniserer over bluetooth https://secuyou.se/

Jeg sier det igjen, det er samme operasjonen som utføres i HA som i NodeRed. Se på flowen du selv la ut. Hvert 10 minutt sendes det HTTP request, som oppdaterer de stasjonene du har lagt inn. I HA gjøres det samme i restful. Hver 10 min oppdateres de stasjonene man legger inn. Er ikke NodeRed enda mer "under panseret" enn native HA? NodeRed er sikkert flott det, men mitt poeng er at man virkelig ikke må ha NodeRed, og får til det samme i HA, uten at det er noe stor forskjell. Og jeg mener at det er bedre å kjøre native HA enn å benytte NodeRed som mater HA med data. Jeg klarer ikke se hvordan det er bedre å gjøre det i NodeRed?

Du gjør jo det samme? Du lager en sensor i nodered for hver stasjon. Istedenfor å bruke nodered lages det en sensor for hver stasjon i HA. edit: For å presisere så legger du inn 1 og 1 stasjon i nodered. Så lager du en sensor som sorterer etter laveste pris, som sender dette til HA. I HA viser du samme sensor på et kort. Jeg kan ikke se at det er noe enklere i nodered? For meg virker det enklere i HA, i tillegg til at du slipper add-on, blande inn nodered, beholder alt native osv. Her er samme kortet som du bruker, uten nodered:

Jeg har redigert mitt innlegg noe, og har inkludert JSON filen. @hjemmedude Nei du skal ikke få mange flere av samme sensor plutselig. REST sensor oppretter 1 sensor for 1 stasjon. Template sensor henter dieselpris fra samme stasjon. Har du utklipp av hvordan det ser ut hos deg? Vedrørende not authorized har dette skjedd fra tid til annen, uten at jeg vet hvorfor. Jeg bruker Postman med api key, da kommer json fila med en gang 🙂

Da antar jeg du må endre X-api-key. Du finner ny ved hjelp av Postman API explorer 2CD114509703F6E0A976C32FCB79C4F62966EEC6 Edit: X-API-KEY fungerer hos meg, så da tenker jeg den skal fungere hos deg også. Edit2: hvor får du den feilmeldingen?

Hei, Her er slik jeg har gjort det, uten bruk av Node-Red etc. Jeg bruker Auto-Entities kortet i HA, og sorterer på pris lavest - høyest. Ett kort for bensin, og ett for diesel. Jeg hadde en del planer for hvordan jeg skulle ha dette, blant annet med bilde som ikon, kart som viste de forskjellige stasjonene, legge inn når den ble sist oppdatert etc.. Tiden strekker dessverre ikke til, så det har blitt lagt på is inntil videre. Anyways, her er det jeg har så langt: I configuration.yaml har jeg lagt inn restsensor som henter stasjoner fra json filen som ble linket til lenger oppe. Tipset for å få den lett leselig er å legge den inn i en JSON formatter, da blir filen mye renere å lese. Edit: Noen ganger når man går inn på JSON filen uten å bruka api-key, får man authorization denied. Da må man bruke Postman API explorer og X-API-KEY for å hente JSON filen. JSON filen ligger vedlagt. Jeg bruker Notepad++ og brukte søkefunksjon for å finne stasjonene jeg vil ha inn i oppsettet. For å legge til stasjonen du ønsker gjør du følgende: 1. Finner stasjonen i JSON filen 2. Kopierer DiscountInfo navnet som du finner i JSON filen 3. endrer 3 ting under rest-sensor i configuration.yaml - Name - Valgfritt navn, men legg merke til at navnet har bensin i seg. Det er fordi value_template henter bensin-prisen - json attributes path discount info må endres til stasjonsnavnet slik den står i JSON filen. - og value_template må endres til samme navnet som du valgte på øverste linje. Under template sensor må du endre navn på sensor (valgfritt), men state_attr må henvise til sensor som du har laget under rest-sensor. Shell bryne diesel henter altså dieselprisen fra sensoren som heter shell bryne bensin... Nedenfor er YAMLkoden for REST og for template sensor. Begge skal i configuration.yaml (ihvertfall hos meg 🙂🙂 ) I RESTsensoren er det name: som sier hva sensoren skal hette, og value_template er verdien til sensoren som blir opprettet. Sensorene som ligger i restsensoren blir da bensinprisen (på grunn av [0] i value template). Hvis det ønskes diesel her så må du sjekke hva som står i JSON fila. [0] er øverste avsnitt, [1] blir neste osv.. Se utklipp nedenfor, kanskje det ga mer mening. configuration.yaml rest: - scan_interval: 600 method: GET headers: Content-Type: application/json X-API-KEY: 2CD114509703F6E0A976C32FCB79C4F62966EEC6 User-Agent: Drivstoffappen/1.3.8 (com.raskebiler.drivstoff.appen; build:130; iOS 15.2.1) Alamofire/5.4.4 Accept-Language: nb-NO;q=1.0, en-GB;q=0.9 Accept-Encoding: br;q=1.0, gzip;q=0.9, deflate;q=0.8 Connection: keep-alive resource: https://api.drivstoffappen.no/api/stations?stationType=0&countryCode=NO sensor: - name: "Shell Bryne Bensin" json_attributes_path: "$..[?(@.discountInfo=='Shell Bryne')]" value_template: "{{ state_attr('sensor.shell_bryne_bensin', 'stationDetails')[0].price }}" force_update: true json_attributes: - "id" - "location" - "latitude" - "longitude" - "pictureUrl" - "discountInfo" - "lastUpdated" - "stationDetails" - name: "Circle K Lagårdsveien Bensin" json_attributes_path: "$..[?(@.discountInfo=='Circle K Lagårdsveien')]" force_update: true value_template: "{{ state_attr('sensor.circle_k_lagardsveien_bensin', 'stationDetails')[0].price }}" json_attributes: - "id" - "location" - "latitude" - "longitude" - "pictureUrl" - "discountInfo" - "lastUpdated" - "stationDetails" - name: "Uno-X Bryne Bensin" json_attributes_path: "$..[?(@.discountInfo=='Uno-X Bryne')]" force_update: true value_template: "{{ state_attr('sensor.uno_x_bryne_bensin', 'stationDetails')[0].price }}" json_attributes: - "id" - "location" - "latitude" - "longitude" - "pictureUrl" - "discountInfo" - "lastUpdated" - "stationDetails" - name: "Esso Bryne Bensin" json_attributes_path: "$..[?(@.discountInfo=='Esso Bryne')]" force_update: true value_template: "{{ state_attr('sensor.esso_bryne_bensin', 'stationDetails')[0].price }}" json_attributes: - "id" - "location" - "latitude" - "longitude" - "pictureUrl" - "discountInfo" - "lastUpdated" - "stationDetails" - name: "Circle K Klepp Bensin" json_attributes_path: "$..[?(@.discountInfo=='Circle K Klepp')]" force_update: true value_template: "{{ state_attr('sensor.circle_k_klepp_bensin', 'stationDetails')[0].price }}" json_attributes: - "id" - "location" - "latitude" - "longitude" - "pictureUrl" - "discountInfo" - "lastUpdated" - "stationDetails" For å lage diesel sensorene er det hentet samme sensor, men brukt neste avsnitt i JSON fila ( [1] ). Noen ganger har stasjonene avgiftsfri diesel eller 98 bensin på 2. avsnitt, så da må det brukes [2] eller [3] alt etter hvordan JSON ser ut på aktuell stasjon. Merk at sensorene henter attribut fra sensor.shell_bryne_bensin. Det er fordi i restsensoren henter vi bensinprisen, og hele stasjonen som vi henter inn i HA blir da kalt for shell bryne bensin. For å hente dieselpris bruker vi altså attribute under bensinsensoren, hvis det ga mening. Her er for å hente diesel på de samme stasjonene: template: - sensor: ########## DIESELPRISER ############################ - name: Shell Bryne Diesel state: "{{ state_attr('sensor.shell_bryne_bensin', 'stationDetails')[1].price }}" device_class: monetary unit_of_measurement: NOK - name: Circle K Lagårdsveien Diesel state: "{{ state_attr('sensor.circle_k_lagardsveien_bensin', 'stationDetails')[1].price }}" device_class: monetary unit_of_measurement: NOK - name: Uno-X Bryne Diesel state: "{{ state_attr('sensor.uno_x_bryne_bensin', 'stationDetails')[1].price }}" device_class: monetary unit_of_measurement: NOK - name: Esso Bryne Diesel state: "{{ state_attr('sensor.esso_bryne_bensin', 'stationDetails')[1].price }}" device_class: monetary unit_of_measurement: NOK - name: Circle K Klepp Diesel state: "{{ state_attr('sensor.circle_k_klepp_bensin', 'stationDetails')[1].price }}" device_class: monetary unit_of_measurement: NOK Blir altså mye manuelt arbeid, men er forholdsvis enkelt. Knotet en del med dette før jeg fikk det til. Håper det fungerer for dere også 🙂 Slik ser kortet ut i HA: Hvor konfigurasjonen til auto-entities kortet for diesel ser slik ut: type: custom:auto-entities card: type: entities title: Diesel - sortert på pris filter: include: - name: '*Diesel*' exclude: [] sort: method: state numeric: true DS appen.json

Det er enkelt å få til uten node-red. Jeg har ferdig konfigurasjon til dette, men utilgjengelig grunnet systemkrasj. Du henter priser via REST, lager template sensor for hvert drivstoff pr stasjon.

Du kan kjøpe en dum bevegelsesdetektor, og la den styre ett rele. Releet kobler du til en smart implant, som igjen styrer lyset..

Har du prøvd Windy? Jeg bruker den til vindstyrke, men de har for skyer også. https://www.windy.com/en/-Clouds-clouds

n= (Avtrekkstemperatur - avkasttemperatur) / (Avtrekkstemperatur - Inntak). Formelen stemmer så lenge utetemperatur ligger under avtrekkets duggpunktstemperatur. Avtrekkstemperatur er temperatur som går inn i gjenvinner. Å måle denne kun på badet vil ikke være representativt for avtrekkstemperaturen i anlegget, men dette er avhengig av hvor mange avtrekksventiler du har. Har du 18 grader i huset, vil avtrekkstemperatur være 18 grader. Er avtrekkstemperatur i huset 18, men badet er 25, vil du måle avtrekkstemperatur på 25 når du måler kun på badet, og da vil ikke virkningsgraden være riktig. Virkningsgraden er jo hvor mye gjenvinneren klarer å gjenvinne (forskjell på inn og ut av gjenvinner), og ved å kjøre kunstig høy temperatur på avkast vil virkningsgraden du regner ut være lavere enn virkelig. 🙂

og ikke minst en behagelig pris, sett opp mot andre produkter med samme funksjon. Men maks 420 mA på 5V kan vel ikke drive ipad eller lignende..

Interessant! Det sikker jo ikke elektronikk i fiberadapter trodde jeg. Hvorfor må man ha fiberadapteret?

Om det er telenor GPON må du bruke telenor sitt eget utstyr og sette dette i bridge modus såvidt jeg vet.

Denne var ikke lett å finne! Burde kanskje vært en poll som var synlig når man åpnet forum-siden. 🙂