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

[roarfred]

3 minutes ago, xibriz said:

Koblet ut debugPrint-funksjonen og da ser det stabilt ut... jeg er sikker på at jeg prøvde å sette debugPort til NULL tidligere uten at det funket... får forske litt til.

 

Det er deilig å sitte inne i 24 grader kontra ute i 5 minus Kanskje derfor jeg finner ut av ting her

hehe, så ut som vi fant løsningen samtidig her  godt jobbet!

[xibriz]

1 minutt siden, roarfred skrev:

Vi kan ikke bruke Serial både til HAN og til debugging.

 

Joda.. RX fra HAN og TX inn på PCen

[xibriz]

2 minutter siden, roarfred skrev:

hehe, så ut som vi fant løsningen samtidig her  godt jobbet!

 

?

 

Jeg var sikker på at jeg hadde prøvd å sette debugPort til NULL, og da skulle ikke debugPrint kjørt.. så det er litt rart hvis jeg hadde problemer med det. Men det kan jo hende at jeg bare har tenkt på saken uten å faktisk gjort det. Får kaste mer kode inn på ESPen å se hva som skjer.

[roarfred]

24 minutes ago, xibriz said:

 

Joda.. RX fra HAN og TX inn på PCen

Du har helt rett, jeg som ikke helt tenkte på denne muligheten...

 

En endring jeg bør få inn er da selvfølgelig noen yields() inni kode som skriver ut hele mottatte pakke som hex. Denne blir fort nesten 4 x antall mottatte bytes, og over 2400 baud er det fort å nærme seg 1 sekund.

[roarfred]

Fikk kretskort i dag. De sendte 12 istedet for 10, mulig de vil kompensere for evt. feil...

Kortene ble bestillt 2. mars, med 7 dagers prosessering. Viser seg å være 7 arbeidsdager, fra de får bestilling til de blir sendt, men 12 dager er ikke så ille.

(PCB ble bestilt fra EuroCircuits, kan se ut som de holder til i Belgia)

 

Loddet på komponenter. Så at ESP fikk strøm. Plugget i FTDI kabel og så AI Thinker ready... melding

Patchet om HAN til labben og plugget denne i. Sjekket JP1 med oscilloscope, og så finfin 3.3V TTL komme rasende inn

Satte jumper på JP1, lastet opp ESPDebugger sketch, og så på serial output...

 

Her var det jo bare rabbel! Så kom jeg på, jeg har jo debug på Serial1, og det har jeg ikke tatt høyde for på kortet.

Fant ut at Serial1 TX er Pin02, og at denne er lagt høy via R3. Kunne derfor koble til FTDI via en kabel, og voila!

(Helt fantastisk at vi for to dager siden så at debug vil fungere helt fint via vanlig Serial også, om en kjører denne på samme config som HAN)

 

En sjelden gang bare funker ting, "out of the box"  

 

PS: Er i gang med å lage en mer skikkelig software. AP boot, DNS, config i EEPROM, støtte for alle målere, osv. 

 

 

 

 

 

 

[sajje]

Med denne løsinng får du en ekstern enhet som kan sende data over MQTT over WIFI?

 

Finns det mulighet å få kjøpe en "ferdig loddet" enhet?

[Moskus]

22 minutter siden, sajje skrev:

Finns det mulighet å få kjøpe en "ferdig loddet" enhet?

Samme!

[Øyvind]

9 minutter siden, Moskus skrev:

Samme!

det han sa

[xibriz]

Jeg fikk også mine kort i går, men jeg er ikke i nærheten så rask som @roarfred

 

[Morten B]

1 time siden, Øyvind skrev:

det han sa

Meg og Kanskje man skulle sjekket hvordan interessen er. Det finnes jo firmaer der ute som lager kort med komponenter i små mengder.

Jeg sjekket med PCBCart.com når førsteutkastet var klart og fikk "tilbud" som følger:

 

Kosten ligger altså i å få de satt sammen. Kanskje assembly cost går ned om det er mange kort som bestilles på en gang.

 

//M

[Ravn]

Hei. Ny på formuet, kom her etter å ha googlet etter teknisk info om AMS/HAN.

 

Jeg driver ett lite firma som driver blandt annet med styring av ladestasjoner for elbiler. Vi har tidligere brukt egne målere i sikrinsskapet for å kunne styre ladingen av elbil ut fra annet forbruk (eksempel: man har en tesla og en bmw som skal lades, bor i gammelt hus med IT nett og 50A inntak. Plutselig er det logistikk innvolvert i å få ladet bilene uten at hovedsikringa går. Men med smart styring tilpasser ladingen seg etter hva som er tilgjengelig).

I fremtiden blir dette enda viktigere med tanke på effektprising. I tillegg så har man sånne teknofrelste (eventuelt miljøforkjempere) som meg som har solceller på taket. Da stemmer plutselig ikke avlest last fra hovedsikringen lengre. Og man vil gjerne putte overproduksjon inn på bilbatterier, istedenfor å selge osv.

 

Så tilbake til topic.

SMD vil gjøre kortet ditt mye rimeligere å få produsert, i tillegg er selvfølgeig antall en viktig faktor.

 

Vi har selv planlagt å lage ett HAN->ESP kort (vi bruker primært WROOM32 moduler, men det er ikke så nøye i denne sammenhengen), som igjen vil kommunisere med ladestasjonene, men dette er jo kun snakk om forskjellig firmware. Men her kan vi kanskje finne en felles løsning. Vi har gode kontakter i Schenzen og Hong Kong så tror nok jeg skal klare å få presset prisen en del ned. Vi må i tillegg har en komplett enhet i en eller annen enclosure. Tenkte først DIN enhet, men flere enn meg har det vel rimelig trangt i sikringssskapet, så noe lite som kan festes med borrelås på siden av måleren er vel bedre.

 

Så noen nevnte en "service"/stikkontakt i skapet for strøm. Som nevnt har ikke jeg plass til slikt selv, og sikkert mange som har samme problemet. Selv planlegger jeg å hente ut strøm fra ringetrafoen, 8VAC er de fleste komfortable med å skru på.

 

 

 

 

[ZoRaC]

8 minutter siden, Ravn skrev:

Så noen nevnte en "service"/stikkontakt i skapet for strøm. Som nevnt har ikke jeg plass til slikt selv, og sikkert mange som har samme problemet. Selv planlegger jeg å hente ut strøm fra ringetrafoen, 8VAC er de fleste komfortable med å skru på.

 

Do'h! Jeg fikk elektriker til å bytte ut min ringetrafo (bruker trådløs ringeklokke uansett) med en DIN-stikk (var ikke plass til begge deler). Tenkte ikke tanken på at jeg kunne brukt ringetrafoen til formålet...  

 

10 minutter siden, Ravn skrev:

Tenkte først DIN enhet, men flere enn meg har det vel rimelig trangt i sikringssskapet, så noe lite som kan festes med borrelås på siden av måleren er vel bedre.

 

Enig! Jeg har, som sagt, fylt skapet allerede...  

 

11 minutter siden, Ravn skrev:

Vi har selv planlagt å lage ett HAN->ESP kort (vi bruker primært WROOM32 moduler, men det er ikke så nøye i denne sammenhengen), som igjen vil kommunisere med ladestasjonene, men dette er jo kun snakk om forskjellig firmware. Men her kan vi kanskje finne en felles løsning. Vi har gode kontakter i Schenzen og Hong Kong så tror nok jeg skal klare å få presset prisen en del ned. Vi må i tillegg har en komplett enhet i en eller annen enclosure.

 

Veldig interessant! Har ikke fått info om når jeg får AMS-måler selv enda, men jeg er klar til å kjøpe en ferdig "dings",  når den tid kommer!  

[Ravn]

Jeg har fått AMS måler, men Lyse nett har (som andre har påpekt) ingen plan om når HAN interfacet skal bli aktivert. De brukte 7 måneder fra AMS måler ble levert til de klarte å ta imot dataene hos seg. De har enda ikke fått skikkelig kontroll på å levere dataene videre til min strømleverandør, så holder ikke pusten.

 

[roarfred]

@Øyvind, @Moskus og @sajje, jeg har desverre ikke kapasitet til å lodde kretskort for salg... Det jeg imidlertid kan bruke litt tid på er å få omformet kortet til en SMD variant, slik @Ravn foreslår, og få det lagt inn hos en PCB service hvor en kan kjøpe ferdige kors. Hvis noen har kompetansen og slik på dette, setter jeg også stor pris på en Pull Request  Oppgaven vil egentlig bare bestå i å kjøre KiCad og bytte ut innkapslingen til through hole komponentene med SMD ekvivalenter.

[roarfred]

Ang, den mystiske byten vi så i DLMS headeren, som Kamstrup fjernet, men som vi fremdeles ser hos Kaifa. DLMS.com har bekreftet at dataene vi får fra Kaifa er feil, så her må vi nok regne med at det kommer en korreksjon:

 

Quote

 

Dear Roar,

I can confirm now that the KAIFA APDU is wrong.

This is the APDU carried by the HDLC frame:

0F 40 00 00 00 09 0C 07 E1 09 0C 02 17 12 2A FF 80 00 00 02 01 06 00 00 05 28

This translates to:

<DataNotification>
  <LongInvokeIdAndPriority Value="40000000" />
  <DateTime Value="0C07E1090C0217122A" /> // 09 is interpreted as the length 
  <NotificationBody>
    <DataValue>
      <DontCare /> // This is because the bte FF, the remaining bytes 80 00 00 02 01 06 00 00 05 28 are ignored.
    </DataValue>
  </NotificationBody>
</DataNotification>

The correct APDU would be:

0F 40 00 00 00 0C 07 E1 09 0C 02 17 12 2A FF 80 00 00 02 01 06 00 00 05 28 (the tag 09 is for octet-string is not present)
 

<DataNotification>
  <LongInvokeIdAndPriority Value="40000000" />
  <DateTime Value="07E1090C0217122AFF800000" /> the lengh of the octet-string is 12
  <NotificationBody>
    <DataValue>
      <Structure Qty="0001" > // structure of 1
        <DoubleLongUnsigned Value="00000528" />
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

The KAMSTRUP APDU is correct.

Please advise KAIFA, I will ask advise them.

best regards

DLMS Support

 

 

Jeg har meldt dette inn til NTE Nett som tar det videre til Kaifa og lover å holde oss oppdatert på når evt. ny firmware kommer.

[Ravn]

@roarfred Jeg har ikke lært meg kicad enda dessverre (må nok hoppe over snart etter at Eagle startet med denne idiotiske nye betalingsmodellen sin), men jeg kan påta meg å lage en liten batch av kort til folk på forumet her, har godt med utstyr for SMD arbeid på jobb, det er verre med ledig tid. Men en 10-15 kort skulle gå greit. Mer enn det så får vi sette det ut.

 

 

[roarfred]

2 hours ago, Ravn said:

Jeg har ikke lært meg kicad enda dessverre

Kan skrive under på at det var en befrielse å gå over til KiCad. MYE enklere, og bedre kontroll over kapsling osv. Og bonusen med 3D modell da. Drog den nettopp inn i Fusion 360 for å printe meg en boks...

[Ravn]

Ja tror det blir ett prosjekt for påsken

 

Angående han->esp interfacet. Har du sett på å drive hele kortet fra m-busen, istedenfor egen tilførsel via usb?

[sajje]

Vurderer å kjøre en Raspberry PI med en lik adapter:

https://www.aliexpress.com/item/Freeshipping-USB-to-MBUS-slave-module-discrete-component-non-TSS721-circuit-M-BUS-bus-data-monitor/32814808312.html

Trekker en CAT6 fra sikringsskapet og til Raspberryn alternativt plassere den i sikringsskap med DIN stikk eller power fra ringetrafo

 

Logger data med denne:

https://drive.google.com/drive/folders/0B3ZvFI0Dg1TDbDBzMU02cnU0Y28

 

Føles som en enklere løsning, mere fleksibel samt at man kan gjøre hva man vill med data (MQTT, NodeRed, MongoDB)

 

Kjører Hassio for huset og der kan jeg ta inn den med MQTT fra Raspberry i sikringsskapet. 

[petersv]

@sajje, vi har en egen tråd på den "enkle" løsningen  Der finner du ferdig node-red-oppsett også.

 

 

 

Endret 16. mars 2018 av petersv

[roarfred]

1 hour ago, Ravn said:

Angående han->esp interfacet. Har du sett på å drive hele kortet fra m-busen, istedenfor egen tilførsel via usb?

Ja, utfordringen ligger i svært ulik spec på hvilken belastning. Tror Kamstrup kommer dårligst ut med 144mW. Med ZWave eller Zigbee ville det vært enklere, men ESP8266 er nokså kravstor her. Vet du noe om ESP32 er noe bedre her?

[Ravn]

3 minutes ago, roarfred said:

Ja, utfordringen ligger i svært ulik spec på hvilken belastning. Tror Kamstrup kommer dårligst ut med 144mW. Med ZWave eller Zigbee ville det vært enklere, men ESP8266 er nokså kravstor her. Vet du noe om ESP32 er noe bedre her?

 

Ante meg at det var noe slikt. Esp32 er vel heller verre (har BLE i tillegg til wifi)

Er nok lurest med ekstern strøm da ja. Jeg er vanligvis veldig fan av usb som strømtilførsel, men akkurat i dette prosjektet så vil jeg måtte ta strøm fra ringetrafoen så ser for meg skruterminaler og en likeretter i tillegg.

 

 

 

[Odd]

Noen som husker at M-bus i utgangspunktet er toveis?

Jeg ønsker å kople på andre M-bus enheter på samme grensesnitt.

Det er jo ikke mye som skal til når kretsene i utgangspunktet støtter dette-

[backspace]

Har plaget Lyse litt og fikk svar nedenfor. En kan jo håpe de åpner opp litt før nyttår... 

 

Quote

 

Hei igjen.

Beklager sen respons. Fikk sjekket litt nærmere opp, og det stemmer som du sier. Det er ikke helt ferdigstilt enda så derfor har vi ikke mulighet for å åpne denne per nå. Dette vil dog bli klart innen utgangen av 2018. Vi har mottatt flere forespørsler om dette den siste tiden så vi håper å få det på plass i løpet av kort tid, uten at vi kan gi noe konkret tidsestimat utover senest 01.01.19. 

Vennlig hilsen
Lyse Dialog AS

 

[kanor]

På 16.3.2018 den 9.19, sajje skrev:

Vurderer å kjøre en Raspberry PI med en lik adapter:

https://www.aliexpress.com/item/Freeshipping-USB-to-MBUS-slave-module-discrete-component-non-TSS721-circuit-M-BUS-bus-data-monitor/32814808312.html

Trekker en CAT6 fra sikringsskapet og til Raspberryn alternativt plassere den i sikringsskap med DIN stikk eller power fra ringetrafo

 

Logger data med denne:

https://drive.google.com/drive/folders/0B3ZvFI0Dg1TDbDBzMU02cnU0Y28

 

Føles som en enklere løsning, mere fleksibel samt at man kan gjøre hva man vill med data (MQTT, NodeRed, MongoDB)

 

Kjører Hassio for huset og der kan jeg ta inn den med MQTT fra Raspberry i sikringsskapet. 

 

Jeg kjøpte ett slikt:   https://www.aliexpress.com/item/Industrial-Grade-USB-Transfer-to-MBUS-Host-USB-MBUS-Meter-Reading-Communication-USB-Power-Supply-10/32831725364.html?spm=a2g0s.9042311.0.0.V57FUI  og det fungere ok, så ser ikke bort fra at denne billigere varianten også vil virke. Men mener å ha lest advarsler om at man skal være obs på at slike billige M-BUS adaptere som er bygd opp av diskre komponenter ikke har galvanisk skille og man kan risikere å skade USB-porten man kobler seg inn på.

 

Jeg også bruker en Raspberry Pi 3 som kjører domoticz. Har skrevet python-script som leser serie-dataene som kommer inn på USB-porten også henter ut/konverterer de hex-bytene som inneholder de verdiene jeg vil ha tak i. Har gitt blanke i å forsøke å forstå 'obis-språket' siden dataene som strømmer ut på hanporten har ett kjent fast og forutsigbart mønster, og det holder å telle seg fram til riktig byte for aktuell verdi i hver frame.

 

Men hadde jeg vist om den sw som du linker til over, hadde jeg nok spart meg noen timer med å lære meg python....?

 

Har i tillegg laget ett python-script som laster ned xls-arket med spot-prisene fra nordpool  så jeg kan kalkulere strømkost time for time. Skal bli spennende å se når strømregningen kommer neste mnd om man med timebasert avregning som kommer i nær fremtid vil måtte betale mer eller mindre, og om det vil være noe å spare på å flytte de 'trege forbrukerne' til timer med lav pris: