roarfred

On 2/25/2018 at 20:58, cpu22 said:

Jeg har et par problemer med kommunikasjonen. 0xff bytene blir konsekvent duplisert, så jeg måtte ta høyde for det i programmet og fjerne dublettene.

Jeg koblet opp en sånn tss krets nå manuelt inn på en FTDI. Funket bra stabilt det, kunne ikke se dupliserte bytes eller noe... vær imidlertid klar over at c# koden som jeg la ut er skrevet i hui og hast og jeg tror kanskje den bare ser etter 0x7E og klipper tvert på det. Arduino koden er mer forseggjort og tar høyde for mer riktig prosessering av dataene

Denne saken er nok også kjekk for feilsøking evt. om en ønsker noe enkelt for direkte tilkobling til PC/Raspberry PI:

https://www.aliexpress.com/item/USB-transfer-MBUS-module-slave-module-communication-debug-alternative-TSS721/32719562958.html 

Veldig bra @cpu22! Regner med du også har koblet til en FTDI el.l. og fått lest ut maskinelt på TTL nivå? Har du en skisse til den totalt kretsen du kunne postet her?

Jeg er usikker på begrepet IR port... jeg mener pulse/blink port her. Den gir et blink hver gang du har forbrukt ett visst antall Wh. Ut fra dette kan du kalkulere mye av det samme som HAN porten leverer, men eksempelvis ikke strømtrekk / spenning pr leder. Det meste av info fra HAN er imidlertid bare en aggregering av de samme data. Strømtrekk og spenning kan ellers finnes ved å måle direkte på lederne som finnes like tilgjengelig som HAN porten i skapet, så jeg gleder meg litt til å se noen som mener vi må kryptere de også ☺

Edit: poenget mitt er: har du fysisk tilgang til strømskapet, så kan ikke HAN gi noe mer info enn du ellers kunne finne. HAN porten er et fysisk grensesnitt, så du må ha tilgang til skapet for å høste data. Herfra må den opplyste forbruker gjerne velge å kryptere, men det blir helt meningsløst å forlange kryptering av noe som likevel finnes ukryptert like ved

Enig med flere andre her om at det ikke er større grunn til beskyttelse/kryptering av HAN port enn av blink utgang. Om den ene kan fysisk beskyttes kan også den andre det. Blir spennende å se, men oppfatter det som helt urimelig at det skal være behov for kryptering.

Om så blir må en evt tillate å legge inn nøkkel sammen med ssid/passord på ESP software. Ser for meg at vi lar denne boote som access point første gang og at den server en enkel webside for å legge dette inn i flash minne...

17 hours ago, Blip! said:

Det er viktig å ikke blande optisk dataport (IR, inn/ut) og blinkende lysdiode. Kamstrup har f.eks. IR-port for å lese ut alle data i tillegg til blinkende lysdiode.

ja, stemmer. På min AMS måler (Kaifa) er det to separate slike pulse-lys. Ett for aktiv og ett for reaktiv energi ser det ut som. Den er merket 2000 pulser per kWh og skulle da gi noe slik som 1 puls per 0.5Wh, eller 1.8 sek mellom hver puls ved 1kW belastning.

On 2/13/2018 at 13:47, ronnyandre said:

men betyr det at det er umulig å lese av data

Med forbehold, gjetter litt her, men mulig noen kan bekrefte/avkrefte?

I prinsippet kan du få ut forbruksdata omtrent like nøyaktig, om du er villig til å bruke optisk utgang. Denne er veldig forenklet, men gir en lys-puls for hver enhet energi som er brukt. (eks. for hver Wh). Ved å samle inn disse pulsene får du data om forbruk og kan gjenskape mye av det som måleren rapporterer ut på HAN porten. (Dette, dvs. slike lys-pulser, er en relativt vanlig måte å rapportere forbruk på, så her finnes sikkert mye ferdig også)

Det du evt. mister er spenning/strøm, reaktiv effekt/energi etc, men det er egentlig for spesielt interesserte.

6 hours ago, kjetilsn said:

BKK sendte også med denne linken

Tøft! Savnet litt "kontekst" for disse dokumentene, men regner med det er ansatte hos BKK selv som har eksperimentert. Overrasket over at de ikke har funnet veien hit før

2 hours ago, ZoRaC said:

Kan man da nekte dem de andre «funksjonene» som en AMS-måler skal gi? Altså timesbasert avregning på regningen

Er det kraftleverandører som allerede fakturerer med differensiert prising for forbruk på ulike tider på døgnet? Hvis det er tilfelle, så er det kanskje litt i grenseland å la kunden sitte igjen i "blinde"?

Stemmer forøvirig at det er en viss enighet om OBIS koder, elektrisk format og protokoll på HAN porten. Det som gjenstår skal visstnok være spørsmålet om dataene på HAN porten skal krypteres, og evt. om det skal være valgfritt eller ikke. Mener Hafslund brukte som argument at de venter på svar fra NVE på denne delen...

3 hours ago, xibriz said:

Der satte de en mikrofon på ett kjøkken f.eks. også lagde en audio-profil til lyden som vasken, kaffetrakteren, komfyren etc. lager.

Dette er samme video som jeg så. Har lett litt, men ikke funnet den igjen.

Selv om dette ikke gir styring, så kan det gi gode varsler. Sammen med ML kan det varsles fordi noe observeres som unormalt, ikke nødvendigvis fordi du selv hadde forutsett en situasjon og laget en konkret regel for det.

59 minutes ago, berland said:

Dette er forsåvidt allerede kommersielt tilgjengelig, eksempelvis med Smappee som jeg har i sikringskapet mitt.

Tøft! Gir denne deg direkte tilgang til sensoren også? Uten å gå via et eksternt API utenfor huset?

9 minutes ago, Moskus said:

Enig! Men er vi der enda...? 

Teknologien skal være der. Hvis jeg har forstått dette riktig, så lager en en ML modell og trener den opp i skyen, hvoretter en kan pakke den inn i en docker container og deploye den til en Azure IoT device. Eksempel her: https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-deploy-machine-learning

Jeg er ikke helt sikker

Tror nok dette blir et hakk lavere enn andre hjemmesentraler, og mulig det ikke engang hører hjemme i et hjemmeautomasjons-forum. Vi hadde tidligere noen forsøk med sensorer direkte koblet til Azure IoT Hub (MQTT), men jeg har alltid hatt en dårlig følelse rundt det å være avhengig av en ekstern tjeneste. Med IoT Edge ser jeg at en får en lokal MQTT, og mulighet til å prosessere/filtrere data som en evt. vil sende til skyen. Samtidig blir også flere av sky-tjenestene direkte tilgjengelige lokalt, som eks. Azure Functions, AI og ML, og i tillegg kan hele oppsettet administreres fra Azure portalen.

Totalt sett tror jeg kanskje dette er mer en plattform å utvikle en ny type hjemmesentral på, enn noe som egner seg for hvermansen å styre huset med. Prøver enn så lenge å samle litt erfaringer med teknologien.

En konkret ting som hadde vært litt besnærende å få til, er å lage et nevralt nettverk for å analysere øyeblikksforbruket på strøm-inntaket, og gjenkjenne ulike elektriske apparaters signatur på forbruk. Er usikker om data fra HAN porten har god nok oppløsning til dette, med 2 sek intervall, men evt. kunne en hatt en egen sensor/måler. Ut fra dataene ville en da kunne gi en oversikt over hvilke apparater som bruker hvor mye strøm i hvilke tidsrom, og evt. forslag til forbedringer.

Tar en denne tanken videre vil en kunne måle mye annet på samme vis. Så noen hadde et eksperiment med en multi-sensor (audio, IR, temp, accellereometer etc) i hvert rom som kunne gi en ganske stilig status på hva som foregikk i rommet. Type kaffetrakteren står på, men det er ikke folk i rommet. Vannkranen drypper, temperaturen i sikringskapet ligger 4 grader over normalen etc. Med enkle sensorer og direkte logikk er mye av dette enkelt nok å detektere, men det er først når en får kontinuerlig prosessering av en kombinasjon av sensorer at de mer intelligente løsningene kan komme til overflaten.

Drømmer litt, men det må vel være lov

Mener andre har fått data ut av Kampstrup, så dette høres ut som porten ikke er aktivert. Mener eneste forskjellen fra kaifa var at kommunikasjon var uten paritet der.

Jeg har nettopp installert Azure IoT Edge på en Raspberry PI 3 her, og håper å komme litt i gang med å knytte devices opp til denne.

Noen som har gjort dette og fått noen erfaringer?

Kan foreløbig se ut som litt høy terskel, og at en må utvikle egen software og deploye i docker containers

Var i Seattle på LEAP Nordig nylig og var innom bla. dette. Spesielt interessant at en kan begynne å dra machine learning ned lokalt...

En liten oppskrift på oppsett som funket for meg:

https://github.com/roarfred/IoT_Edge_On_Raspberry_3_Setup

Mer om IoT Edge:

https://azure.microsoft.com/en-us/services/iot-edge/

5 minutes ago, cpu22 said:

 

Nå har jeg loddet opp en converter basert på TSS721A, men det gjorde ingen forskjell for meg. Fortsatt like dødt. Det ser ikke ut som måleren sender ut data. Bare 24 V DC.

 

Kan en av dere som har fått data fra måleren, legge ut bilde av et ubelastet signal på oscilloscopet, eller bekrefte 100% at det er transisjoner fra måleren ubelastet? Det er greit å være helt sikker før jeg starter en diskusjon med kraftselskapet.

 

https://github.com/roarfred/AmsToMqttBridge/blob/master/Electrical/Board_001/Raw HAN (scope).jpg

Edit: Dette er fra Kaifa måleren min, første test samme dag som de åpnet. Direkte mellom pin 1-2 på HAN port, uten noen annen belastning enn ocillioscopets probe

53 minutes ago, ZoRaC said:

 

Det er jo ikke "sample-shop" som i "test-butikk", men som i "kjøp en vareprøve før du velger om du vil kjøpe 1000 stk med din firmalogo på".  

Jeg bestilte fra en annen butikke da, den så helt normal ut, bortsett fra prisen... 

Og at du var nr 2 som la inn en ordre ?

3 hours ago, Tortho said:

Hei, Nå har jeg ikke lest alle de 22 sidene, men har noen sett på denne? https://www.develcoproducts.com/products/meter-interfaces/emi-norwegian-han/

 

Har observert den, som det eneste kommersielle produktet "på markedet". Har dog ikke klart å finne den i salg, men det er nok naturlig at den holdes tilbake frem til HAN-portens oppførsel standardiseres av de ulike målertypene.

46 minutes ago, Øyvind said:

@roarfred Husker du hva du betalte for energimåleren?

Faktura sier kr 2800,- inkl mva, men uten montering.

On ‎26‎.‎01‎.‎2018 at 09:30, xibriz said:

 Hvis flere tror dette kan funke kan jeg være fristet til å prøve på min måler som vi vet fungerer. 

Jeg tror absolutt denne kan erstatte den enkle level-converteren som jeg tegnet! En annen fin ting med denne er at den har LED for TX og RX, så en bør kunne plugge den rett i HAN porten og se indikasjon på at data kommer ut, uten behov for annen elektronikk eller software. Jumper ser ut til å ha noe med strømforsyning å gjøre, kanskje valg om strøm skal tas fra M-BUS eller fra VDD på TTL-siden. Selv om denne har tilrettelagt for å hente ut 3V3 fra M-BUS, så vil den ikke kunne forsyne ESP8266. Et alternativ kan være å kjøre en Zigbee eller BLE basert modul som mottaker for å få ned strømforbruket. 

1 hour ago, petersv said:

 

Det står jo at de må bruke M-bus i skrivet fra NVE, så kan ikke skjønne at der er noe spesielt her med AMS. Master/slave bestemmer bare hvem som driver busen. Det står ganske bra forklart her. http://www.m-bus.com/mbusdoc/md4.php

Kikket litt mer på datablad nå. Kan se ut som denne fint kan brukes, og at den kan kjøre som en ren level converter. Fordelen vil være bedre tilpassing til varierende spenning på mbus og at denne er uavhengig av polaritet.

On 1/25/2018 at 20:51, petersv said:

For å slippe å måtte begi meg ut på noe potensielt dødfødt prosjekt, hva er begrunnelsen for at du mener denne ikke vil fungere?

I tillegg til det moskus nevner er det også noe med at en ikke opererer med vanlig mbus master/slave her, men en form for push, der måleren kontinuerlig strømmer data på gitte intervaller. (Med vanlig mbus vil en polle data)

Jeg trodde denne mekanismen lå inne i TI kretsen, men ser noen sier det er en ren tranciever, så hvis den kun gjør level-konvertering burde det funke. Venter i spenning!

2 hours ago, petersv said:

Etter litt research ser jeg at TI har en transceiver for M-BUS

Denne har dukket opp som alternativ noen ganger, men tror det er et blindspor. Selv om det elektriske laget er M-Bus, så er det på høyere lag nyttet andre protokoller. For tilkobling til mer tradisjonelt M-Bus utstyr er nok denne kretsen en mulighet, men mot AMS målerne tror jeg ikke du får så mye hjelp.

Understreker TROR her, så fantastisk om du prøver og får det til! Jeg har også noen slike liggende ubrukt i skuffen. Kjøpte noen helt enkle multi-purpose kort for å kunne bruke denne i et breadboard.

15 hours ago, petersv said:

Vil det ikke være mye enklere (...)?

Nei, ikke enklere  Sikrere vil det være, kommer litt an på hva du vil sikre deg mot...

Signalet fra HAN porten ligger normalt på ca 25V, og dette indikerer en logisk "0"

Når data sendes vil en logisk "1" trekke ned til ca 12-15V

Disse to spenningene ønsker du å oversett til hhv. 3.3V og 0V. Jeg ser ikke helt at den kretsen fra aliexpress skulle løse dette, gjør du?

2 hours ago, clio75 said:

Har aidon måler. Bare si hva du vil ha så skal jeg gjøre hva jeg kan

I utgangspunktet dette:

1) Snakk med din kraftleverandør om å få åpnet HAN porten

2) Bygg kretsen for level-konvertering av HAN/M-bus signal

3) Sample noen data og post her (eks. vha HanDebugger fra gthub-prosjektet)

Er redd for at mange har prøvd på 1) for Aidon og bare fått svar at pga. uklarheter fra NVE rundt kryperting av signalet vil de ikke åpne HAN porten før tidligst Q3 2018...