Christopher Stenersen

Takk for god informasjon @Vaskeklut

Jeg greier å få ut tarifftyper og priser pr. tariff.

Men får ikke helt dreisen på å få informasjon om pris og tarifftype

Har du bedre hell enn meg?

Kjører denne i function node:

msg.headers = {};
msg.headers['Ocp-Apim-Subscription-Key'] = 'xxxxxxxxxxxxxxxxxxxxxxxxxx' // Her limer du inn "Primary key"
msg.payload = {
    "range": "today",
    "meteringPointIds": ["xxxxxxxxxxxxxxxxxxxxxxx"] // Her skriver du inn målepunkt-id for din måler
}

return msg;

slik i http request node:

men får bare dette i retur:

Ser ut som jeg får ok på min request men ingen fornuftig informasjon følger i payload.

På 26.12.2020 den 19.42, Christopher Stenersen skrev:

ok.  Ja det kan kanskje virke slik. jeg fant to 16-bit registere som gir sekunder til neste filterskift som gir et fornuftig resultat. Jeg regner om dette til uker og får det frem slik som på bilde i Home assistant. 

Men jeg får fremdeles ikke noe fornuftig ut at det registeret som skal vise dato for siste. filterskift.. jeg sender en forespørsel til systemair vedrørende dette. mulig det er en bug eller noe. 

Jeg fikk svar på fremgangsmåte for å få en fornuftig timestamp fra registerne som skal vise dato for siste filterskift:

"This is not easy, but it can be done:

First, calculate the filter replacement time in seconds:
Read x: register 7002
If x < 0 then add 65536
Read y: register 7003
If y < 0 then add 65536
Multiply y with 65536 and add the result to x.

The result is the internal representation of the filter replacement time in seconds.

Substract 2212122512. This is the number of seconds since 1.1.2016 00:00. Divide by 86400 to get the number of days since 1.1.2016."

Må si jeg ble forbauset over hvor komplekst dette var uten at det var nevnt i modbus manualen.. men det ser ut til å stemme ganske bra.

37 minutter siden, 2jan skrev:

Mitt er nok bare et eldre aggregat, samme modellnr. Tror de byttet registerkoder en gang etter mitt ble innstiller (2014), men prosedyren skal ellers være lik.

ok.  Ja det kan kanskje virke slik. jeg fant to 16-bit registere som gir sekunder til neste filterskift som gir et fornuftig resultat. Jeg regner om dette til uker og får det frem slik som på bilde i Home assistant. 

Men jeg får fremdeles ikke noe fornuftig ut at det registeret som skal vise dato for siste. filterskift.. jeg sender en forespørsel til systemair vedrørende dette. mulig det er en bug eller noe. 

3 minutter siden, 2jan skrev:

 

Jeg bruker register 601, ellers er det rett frem i Home Assistant hvertfall med yaml config under. Etter skifte resetter jeg timeren på villavent-anlegget, og det gjenspeiles i HA med en gang..

 

- name: Villavent filter elapsed

   hub: villavent

   unit_of_measurement: days

   slave: 1 

   register: 601

ok. 601 er ikke et register i mitt anlegg (Systemair VTR 500) så da blir det nok ikke det samme tenker jeg. 

2 timer siden, bergen77 skrev:

(in2 + (in1*65536))/60/60/24

forklar gjerne nærmere. Jeg fikk ikke noen fornuftig resultat utifra den formelen. 

På 20.3.2020 den 23.07, 2jan skrev:

Takk for god informasjon i guiden. Endelig oppe å kjører med USR-TCP232-410s, VTR500 og Home Assistant. Ser nå at jeg kjører på omtrent 47 liter/s tilluft på medium og rundt 63 l/s når jeg kjører på High. TEK10 krav tilsier 1.2 m3/h/m2 noe som for min bolig på omtrent 225 m2 tilsvarer ca 75 l/s. Stemmer disse flowmålingene fra aggregatene? 

 

 

Jeg er veldig interessert i å se hvordan du har integrert datoen for filterbytte. Jeg har også VTR500 med IAM-modul som er satt til modbus. verdier for temperaturer og andre moduser etc får jeg til å fungere fint via node-red men akkurat timestamp verdiene sliter jeg med. 

Jeg forsøker å lese av register 7002 og 7003 men få ikke helt til å konvertere verdiene jeg får i retur til en fornuftig timestamp. Jeg gjorde et filterbytte på maskinen igår 25.12.2020 i 12-tiden og får nå disse verdier når jeg poller registerene:

7002:0x62DE

7003:0x8D3A

13 minutter siden, oleandor skrev:

 

Har kobla den til som vist under, men får ikke noe lys i noen av diodene.

Litt usikker på om ledningene er koblet riktig, men testa begge varianter.

 

 

 

Jeg tror det er det orange paret som skal benyttes hvis det er en standard patchesnor du har benyttet?

Det er pin1 og 2 som skal sende data i RJ45 utgangen på måleren.

Det er i alle fall det paret jeg benytter på min Aidon måler.

13 minutter siden, Kimzer skrev:

Bruker denne, fungerer helt fint. Får bare ikke med målerstand med den desverre. Mulig det er noe enkelt jeg ikke får med meg dog.

flows.json 27 kB · 0 downloads

ok.

Jeg er ikke så kjent med denne men ser ikke helt hensikten med å benytte så mange switch og split noder.

Dette er min komplette flow der jeg logger alle data i influxDB og i tillegg visualiserer noen av dataene i dashboard.

flow.json

41 minutter siden, Kimzer skrev:

Var noe ala det jeg hadde ordna selv, men jeg bruker fortsatt litt av node-red oppsettet fra tidligere i tråden. Alt fra split og ned til influxdb. Ønsker å beholde dette, men mistenker at kanskje splitten ødelegger for meg. Kan for lite om node-red merker jeg.

Vil du dele flow'en så kan jeg ta en titt?

Jeg benytter denne funksjonsnoden før jeg sender data inn til influxdb. 

flow.json

22 timer siden, Kimzer skrev:

Noen som gidder å dele en flow de vet fungerer med den noden? 

Denne funker hos meg. Bare skift ut "Aidon" noden med "kaifa" noden

flows.json

8 timer siden, Kimzer skrev:

Litt usikker på hvor jeg finner logs til dette, kjører via node-red som guiden viser og test_rx

Ok. Log fil kan du lage selv via node-red f.eks.

Jeg trodde du kjørte med denne noden:

https://flows.nodered.org/node/node-red-contrib-ams-decoder

Har du forsøkt om den viser riktig?

2 timer siden, Kimzer skrev:

Kaifa måler her, men ja du har såklart rett i at strømmen er lik der.

 

Noe input på målerstanden? 

Hvis du har en loggfil så send gjerne den over så kan jeg ta en kikk.

@el_frodo er du sikker på at TrønderEnergi har åpnet HAN-porten? Mulig dette må bestilles.

Hvilken type måler er det snakk om?

Får du ikke logget noe som helst data ut fra USB-serial eneheten? f.eks i node-red eller lignende?

@Howi42 ble det bra?

takk for logg @Howi42.

@Hårek Du har helt rett. Det er signed på strømmene,

V1.1.3 er publisert i npmjs med endring som ivaretar dette. Flott hvis du kan teste @Howi42 og se om det fungerer bedre nå.

Jeg finner dog ikke noe info om dette i Kamstrup og Kaifa sine spesifikasjoner. Noen som har erfaringer med produksjon av strøm på disse målerne?

Du har rett. En av de bør være null til enhver tid men husk at måleren pusher ut snittet av siste 2,5 sek så mulig det kommer noen verdier på begge hvis du ligger i grenseland det siste 2,5 sek kanskje?

Ja se der ja. Har du mulighet til å logge litt på meldingene som kommer før decoderen så er jeg interessert i å ta en titt. 

Jeg mener det er unsigned integer som kommer fra HAN interface. Litt usikker på hvordan man da skal takle negative verdier men det finner jeg sikkert ut av etter litt «googling»

På 20.6.2019 den 14.07, Howi42 skrev:

Jeg bruker nå denne noden her i node-red :

 

https://www.npmjs.com/package/node-red-contrib-ams-decoder

 

Det funker bra, med en liten anmerkning :

Måleren kjenner bare en Amperemåling, uansett om det går inn eller ut.

Leverer jeg strøm til nettet, blir den negativ.

Greitt nok, men decoderen kjenner bare positive tall, altså for eksempel 65530 istedenfor -6, etc.

Ingen stor problem, skulle bare nevne det.

@Howi42 jeg tar gjerne imot tips på hvordan jeg kan løse denne anmerkningen i noden så kan jeg rette dette på en oppdatering. 

Ny versjon 1.1.0 av HAN decoderen er nå publisert.

12 timer siden, ole88 skrev:

Takk for hjelpen. Jeg trodde at å skrive kun msg i debug noden ville "printe" alle verdier, men når jeg fylte inn "payload.act_pow_pos" i feltet, fikk jeg ut forbruk av watt. Tusen takk for hjelp!!

Til andre som kanskje kommer til å slite med det samme, disse innstillingene fungerer for meg: 

 

Til info så jobber jeg med en ny versjon av decoderene der man får opp alle data i msg.payload uavhengig av man setter inn komplett objektnavn slik som msg.payload.act_pow_pos. I tillegg kommer jeg til å implementere "msg.payload = msg.payload.toUpperCase();" slik at man kan slippe å medta denne i funsksjonsnoden. 

3 minutter siden, ole88 skrev:

Prøvde å korte ned ledningen, men ingen forandring. Har vært inne på tanken selv, om at kanskje adapteret er problemet i og med at det er ustabilt i meldingene.

Uansett, takk for hjelp

Jeg har benyttet denne et par mnd nå uten problemer:

https://www.aliexpress.com/item/USB-to-MBUS-Slave-Module-Discrete-Component-Non-TSS721-Circuit-M-BUS-Bus-Monitor/32917153031.html?spm=a2g0s.9042311.0.0.65084c4dHuLwpT

5 timer siden, ole88 skrev:

Her har du 2 filer. Lagde en logfil med timestamp,  og en med bare data fra kl 14.38 til ca 15.45 i dag. 

 

 

ams_raa_1438.log

ams2_medtid1438.log

Oi her var det veldig varierende lengder på linjene, disse burde hvert eksakt like lange hvert 10.sek  og noe lengre hver time. 

Ser ut som dataene er riktige frem til act_pow_pos men deretter er det veldig varierende struktur. 

Kanskje du kan forsøke en annen USB-Seriell overgang?

Kan du sende meg rådata fra ca en times logging så kan jeg ta en kikk. Act_pow_neg skal være strøm ut av huset ved for eksempel solcelleanlegg etc.

4 timer siden, ole88 skrev:

Hei alle.

 

Jeg skriver her på grunn av at jeg ikke kommer helt i mål. Får ut melding i Node-red som starter på 7E og slutter på 7E. Har en Kamstrup måler med en mbus til usb, samme som trådstarter. Har laget en skisse, se vedlegget. Ved bruk av Kamstrup noden får jeg ikke ut noe annet enn payload: function. Er det noen åpenbar enkel feil eller noe jeg har oversett?

 

Takk for all hjelp.

Alt 1:

huk av at debuger node skal vises i console. Da burde meldinger vises i terminal som kjører node red med noe mer informasjon

alt 2:

du må skrive komplett objektnavn i debugger. 

F.eks msg.payload.act_pow_pos. Se readme for noden for å få oversikt over alle objektene. 

Du finner readme her:

https://flows.nodered.org/node/node-red-contrib-ams-decoder

AMS decoderen for Node-Red inneholder nå en beta node fro Kaifa målere.  kult hvis noen har mulighet til å teste ut på forskjellige typer da jeg bare har testet med data fra 1-fas måler.

https://flows.nodered.org/node/node-red-contrib-ams-decoder