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

[Andreas]

https://editor.p5js.org/andreaspedersen/sketches/HyPgTFqGN

 

Med varighet på sending til HomeSeer på 3 sek, og virkningsgrad på 75%, så er det nødvendig å buffre 7 innkommende datapakker mellom hver rapportering.

Hvis ikke går vi konkurs..

Endret 15. januar 2019 av Andreas

[ArnieO]

Utlegg av PCB med buck converter begynner å nærme seg klart - bortsett fra den "detaljen" at jeg ikke har breadboardtestet det ennå. ?

 

Skjema: AMS_HAN_ESP_Buck.sch.pdf

Jordplanet er ikke lagt på ennå, alt annet skal være rutet.

 

 

 

Jeg blir bortreist ifm jobb neste 3 uker, skal forsøke å teste dette på breadboard før jeg drar.

Men selv om det skulle være lite debugging (kryss fingre!) vil det realistisk sett ta minst en måneds tid før jeg får bestilt PCBer.

 

Endret 16. januar 2019 av ArnieO
Flyttet på link til skjema

[bearer]

Undres om wifi rekkevidden påvirkes av å ha baner og eller jordplan foran? 

[ArnieO]

7 hours ago, bearer said:

Undres om wifi rekkevidden påvirkes av å ha baner og eller jordplan foran? 

Det blir ingen baner eller jordplan under ESPens antenne. Skravert felt på utlegget.

[StenO]

11 timer siden, ArnieO skrev:

Skjema og layout i vedlagte filer.

Finner ikke skjema. 

Lurer litt på hvor stor kondensator du har satt på for å holde på energien lenge nok til at ESP'en får sendt?

Trodde kanskje vi måtte til med en supercap her et sted...

 

Dette blir knall! Blir med og tester jeg...

 

[ArnieO]

1 minute ago, StenO said:

Finner ikke skjema. 

Lurer litt på hvor stor kondensator du har satt på for å holde på energien lenge nok til at ESP'en får sendt?

Trodde kanskje vi måtte til med en supercap her et sted...

 

Dette blir knall! Blir med og tester jeg...

 

Linken til skjemaet havnet innimellom illustrasjonene - jeg skal flytte på den.
Jeg tenkte å forsøke med 470 µF, så får vi se. ESP'en bruker ikke lang tid på å sende - så behovet vil avhenge av om hvordan strømsparingen i koden implementeres, dvs hvilken sleep mode som brukes på ESPen.

Veldig bra om du (og evt andre) kan hjelpe til med å teste dette!

 

Angående skjemaet så er jeg ikke sikker på om MBUS kobles til buck converteren før eller etter de 220 ohm motstandene på inngangen. I prinsippet bør det vel kobles etter, men jeg var redd spenningsfallet over de vil skape trøbbel. Må testes før skjemaet fryses. Dersom de kan kobles etter kan strømbegrensningsdioden D2 fjernes.

[StenO]

Nå har etter hvert Lyse slått av HAN porten (eller egentlig Aidons egen datakommunikasjon ut på den samme porten) og jeg har bedt dem slå den på (nå med HAN-spesifikasjon).

Intet svar enda, men jeg tenkte å implementere AIDON sin versjon av den protokollen mens jeg venter.

Hvilken av de 21 forkene (https://github.com/roarfred/AmsToMqttBridge/network/members) bør jeg bygge videre på?

Tenker neste steg er å lage en ny hardware basert på det ArnieO har begynt på her.

 

[ArnieO]

2 hours ago, StenO said:

Hvilken av de 21 forkene (https://github.com/roarfred/AmsToMqttBridge/network/members) bør jeg bygge videre på?

Jeg har ikke full oversikt, men vet at @roarfred fikk sin Kaifa i drift. Han hadde som mål å lage kode som gikk på alle, men ble ikke ferdig før han dessverre gikk bort. @xibriz har kode i drift for Kamstrup, den har jeg lånt. Men jeg vet ikke om noen har kode i drift mot Aidon ennå. Mulig det står et sted på en av de forrige 54 sidene...

[frodegill]

45 minutes ago, ArnieO said:

Jeg har ikke full oversikt, men vet at @roarfred fikk sin Kaifa i drift. Han hadde som mål å lage kode som gikk på alle, men ble ikke ferdig før han dessverre gikk bort. @xibriz har kode i drift for Kamstrup, den har jeg lånt. Men jeg vet ikke om noen har kode i drift mot Aidon ennå. Mulig det står et sted på en av de forrige 54 sidene...

 

Jeg er i ferd med å konvertere min Aidon-kode til OBIS. (Dvs, jeg har vel som mål å støtte alle tre, men det er Aidon jeg har i sikringsskapet..)

[StenO]

3 minutter siden, frodegill skrev:

 

Jeg er i ferd med å konvertere min Aidon-kode til OBIS. (Dvs, jeg har vel som mål å støtte alle tre, men det er Aidon jeg har i sikringsskapet..)

Flott! 

Ingen grunn til å finne opp kruttet flere ganger. Om jeg cloner ditt prosjekt kan jeg bidra med pull-requester ?

Har du et git-repo jeg kan klone?

 

Endret 17. januar 2019 av StenO

[xibriz]

Jeg blir kun å legge tid i koden for å eventuelt optimalisere for å kjøre uten ekstern strøm. Har ingen ambisjoner om å støtte alle målere

[DIYglenn]

Jeg har ryddet en del i min fork av roarfreds prosjekt.

Jeg ønsker å fokusere kun på det kortet som har vært diskutert mest i denne tråden, og derfor lagt de andre under «debugging» inntil videre. 

Det var flere versjoner som ble laget, men ESP_TSS721 er vel den som har kommet lengst. 

 

Jeg skal også oppdatere med guide på montering/lodding og flashing av firmware, dependencies som må installeres i Arduino IDE etc. 

 

Jeg skal også fjerne nåværende webgrensesnitt for førstegangsoppsett, da dette ikke alltid fungerer, og er litt «bloated» i forhold til hva man trenger.

 

Dette skal erstattes med WifiManager, og ArduinoOTA skal implementeres. 

Da er det to sett ferdigbygget kode som tar for seg det, så kan fokuset ligge på å få støtte for alle målere. 

 

Jeg hadde håpet at det var mulig å samle alle her i tråden som sitter på kompetansen, få produktet til å fungere godt, så kan vi deretter videreutvikle V2.0 med nytt PCB, andre strømkilder etc. 

 

Mine tanker rundt det iallefall. 

Jeg skal gjøre mitt for å få ESP_TSS721 til å være mest mulig et «ferdig» produkt, og rydding i kode er første steg. 

[ArnieO]

28 minutes ago, DIYglenn said:

Jeg hadde håpet at det var mulig å samle alle her i tråden som sitter på kompetansen, få produktet til å fungere godt, så kan vi deretter videreutvikle V2.0 med nytt PCB, andre strømkilder etc.

Det er en god tanke, som jeg støtter.

 

Jeg ser "alle" her bruker Github. Jeg har installert GIT og Github desktop - og har gjort et seriøst forsøk på å forstå hvordan det brukes - men har ennå ikke "knekket koden".

Kunne en av dere som er oppe å gå, og som kanskje er i stand til å forstå hva jeg ikke forstår?, gi meg et dytt i riktig retning?

 

Jeg forsøker å starte en egen tråd for å få hjelp. Jeg har aldri vært "dummeste i klassen" som trenger spesialundervisning ? så dersom jeg plundrer er jeg sikkert ikke alene (dvs andre kan ha nytte av en slik tråd).

 

EDIT:

Har startet tråd her:

 

Endret 18. januar 2019 av ArnieO

[DIYglenn]

GitHub Desktop er greit for å se litt hvordan det henger sammen, men jeg har hatt godt nytte av VS Code med GitHub lagt til. Da kan du kode og slenge det rett opp i GitHub. 

 

Jeg er heller ingen ekspert, men et eksempel på flyt:

En issue #123 er registrert, du ønsker å fikse dette. Du lager en ny branch (speiling av fork), som kalles «fix-issue-wifi», og koder i den. Når du er ferdig og ser det fungerer, legger du inn en pull request (pass på at det er pull request til fork, ikke til original (roarfred)), og i kommentarfeltet «closes #123» + evt kommentarer. Når den pull request’en blir «committed» blir issue stengt, branch kan slettes (får automatisk spørsmål om du ønsker det) og master er up to date med ny kode. 

 

Noe sånt

[ArnieO]

 

3 minutes ago, DIYglenn said:

GitHub Desktop er greit for å se litt hvordan det henger sammen, men jeg har hatt godt nytte av VS Code med GitHub lagt til. Da kan du kode og slenge det rett opp i GitHub. 

 

Jeg er heller ingen ekspert, men et eksempel på flyt:

(...)

Nettopp noen slike tips jeg trenger. Dersom noen som er "på lufta" kan tipse om en enkel workflow for bruk av GitHub så vil det gi meg kort vei mot mål.

Kan vi ta dette i tråden jeg nettopp opprettet? (se EDIT i posten ovenfor).

[frodegill]

3 hours ago, DIYglenn said:

Jeg hadde håpet at det var mulig å samle alle her i tråden som sitter på kompetansen, få produktet til å fungere godt, så kan vi deretter videreutvikle V2.0 med nytt PCB, andre strømkilder etc. 

 

Jeg kan godt være med. Har kode som setter opp Wifi, parser Aidons standard-firmware og gjør resultatet tilgjengelig via key-value på REST-endepunkt. Har også en nyere versjon som også kan sette opp en MQTT-kobling og publisere verdier til MQTT.

Hvor og hvordan er det egentlig folk her ønsker å få tak i data? Key-Value på REST? JSON på REST? Subscribe til MQTT-topic? Binært over Seriell/USB?

[StenO]

4 minutter siden, frodegill skrev:

 

Hvor og hvordan er det egentlig folk her ønsker å få tak i data? Key-Value på REST? JSON på REST? Subscribe til MQTT-topic? Binært over Seriell/USB?

Før Lyse slo av porten hadde jeg også en kode kjørende som hentet Aidon native og publiserte dette på en mqtt-server. Koden har jeg forsåvidt liggende enda og kan kanskje bli (sammen med din kode) et alternativ for de Aidon-eierne utenfor Norge som ikke har noe HAN-grensesnitt å forholde seg til...

 

[ArnieO]

6 minutes ago, frodegill said:

Hvor og hvordan er det egentlig folk her ønsker å få tak i data? Key-Value på REST? JSON på REST? Subscribe til MQTT-topic? Binært over Seriell/USB?

MQTT for min del.

Endret 18. januar 2019 av ArnieO

[cpu22]

Jeg foretrekker å sende meldingene fra måleren direkte videre uten å dekode de først. Da sender jeg dem videre med MQTT. Etterpå subscriber jeg på meldingene fra et system (f.eks. OpenHAB) som gjør dekodingen. På den måten slipper jeg å endre på formatet i ESP8266, og laste opp nye versjoner der. Jeg sender fra to målere, Aidon og Kamstrup, på begge har formatet blitt endret siden jeg startet med utlesning.

[DIYglenn]

MQTT er jo veldig lett, og kanskje det beste i forhold til å senere skulle få laget en modell som ikke trenger separat strømforsyning.

 

Jeg har ikke brukt min enhet ennå, har ikke hatt tid til å holde på med dette siden i sommer, og ble allerede litt lei når jeg så at web-oppsett etc. ikke fungerte som det skulle.

Man er vel så vidt jeg også nødt til å gjøre endringer i MQTT-biblioteket for å kunne sende store nok pakker. Dette er vel noe man kan unngå om man får delt opp dataen som sendes? Det vil da igjen øke antall sendinger (som bruker mer strøm) men etter min mening er det bedre å unngå redigering av de offisielle bibliotekene for å gjøre det lettere for brukere som bare ønsker å kjøpe PCB + laste inn koden.

 

Det er også mange som kanskje ikke bryr seg om å abonnere på alt AMStoMQTT sender, de er kanskje bare ute etter strømforbruk, ikke kvalitet på leveransen.

Det er etter min mening kanskje ønskelig å derfor gjøre mest mulig av dekodingen på selve enheten.

[ArnieO]

1 hour ago, DIYglenn said:

MQTT er jo veldig lett, og kanskje det beste i forhold til å senere skulle få laget en modell som ikke trenger separat strømforsyning.

 

Jeg har ikke brukt min enhet ennå, har ikke hatt tid til å holde på med dette siden i sommer, og ble allerede litt lei når jeg så at web-oppsett etc. ikke fungerte som det skulle.

Man er vel så vidt jeg også nødt til å gjøre endringer i MQTT-biblioteket for å kunne sende store nok pakker. Dette er vel noe man kan unngå om man får delt opp dataen som sendes? Det vil da igjen øke antall sendinger (som bruker mer strøm) men etter min mening er det bedre å unngå redigering av de offisielle bibliotekene for å gjøre det lettere for brukere som bare ønsker å kjøpe PCB + laste inn koden.

 

Det er også mange som kanskje ikke bryr seg om å abonnere på alt AMStoMQTT sender, de er kanskje bare ute etter strømforbruk, ikke kvalitet på leveransen.

Det er etter min mening kanskje ønskelig å derfor gjøre mest mulig av dekodingen på selve enheten.

Enig.

 

Koden jeg bruker dekoder, og sender separate MQTT-meldinger for hver enkelt parameter. For min del er det bedre enn å sende en diger MQTT-melding f.eks. med en JSON-pakke.

Fordelen med dette er at man (i hvert fall enklere) selv kan velge bort (kommentere ut linjer i koden) parametre man ikke bruker, det vil også kunne holde strømforbruket litt nede. F.eks. vil de som ikke har solceller ha lite bruk for eksportert energi. De fleste av oss er vel også i det daglige kun moderat interessert i nettfrekvensen med desimaler. ting som strøm per fase og reaktiv energi - for eksempel.

 

Og man kan enkelt (enklere) legge til ting. Jeg ønsker å rapportere inn RSSI og temperatur fra 18B20 sensor, dette mangler foreløpig i den koden jeg bruker nå.

 

Mens vi diskuterer kode:

OTA-oppdatering av en device som trekker strøm fra MBUS vil antakelig ikke fungere, den risikerer vel å gå i brownout mens man overfører ny kode - og da sitter man jo der...

Endret 18. januar 2019 av ArnieO

[HWal]

Hvilket utstyr er det som viser nettfrekvensen?

[ArnieO]

9 minutes ago, HWal said:

Hvilket utstyr er det som viser nettfrekvensen?

Beklager, jeg husket feil. Redigerer posten ovenfor.

[StenO]

11 minutter siden, HWal skrev:

Hvilket utstyr er det som viser nettfrekvensen?

Min kode som leser "native" Aidon, har nettfrekvens, men HAN spec'en har visst ikke det...

[HWal]

Hvis jeg kunne valgt noe mer enn det som kommer ut av min Kaifa måler i dag, så hadde fasespenningene mot jord kommet på listen.