SteinarH

Jeg har fortsatt to USB-RS485 og en RS485-TCP/IP som jeg ikke trenger. Dersom noen er interessert, så bare ta kontakt.

Hvor viktig det er med strømpris og besparelse, er jo helt avhengig av det forbruket man har. For de som har lavt forbruk, er det nærmest irrelevant å tenke på strømpriser i det hele tatt. For min del derimot, hvor en signifikant andel av lønnen spises opp av strømforbruket, kan det ha relativt store utslag. (Ligger mellom 40 og 50k i året). Det er dette jeg også har siktet meg mot, men det bør være en relevans i forhold til strømprisen. Jeg ønsker å ta i bruk TibberSeer. Fra min leverandør, oppgis det snittpris for måneden som fakturagrunnlag, noe som jeg mener også må være det riktige (i mitt område) gitt at informasjon fra HAN-porten fortsatt ikke er tilgjengelig. Timesfakturering bør kun tillates hvor forbruker selv kan få innsikt i momentanforbruket, og dermed kunne ha mulighet for å utføre korrigerende tiltak. På denne måten, som NVE/Grøtterud formaner; å kunne ta (mer) ansvar for sitt eget forbruk. Jeg har i dag hatt kontakt med Tibber (hyggelige folk, forresten), og de forklarer at de fakturerer alt pr .time. Dvs. aktuelt timeforbruk x aktuell timepris. For dere som har strømstyring, så er jo dette ikke noe problem. Da er det bare hvor mye energi man har lagt ned i programmering og hvilket utstyr man kan påvirke, som vil gi svaret på om man bør gjøre korrigerende tiltak. For oss som ikke har noe informasjon å hente, så blir det straks verre. Joda, vi også vet jo timprisen, men må/bør vi senke forbruket? Det vet vi ikke, siden vi ikke vet hvor mye effekt som forbrukes. I alle fall ikke før dagen etter, da vi kan lese det av hos nettleverandøren. ... som er ganske likt min leverandør, inkludert påslag og avgifter. Interessant dette her, syns jeg

Mulig dette er dekket i annen emne, men har ikke klart å finne det til nå. Jeg vurderer å gå over til Tibber som strømleverandør, og det er sikkert mange som har erfaring fra de. De har jo også Tibber Pulse som kan være interessant for å strømstyre huset mot både effekt- og pristopper. Men spørsmålet er hvor "billig" strømmen fra Tibber egentlig er. Jeg har over tid fulgt med på strømprisene hos Tibber og sammenlignet med andre strømleverandører, blant annet Gudbrandsdal Energi (GE). Tibber hevder i vilkårene å ikke skulle ha noen marginer på sitt strømsalg. Det som tilkommer innkjøpspris (spotpris) fra Nordpool, skal være de lovpålagte avgiftene (El-sertifikat og mva.), og en månedlig abonnementskostnad på kr 39,-. Ved sammenligning mellom Tibber og andre, så ligger imidlertid Tibber sin pris pr. kWh, en god del høyere. Min nærmeste sammenligning, er den strømleverandør jeg har i dag, GE. Jeg har i dag en avtale med GE på innkjøpspris (spot) + el-sertifikat og mva., og med et påslag på 6,9 øre/kWh inkl. mva. Det påløper ingen ekstra månedskostander. Total pris inkl. alt ga i oktober, november og desember 2018, priser på henholdsvis 53,41 øre/kWh, 61,67 øre/kWh og 67,40 øre/kWh. I samme måneder (oktober, november og desember 2018), oppgir Tibber sine priser til å være 53,41 øre/kWh, 61,71 øre/kWh og 67,40 øre/kWh (merkelig likt). I tillegg kommer en månedlig abonnementskostnad på kr. 39,- (3900 øre). Jeg stiller derfor spørsmålet hvor besparelsen er? Og også hvordan Tibber beregner sin 0%-margin? Eller misforstår jeg dette helt? Så kan man alltid stille seg spørsmålet hvor viktig dette er, at det er småpenger det er snakk om, og at man ikke bryr seg hva ting koster. Det er ikke det jeg ønsker å diskutere her Andre som har gjort seg tanker rundt dette?

Men det var jo enkelt da. Så da har jeg endret navn på config-filen som ble lastet ned. Dette skal være nok; ikke nødvendig å laste det ned engang til?

Ja, det ser jeg nå. Man må jo bare være takknemlig for at noen har kapasitet og kunnskap til å kunne utvikle slike plugins. Jeg har da fått installert plugin for Robonect, men ble litt usikker da jeg så filene som bli lagt til i katalogen. Antagelig bare en navnefeil, men tenkte likevel å spørre i tilfelle det er noe mer. Skal den ene filen være en Tibberseer?

Da bøyer jeg meg i støvet, og takker for alle den innsats du gjør så vi andre også kan gjøre nytte av dette. Står respekt av dette :-)

Så veldig flott!! Takk skal du ha. Og jeg skjønner nå at Moskus = Magnus? Hvor gir man donasjoner til han? For han sitter vel ikke å gjør dette for oss alle, helt gratis?

Det er gode nyheter. Prøvde meg på rabattkoden, men den var nok vel utgått :-) Finner ikke noe relevant rabattkode på nett heller, men får følge litt med. Nesten halv pris med den koden du brukte. Plugin til Magnus; vet du hvor jeg få tak i den?

Dette er veldig interessant for meg også og lurer på hvordan dine erfaringer er. Er dette plug'n and play? Og integrasjonen mot HS er greit? Regner med at kortet er greit å montere i klipperen, men noen utfordringer? Finner ingen steder i Norge å bestille. Kjøpte du direkte fra Tyskland?

Da har jeg kunne konkludere med at den oppfattelsen jeg hadde rundt strømforsyning, ikke stemte. Jeg har nå en sentralt plassert strømforsyning som gir strøm til begge CI66, og kommunikasjonen er fortsatt utmerket. Bakgrunnen for at jeg ønsker å ha en sentralt plassert strømforsyning, er at jeg ønsker å begrense enhetene ute ved ventilasjonsaggregatene. Spesielt i utleieenheten, får jeg ikke plassert CI66 skjult, og da ha en strømforsyning hengende med en ledning i tillegg, hadde ikke blitt bra. Jeg har også HomeseerPC stående i et 19" rack på teknisk rom, og forsyner da RS485-bussen fra dette skapet. Ryddig og greit :-)

Bare sånn for orden skyld, så kaller vi fra nå, kommunikasjon mellom ventilasjonanlegg og styreenheter (CI60/CI600/CI66) for primærkommunikasjon. Kabel med RS485 (Modbus) kaller vi for sekundærkommunikasjon. Ja, jeg har to ventilasjonsanlegg (og to CI66), en i hoveddelen av huset og en som skal i en utleieenhet. Begge er koplet til sekundærkommunikasjonen. Foreløpig ligger CI66 til utleie på gulvet i teknisk rom og er ikke koplet til ventilasjonsanlegg (primærkommunikasjon). Leser derfor ikke noe fra den enda. Lengden på kabel for primærkommunkasjon kan være opp til 12 meter i henhold til manualen. Det er ikke endemotstander på primærkommunikasjonen som skal settes av "oss". Du skriver at du ser noen bedring etter bytte av A og B. Hva får du opp?

Nei, det har jeg bevisst ikke satt. Dette kommer nok litt an på hvordan systemet er lagt opp. RS485 for dette systemet, er bygd etter "trunk"-system. Det vil si at du har en "kommunikasjonslinje" (hovedkabelen hvor A, B og GND går). Denne kan være lang (opptil 1,2km). Som vilkårlig avtapping på denne, tilkopler man utstyret, både slaver og master. Om ikke enhetene er plassert i enden på kabelen, skal de ikke settes med endemotstand. Hos meg har jeg master midt på kabelen. I hver ende, en CI66. Med de lenger vi her snakker om (antar også hos deg), er det ikke sikkert det er behov for endemotstander i ene enden. Både 9600 og 19200 fungerer helt fint. Prøv 19200 og hold deg til det. Dette er en variabel som jeg mener ikke vil være årsak til dine problemer, og bør bare fastsettes. Samme med slavenummer. Hvorfor 21? Hvorfor ikke bare sette 1? Dette er også en variabel som ikke påvirker problemer så lenge du er tro til den du velger. Vær sikker på strømforsyningen, så forsøker du bytte av A og B. Har du lastet ned qModMaster som Christoffer har anbefalt?

Jeg antar du har manualen til CI66? Hvis ikke, så laster du den ned fra Flexit. Jeg kan gi deg svarene på slik jeg har forstått det, men begir meg ikke inn på Raspberry-delen. Tar utgangspunkt i at du bruker en USB-RS485 konverter. Siden du har CI600, er det likegyldig hvilken posisjon switchen for "master/slave" på aggregatsiden står. Dette er den single DIPswitchen. DIPswitch for øvrige instillinger, er rekken med 10 stk. Posisjon ON, er mot ON. Angående hastighet, så vil jeg mene at det er helt unødvendig å kjøre opp i de høyeste hastighetene. 19200 kjører jeg på, og det er mer enn raskt nok. (DIP switch 7: On) Angående endemotstand, så tenker jeg det er greit å ha denne på i CI66. (DIPswitch 1: On) Du må sette slaveadresse på CI66 og antar du kun har denne å snakke med. Setter den da til slave 1. (DIPswitch 2: On) Når det gjelder lysdiodene på CI66, kan det ikke annet være feil i manualen fra Flexit. Grønn lysdiode lyser når den er koplet til og får strøm fra ventilasjonaggregatet. Rød lysdiode angir feil og skal ikke lyse (eller blinke). Orange lysdiode skal lyse når den kommuniserer. Lyser konstant hos meg (mener jeg). Angående tilkopling, så skal CI66 strømforsynes med + på terminal 4 (grønn plugg). Felles GND (Common) på terminal 3. Kommunikasjon A skal på terminal 1, kommunikasjon B skal på terminal B. Kommunikasjon GND skal på terminal 3 (sammen med GND for strømforsyning). Når det gjelder A og B, er det noen tilfeller at produsentene av utstyret ikke er tro til RS-485-standarden, eller at det er manglende standardisering for hva som er A og B. Hos meg måtte jeg bytte A og B på CI66 for å få kommunikasjon. Det er selvfølgelig viktig og også sette rette (samme) hastighet på COM-porten som for CI66, sammen med de øvrige instillingene. Disse skal være 8 databiter, 1 stoppbit og EVEN paritet. Jeg har foreløpig oppfattet (uten å ha sjekket dette nærmere enda) at ved å flytte strømforsyningen et annet sted enn rett i CI66, så fikk jeg problemer med kommuniksjonen. Dette vil jeg ikke bekrefte eller avkrefte enda, og vil komme tilbake med svaret. Jeg prøvde først med en USB-RS485 konverter som jeg kjøpte på Ebay. Andre har fått den til å fungere, mens jeg mistenkte denne først som årsak til problemer. Jeg antar at denne fungerer helt fint. Jeg valgte imidlertid å kjøpe en Moxa PCI-kort plassert inne i maskinen. Dette for å være sikker på at det ikke var kvaliteten som satte hinder. Oppklarende? Kanskje :-) EDIT: Skal for øvrig lage en steg-for-stegoppstilling også basert på mine erfaringer, samt en tegning som viser det fysiske.

Da har jeg omsider fått dette til å spille... Takket være Christoffer sine evner og kunnskaper. Må bare rette en stor takk til deg, både for at du tok deg tid og for at du fikk dette i orden. I utgangspunktet var nok feilen en blanding av flere faktorer, koblingsfeil, utstyrsfeil og til slutt en polariseringsfeil. Smekk på fingrene til meg selv for det første... Utstyrsfeilen må jeg skylde på noen andre, men uansett en faktor som må være riktig. Polariseringsfeilen er en feil basert på manglende standard i RS485-verden. Uansett er det nå oppe og går, så da er det bare å legge inn alle registeradressene..håper jeg :-) Nå ble det en god jul likevel.. EDIT: Hvis det er noen som trenger en USB-RS485konverter, så har jeg en liggende (gratis).. Antagelig i orden, men ingen garantier. Og jammen har jeg ikke bestilt en RS485-TCP/IPkonverter også.. Ikke fått den enda, men er på vei påstås det. Selges billig :-)

Hei Christoffer. Jeg spør deg igjen. Du skriver at hvert register blir en device i HS. Betyr dette at man ikke skal legge inn alle registeradressene? I så fall, hva skal legges inn i feltet for registeradresse? Jeg trodde det var denne som styrte hvilken informasjon som skulle leses av/skrives til. Jeg får stadig opp feil . Hvis jeg stresser den litt med å polle ofte, blir Function code endret. Har fått opp både 36, 73 og 100. Har også fått opp Check sum-feil. Kan det være noe galt med CI66?

Her er det sikkert åpning for tolkning. Men man kan jo tolke at det er ment 1. januar 2019 som siste frist for HAN-port, hvis det er det som menes med å ha tilgang til måleverdiene lokalt. Nå skal det sies at NVE helt sikkert har mulighet til å gi dispensasjon fra forskriften, men da skal det foreligge et vedtak om dette. Og det er det jeg mener bør fremkomme i den teksten som ligger ute på offentlige nettsider. Det er også dette Grøtterud har meddelt i samtale. Slik det fremkommer på nettsiden, virker det som dette er bare noe som er "gjort". Det er også her jeg mener en offentlig instans bør være etterrettelig i sin informasjon, og fremlegge saken i sin helhet, ikke bare endre en tekst uten nærmere forklaring. Det er ganske amatørmessig. Vi ser også at siste endring på den nettsiden er gjort 21. desember; altså i går. Visste de ikke om dette før? Jo, det gjorde de... .. og bakgrunnen for det, er at jeg hadde en samtale med Grøtterud om akkurat dette. Hun var da usikker på hvilken reaksjon de skulle gi. Uansett så var det klart for NVE at Aidon ikke hadde alt klart til 1. januar 2019, og jeg oppfordret de da om å legge ut den informasjonen på nettsidene deres. Dette innspillet skulle hun ta med seg og få effektuert. Dette er over en måned siden, og jeg har sjekket med jevne mellomrom, men ingen informasjon er lagt ut. Hadde de gjort det, så ville man kunne forholde seg til det som ble skrevet og vedtatt. Når de bare endrer en tekst, så.. Ja. jeg har vel sagt mitt..

Dette er faktisk helt utrolig, og maksimal arroganse fra NVE. Her har de faktisk gått inn og endret den opprinnelige teksten som sto skrevet, i stedet for å gi tilleggsinformasjon. Slik tekstendring skal ikke forkomme fra offentlige instanser, på ingen måte. En slik endring, er å anse som svikt i rutiner og viser mangel på forståelse av hva de driver med. Kan fint sammenlignes med å endre et opplest og vedtatt notat, til noe som passer bedre, fordi det passet de. Absolutt ikke bra.. Og hvor er sporbarheten? Setter inn den nye teksten.. Ved understreking sto det før at Han-porten skulle åpnes innen 1. januar 2019. Ser ut som jeg må ringe Guro Grøtterud igjen.. Hun virker ikke å være til å stole på..

Da (tror jeg) at jeg har fått noe kontakt med CI66. Noe usikker da jeg ikke evner å forstå hvilke informasjon i loggen som gjelder master og hva som gjelder slave. Det står "read", men er dette "read" fra slave til master, eller er det "read" fra master til slave; altså en tilbakemelding fra slaven om at den ikke klarer å lese? Hvis det er fra slaven, hva er det som genererer en slik "function code"? Jeg kan ikke se at jeg kan påvirke tilbakemeldingen. Eller er det master som spør om feil "function code", og dermed får feil svar? Kan det bekreftes at jeg har kontakt med slaven? Og hva gjør jeg feil?

Enn så lenge betyr dette nettbrett for din del.. og smarttelefon for min del. Med to parallelle systemer. Jeg er ingen utvikler, og må bare vente og håpe på at det går vår vei ?

Du har helt rett i alt du skriver, Trygve. Likevel må Nobø, som mange andre, følge med på den reelle utvikling som foregår. Om det er ene eller andre veien som er rett, vil bare fremtiden vise. Sånn har det vært i mange andre settinger før, og vil komme en rekke også i fremtiden. Det er klart at Nobø skal få skryt for å gjøre tilgjengelig sitt API, sånn at andre kan gjøre seg nytt av det. De skal ha skryt av mye annet godt arbeid også, og ris for noe dårlig, men det betyr ikke at man ikke kan gjøre enda mer. Det er også, slik jeg har forstått det, vanskelig å nyttiggjøre seg informasjonen som fremkommer i API'et, og hvem er da bedre enn Nobø selv til å gjøre seg tilpasning til andre systemer. Det vil jo også være litt unødvendig at hver mann sitter på sin tue og utvikler noe som bare nesten fungerer, selv om dette helt sikkert er spennende for mange av de som forstår hva de holder på med. Der er ikke vi alle. Som jeg skriver i min henvendelse, har jeg brukt Nobø en tid, tror det dreier seg om nærmere 25 år, og hatt mye glede og en noe frustrasjon over produktene. Hvor mange defekte komponenter jeg har byttet gjennom tiden, vet jeg ikke, men Nobø har alltid ryddet opp i problemene. De kom faktisk hjem til meg ved ett tilfelle, for å fundere over noe problematikk. Og nye enheter kommer stadig i posten ved nye henvendelser. Som de uttrykte ved siste telefonsamtale: "Ja, dette må være den lengste loggen vi har her". Uansett: Jeg hadde satt pris på om Nobø/Glen Dimplex tok seg bryet med å utvikle noe som kunne gjøre seg nytte i de åpne systemene vi har i dag. Om det er Z-wave eller noe annet, spiller ikke så stor rolle så lenge det er muligheter for integrasjon og tilstrekkelig informasjon blir overført.

Jeg var i kontakt med Nobø for en liten tid tilbake, hvor jeg uttrykte min "overraskelse" over at Nobø ikke valgte å utvikle enten egne produkter for f.eks Z-wave eller et grensesnitt for sin egen Energy Hub mot et åpent system. Tilbakemelding var at de stadig hadde dette oppe som tema, men ikke landet på noen konklusjon. Håpet kan jo være at de faktisk har et ønske om å få til en åpen "Smarthusløsning", og hvis vi kanskje er mange nok til å "presse" de, så er det enklere for de å ta en god beslutning. Her er min henvendelse: Hei. Jeg har i dag et system basert på EcoHUB, noe som i og for seg fungerer greit nok. Men bare det også. I dag, hvor det finnes så utrolig mye mer i markedet, så setter bare ens egne (produsentens) tanker, begrensingene. I mitt system har jeg mange panelovner og mange termostater. I tillegg styring av ventilasjon og utestikk til motorvarmer. Systemet har mange gode egenskaper, men også klart sine begrensinger. Jeg vil videre i livet.. .. og i den forbindelse har jeg kjøpt inn et utbyggbart smarthussystem. Det er leit å si det, men EcoHUB med sin app, setter en begrensning i sitt lukkede system. Derfor hadde jeg bestemt meg for å gå over til andre leverandører som spiller på det åpne laget, og som lett lar seg implementere i mitt (og mange andre) smarthussystem. Nå sitter jeg her da, med en nyervervet termostat i hånden, som spiller på det åpne Z-Wave-språket. Fin og flott er den, men så tenker jeg.. Dette må da Nobø/Glen Dimplex kunne gjøre vesentlig bedre. Og ikke bare det, men ha en løsning som implementerer flere funksjoner enn den som jeg her sitter med. Tenker jo også at dette må da være et kjempemarked for Nobø, da det i dag er mange som går over til smarthussystemer, men sitter (som meg) på mange panelovner og termostater fra Nobø. Og jammen ser jeg ikke at frekvensen signaler sendes på, er samme som Z-wave. Det burde jo gjøre utviklingen både gunstig og lett. Så.. Hvorfor gjør ikke Nobø noe med dette? Hvorfor vil de ikke ta sin del av dette markedet, som er like mye i andre land som her hjemme? Og hvorfor skal de tviholde på en egen app/EcoHUB som etter all sannsynlighet vil tvinge seg i døden om ikke mange år? Merkelige spørsmål kanskje, men ikke desto mer viktig. Svaret er jo enkelt.. Penger. Det koster penger å utvikle noe. Og så lenge man er i tro om at det man har er best, så tviholder man på det. Men sannheten er vel at vi kan ikke ha et system for ditt og et system for datt.. men dertil hørende like mange apper. Det er jo ikke særlig smart. Og når folk finner ut at det ikke er særlig smart, så vil jo det ikke bli mer penger til de som tviholder på sitt system. SÅ.. Derfor utfordrer jeg herved Nobø/Glen Dimplex til følgende: Utvikle termostater for panelovner (også de gamle) og gulvtermostater som sender signaler over den åpne Z-Wave-protokollen eller tilsvarende. Alternativt, og kanskje enda lettere, bedre og rimeligere (og ikke minst smart for Nobø), utvikle et grensesnitt (eller ny EcoHUB) som gjør at EcoHUB kan implementeres fullstendig i et åpent smarthussystem. Eller hvorfor ikke begge deler?

Takk for det.. Og all den andre hjelpen. Jeg tenkte at jeg ved bruk av den enheten du linket til, måtte ha to stykker; en ved hver av CI66-enhetene. Og at de da fikk hver sin IP-adresse. Men kanskje det holder med en? Dette med kabel, kan være så ymse., men trodde ikke dette var noe problem med den hastigheten og spenningene som skulle være ved RTU. Jeg får tenke litt på saken, hva som blir neste skritt. Takk for hjelpen så langt.

OK. Det kan jo være en mulighet, men tenker det er viktigere når man bruker Modbus TCP/IP som den enheten du referer til også er. Jeg bruker RTU og avstanden mellom enhetene er kun knapt 6 meter. Kanskje jeg også bør bruke TCP/IP, men har den mulighet for å kommunisere med flere slaver? Dette trenger du ikke svare på: selvfølgelig gjør den det.

Takker for den bistand du gir. Litt usikker på hva du mener med ledning mellom de. Jeg har foreløpig kun montert den ene CI66, med tanke på å få den opp å spille før jeg monterer den andre. På den har jeg aktivert Dip 1 (On). Noe mer ledning for dette, skal det vel ikke være? Mellom USB til RS485-konverter og CI66 har jeg brukt Cat5e.

Samme resultat. Prøvde begge i sted også. Er disse settingene riktig?