Er dette ment for en esp8266 eller 32?

[erazor666]

Driver å sysler litt med HAN lesing og kom over dette repoet. Det stod på forumet, hjemmeautomasjon.no at denne kun virket for esp32. Den bruker da esp8266wifi biblioteket? Jeg får den til å verifisere og flashe på en 8266 (wemos) men får ikke verifisert for esp32. Den starter og gjør litt på en 8266, kobler seg til mqtt osv. Men det kommer ikknoe data annet enn at den har koblet seg til. Jeg er klar over at den angivelig må restartes etter 10 dager osv. Jeg er bare ute etter å se noe som virker i det hele tatt. Vært å rota ganske mye rundt på forker av Roarfreds kode uten å egentlig få noe til å virke.

Den begynner å spørre etter queue.h og userconfig.h blant annet når jeg skal verifisere den for esp32. Det hadde vært fint om disse forkene fikk lastet opp alle nødvendige biblioteker sammen med koden for å slippe å være detektiv med dette. Har du mulighet til å laste opp de eksakte bibliotekene du bruker?

[alekslt]

Hei, ser jeg muligens har pusha en mellomversjon av esp8266 og esp32. Gikk litt raskt i svingen forleden kveld når jeg skulle ha ut dette. Var nok i prosessen med å teste mellom ESP8266 og ESP32. En viktig bit for at det skal fungere på esp8266 er at seriell-porten settes opp riktig.

Om du endrer i setupHAN() linja: hanPort = &HSerial1; til å være hanPort = &Serial; og deretter utkommenterer Serial.swap() (gitt at du bruker f.eks. nodemcu hvor usb-seriell-adapteren er koblet rett mot serial0-tx/rx-pinnene. Så blir det nok litt mer action. Med serial.swap() så redirecters uart0 på esp8266 til GPIO15 (TX) and GPIO13 (RX). Uten denne swappen fikk jeg store mengder bit-errors.

Jeg innser også nå at jeg ikke har vært helt ryddig med å definere de eksterne bibliotekene jeg bruker. NTPClient og PubSubClient.

Jeg får ikke gjort noe med koden akkurat nå da det er leggetid, men tidligst i morgen kveld, evt lørdag så skal jeg få tatt en gjennomgang og fikset opp. Ender vel opp med at jeg da lager noe som compiler og fungerer på både esp32 og esp8266 uten manuell fikling.

Takker for interesse og beklager for litt halvferdig opplegg her.

[erazor666]

Ikkenoe problem med tilstanden, jeg har vært borti lang mer "grisete" saker ;-) Det var bare litt forvirrende det som stod i forumet kontra det jeg opplevde/oppdaget i koden. Jeg bare sysler litt med dette for moroskyld, kommer nok en tibber pulse en av dagene. Men uansett vært tilfredstillende å sett det funke. Om man ikke trenger å laste opp bibilotekfilene i seg selv er det sikkert fint med linker til der du lastet dem ned, eventuelt versjonsinfo ol. Det er styggelig mye versjoner og forker av ting, blir fort litt lost i det hele. Det kan være litt frustrerende å bruke tiden man skulle brukt på å grave i kode eller forbedre på å lete etter riktige biblioteker da det egentlig ikke er så produktivt i seg selv :D

[erazor666]

Da ble det vel mer saker enn jeg har sett siden jeg begynte å sysle med dette iallefall. Jeg har en sånn sak koblet til en Wemos D1 mini.

bruker: WEMOS TSS721 3.3v -> VIN G -> GND D7(GPIO13) -> TXD D8(GPIO15) (ikke koblet til for øyblikket, det stoppet å komme meldinger når den var på)

Også gikk det ikke å flashe ESPen når det var tilkoblet noe på D7 & D8 av en eller annen grunn. (har ESPen noe behov for å sende noe TIL mbus egentlig?)

Får en masse sånne meldinger i MQTT iallefall, det hele er litt nytt for meg så jeg vet ikke om dette er riktig eller galt 😄

EDIT: ser for meg ut som den bare sender øyeblikksvserdiene? er det forventet? Aidon, åpen HAN, Eidsiva

[alekslt]

Se der ja. Der får du meldinger fra HAN-porten hele veien igjennom. value under obis-topicet skal da inneholde liste1-obismelding-nåværende strømforbruk. Det er mulig D7 er koblet mot flash uten at jeg helt husker det, som låser flashing. Har brukt OTA-flashing på de jeg har i stor grad. ESPen skal ikke ha behov å sende noe til MBUS/strømmåleren, og som du merker så setter heller ikke mbus eller strømmåleren særlig pris på kommunikasjon mot den, så er bare å droppe å koble opp den pinnen.

Liste 1 kommer jo ca en gang hvert 2-3 sekund. Liste 2 hvert 10ende sekund og Liste 3 hver time (med akkumulerte verdier osv)

Alle listene/meldingene skal sendes ut per default.

Jo lengre listene er jo mer fare for bitfeil er min erfaring. Har testa på den overgangen du hadde og det var merkbar forskjell på kabellengde og om jeg hadde lodda fast kabler vs bare å plugge de og håpe på mekanisk kontakt.

Debug-topicet vil inneholde melding som sier noe om at det var checksum error. Om du får en slik melding hvert 10nde sekund så må du revurdere hvordan du har koblet alt dette sammen.

Her er for øvrig en node-red flow som 1. buffrer opp meldingene i en liste og lagrer til influx. og 2. sjekker debug-meldingen etter checksum error som kan indikere noe annet feil. https://gist.github.com/alekslt/ac45e4b55401e341692849f303cdca91

[erazor666]

Den har da funka gjennom hele dagen i dag, og den spytter stadig ut medlinger, jeg har ikke sett noe til den hver 3. time meldinga men det er jammen ikke lett å finne den i alt rotet som mqtt'n inneholder heller ;-)

Jeg har en 20m (mbus takler visstnok 350m) lang cat 5 fra sikringsskapet til mekkerommet mitt da det er på soverommet til jentungen og mora blir ikke særlig happy om jeg driver å mekker der om natta har jeg skjønt. Så går den tpen inn i den TSS721 saken og så vanlige breadboard kabler til espen i andre enden. Det er bare festet kabler med skrukoblinger foreløbig, og ganske tynne skrøpelige sådan men det har funka så langt. Er nok absolutt fint å ta inn den flowen til node red ja. Håpløst å sitte å følge med på MQTT.

Jeg har sett en sjelden gang den feil i checksum meldinga, men ikke mange ganger. So far so good. Dette er det første av alle de forkene som har vært laget jeg har fått til å virke og den ser da ut til å virke helt fint. Bruker home assistant som system i huset, så tenkte å lage opp et par sensorer og kanskje prøve på et dashboard i grafana. Jeg hadde sånn som telte antall blink på strømmåleren før, det funka sånn "ok'ish" men det er langt ifra dette her. Jeg er skikkelig amatør på node red så håper den funker as-is :D

[AageEilertsen]

Hei, Takk for et godt prosjekt! Fikk nå kompilert koden din på en NodeMCU, og tenkte å få de overført til HomeAssistant, men først... Har du en tegning av koblingsskjemaet med komponenter som inngår i løsningen din? Skulle gjerne sett om jeg kobler riktig og har nødvendig MBUS-TTL-komponenter m.m...

[alekslt]

@AageEilertsen Det er bare snakk om to brett/komponenter i løsningen her. ESP32 / ESP8266 og så en TTL<->MBUS adapter. Siden vi bare mottar data så trenger vi bare receive fra adapteren. - Har nå også oppdatert Readme.md | forsiden på samme informasjon om kabling som nevnt i dette issuet.

Siden vi trenger en UART med støtte for even-parity må vi bruke den eneste hardware-serialenheten på ESP8266, mens på ESP32 kan vi velge en annen ledig.

Siden du nevner NodeMCU uten å spesifisere ESP8266 eller ESP32-utgaven så regner jeg med det er førstnevnte i NodeMCU 1.0/v3-varianten. Her må/bør vi remappe UART0 fra pinnene som normalt sett er koblet til USB-Seriell til de alternative slik at vi reduserer biterrors.

Så for ESP8266 så vil vi treffe følgende linje i koden.

hanPort = &Serial; hanPort->begin(2400, SERIAL_8E1); hanPort->swap();

Sistnevnte gjør at istedenfor GPIO1(TX) og GPIO2(RX) så bruker vi GPIO15 (TX2) and GPIO13 (RX2) som bør være nabopinneparet. Ref:

Laster over koden nå på en NodeMCU og tester med den + tar noen bilder. Gjorde noen småendringer knyttet til valg av serieport i ESP32 og ESP8266, samt med conditional for debugging. Håper disse gjør det noe enklere å forstå flyten for nye øyne.

Som du ser på den adapteren nedenfor så sender den data ut på RXD inn på RXD2 på ESP8266. Du vil ha D7/RXD2 på ESP8266-siden, mens det kan være fabrikanten av MBUS-TTL adapteren har vært fleksibel med hva de bruker om TX/RX så du kan prøve å bytte om på den der om du ikke får data.

Kobling på HAN-TTL-Adapter

Kobling på NodeMCU

Kobling på ESP32 Devkit V1

[AageEilertsen]

@alekslt Takk for oppdatering. Jeg har kommet et godt steg videre, og får nå kompilert og kjørt alt, -utenom å få lest HAN-meldingene... Får bare melding om at den rebooter om 60sek, siden den ikke har mottatt noen melding på porten.

Jeg benytter et opplegg likt @erazor666 , med denne MBUS_TTL-komponenten https://www.aliexpress.com/item/TSS721-Module-Board-M-BUS-To-TTL-with-RX-TX-Indicator-STM32-Development-Board-Free-Shipping/32751482255.html Og jeg har en NodeMCU v.2...

Gir meg ikke enda... :)

[alekslt]

i

@AageEilertsen Hei, jeg har den adapteren selv og har kjørt løsningen fungerende med den. Jeg derimot å teste ut en alternativ adapter hvor jeg fastlodda noen kabler for å se om det reduserte bit-errors.

Det du må være obs på med den mbus-ttl adapteren er MB_A "låsepostene" på HAN-siden er koblet sammen. Så når du kobler i kabel fra sikringsskapet så skal det være på både MB_A og MB_B.

Ellers tror jeg TX faktisk er merket riktig (og med pil "ut" fra adapteren på denne.

Ellers - for å være sikker. Du har en Aidon-måler? For jeg har ikke fått kodet inn støtte for Kamstrup eller Kaifa enda. I en av de senere comittene har jeg dog begynt å bryte ut logikken for å håndtere de formatene.

[AageEilertsen]

Hei, -takk for veldig god oppfølging. Jeg har en Aidon-måler. Slik jeg forstår deg, så skal ledning 1 inn på MB_A, og samme signal videreføres til MB_A2, og samme med MB_B, og MB_B2. Se tegningen min, der jeg prøver å beskrive hvordan jeg tenker å løse det.

[alekslt]

Hei, -takk for veldig god oppfølging. Jeg har en Aidon-måler. Slik jeg forstår deg, så skal ledning 1 inn på MB_A, og samme signal videreføres til MB_A2, og samme med MB_B, og MB_B2. Se tegningen min, der jeg prøver å beskrive hvordan jeg tenker å løse det.

@AageEilertsen Det er korrekt forstått ut i fra hva jeg prøvde å si ja :). Så når du har koblet slik så vil LED-lampa nær MB_B lyse opp når du får meldinger fra HAN-porten, og sånn sett indikere at du får meldinger inn.

[AageEilertsen]

Det løste oppgaven å koble MBUS-adapteren slik du beskrev, og vist i bildet over. Nå strømmer det inn med MQTT-meldinger. Skal nå jobbe med å hente ut verdier fra MQTT-meldingene, og gjøre de om til sensor-verdier som skal vises i HomeAssistant, ref https://www.nek.no/wp-content/uploads/2018/11/Aidon-HAN-Interface-Description-v10A-ID-34331.pdf

Takk for veldig god hjelp!

[AageEilertsen]

Hei igjen, Verdiene vises nå i HomeAssistant, -lest fra MQTT, -ikke lagt tid på å formattering av verdiene, samt noe høyt timeforbruk :)

Jeg sliter med at NodeMCU (v2), som er koblet til HAN-porten, henger etter 1-6 timer, -usikker på hvorfor. Jeg har derfor bestilt en ESP32 for å se om dette kan gi en mer stabil løsning.

[alekslt]

Det er noe som trigger et heng i koden ja. Tror det går på at den får noe feil på kommunikasjonen og så henger den istedenfor å reconnecte. Issue #2 er laget for å spore dette problemet. Jeg har lagt til en hardere timer-basert watchdog for ESP32, men har vært litt på reise siste tiden så har ikke fått implementert og testet ordentlig for samme path/logikk på ESP8266. Trenger en ukes tid til med driftstid på ESP32-løsningen før jeg kan være sikrere på at det er mitigert greit nok med recovery og restart. Skal uansett se om jeg får implementert det samme for ESP8266 i helgen.

Når det gjelder timesforbruket må jeg innrømme at jeg ikke har sjekket over så grundig om jeg skalerer times-målingene. Det er en code-path jeg har på INT32-type jeg ikke har verifisert /og aktivert. Skal være raskt å få på plass.

[AageEilertsen]

Hei igjen, Har du hatt mulighet å se på timesverdiene, og formatteringen på disse? Som du ser på skjermbildet jeg sendte i sist post, så er timesverdiene veldig høye... Her er MQTT-settings for den øverste timesverdien:

• platform: mqtt name: "Cumulative hourly import pos Q1Q4" state_topic: "kdg/sensors/powermeterhan/obis/1.0.1.8.0.255/value" unit_of_measurement: "Wh"

[alekslt]

@AageEilertsen Hei, dette gikk litt i glemmeboka. Har sjekket opp mer nå.

!!EDIT!! Flyttet opp. Sjekket opp litt hva jeg har registrert på denne verdien og da ble det litt mer tydelig.

Det er såklart total kumulativ telling, men fra tidenes morgen uten reset. - også kjent som måleverdien, den vi leste av i gamledager :) Bekreftet den ovenfor nå og måleren min står på 11276kWh.

Målingen fra HAN var 1127661 før skalering 11276610 etter.

Mao litt dårlig formulering i standarden fra Aidon der. De mener tydelig at det er en kumulativ teller som oppdateres per time.. Ikke kumulativ per time som så blir nullstilt...

---

Problemet er at det virker tilsynelatende å være korrekt parsing av de kumulative verdiene om det skal brukes samme logikk som på andre like. (Dvs, bruk av scaler for å gange opp eller dele ned verdien - typ flytte komma).

Om vi tar timesforbruk jeg hadde tidligere en gang i feb fra hafslund, så sier de 2.04kWh = 2040Wh

Samme melding over HAN-port sier. UINT32: 795627 Om vi også følger scale:1 så får vi da 7956270 Denne verdien virker også å stemme med andre har fått/har i sin test data.

Slik jeg leser standarden fra Aidon så skal vi skalere opp. Eneste som er litt suspekt er at de også sier det er to desimaler (se nedenfor. xxxxxx.xx kWh) Kan være det må noe manuell parsing til for å både skalere opp, men deretter få decimal-verdiene.

Har også sett f.eks. skagmo i sin kode bare delte opprinnelige tallet på 100. Etter oppskalering vil det si at vi måtte dele den ovenfor på 1000. Mao. 7956270 / 1000 = 7 956.27. Ikke at dette tallet gir meg ‬

Standard

16 Active energy import, with resolution of 10 Wh, Format 7.2 ( xxxxxxx.xx kWh)
17 Active energy export, with resolution of 10 Wh, Format 7.2 ( xxxxxxx.xx kWh)
18 Reactive Energy import, with resolution of 10 Varh, Format 7.2 ( xxxxxxx.xx kVArh)
19 Reactive Energy export, with resolution of 10 Varh, Format 7.2 ( xxxxxxx.xx kVArh)

Dekodet timesmelding

<Structure Qty="2" >
          <!--0.0.1.0.0.255-->
          <OctetString Value="0000010000FF" />
          <!--2019-02-09 22:00:00-->
          <OctetString Value="07E3020906160000FF000000" />
        </Structure>
        <Structure Qty="3" >
          <!--1.0.1.8.0.255-->
          <OctetString Value="0100010800FF" />
          <UInt32 Value="795627" />
          <Structure Qty="2" >
            <Int8 Value="1" />
            <Enum Value="30" />
          </Structure>
        </Structure>

[AageEilertsen]

Hei, Nå begynner verdiene å gi en mening. Jeg gir lyd fra meg når jeg har fått implementert en løsning for skaleringen :) Takk for hjelpen!

[AageEilertsen]

Kontinuerlige verdier tikker inn jevnt og trutt, men timesverdier er dessverre veldig sporadisk at jeg mottar. Har mottatt en ESP32 nå, skal prøve å kompilere koden på denne, og se om det gir bedre resultat... Kode for å vise formattert MQTT-verdi i Home-assistant:

• platform: mqtt name: "Cumulative hourly import pos Q1Q4" state_topic: "kdg/sensors/powermeterhan/obis/1.0.1.8.0.255/value" value_template: "{{ (value | int)/1000 }} unit_of_measurement: "kWh"

[alekslt]

@AageEilertsen Jeg opplever signalkvaliteten er litt følsom på kabellengde og kvalitet. Det er tvilsomt at strekket fra MBUS-TTL adapteren bør ha noe signifikant påvirkning her med mindre der er snakk om ekstremt dårlig kabelkvalitet. Mellom MBUS-TTL og ESPen derimot så er spenningen mye lavere og jeg har opplevd forskjellig bit-error rate basert på koblingstype (og adapter).

Skal gjøre litt grundigere tester og se om jeg kommer frem til noe som kan hjelpe, men tror nesten løsningen vil være å minimere avstand mellom ESP og MBUS-TTL adapter og lodde begge sider. Kan håpe det er noe som kan fikles på i software, men får se.

Nedenfor er for øvrig bit-error raten jeg observerer nå.

[ingarlyso]

Dette oppsettet fungerer supert @alekslt . Har satt opp raspberry pi 3 med ESP8266 NodeMCU og TTL<->MBUS adapter. Problemet er bare at det kun er 30mA tilgjengelig fra Aidon måler. Jeg er ganske ukjent med programmering så her trenger jeg hjelp. Ønsker å bruke et batteri og lade dette med de 30mA. Er det mulig å legge inn deepsleep i denne koden slik at ESP mottar data f.eks en gang pr 5 min så så går tilbake til sleep ? På denne måten slippe ekstra strømforsyning til ESP i sikringsskapet ? Mulig ?

[alekslt]

@ingarlyso flyttet som du ser oppfølgingen av dette punktet inn i et eget issue.