Lesing av AMS data (AMS/HAN -> IoT)

[Tubez]

Hei igjen

 

Jeg har sett over de dataene du har mottatt, og jeg kom da fram til følgende (se under).

 

Det jeg ser er at E7 og E6E700 i rad 1 er identisk hele veien og med Kamstrup sitt eksempel. 0F er også lik for alle, inklusiv Kamstrup. Det jeg ikke er helt enig i er Dato og tid. For denne strengen er ikke lik for Kamstrup. Videre så har dato og tid en egen kode i BB12 (tabell 2 side 34). Denne avsluttes også med FF800001 på Kamstrup sitt eksempel. 

[2017-09-12 23.18.43.731 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C0217122AFF800000 Kommentar: Dato og tid (2017-09-12, 02 = tirsdag, kl 23:18:42). FF800000 ukjent.

0201 Kommentar: Struktur med 1 objekt. http://dlms.com/documents/Excerpt_BB12.pdf Tabell 2 side 34.

0600000528 Verdi: “1320” W

B80C 7E


[2017-09-12 23.18.45.739 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C0217122CFF800000 Kommentar: Dato og tid

0201 Kommentar: Struktur med 1 objekt.

0600000524 Verdi: “1316” W

19C1 7E


[2017-09-12 23.18.47.732 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C0217122EFF800000 Kommentar: Dato og tid

0201 Kommentar: Struktur med 1 objekt.

0600000535 Verdi: “1333” W

AAC2 7E


[2017-09-12 23.18.49.724 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C02171230FF800000 Kommentar: Dato og tid

0201 Kommentar: Struktur med 1 objekt.

0600000527 Verdi: “1319” W

C0E9 7E


 

[2017-09-12 23.18.51.733 - Received 123 (0x7B) bytes]
7E A079 01 02 01 10 8093 E6E700

0F 40000000

090C 07E1090C02171232FF800000 Kommentar: Dato og tid

020D Kommentar: Struktur med 13 objekter.

Objekt 1: 0907 4B464D5F303031 Output: “KFM_001”, OBIS liste

Objekt 2: 0910 36393730363331343031373533393835 Output: “6970631401753985”, Måler-ID.

Objekt 3: 0908 4D41333034483345 Output: “MA304H3E”, Type måler.

Objekt 4: 0600000524 Verdi: “1316” Active power [W] (+)

Objekt 5: 0600000000 Verdi: “0” Active power [W] (-)

Objekt 6: 0600000000 Verdi: “0” Reactive power [VAr] (+)

Objekt 7: 0600000081 Verdi: “129” Reactive power [VAr] (-)

Objekt 8: 06000006D2 Verdi: “1746” Strøm fase 1 [mA]

Objekt 9: 06000011D5 Verdi: “4565” Strøm fase 2 [mA]

Objekt 10: 0600001268 Verdi: “4712” Strøm fase 3 [mA]

Objekt 11: 0600000960 Verdi: “2400” Spenning U1-N [V]  (xxx.x V)

Objekt 12: 0600000000 Verdi: “0” Spenning U2-N [V] (xxx.x V)

Objekt 13: 0600000962 Verdi: “2402” Spenning U3-N [V] (xxx.x V)
4BDB 7E

[Tubez]

Kan 0F 40000000 være "SND_NKE 0100 0000 40 Short Frame Initialization of Slave"? http://www.m-bus.com/files/MBDOC48.PDF side 24.

 

Jeg ser også at de 12 første bytes i serien er definert som header (som du også sa). Så da tenker jeg at 0F 40000000 sier noe om formatet (i dette tilfelle "Short Frame")?

 

Edit: jeg leste nylig på m-bus.com at "0F" kan bety: "Start of manufacturer specific data structures to end of user data", om det har noen betydning. 

Endret 30. september 2017 av Tubez

[roarfred]

On ‎30‎.‎09‎.‎2017 at 10:17, Tubez said:

 

Tenker du på 0A i rad 5 og 6? Det er måler ID og type måler. 

 

Det som jeg lurer på i A0 i rad 1 kan være en tekststreng med E2 bytes? Edit: nei,  tviler på at der skal være 226 bytes i den strengen xD... 

 

Det jeg ikke klarer å finne ut av er hva som foregår på rad 2... 

Sorry, ser nå at jeg må ha ment rad to jeg også...

 

A0 i rad 1 er egentlig delt i to "halve" bytes. A angir en frame type eller noe slik, mens 0 settes sammen med E2 (som MSB) for å angi størrelsen på rammen. (muliggjør da rammestørrelser på opp til 4096 bytes i stedet for 256)

 

Forresten, lurer på om ikke det er en timestamp i rad 2:

0C = 12 bytes

07 D0 = 2000 (årstall)

01 = 1 (januar)

01 = 1 (1. januar)

06 = ??? (skilletegn)

16 = 22 (timer)

21 = 33 (minutter)

00 = 0 (sekunder)

FF800001 = usikker på denne, mener FF anga at hundredeler ikke er oppgitt, og at det lå noe om sommertid etc. i dette

[Tubez]

Ja jeg ser den, men jeg får det fortsatt ikke til å stemme. Hvis du ser på Kamstrup så starter denne med 0C07. Den tar heller ikke med FF800000 i samme streng.

 

Det som jeg også har sett, er at i de tilfellene en sekvens starter med 09 (An orderes sequence of octets (8 bit bytes)), så tar han for seg byte for byte. Det vil si at 07D0 skal sees på som 07 = 7 og D0 = 320... Eller hvis man ser hele samlet så blir dette "07E1090C02171232FF800000" = "1760411030010270444000000000000". Dette ser du stemmer med følgende:

0907 4B464D5F303031 = KFM_001

0908 4D41333034483345 = MA304H3E

[roarfred]

26 minutes ago, Tubez said:

Ja jeg ser den, men jeg får det fortsatt ikke til å stemme. Hvis du ser på Kamstrup så starter denne med 0C07. Den tar heller ikke med FF800000 i samme streng.

 

Det som jeg også har sett, er at i de tilfellene en sekvens starter med 09 (An orderes sequence of octets (8 bit bytes)), så tar han for seg byte for byte. Det vil si at 07D0 skal sees på som 07 = 7 og D0 = 320... Eller hvis man ser hele samlet så blir dette "07E1090C02171232FF800000" = "1760411030010270444000000000000". Dette ser du stemmer med følgende:

0907 4B464D5F303031 = KFM_001

0908 4D41333034483345 = MA304H3E

Jeg tror det er slik at den første byte forklarer dataformatet. Dvs 07=dato, 09=string, 06=int (32 bit)

 

Hver av disse har så sin egen definisjon av de påfølgende bytes. Eks trenger ikke 06 si hvor mange bytes som følger. 07 er nok et definert datoformat der det settes av 2 bytes (16 bit) til årstall. 07 D0 må dermed sees i sammenheng og gir 2000. Se mine data, så stemmer det godt

[roarfred]

Da har jeg fått komplette filer for schematics, part list og PCB, inklusive gerber filer fra vår venn i India. Det hele er lagt ut her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical

Jeg har også laget et lite sammendrag i readme.md her (den som kommer opp når en åpner linken)

 

Edit: fikset url

 

Endret 2. oktober 2017 av roarfred

[roarfred]

On 9/30/2017 at 14:42, Tubez said:

Hei igjen

 

Jeg har sett over de dataene du har mottatt, og jeg kom da fram til følgende (se under).

 

Det jeg ser er at E7 og E6E700 i rad 1 er identisk hele veien og med Kamstrup sitt eksempel. 0F er også lik for alle, inklusiv Kamstrup. Det jeg ikke er helt enig i er Dato og tid. For denne strengen er ikke lik for Kamstrup. Videre så har dato og tid en egen kode i BB12 (tabell 2 side 34). Denne avsluttes også med FF800001 på Kamstrup sitt eksempel. 

 

[2017-09-12 23.18.43.731 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C0217122AFF800000 Kommentar: Dato og tid (2017-09-12, 02 = tirsdag, kl 23:18:42). FF800000 ukjent.

0201 Kommentar: Struktur med 1 objekt. http://dlms.com/documents/Excerpt_BB12.pdf Tabell 2 side 34.

0600000528 Verdi: “1320” W

B80C 7E


[2017-09-12 23.18.45.739 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C0217122CFF800000 Kommentar: Dato og tid

0201 Kommentar: Struktur med 1 objekt.

0600000524 Verdi: “1316” W

19C1 7E


[2017-09-12 23.18.47.732 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C0217122EFF800000 Kommentar: Dato og tid

0201 Kommentar: Struktur med 1 objekt.

0600000535 Verdi: “1333” W

AAC2 7E


[2017-09-12 23.18.49.724 - Received 41 (0x29) bytes]
7E A027 01 02 01 10 5A87 E6E700

0F 40000000

090C 07E1090C02171230FF800000 Kommentar: Dato og tid

0201 Kommentar: Struktur med 1 objekt.

0600000527 Verdi: “1319” W

C0E9 7E


 

 

[2017-09-12 23.18.51.733 - Received 123 (0x7B) bytes]
7E A079 01 02 01 10 8093 E6E700

0F 40000000

090C 07E1090C02171232FF800000 Kommentar: Dato og tid

020D Kommentar: Struktur med 13 objekter.

Objekt 1: 0907 4B464D5F303031 Output: “KFM_001”, OBIS liste

Objekt 2: 0910 36393730363331343031373533393835 Output: “6970631401753985”, Måler-ID.

Objekt 3: 0908 4D41333034483345 Output: “MA304H3E”, Type måler.

Objekt 4: 0600000524 Verdi: “1316” Active power [W] (+)

Objekt 5: 0600000000 Verdi: “0” Active power [W] (-)

Objekt 6: 0600000000 Verdi: “0” Reactive power [VAr] (+)

Objekt 7: 0600000081 Verdi: “129” Reactive power [VAr] (-)

Objekt 8: 06000006D2 Verdi: “1746” Strøm fase 1 [mA]

Objekt 9: 06000011D5 Verdi: “4565” Strøm fase 2 [mA]

Objekt 10: 0600001268 Verdi: “4712” Strøm fase 3 [mA]

Objekt 11: 0600000960 Verdi: “2400” Spenning U1-N [V]  (xxx.x V)

Objekt 12: 0600000000 Verdi: “0” Spenning U2-N [V] (xxx.x V)

Objekt 13: 0600000962 Verdi: “2402” Spenning U3-N [V] (xxx.x V)
4BDB 7E

 

Imponerende innsats fra deg her! Kunne du tenke deg å lage litt oversiktlig dokumentasjon på github-prosjektet? Ser for meg en egen folder med diverse markdown-filer, for å dokumentere fra elektrisk nivå 27/15V ned til innholdet i de enkelte verdi-pakkene...

[Tubez]

3 timer siden, roarfred skrev:

Jeg tror det er slik at den første byte forklarer dataformatet. Dvs 07=dato, 09=string, 06=int (32 bit)

 

Hver av disse har så sin egen definisjon av de påfølgende bytes. Eks trenger ikke 06 si hvor mange bytes som følger. 07 er nok et definert datoformat der det settes av 2 bytes (16 bit) til årstall. 07 D0 må dermed sees i sammenheng og gir 2000. Se mine data, så stemmer det godt

 

Ja, jeg er enig i at første byten forteller noe om dataformatet, og så ser ut som at byte 2 skal fortelle om antall bytes dataen består av eller ikke. Dette ser man i for eksempel når man får avleste verdier, så står denne til 0600000524. Så kanskje skal alle avleste verdier være oppført som 0600 000524? I dette tilfellet er allerede 06 definert til å Unsigned 32, og man trenger da ikke å gi noe ytterlige informasjon om antall bytes, derfor er byte 2 satt til "00"? Eller så har de bare droppet å gi ytterlige informasjon om denne og denne skal være oppført som 06 00000524?

 

Etter å hatt lest litt så ser jeg at du har nok rett i det med datoen, for i henhold til Bluebook: 

"OCTET STRING (SIZE(12))

{

year highbyte,

year lowbyte,

month,

day of month,

day of week,

hour,

minute,

second,

hundredths of second,

deviation highbyte,

deviation lowbyte,

clock status

}

The elements of date and time are encoded as defined above. Some may be set to “not specified” as defined above. In addition: deviation: interpreted as long"

[Tubez]

2 timer siden, roarfred skrev:

 

Imponerende innsats fra deg her! Kunne du tenke deg å lage litt oversiktlig dokumentasjon på github-prosjektet? Ser for meg en egen folder med diverse markdown-filer, for å dokumentere fra elektrisk nivå 27/15V ned til innholdet i de enkelte verdi-pakkene...

 

Jeg har allerede startet med et dokument med forklaringen av kodene, så jeg kan godt fortsette å oppdatere den  

 

Ellers så mottok jeg en mail fra nettleverandøren min i dag: 

 

Sitat

Viser til din henvendelse vedrørende HAN og OBIS koder. Informasjon fra måleren via HAN grensesnittet vil bli overført via protokollen MBUS, EN 13757-2. Tilkobling skjer via standard nettverkskabel med RJ45 kontakt. 

HAN kontakten er ikke aktivert i måleren per dags dato. Følgelig sendes det derfor ingen noen form for informasjon ut fra dette grensesnittet enda. Det er heller ikke helt avklart hvilke data man som kunde kan få tilgang til via HAN grensesnittet enda. Vi har foreløpig ingen dato klar enda, men vi regner med at dette vil være på plass innen høsten 2018.

OBIS (Object Identification System): Dette henger sammen med det ovennevnte, dvs at hver parameter som vil bli overført via HAN grensesnittet har en egen unik OBIS kode. Dette er altså ikke på plass enda. Alle målerprodusenter skal tilby samme informasjons meny som kan avleses på samme lesemedium. 

 

Det vil bli sendt ut informasjon om HAN grensesnittet og om hvilke parametere som kan avleses når dette er klart og aktivert i målerene.

 

[roarfred]

4 hours ago, Tubez said:

 

Ja, jeg er enig i at første byten forteller noe om dataformatet, og så ser ut som at byte 2 skal fortelle om antall bytes dataen består av eller ikke. Dette ser man i for eksempel når man får avleste verdier, så står denne til 0600000524. Så kanskje skal alle avleste verdier være oppført som 0600 000524? I dette tilfellet er allerede 06 definert til å Unsigned 32, og man trenger da ikke å gi noe ytterlige informasjon om antall bytes, derfor er byte 2 satt til "00"? Eller så har de bare droppet å gi ytterlige informasjon om denne og denne skal være oppført som 06 00000524?

 

Etter å hatt lest litt så ser jeg at du har nok rett i det med datoen, for i henhold til Bluebook: 

"OCTET STRING (SIZE(12))

{

year highbyte,

year lowbyte,

month,

day of month,

day of week,

hour,

minute,

second,

hundredths of second,

deviation highbyte,

deviation lowbyte,

clock status

}

The elements of date and time are encoded as defined above. Some may be set to “not specified” as defined above. In addition: deviation: interpreted as long"

Ukedag er det de har puttet mellom der ja

[Einar]

6 timer siden, roarfred skrev:

Da har jeg fått komplette filer for schematics, part list og PCB, inklusive gerber filer fra vår venn i India. Det hele er lagt ut her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical

 

 

Jeg tok en kjapp titt på dem og tror du får problemer.

Det ser ut som pads er ubetydelig større enn hull, noen er faktisk mindre.

Om du måler pads i en gerber viewer så ser du at pads er nede på ca. 0.63mm og ingen drill er liten nok til å la det bli igjen noe kobber.

Best case er at kortprodusenten kontakter deg for å fikse det. Worst case så bare lager de det og du får ubrukelige kort.

 

Sjekk også at pads for WiFi modulen stikker godt utenfor. Ellers kan du ikke lodde den med loddebolt. Jeg får ikke sjekket dette uten å legge det ut på nytt, men det er en vanlig feil om man ikke tar høyde for håndlodding.

 

Sjekk drill file (nedenfor). De vil antagelig ta ekstra betalt for at maskinen skal skifte drill bit unødvendig.

Hullstørrelsen er jo også tildels altfor store.

 

---------------------------------------------------------------------------------------------------------------------------------
NCDrill File Report For: AMSTOMQTT.PcbDoc   10/2/2017  4:27:12 AM
----------------------------------------------------------------------------------------------------------------------------------

Layer Pair : Top Layer to Bottom Layer
ASCII RoundHoles File : AMSTOMQTT.TXT

Tool       Hole Size               Hole Tolerance               Hole Type       Hole Count   Plated         Tool Travel
----------------------------------------------------------------------------------------------------------------------------------
T1      28mil (0.7mm)                                             Round             9         PTH        4.25inch (107.84mm)
T2      28mil (0.711mm)                                           Round             1         PTH        0.00inch (0.00mm)
T3      30mil (0.76mm)                                            Round             10        PTH        0.91inch (23.16mm)
T4      33mil (0.85mm)                                            Round             22        PTH        7.25inch (184.18mm)
T5      35mil (0.9mm)                                             Round             18        PTH        5.72inch (145.35mm)
T6      47mil (1.2mm)                                             Round             8         PTH        1.55inch (39.49mm)
T7      126mil (3.2mm)                                            Round             2         PTH        0.45inch (11.43mm)
----------------------------------------------------------------------------------------------------------------------------------
Totals                                                                              70

Total Processing Time (hh:mm:ss) : 00:00:00

[roarfred]

1 minute ago, Einar said:

 

Jeg tok en kjapp titt på dem og tror du får problemer.

Det ser ut som pads er ubetydelig større enn hull, noen er faktisk mindre.

Om du måler pads i en gerber viewer så ser du at pads er nede på ca. 0.63mm og ingen drill er liten nok til å la det bli igjen noe kobber.

Best case er at kortprodusenten kontakter deg for å fikse det. Worst case så bare lager de det og du får ubrukelige kort.

 

Sjekk også at pads for WiFi modulen stikker godt utenfor. Ellers kan du ikke lodde den med loddebolt. Jeg får ikke sjekket dette uten å legge det ut på nytt, men det er en vanlig feil om man ikke tar høyde for håndlodding.

 

Sjekk drill file (nedenfor). De vil antagelig ta ekstra betalt for at maskinen skal skifte drill bit unødvendig.

Hullstørrelsen er jo også tildels altfor store.

 

---------------------------------------------------------------------------------------------------------------------------------
NCDrill File Report For: AMSTOMQTT.PcbDoc   10/2/2017  4:27:12 AM
----------------------------------------------------------------------------------------------------------------------------------

Layer Pair : Top Layer to Bottom Layer
ASCII RoundHoles File : AMSTOMQTT.TXT

Tool       Hole Size               Hole Tolerance               Hole Type       Hole Count   Plated         Tool Travel
----------------------------------------------------------------------------------------------------------------------------------
T1      28mil (0.7mm)                                             Round             9         PTH        4.25inch (107.84mm)
T2      28mil (0.711mm)                                           Round             1         PTH        0.00inch (0.00mm)
T3      30mil (0.76mm)                                            Round             10        PTH        0.91inch (23.16mm)
T4      33mil (0.85mm)                                            Round             22        PTH        7.25inch (184.18mm)
T5      35mil (0.9mm)                                             Round             18        PTH        5.72inch (145.35mm)
T6      47mil (1.2mm)                                             Round             8         PTH        1.55inch (39.49mm)
T7      126mil (3.2mm)                                            Round             2         PTH        0.45inch (11.43mm)
----------------------------------------------------------------------------------------------------------------------------------
Totals                                                                              70

Total Processing Time (hh:mm:ss) : 00:00:00

Impressed! Forstod nok til å skjønne at dette er problematisk, men ville ikke oppdaget det selv

 

Vet du noe hvordan det er å lese filene og fikse dette selv? (Det er laget i Altium PCB Designer)

[Einar]

Beklager, der ble jeg lurt av GerbViev. Når jeg måler med GerbV så sier den 1.3mm diameter pads. Og det er akkurat passe.

 

Snodig siden GerbView er et komersiellt program og GerbV et open Source prosjekt.

 

Men fortsatt bør du fikse drill filen. Vanlig feil som jeg også fikk kjeft for på de første kortene jeg la ut.

Om det ikke er noen spesiell komponentkrav så ville jeg kjørt 0.85mm på tool 1-5.

 

 

[Tubez]

Hei

 

Har du noen samples av den datapakken man får én gang i timen? 

 

Er det noen flere som har fått til å sample data fra måleren sin? 

[Actibus]

Var noe snakk om dagens strømpris ble satt dagen i forveien, var det linket til noen side man kan få hentet ut den prisen hver dag?

[roarfred]

21 hours ago, Tubez said:

Hei

 

Har du noen samples av den datapakken man får én gang i timen? 

 

Er det noen flere som har fått til å sample data fra måleren sin? 

Se under samples mappen, og etter de siste tekstfilene der. Er på mobil så får ikke lagt til link...

 

Edit:

Denne viser hver enkel av de tre pakkene, og en forklaring til hvert element, men bare data-delen av pakken:

https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kaifa OBIS breakdown.md

 

Denne viser eksempler med verdiene som kommer hver time, men du må kanskje lete litt:

https://raw.githubusercontent.com/roarfred/AmsToMqttBridge/master/Samples/ESP 20170915.txt

 

Her er et konkret eksempel: (komplett pakke)

7E A0 9B 01 02 01 10 EE AE E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09 0F 05 05 00 0A FF 80 00 00 02 12 09 07 4B 46 4D 5F 30 30 31 09 10 36 39 37 30 36 33 31 34 30 31 37 35 33 39 38 35 09 08 4D 41 33 30 34 48 33 45 06 00 00 03 7A 06 00 00 00 00 06 00 00 00 00 06 00 00 00 22 06 00 00 04 AF 06 00 00 0C 9A 06 00 00 0B F3 06 00 00 09 55 06 00 00 00 00 06 00 00 09 58 09 0C 07 E1 09 0F 05 05 00 0A FF 80 00 00 06 00 02 E7 85 06 00 00 00 00 06 00 00 01 61 06 00 00 43 EB 4C 88 7E

 

 

Endret 5. oktober 2017 av roarfred
more info

[Tubez]

51 minutter siden, Actibus skrev:

Var noe snakk om dagens strømpris ble satt dagen i forveien, var det linket til noen side man kan få hentet ut den prisen hver dag?

Nordpoolspot.com

 

Denne er kun gjeldende om du har et strøm abonnement som baserer seg på spottpris, altså ikke fast eller fast-variabel. Du må også vite hvordan pris-sone du er i. Dette kan du lese mer om på Statnett.no

Endret 4. oktober 2017 av Tubez

[roarfred]

Da kom første bruksområde... Fikk melding fra E-laget at de ikke helt klarer å lese av måleren ennå, så vi må fortsatt lese av og sende inn selv inntil videre.

 

Da var det jo ikke annet å gjøre enn å lage følgende oppsett i Node Red:

 

[Tubez]

Åh? Har de feil på systemet eller har de ikke fått montert utstyret ute i felt enda?

 

Ganske genialt å sette dette opp som automatisk avsender

[roarfred]

2 hours ago, Tubez said:

Åh? Har de feil på systemet eller har de ikke fått montert utstyret ute i felt enda?

 

Ganske genialt å sette dette opp som automatisk avsender

Er litt usikker på om det er lokalt eller hos Valider feilen ligger, og heller ikke om det er en feil eller bare ikke helt ferdig ennå.

 

Mener jeg så et sted at måleren selv vil vite om den er blitt avlest. Mulig jeg selv har feiltolket, men det var noe med at siste pakken inneholder en dato/klokkeslett. Noen som vet mer om det?

[Tubez]

Jeg har ikke fått sett på den siste pakken enda, men den siste pakken skal inneholde dato og klokkeslett ja. 

 

Jeg snakket litt med netteier her i området, og de fortalte at de leser av måleren 3 ganger i døgnet, og da får de opp samme info som oss angående kWh fordelt over pr. time. Om måleren vet om den blir lest av eller ikke har vell egentlig ingen betydning da vi ikke får tilgang til den parameteren...

 

Jeg tenker at jeg skal sette opp 3 dokumenter, 1 for hver "pakke". Dermed kan det bli litt lettere å sortere hva som er i hva.

[Tubez]

Jeg har tenkt litt på hvordan jeg ønsker å ha grensesnittet mitt for avlesning, og jeg har veldig lyst å ha frekvens-indikatoren som står på statnett sine sider: http://statnett.no/Kraftsystemet/

 

Har du noen forslag på hvordan man kan implementere det?

 

Jeg tenkte at jeg skal lage en en web-basert interface med Django eller tilsvarende. 

[roarfred]

1 hour ago, Tubez said:

Jeg har tenkt litt på hvordan jeg ønsker å ha grensesnittet mitt for avlesning, og jeg har veldig lyst å ha frekvens-indikatoren som står på statnett sine sider: http://statnett.no/Kraftsystemet/

 

Har du noen forslag på hvordan man kan implementere det?

 

Jeg tenkte at jeg skal lage en en web-basert interface med Django eller tilsvarende. 

Tenker du på å ha selve frekvens-indikatoren hos deg selv? Ville du forventet at frekvensen hos deg ikke fulgte den hos statnett?

 

Tror i tilfelle det er utenfor HAN porten du har anledning til noe slik. Med målinger hvert annet sekund tror jeg du har en rimelig komplisert oppgave om du skal gjette deg fram til frekvensen. Om målingen som gjøres virkelig er en øyeblikksmåling er det ikke umulig, men ville gitt en vanvittig feilmargin...

 

Om du ser etter noe helt separat som skulle målt frekvensen på nettet hos deg, så tror jeg ikke det er så komplisert. Med en ESP8266 kunne du transformert ned og kjørt sinusen gjennom en schmitt-trigger og deretter inn på en interupt-inngang. Deretter kan en skifte mellom å måle og rapportere, eks. mål tiden det tar for 50 pulser, rapporter verdien, mål igjen osv. Du burde kunne få ut frekvensen med ganske høy oppløsning. (Til sammenligning er vi på HAN porten på 2400 baud, og ca. 10 bit per sek, så rundt 24000 Hz, og dette er langt, langt fra hva som kan prosesseres)

[Tubez]

Hehe nei det var ikke det jeg tenkte, jeg vet at frekvensen er lik den på Statnett sine sider. 

 

Det jeg vil, er å ha indikatoren som er på Statnett sin side inn på mitt web-interface, altså ikke bruke HAN kontakten til det

 

Edit:

Jeg fant en link på siden deres som kun viser denne indikatoren: 

http://driftsdata.statnett.no/web/Frequency/Mini

 

 

Endret 6. oktober 2017 av Tubez

[roarfred]

Var det noen som hadde (programmatisk) tilgang til strømpriser? Jeg trodde dette skulle kunne hentes ut fra nordpool, men det viste seg å være en litt for kostbar affære...

(Jeg skal høre med lokalt e-lag også, men har min tvil om det fører noe sted hen) 

 

Fant plutselig ut at en kunne lage dashboards i node-red. Må kanskje henge en gammel telefon på veggen