cpu22

Jeg ser at dette er en gammel tråd, men jeg lurer på hvilke vanntette reléer du har funnet, og om løsningen fungerte over tid? Jeg ser på muligheten å endre klippeområde dersom det er parkerte biler og lingnende hindringer på området.

Ja, det er mulig jeg kan spare et relé eller to. Guide-kabelen min går videre tvers gjennom "P-området" også. Det står selvfølgelig ingen ting i bruksanvisningen om dette, så det er interessant det du skriver. Jeg må vel prøve meg fram, men problemstillingen ser ut til å være akkurat det samme som ditt tilfelle.

Bra tips. Et slikt relé vil også huske siste posisjon såvidt jeg skjønner. Jeg tror ikke det trengs noen komponenter ved reléene, hvis styresignalene lages et sentralt sted.

Jo, egentlig. Kanskje det blir løsningen. Jeg hadde foretrukket å ikke bruke effekt på å holde reléet i den ene posisjonen. Men det er jo ikke mye effekt det er snakk om (tenker høyt). Enheten som styrer reléene kan huske hvilken posisjon den hadde før et evt. strømbrudd.

Jeg parkerer på gresset det robotklipperen skal klippe. Så jeg har tenkt å grave ned 3 brytere (SPDT) som endrer på grensewiren (og guidewiren) som bestemmer hvor klipperen skal kjøre. Når bilen er parkert, switcher jeg om bryterne slik at robotklipperen ikke kommer inn på området og kjører seg fast under bilen. Bryterne må få power fra en wire som også graves ned, og de bør huske sin siste posisjon etter et strømbrudd. Styringen kan være via kabel, wi-fi eller annet. Er det noen som har idéer til hvilken bryter jeg kan bruke til dette?

Med MBUS til USB kan du ta dataene inn på en PC eller Rarpberry Pi, hvis du ikke har tenkt å bygge noe som helst selv. Det gjorde jeg til å begynne med, for å undersøke datastrømmen fra Kamstrup og Aidon målerne. Jeg lagde noen enkle C-programmer for å dekode dataene. For å komme videre da, må du enten snekre noen programmer selv, eller prøve å tilbasse AmsToMqttBridge til PC/RPi. Så litt jobb må du regne med.

Jeg har brukt HW som er beskrevet lengre opp i tråden: https://github.com/gskjold/AmsToMqttBridge/tree/master/hardware/v1 Der er både skjema og alt som trengs. Dette kortet kopler sammen ESP8266 med usb og TSS721 på en ryddig måte.

Takk for tips, både @StenO og @gskjold. Jeg overså den blå linja nederst, og byggingen går fint nå. Jeg oppdaget også at det ligger ferdigkompilerte versjoner også på github. Vurderer å teste den hvis jeg ikke får opplasting av .bin fil fra VSC til å virke. Lurte forresten på output fra byggingen: Environment Status Duration ------------- -------- ------------ hw1esp12e IGNORED esp12e IGNORED d1mini IGNORED esp32 IGNORED lolind32 IGNORED featheresp32 IGNORED dev SUCCESS 00:00:53.810 Jeg hadde forventet bygging av "hw1esp12e", som er ESP-kortet beskrevet tidligere i denne tråden (eller tar jeg feil?). I stedet ble "dev" bygd. Hva er "dev"? Jeg endret [platformio] i platformio-user.ini til default_envs = hw1esp12edefault_envs = hw1esp12e og fikk da denne outputen: Environment Status Duration ------------- -------- ------------ hw1esp12e SUCCESS 00:00:55.504 esp12e IGNORED d1mini IGNORED esp32 IGNORED lolind32 IGNORED featheresp32 IGNORED dev IGNORED Det ser riktig ut for meg, så jeg prøver å laste filen ".pio/build/hw1esp12e/firmware.bin"

Hittil har jeg brukt Arduino IDE for å laste opp mine egne programmer til kortet (esp8266), men jeg ser at AmsToMqttBridge bruker Visual Studio Code (VSC) for å lage binær kode. Så jeg har lastet ned VSC og installert PlatformIO plugin og hentet koden fra gskjold/AmsToMqttBridge. Det ser bra ut så langt, jeg har også kopiert platformio-user.ini-example siden jeg har det opprinnelige kortet fra roarfred. Siden jeg ikke har brukt VSC før, så har jeg litt trøbbel med å finne ut hvordan man gjør "ting". Jeg finner "Run" kommando, men ingen "bygge" kommando for å lage binær-filer. Hvordan gjør dere det fra VSC? Laster dere direkte til kortet, eller flasher dere en binær-fil, som lages av VSC? Det hadde vært fint med en kokebok fra noen som har gjort dette før.

Takk for tipset. Jeg prøver den.

Det har vært flere forker av roarfred sin opprinnelige AmsToMqttBridge i denne tråden. Hvilken programvare er det folket bruker nå? Hva anbefales å bruke hvis jeg skal oppdatere mitt HAN ESP8266 kort.

Jeg har også en Kamstrup-måler. Times-meldingene kommer xx:xx:05, som de alltid har gjort.

Hvis målet er å se MQTT-meldinger uten å mekke et system selv, kan du bruke en MQTT broker på "nettet", f. eks. https://test.mosquitto.org/ Så kan du abonnere på meldinger derfra vha. telefonen, Det finnes et utall MQTT klienter der ute. Jeg har brukt denne: https://apps.apple.com/us/app/mqttool/id1085976398

Det er en av de første som ble lagd i denne tråden fra "roarfred", HAN til MQTT interface med ESP8266.

Jeg har masse strøm i sikringsskapet, så jeg satte inn et 5V power supply som passer DIN-skinne. Fordelene er: Du slipper å tenke ut lure måter å hente power fra M-bussen på Det er bare en kort power-ledning til HAN-interfacet, som likevel er plassert i sikringsboksen. Ut fra HAN-interfacet er det WiFi, så ingen eksterne ledninger. Koster riktignok over 100-lappen, men du slipper en del annet styr. Power supplyet er til venstre på bildet.

Jeg meldte fra om dette til min kraftleverandør, og fikk følgende svar: Hei. Det er flere kunder som har meldt i fra om dette, og Aidon er på saken for utvikling på dette. Sitat slutt. Så det kommer vel etter hvert.

Siden jeg har både Kamstrup og Aidon målere, har jeg sammenliknet data-formatene, og det er en god del forskjeller. 1) Aidon bruker odd parity, Kamstrup bruker no parity 2) OBIS-kodene er forskjellige, for eksempel er active power 01,00,01,07,00,ff på Aidon og 01,01,01,07,00,ff på Kamstrup. 3) Skaleringen er forskjellig på noen av avlesningene, f.eks. er spenningen oppgitt med 1V oppløsning på Kamstrup og 0.1V på Aidon. 4) Hvert data-record er forskjellig, f.eks. Active power På Kamstrup: 0906 0101010700FF 0600000000 På Aidon: 0203 0906 0100010700ff 06 00000552 0202 0f00 161b 5) Det er forskjellige headere (før selve data kommer): På Kamstrup: 0: 0x7e 0xa0 0xe2 0x2b 0x21 0x13 0x23 0x9a 0xe6 0xe7 0x00 0x0f 0x00 0x00 0x00 0x00 16: 0x0c 0x07 0xe3 0x03 0x04 0x01 0x16 0x08 0x00 0xff 0x80 0x00 0x00 0x02 0x19 På Aidon: 0: 0x7e 0xa1 0x77 0x41 0x08 0x83 0x13 0x39 0x1e 0xe6 0xe7 0x00 0x0f 0x40 0x00 0x00 16: 0x00 0x00 0x01 0x11 Det er bare selve OBIS-kodene som er listet i dokumentasjonen. Noen som vet hva de andre tallene er? For eksempel pkt 4 over, hva er "0203" foran og "0202 0f00 161b" etter Kamstrup sin data record? Og i punkt 5 over, hva betyr alle feltene i headeren? Jeg har fått med meg at 0x7e er et start-merke, og at de to neste bytene inneholder lengden.

Jeg brukte et TSS721A kort med serieutgang til å eksperimentere med. Jeg koplet en vanlig FTDI-kabel til serieutgangen og til en USB-kontakt på PC-en. Pass på at de har samme spenning (3.3 eller 5.0 volt) på grensesnittet. Da kan du akkessere FTDI-kabelen som en serielinje og dumpe data fra den. Litt programmering blir det når du skal dekode meldingene.

Såvidt jeg har sett, så er det ikke HDLC-protokoll selv om meldingene starter og slutter med 0x7e. Det er både 0x7d og 0x7e i måleverdiene inni selve pakken. Det er heller ikke noe bit-stuffing for å unngå mange '1'-ere på rad. Jeg har monitotert min Kamstrup-måler i over et år nå, og meldingene har alltid lik lengde, 228 bytes hvert 10. sekund, og 302 bytes hver time. Jeg har en Aidon-måler også, og fram til nå har jeg lest "u-standard" format der. Den er nå "åpnet", og jeg skal sjekke neste gang jeg har mulighet. Men når jeg ser utskriftene fra andre her, ser det ut til at Kamstrup og Aidon har noen forskjeller i formatet.

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.

Er det noen av dere som har fått produsert kretskortet med ESP8266 og TSS721A på. Hvis det finnes noen til overs der ute, kjøper jeg gjerne et par stykker.

Hei. Lurer på om det du beskriver her, er tilgjengelig i github, eller det er helt "privat"?

Jeg måtte melde meg som pilotkunde, og fikk da HAN-modulen tilsendt i posten.

Jeg har sammenliknet dette med mine logger, og det kan godt stemme. Jeg ser at jeg ikke har hatt belastning på fase 2, og derfor har jeg alltid fått 0 der. Når det gjelder byte 56-69, er dette 4 forskjellige felter: 56-59, 60-63, 64-67 og 68-69. En av de to førstnevnte (altså 56-59 og 60-63) har alltid en verdi, men aldri begge samtidig. Verdien er i størrelsesorden 40-60, og noen ganger høyere, f. eks. 368 eller 669. Kan dette være jordstrøm i negativ og positiv retning? Mener å ha hørt at de nye målerne kan måle jordstrøm også. Byte 64-67 varierer hos meg mellom 30070 og 35894. Vet ikke hva dette kan være. Byte 68-69 ligger i området 4986-6118. Av til faller den til omkring 1200-1300.

Det ser ut som du skriver ut de første 116 bytene av menldingene. Resten mangler, og du har listet starten på 4 meldinger. Jeg har sammenliknet med mine meldinger, og jeg ser ikke noe feil med dataene (bortsett fra at siste del mangler). Sjekk programmet som tar imot. Kanskje du har for lite buffer, eller noe sånt. Er FIFO enablet på UART? Bruker du samme program på RPi og PC?