dagern

Må man ha wifi modulen for å få til dette eller finnes disse kontaktene på hovedkortet? Eller er det rett og slett de kontaktene som sitter på utsiden? Jeg mener de var ihvertfall d1,d2,d3, kV og co2 elns. Kan dette gjøres med feks en esp32 også?

Dette med elbillading får jeg direkte i Tibber med tesla powerup

En 3.partskontroller er en boks som er laget av et annet firma. En slik har alt av i/o og mulighet for å styre via IP feks. Problemet er at du må konfigurere alt selv og du kan kanskje bruke eksisterende sensorer og motorer. Samtidig er det ikke sikkert at du får kontrollert den via din hjemmestyring. Blir et kaninhull for å si det slik Sånn som disse feks: https://www.ebay.com/itm/114410500365?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=GdkexL_zQ0e&sssrc=4429486&ssuid=5U12BRXfQV2&var=&widget_ver=artemis&media=COPY https://www.trane.com/commercial/north-america/us/en/products-systems/building-management---automation/air-handler-controllers.html

Jeg kom så langt at jeg sniffet på det som skal være RS485 på kontakten på toppen. Problemet er at det jeg så der var bare "jibberish". Ingenting som ga noe mening. Jeg forsøkte bare med modbus og raw RS485, men det ble ikke noe bedre. De bruker selvfølgelig en helt annen protokoll på toppen av RS485 som jeg allerede har nevnt over her, og det kan bli vanskelig å finne ut av hvordan den fungerer. I tillegg så går det ganske mye trafikk der og jeg vil tro at masterkortet har en P-regulator som konstant jobber mot viftehastighet, temperatur e.l. Jeg satt der og vurderte alternativet med å kjøpe inn en 3 parts kontroller siden mitt anlegg er utenfor alle garantier og reklamasjonstider. Kom fram til at det ikke er en ide og samtidig gikk freeware-perioden på mitt RS485 analyseverktøy ut og jeg ga opp igjen.

Hvis skopet ditt kan zoome mer inn enn det du har på bildet så kan du sjekke tiden fra start til slutt på den korteste pulsen. Dette er da en bit med verdi 1. På ditt bilde kan det se ut som at en kort puls er ca 10 mikrosekunder. 1/10mikrosekunder = 100KHz. Dette blir antagelser, men den nærmeste baudraten blir da 115200.

Her er også noen nye opplysninger som jeg fant i et dokument ang oppgradering av firmware på AHUen. Problemet her er at ingen av kontaktene på toppen eller for displayet er RJ11 men RJ9/10, den er litt smalere. Jeg har bestilt en RJ10-kabel for å være sikker på at jeg får bra tilkobling. Men det som står mellom linjene her er at RS485-bussen er mulig å koble til på toppen av kabinettet.(Jeg har foreløpig ikke skrudd opp for å se hvordan hovedkortet og tilkoblingene ser ut. Så her sier altså Ensy selv at det er RS485 som brukes på disse portene. I følge mail2 i min forrige post så ser det ut for at Ensy har en intern multimaster-protokoll som går over rs485 som vanligvis brukes som "en master/multippel slave". Jeg tror ikke Ensy har funnet opp kruttet på nytt så de bruker en industristandard mutimaster-protokoll for å gjøre dette. Noen som har en ide om hva dette kan være?

Ok, mens jeg satt å fiklet med noen nodemcu så ryddet jeg opp i gamle filer på pcen og da dukket disse opp. Ser ut som dette er de registerverdiene man kan programmere mot hvis man ihvertfall har modbus-adapteret til Ensy. Sjekket da opp gammel mail og der fant jeg at jeg fikk dette tilsendt på mail jeg fra en eller annen i 2019. Her er utdrag fra maildialogen med han. Jeg prøvde å kjøpe den modbusoversetteren men fikk aldri noe svar fra ventistål på det og ga det opp og glemte det. Ser ut som av epostene ovenfor at vi må ha de modbus-adapterne, hvis vi ikke finner på noe kjempelurt. Ensy register values english.xlsx EnSy registere for Modbus RTU 06-03-2017 MD.xlsx

Unnskyld, men jeg blir litt forvirra her. Så du sier at de bruker sin egen protokoll mellom sentralenhet og skjermer, men at man kan sniffe på rs485 mellom skjerm og sentralenhet?

Det kan tenkes at du har rett. På Ensy så er det jo et hoveddisplay og dette går jo også på modbus, det er ikke nødvendig å ha wifi-modulen fra Ensy for å se hva som går der. Man kan som du sier koble seg på hoveddisplayet og antageligvis logge trafikken direkte der. Jeg vil jo tro at det er den samme modbusen på kontakt både for hoveddisplay og slavedisplay så man trenger ikke å dissekere noenting. Nå får jeg mine NodeMCU utviklingskort i posten snart og jeg har også et USB til RS485 adpater så jeg kan prøve det også.

Problemet her er at vi ikke vet hvilke registre som er brukt til hva inne i Ensy-ventilasjonen. Derfor må vi overvåke bussen mens vi legger inn forskjellige kommandoer. Når dette er gjort så har vi kanskje oversikten over de viktigste funksjonene og DA kan man sikkert bruke den enheten fra Aliexpress. Jeg går allikevel for en NodeMCU siden det er støtte for den i HA.

Beklager litt sent svar men, ja jeg kan gjøre dette, men som deg @explså strekker ikke tiden helt til. Men dette er noe jeg har veldig lyst til å få til. Dette er den siste biten av huset som ikke er under kontroll. Jeg har sendt deg en PM med tlf så kan vi kanskje ta en prat en gang til uka. Med til historien er at jeg bygde huset mitt i 2017 og ba enteprenøren om et ventilasjonsanlegg med modbus eller RS485. De sa at de brukte HERU fra Østberg og da var ikke det noe problem. Når ventilasjonen var installert så jeg at dette ikke var Heru og når jeg spurte om dette så sa de at de hadde byttet ventilasjonsleverandør fordi de fikk bedre priser hos Ensy. Men meg sa de ikke noe til før det var for sent.

Jeg har KNX og jeg har et Ensy AHU 700. Jeg kan styre forsert ventilasjon med knx feks basert på forskjellige sensorer rundt om, men det jeg ønsker meg er å kunne få alarm hvis ventilasjonen har stoppet opp. En ESP med rs485 adapter burde vel kunne se dette, bare man kunne koble seg på et sted? Det ble nevnt over at RJ-11 utgangen var rs485, men mulig jeg misforsto med at det var RJ-11 adapteret fra Ensy? Hvis det er på noen av pinnene til RJ11 at rs485-kommunikasjonen går så burde man kunne sniffe på de kommandoene som går mellom styrepanelet og kretskortet istedetfor på wifi?

Jeg har nå fått til automasjonen. Problemet var feil innrykk når man editerte i yaml. Jeg måtte endre koden til value template: "{{ state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','current_price') < state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','average')}}" Istedetfor value_template: >- {{ state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','current_price') > state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','average')}} Som forsåvidt HA endret til det nederste etter å ha blitt trigget en gang, men da med riktige innrykk @Thorbjørn Jeg prøvde med Low_price som condition og det fungerte bare hvis jeg skulle slå på, det vil si når low_price var True. Hvis jeg skulle slå av måtte jeg bruke NOT(Low_price) fordi bare en true condition kan gjøre at automasjonen går videre til Action og gjør det den skal. Du omgår denne problematikken ved å bruke If-Then-Else i Action-feltet og dropper du condition-feltet helt. Flott måte å gjøre det på, så jeg har spart på den snutten til en annen gang 🙂

Jo jeg har prøvd det også, men det blir samme resultat.

Jeg har fortsatt ikke fått det til å fungere. Men jeg har nå en fungerende value template Problemene har vist seg å være en kombo av forskjellige display name og name på attributtene til nordpool integrasjonen, og feil bruk av de forskjellige conditions. State, numerical og template Det vil si at den nå gir ut riktig true og false i Template checker. "{{ state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','current_price') < state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','average')}}" "{{ state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','current_price') > state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','average')}}" Men selv om den gjør det i template checker: Så gjør den ikke det i traces: Og den sier at en condition failed og som dere ser så er result:false, selv om den burde vært true for nå klokka 16 er prisen høyere enn gjennomsnittet og da skal varmepumpa i garasjen slå seg av eller fortsatt være av. Noen som ser hva jeg gjør feil her?

Med denne får jeg riktig nåverdi, men jeg skulle gjerne sammenlignet med gjennomsnitt. Attributtene fant jeg i HA på det kortet jeg har laget for den i lovelace. Det er en nedtrekksmeny der med alle attributtene slik jeg har forstått det

Altså, så enkelt var det, med sensor.nordpool.... så viser den true og false. Takk skal du ha. Jeg var litt rask i avtrekkeren. Viser seg det at den viser True og False invertert i forhold til hva som er riktig "{{ state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','Current price')|float(0) < state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025','average')|float(0) }}" Hvis jeg tar bort den ene halvdelen så får jeg 0 og det er det som står i parantesen etter float . Burde akkurat nå vært 138 øre

Hei, Tibber har tatt kvelden for meg, så jeg har installert nordpool. Prøver å få sammenlignet nåværende pris mot gjennomsnittlig ved å bruke templates. Har ikke hatt suksess. Har til og med sett den samme koden i denne tråden, men det fungerer ikke for meg. Denne koden gir False uansett hva man gjør value_template: "{{ state_attr('nordpool_kwh_oslo_nok_3_10_025','Current price')|float(0) > state_attr('nordpool_kwh_oslo_nok_3_10_025','average')|float(0) }}"

Aha, da begynner det å bli logisk. Jeg ser jo at strømprisen vanligvis er høy mellom 0600-0900 og 1600-1830 på hverdager og kan tenke meg å slå av f.eks varmtvannsproduksjon og kanskje sette gulvvarmen i standby i denne perioden. Kurvene er som regel veldig bratte men er det noen som har litt erfaring med når man skal slå av forbrukerne? Vil det være best på over gjennomsnitt, eller 0,6-0,9 av maks?

Jeg ser at eksemplet i Tibber-integrasjonen viser at hvis strømprisen er over 90% på samme dag så kan du få en melding. Meldingen kan selvfølgelig byttes ut til å gjøre noe annet, men det jeg ikke helt forstår er hvordan den vet at strømprisen er 90% av _dagens_ makspris? Hvis klokka er 0600 og strømprisen begynner å stige, så vet man jo ikke hvor høyt den kommer til å gå....eller? - alias: "Electricity price" trigger: platform: time_pattern # Matches every hour at 1 minutes past whole minutes: 1 condition: condition: template value_template: '{{ float(states('sensor.electricity_price_hamretunet_10')) > 0.9 * float(state_attr('sensor.electricity_price_hamretunet_10', 'max_price')) }}' action: - service: notify.pushbullet data: title: "Electricity price" target: "device/daniel_telefon_cat" message: "The electricity price is now {{ states('sensor.electricity_price_hamretunet_10') }}"

Så jeg var ikke helt presis i mitt forrige innlegg men dokumentet du viser til er en plugin-modul for kamstrup-målere. Denne plugin-modulen passer ikke i alle kamstrup-målere, slik dokumentet selv sier. Jeg har en kamstrup-måler fra Ringerikskraft og den plugin-modulen her vil ikke fungere i min måler. Det vil igjen si at jeg ikke kan kjøpe den HAN-leseren fra Elkjøp fordi jeg ikke har en HAN-port med RJ45-utgang. Det som gjelder er at hvis du har en Kamstrup-måler med HAN-plugin med RJ45 slik som den i dokumentet du henviser til så vil elkjøp-adapteren antageligvis fungere helt fint. Hvis du ikke har kamstrup-måler med denne pluginen så må du ta kontakt med din nettleverandør for å få en slik. Men hvis du er i domenet til ringerikskraft så må du vente til en gang i Q1-2020 og de vil bytte til en måler som støtter HAN-plugin med RJ45. Den Kamstrupmåleren de har i dag støtter ingen pluginmoduler med RJ45. Jeg har forsåvidt ikke hørt om noen andre nettleverandører som har denne problemstillingen. Grunnen er at Ringerikskraft var tidlig ute og kjøpte inn målerne sine i 2012 og hverken disse målerne eller programsuiten de kjøpte for innsamling av data støtter pluginen med RJ45.

Develco selger disse som unbranded så det er garantert de som har laget denne. Hvis du kjøper både HAN-leseren og gatewayen så er du i mål med en skreddersydd løsning. Hvis du bare har lyst til å kjøpe leseren, så må du ha en annen hub den kan koble seg til. Jeg prøvde først med raspberry pi og deconz, men det fungerte ikke fordi du må få noen til å lage en driver for deg, hvis du ikke klarer det selv. så kjøpte jeg Smartthings hub og for akkurat den HAN-leseren så finnes det kode her: https://community.smartthings.com/t/new-zigbee-device-handler-for-emi-han-meter/176661/6 Men før dere går og kjøper, vær sikker på at den kamstrup-måleren dere har støtter akkurat denne HAN-leseren fra Develco. Min Kamstrupmåler gjør nemlig ikke det

Ja jeg har kommet litt videre. Fant noen device handlers for zigbee energy meters på github og prøvde koden til disse. Får nå ut momentanverdi på effektuttak og totalt strømforbruk. Brukte den som heter zigbee metering plug. Det er egentlig kode for en slags universell stikkontaktplugg med innebygd energimåler og slå av og på kontakt. Den leser av de verdiene som måleren har, men kun de to. for å lese resten så må det til noe koding. Jeg har programmert litt men mest visual basic og powershell, dette programmeringsspråket til device handlers klarer jeg ikke helt å få grepet på. Samtidig så virker det som det kan ta dagesvis før det blir oppdatert på huben/appen

Jeg har skrevet i tråden her tidligere ang lesing av HAN fra Kamstrup-måleren til ringerikskraft. fikk en Develco MAIZH-061 plugin-modul fra dem etter litt om og men. Prøvde først med Home assistant og deconz, men ingen som kunne hjelpe meg med et skript eller driver for deconz APIet. Har nå prøvd Smartthings og har kommet et stykke videre. Dessverre ser det ut for at denne enheten ikke klarer å lese ut noe data Jeg får til å koble den opp mot smartthings ved å lage en device handler for den, men der stopper det. Jeg konfronterte ringerikskraft med at HAN-porten ikke er åpnet, men de påstår hardnakket at alt er i orden. Det jeg tror er feil da er at denne enheten må ha en eller annen form for autentisering mot måleren for at dataene skal kunne leses. cluster FC00 skal inneholde dataene, men der er det ingenting. Sjekk denne tekniske manualen for måleren https://www.develcoproducts.com/media/1933/kamstrup-meter-interface-meizh-061-technical-manual.pdf kontra denne: https://www.develcoproducts.com/media/3333/emizb-132-technical-manual-emi-norwegian-han.pdf Emizb-132 har ingen "security", mens Meizh-061 har det. Noen som er rå på device handlere for smartthings her? Her er den: /** * Copyright 2019 SmartThings * * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except * in compliance with the License. You may obtain a copy of the License at: * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed * on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License * for the specific language governing permissions and limitations under the License. * */ import groovy.json.JsonOutput import physicalgraph.zigbee.zcl.DataType metadata { definition (name: "Develco MEIZH-061 Energy Meter", namespace: "Testing", author: "Testing", mnmn: "Testing", vid: "Testing") { capability "Energy Meter" capability "Power Meter" capability "Refresh" capability "Health Check" capability "Sensor" capability "Configuration" fingerprint profileId: "0104", deviceId:"0053", inClusters: "0000, 0003, 0004, 0009, 000A, 0702, 0704, FC00", outClusters: "0019", manufacturer: "Develco Products A/S", model: "MEIZH-061", deviceJoinName: "" } // tile definitions tiles(scale: 2) { multiAttributeTile(name:"power", type: "generic", width: 6, height: 4){ tileAttribute("device.power", key: "PRIMARY_CONTROL") { attributeState("default", label:'${currentValue} W') } tileAttribute("device.energy", key: "SECONDARY_CONTROL") { attributeState("default", label:'${currentValue} kWh') } } standardTile("RMSVoltagePhA", "device.RMSVoltagePhA", inactiveLabel: false, decoration: "flat", width: 3, height: 1) { state "default", label:'Voltage A: ${currentValue} V' } standardTile("RMSCurrentPhA", "device.RMSCurrentPhA", inactiveLabel: false, decoration: "flat", width: 3, height: 1) { state "default", label:'Current A: ${currentValue} A' } standardTile("RMSVoltagePhB", "device.RMSVoltagePhB", inactiveLabel: false, decoration: "flat", width: 3, height: 1) { state "default", label:'Voltage B: ${currentValue} V' } standardTile("RMSCurrentPhB", "device.RMSCurrentPhB", inactiveLabel: false, decoration: "flat", width: 3, height: 1) { state "default", label:'Current B: ${currentValue} A' } standardTile("RMSVoltagePhC", "device.RMSVoltagePhC", inactiveLabel: false, decoration: "flat", width: 3, height: 1) { state "default", label:'Voltage ? ${currentValue} V' } standardTile("RMSCurrentPhC", "device.RMSCurrentPhC", inactiveLabel: false, decoration: "flat", width: 3, height: 1) { state "default", label:'Current ? ${currentValue} A' } /*standardTile("reset", "device.energy", inactiveLabel: false, decoration: "flat", width: 2, height: 2) { state "default", label:'reset kWh', action:"reset" }*/ standardTile("refresh", "device.power", inactiveLabel: false, decoration: "flat", width: 2, height: 2) { state "default", label:'', action:"refresh.refresh", icon:"st.secondary.refresh" } main (["power", "energy"]) details(["power", "energy","RMSVoltagePhA","RMSCurrentPhA","RMSVoltagePhB", "RMSCurrentPhB","RMSVoltagePhC", "RMSCurrentPhC", "refresh"]) } } def parse(String description) { log.debug "description is $description" def descMap = zigbee.parseDescriptionAsMap(description) if(descMap) { List result = [] List attrData = [[cluster: descMap.cluster ,attrId: descMap.attrId, value: descMap.value]] descMap.additionalAttrs.each { attrData << [cluster: descMap.cluster, attrId: it.attrId, value: it.value] } attrData.each { def map = [:] log.debug "ClusterId: ${it.cluster} AttributeId: ${it.attrId} Value: ${it.value}" if (it.cluster == "0b04" && it.attrId == "0300") { log.debug "Power Value: ${zigbee.convertHexToInt(it.value)/1000}" map.name = "power" map.value = zigbee.convertHexToInt(it.value)/1000 map.unit = "W" } if (it.cluster == "0702" && it.attrId == "0000") { log.debug "Energy Value: ${zigbee.convertHexToInt(it.value)}" map.name = "energy" map.value = zigbee.convertHexToInt(it.value)/1000 map.unit = "kWh" } if (it.cluster == "FC00" && it.attrId == "041E") { log.debug "RMSVoltagePhA Value: ${zigbee.convertHexToInt(it.value)}" map.name = "RMSVoltagePhA" map.value = zigbee.convertHexToInt(it.value) map.unit = "V" } if (it.cluster == "FC00" && it.attrId == "0434") { log.debug "RMSCurrentPhA Value: ${zigbee.convertHexToInt(it.value)}" map.name = "RMSCurrentPhA" map.value = zigbee.convertHexToInt(it.value) map.unit = "A" } if (it.cluster == "FC00" && it.attrId == "041F") { log.debug "RMSVoltagePhB Value: ${zigbee.convertHexToInt(it.value)}" map.name = "RMSVoltagePhB" map.value = zigbee.convertHexToInt(it.value) map.unit = "V" } if (it.cluster == "FC00" && it.attrId == "0435") { log.debug "RMSCurrentPhB Value: ${zigbee.convertHexToInt(it.value)}" map.name = "RMSCurrentPhB" map.value = zigbee.convertHexToInt(it.value) map.unit = "A" } if (it.cluster == "FC00" && it.attrId == "0420") { log.debug "RMSVoltagePhC Value: ${zigbee.convertHexToInt(it.value)}" map.name = "RMSVoltagePhC" map.value = zigbee.convertHexToInt(it.value) map.unit = "V" } if (it.cluster == "FC00" && it.attrId == "0436") { log.debug "RMSCurrentPhC Value: ${zigbee.convertHexToInt(it.value)}" map.name = "RMSCurrentPhC" map.value = zigbee.convertHexToInt(it.value) map.unit = "A" } if (map) { result << createEvent(map) } log.debug "Parse returned $map" } return result } } /** * PING is used by Device-Watch in attempt to reach the Device * */ def ping() { return refresh() } def refresh() { log.debug "refresh " zigbee.electricMeasurementPowerRefresh() + zigbee.simpleMeteringPowerRefresh() } def configure() { // this device will send instantaneous demand and current summation delivered every 1 minute sendEvent(name: "checkInterval", value: 2 * 60 + 10 * 60, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID]) log.debug "Configuring Reporting" return refresh() + zigbee.simpleMeteringPowerConfig() + zigbee.electricMeasurementPowerConfig() }

Får prøve det da. Men tror du at home assistant hadde fått til dette her hvis raspberr hadde fungert på hass.io? Eller måtte jeg først hatt støtte for det og så noe annet?