roarfred

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...

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.

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.

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

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...

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.

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

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/

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

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

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.

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

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.

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.

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!

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.

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?

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...