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?