Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

Søk i nettsamfunnet

Viser resultater for emneknaggene 'han'.

  • Søk etter emneknagger

    Skriv inn nøkkelord separert med kommaer.
  • Søk etter forfatter

Innholdstype


Kategorier

  • Generelt
    • Automasjonskaféen
    • Annen Elektronikk
    • Ditt system
    • Grafikk og design
    • Nettverk
    • Nybegynner
  • Leverandører
    • ELKO Smart
    • HeatIt
    • Namron
  • Bruksområder
    • A/V-kontroll
    • Belysning
    • Klimakontroll
    • Overvåking
    • Sikkerhet
    • Strømsparing og strøm-overvåkning
    • Talestyring
  • Systemer
    • Fibaro Home Center
    • Futurehome
    • Home Assistant
    • HomeKit
    • HomeSeer
    • Homey
    • Node-Red
    • openHAB
    • SmartThings
    • Øvrige systemer
  • Teknologi / Protokoller
    • Blåtann
    • irDA
    • KNX
    • Matter
    • Mikrokontrollere
    • MQTT
    • RF
    • xComfort
    • Z-Wave
    • ZigBee
  • Utlån, kjøp og salg
    • Prisjakt
    • Kjøp / Salg
    • Powerbuy
    • Kommersielle tilbud
    • Utlån
  • Nettstedet
    • Kunngjøringer
    • Nyheter
    • Ris, ros og spørsmål om forumet

Blogger

  • En teknologisk hverdag
  • Enda en hobby?
  • Smånytt
  • en guide til elektro-verdenen

Kategorier

  • Nyheter
    • Produkter
    • Programvare
  • Tester
    • Systemer
  • Guider
    • Fibaro
    • HomeSeer
    • Nettverk
    • openHAB
    • Z-Wave
    • ESP32

Finn resultater i...

Finn resultater som inneholder...


Startdato

  • Start

    Slutt


Sist oppdatert

  • Start

    Slutt


Filtrer etter antall...

Ble med

  • Start

    Slutt


Gruppe


System

Fant 15 resultater

  1. Har nettopp fått en ny AMS måler, og tenkte litt på å lage en dings til å putte i HAN porten for å nyttegjøre dataene herfra... Ser for meg en ESP8266 koblet til lokalt WiFi nett, men en mini m-bus krets for å lese ut data. (Har gjort noe lignende mot en Kamstrup/Zenner måler på varmepumpen) Rapportering ut til MQTT. WiFi/MQTT parametre bør være konfigurerbare Vil bruke Arduino for programkode på ESP. Fyrer opp et prosjekt på github når jeg evt. er i gang... Noen som vet om dette allerede finnes, om det burde vært gjort på et helt annet vis, el.l. så mottas alle innspill med takk
  2. Hei! Jeg har nettop startet med raspberry pi og python koding. Jeg har satt opp en pi pico til å lese data fra HAN porten på min AIDON måler. Jeg har en M-bus slave HAT og den virker greit. Dataen jeg får inn er problemet. Jeg klarer å manuelt dekode OBIS kodene til å få ut verdiene, men jeg ønsker å lage en funksjon i micropython som gjør dette for meg. Er det noen som kan vise meg veien videre? Eksempel på raw data jeg får: E6E7FF0F40FFFFFFFF01010203090601FF0107FFFF06FFFF1A8002020FFF161B18DC7E7EA10B41088313FA7CE6E7FF0F40FF Takk på forhånd!
  3. Da den andre tråden konsentrerer seg mest om hjemmelagede kort og derfor har en relativt høy terskel og er tidkrevende for å komme i gang med, tenkte jeg å lage en ny tråd der vi kan oppsummere hvordan man kan lese HAN-porten på din strøm-måler enkelt, kjapt, billig og sikkert. Det vi vet: HAN bruker helt standard M-BUS Man får kjøpt ferdige M-BUS til TTL kort (se link under) Ikke alle målere er åpnet for data på HAN selv om man har modulen (Hafslund) (Ikke 100% verifisert) Oppdatering: Det har kommet nye og enklere løsninger for de som liker å ha lokal tilgang for dataene, og ikke sende de ut på internett. Under er noen linker til dette. Alternativ 1 - esp32-basert løsning: AMS2MQTT fungerer med COTS esp32-baserte kort og et TTL til MODBUS-adapter, f.eks. https://www.aliexpress.com/item/32751482255.html. Det anbefales å bruke et galavanisk isolert kort, men en RS422/485-adapter kan også fungere. Home Assistant integrasjoner: https://github.com/toreamun/amshan-homeassistant https://github.com/turbokongen/hass-AMS Alternativ 2 - med stikkontakt og Raspberry PI i sikringsskapet: Denne løsningen og er utviklet av Per Erik Nordbø i BKK. Med denne kan du lese ut HAN data til Raspberry Pi og meldingene kan deretter logges til skjer, fil eller multicast på LAN. For å bruke dataene videre må man lage noe IFTTT og/eller MQTT etc. for å få det inn i ditt favoritt-hjemmeautomasjonsmiljø. Du trenger: HW: Raspberry Pi (lefdal, elkjøp, power etc. fører disse) http://s.aliexpress.com/iM7rQb67 Eller: https://www.aliexpress.com/item/USB-transfer-MBUS-module-slave-module-communication-debug-alternative-TSS721/32719562958.html?spm=a2g0s.9042311.0.0.c8314c4dpbv1pv Etter rapporter om at denne ikke takler lengre meldinger (kan tyde på for dårlig oscillator på mottaker-kretsen) frarådes kjøp av denne: https://www.aliexpress.com/item/Freeshipping-USB-to-MBUS-slave-module-discrete-component-non-TSS721-circuit-M-BUS-bus-data-monitor/32814808312.htm SW Armbian image et. al. fra: https://drive.google.com/drive/folders/0B3ZvFI0Dg1TDbDBzMU02cnU0Y28 Følg instruksjonene i dokumentet her. Gå til posten her og følg instruksjonene: Node-red for MQTT videre til smarthusløsningen din, følg Thomas sin oppskrift fra side 4:
  4. Noen som har fått integrert denne i sitt smarthussystem uten FutureHome-hub/app? Helst Homey da jeg benytter dette selv.
  5. Hei, Har mekka litt for å få HAN-data fra Kamstrup-måleren min (1-fas) inn i Home Assistant. Bruker ESPHome med en ESP32 for å få inn data, forsøkte med en ESP8266, men den var ikke helt glad i software serieport, derfor måtte jeg ty til 32'en. Koden er ganske stygg foreløpig, men kanskje det kan hjelpe noen andre på vei:) Parser dataen ved å lese ut OBIS-koder og så hente tilknyttede data. Ingen CRC-sjekk e.l. da dingsen min ikke ser ut til å lese korrupte data i det hele tatt så langt. Har lånt en del inspirasjon fra RoarFreds HAN-leser, selv om jeg endte opp med noe ganske annerledes etterhvert:) ESPHome-konfigurasjonsfil: esphome: name: ams platform: ESP32 board: nodemcu-32s includes: mbus.h wifi: power_save_mode: light networks: - ssid: "LulzNettOppe" password: ##PASSORD## - ssid: "LulzNettEkstra" password: ##PASSORD## - ssid: "LulzNett" password: ##PASSORD## # Enable logging logger: level: DEBUG # Enable Home Assistant API api: ota: uart: id: uart_bus tx_pin: GPIO17 rx_pin: GPIO16 baud_rate: 2400 # Example configuration entry dallas: - pin: GPIO25 sensor: - platform: dallas address: 0xEA0214808622FF28 name: "Temperature Sikringsskap" - platform: custom lambda: |- auto mbus_reader = new MbusReader(id(uart_bus)); App.register_component(mbus_reader); return {mbus_reader->wattage_sensor, mbus_reader->reactive_power_sensor, mbus_reader->amperage_sensor, mbus_reader->voltage_sensor, mbus_reader->energy_sensor, mbus_reader->reactive_energy_sensor}; sensors: - name: "AMS Wattage" unit_of_measurement: kW accuracy_decimals: 3 filters: - multiply: 0.001 - name: "AMS Reactive Power" unit_of_measurement: VAr accuracy_decimals: 0 internal: true - name: "AMS Amperage" unit_of_measurement: A accuracy_decimals: 2 filters: - multiply: 0.01 - name: "AMS Voltage" unit_of_measurement: V accuracy_decimals: 0 - name: "AMS Hourly Energy" unit_of_measurement: kWh accuracy_decimals: 3 filters: - multiply: 0.01 - name: "AMS Hourly Reactive Energy" unit_of_measurement: kVArh accuracy_decimals: 3 internal: true filters: - multiply: 0.01 mbus.h: #include "esphome.h" class MbusReader : public Component, public uart::UARTDevice, public Sensor { public: MbusReader(uart::UARTComponent *parent) : uart::UARTDevice(parent) {} uint8_t temp_byte = 0; uint8_t *temp_byte_pointer = &temp_byte; uint8_t uart_buffer_[512]{0}; uint16_t uart_counter = 0; char uart_message[550]; char temp_string[10]; char obis_code[32]; char temp_obis[10]; uint32_t obis_value = 0; float wattage = 0; float amperage = 0; float voltage = 0; float energy = 0; Sensor *wattage_sensor = new Sensor(); Sensor *amperage_sensor = new Sensor(); Sensor *voltage_sensor = new Sensor(); Sensor *energy_sensor = new Sensor(); Sensor *reactive_power_sensor = new Sensor(); Sensor *reactive_energy_sensor = new Sensor(); void setup() override { } void loop() override { bool have_message = read_message(); } bool read_message() { while(available() >= 1) { read_byte(this->temp_byte_pointer); if(temp_byte == 126) { if(uart_counter > 2) { uart_buffer_[uart_counter] = temp_byte; uart_counter++; uart_message[0] = '\0'; strcpy(uart_message, ""); for (uint16_t i = 0; i < uart_counter && i < 256; i++) { //sprintf(temp_string, "%02X", uart_buffer_[i]); //strncat(uart_message, temp_string, 2); if(uart_buffer_[i-1] == 9 && uart_buffer_[i] == 6) { obis_code[0] = '\0'; strcpy(obis_code, ""); for (uint16_t y = 1; y < 6; y++) { sprintf(temp_obis, "%d.", uart_buffer_[i + y]); strcat(obis_code, temp_obis); } sprintf(temp_obis, "%d", uart_buffer_[i + 6]); strcat(obis_code, temp_obis); ESP_LOGV("uart", "OBIS code found: %s message length: %d", obis_code, uart_buffer_[i + 7]); obis_value = 0; if(uart_buffer_[i + 7] == 6) { for(uint8_t y = 0; y < 4; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((3-y) * 8); } } else if(uart_buffer_[i + 7] == 18) { for(uint8_t y = 0; y < 2; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((1-y) * 8); } } if(strcmp(obis_code, "1.1.1.7.0.255") == 0) { ESP_LOGV("uart", "Wattage: %d", obis_value); wattage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.31.7.0.255") == 0) { ESP_LOGV("uart", "Amperage: %d", obis_value); amperage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.32.7.0.255") == 0) { ESP_LOGV("uart", "Voltage: %d", obis_value); voltage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.1.8.0.255") == 0) { ESP_LOGV("uart", "Energy Usage Last Hour: %d", obis_value); energy_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.7.0.255") == 0) { ESP_LOGV("uart", "Reactive Power: %d", obis_value); reactive_power_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.8.0.255") == 0) { ESP_LOGV("uart", "Reactive Power Last Hour: %d", obis_value); reactive_energy_sensor->publish_state(obis_value); } else { ESP_LOGV("uart", "Unknown OBIS %s, value: %d", obis_code, obis_value); } } //strncat(uart_message, " ", 1); } ESP_LOGV("uart", "%d length received", uart_counter); //ESP_LOGI("uart", "%d length received: %s", uart_counter, uart_message); ESP_LOGV("uart", "Message length: %d", uart_message[3]); uart_counter = 0; uart_message[0] = '\0'; strcpy(uart_message, ""); } else { uart_counter = 0; } } uart_buffer_[uart_counter] = temp_byte; uart_counter++; } return false; } };
  6. Edit 23-04-2022: Dette ble egentlig skrevet som et svar i en annen tråd, men moderator la det inn som egen tråd i ettertid. * Jeg holder på med å bruke opp noen kort fra rundt 1990 nå som dukket opp blant mye annet rart. Lagret i kjeller. Funker fint, men krever litt mer belysning. Hvis lakken din er Positiv 20, er det gunstig å få litt hjelp av varme. 1 stk leselampe av gammel modell. 60 W er bra. Ei passe stor metallplate som varmespreder som ligger oppå lampa. Spray på lakk Legg et par lister som avstandsstykker og ei ny plate på toppen som lyshinder. Tenn lampa og vent 15-20 minutter. Da flyter lakken fint og jevt ut, og den tørker fort. Støv når du sprayer er det største problemet. Databladet for Positiv 20 sier ca. 15 min og 70 grader. http://www.crceurope.com/wwwcrc/tds/TKC3 POSITIV20/css/TKC3 POSITIV20.htm Dette er slik vi gjorde for 40 år siden før vi fikk råd til å kjøpe ferdiglakkerte kort. Bildet viser siste rester av en boks som gikk ut på dato 11.88. Ble litt frynsete i kantene, men det er ikke så merkelig når det er mer enn 30 år på overtid. Dette var for ett år siden.
  7. Vurderer å kjøpe futurehome sin strømmåler. Er det noen som kan si hvilke funksjoner jeg får med den utenom å se forbruk kan jeg sette automatisjon på rele hvis forbruk er under x antall kw eller motsatt? varsler om høyt forbruk? hvis jeg heller velger tibber pulse, kan moduser automatiseres av lav/høy strømpris?
  8. Hei alle sammen! Etter at jeg har lest gjennom en del poster på forumet her rundt lesing/dekoding av data fra AMS HAN-porten har jeg begynt å lure på hvor sensitiv målepunkt-ID-en er. Hvis man kobler den sammen med navn på abonnent og adresse er det sannsynligvis relativt sensitivt, men hvis den står alene i en binærdump, hvor mye skade kan en ondsinnet person gjøre hvis de har kjennskap til en målepunkt-ID? Grunnen til at jeg spør er fordi jeg har laget en dekoder[1], og jeg tenkte at det kunne være nyttig å legge ved eksempler på dump-filer fra forskjellige målere. Men hvis kjennskap til målepunkt-ID kan brukes til noe (f.eks. bestille eller avslutte tjenester som koster penger) uten å kjenne navnet på abonnenten tenker jeg at de ikke burde gjøres tilgjengelig på internett. Jeg leste et eller annet sted at NVE sammenligner målepunkt-ID med personnummer, og skatteetaten sier at personnummer ikke er sensitivt, men det er personopplysninger. Folk flest gir ikke fra seg personnummeret sitt til hvem som helst som spør om det, selv om skatteetaten sier som over. Jeg vet at målepunkt-ID består av landskode, kraftverk-ID, løpenummer og kontrollsiffer, som i seg selv ikke kan identifisere brukeren direkte. Så i bunn og grunn, hvis man har en målepunkt-ID, hva kan man gjøre med den? 1: https://github.com/robinsmidsrod/ams-han-decoder
  9. Jeg har hatt litt mailkorespondanse med med Eidsiva Nett om å få åpnet HAN-porten på min AMS-måler. Nå er det tydeligvis bare å smøre seg med tålmodighet.
  10. Da har jeg fått installert det meste på en litt eldre raspberry. Koblet til USB-MBUS slave modul, følgt guiden jeg fant her til å sette opp influxdb, grafana og node-red. Når jeg kjører test_rx fila i han-port mappa får jeg dette: root@raspberrypi:/home/pi/src/han-port# ./test_rx num args: 1 read serial: 1 read socket: 0 read file: 0 write file: 1 serial_device: /dev/ttyUSB0 fname: empty key: host: undefined port num: 10001 decrypt: 0 open_serial OK: 4 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 cc 02 02 0f 00 16 1b 9e ca 7e Date Time: , Items: 0 Leste i en annen trår her at på Aidon måler fungerer et python script til å gjøre samme jobb. Men her fikk jeg ikke helt rette verdier tror jeg: ./aidon_test.py /dev/ttyUSB0 {'p_act_in': 1046} {'p_act_in': 1036} {'p_act_in': 1032} {'p_act_in': 1032} {'p_act_in': 1052} {'p_act_in': 1040} {'p_act_in': 1040} {'p_act_in': 1050} {'p_act_in': 1050} {'p_act_in': 1066} {'p_act_in': 1076} {'p_act_in': 1052} {'p_act_in': 1052} {'p_act_in': 1062} I node-red står det bare å blinker "connecting" under alle AMS boksene. Noen som har fått til Aidon målerene som Lyse bruker, som kan hjelpe litt?
  11. Hei! Min første post :) Jeg har koblet til noe utstyr på HAN-porten og observerer noe rart: ca en gang i halvtimen leses det av veldig høye effektverdier i korte tidsrom. Opp til > 40 kW i 5 sekunder, ned til 5kW i 5 sekunder og opp til > 40kW igjen. Dette varer i ca 5 minutter før effektverdien stabiliserer seg på normalt nivå igjen. Er dette normalt?? Jeg bruker en TSS721 til MBUS->TTL, leser av med en nRF52832, sender til Raspberry Pi og parser data med han-port fra BKK. Har en Kaifa MA105H2E AMS. Eksempel output fra han-port og screenshot fra grafana vedlagt. han-port_output.txt
  12. Usikker på hvor overrasket jeg er? Til Hafslund:
  13. Jeg har en Kamstrup AMS fra Norgesnett med åpen HAN-port. For å lese disse DLMS OBIS datapush-meldingene har jeg en USB-til-MBUS-slave-modul koblet til en Raspberry Pi. Jeg skrev noen få linjer med Python for å skrive ut meldingene som kommer, og dette ser i utgangspunktet ut til å fungere stabilt og som forventet. Det jeg lurer på er om noen kan hjelpe meg å tyde/forklare meldingene til meg, fordi de later til å være mye kortere (145-160 bytes) enn det jeg har sett eksempler på her på forumene. Etter å ha lest hundrevis av meldinger og side opp og side ned her inne + lest kode og eksempeldata på spesielt https://github.com/roarfred/AmsToMqttBridge/ så skjønner jeg bare ikke hva det er med meldingene jeg får. Meldingene kommer hvert 10. sekund som forventet, og hver time kommer det en bittelitt lenger melding (den også mye kortere enn forventet). Det er som om OBIS-kodene ikke er med i meldingene. Start og slutt med byten E7 er alltid til stede og CRC for hvertfall header har stemt de gangene jeg har sjekket den. Her er eksempler på noen meldinger jeg får: 2019-01-20T21:50:11.195980 - 155 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFBFE06C006E006F089C7FE74080600F80906F13AC60600FC4A6414DF100600FC89C7FE12C0BD4250B8FF3BE61200EB090601E1901200EB11CB7E 2019-01-20T21:50:21.194220 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126D18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFFFF06C006E006F00906F17408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FCFF12C02FC8505807FC1200EC090601F1D81200EE88D47E 2019-01-20T21:50:31.194745 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126F4800080FBB6FE682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017EF10A1236383431313331424E323433313031303430090681F9FF0680FF06C006E006F00906C1FF7408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FC12C02FC8505CFF07FC1200EC090601F1D81200EE13D47E 2019-01-20T21:50:41.189758 - 156 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A58000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FF96C828FF06C0FF06E006F089C7FE74080600F80906F13AC40600FC4A6414DF100600FCFF12C02FC85058FF3BE61200EC090601F1D81200EB3DC07E Hvis jeg tar f.eks. den siste meldingen over og bruker mye av kunnskapen fra https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/readme.md og https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md så tolker jeg det som noe slikt som under. Jeg har brukt linjeskift ved de typiske separatorene bare for å prøve å finne mønster, men det vil nok ofte være helt feil ettersom jeg ofte ikke får ting til å stemme med "02 - one byte following 06 - long (4 bytes / 32 bits) 12 - int (2 bytes / 16 bit) 09 - string, first byte is length (could it be a byte array?) 0A - string, first byte is length" uansett. 7E <-- Frame Start flag A <-- 4 bits, A = Frame Format Type 3 0E2 <-- 12 bits, Frame size: 0xE2 (226 bytes!?, excluding start/end flags) 2B <-- Destination Address 21 <-- Source Address 13 <-- Control Field 239A <-- Gyldig CRC-16/X-25 E6 <-- Destination LSAP E7 <-- Source LSAP 00 <-- LLC Quality 0F <-- Information, n*8 bits? 0000F8BF60D95 <-- Hva er dette? Ofte(?) likt 09 12 6A58000F0FF682A566B1797AE17AE650582828A4A641428FE 0A 1135372036353627323132343834373536 <-- Gyldig målernummer i ASCII (NB: jeg endret noen sifre her, så evt påfølgende checksum vil feile) 09 06 01017CF1 <-- Hva er dette? Alltid likt 0A 12 36383431313331424E323433313031303430 <-- Alltid likt = ASCII 6841131BN243101040 <-- 684113 = måler-type 09 06 81F9FF 06 80FF96C828FF 06 C0FF 06 E0 06 F089C7FE7408 06 00F897C8287E 09 06 F13AC4 06 00FC4A6414DF10 06 00FCFF 12 C02FC85058FF3BE6 12 00EC <-- 236 (Volt? (L2?)) 09 06 01F1D8 <-- Hva er dette? 12 00EB <-- 235 (Volt? (L3?)) 3DC0 <-- Checksum? 7E <-- Frame End flag Oppsettet for avlesingen er slik jeg hadde forventet det å være: ser = serial.Serial( port='/dev/ttyUSB0', baudrate=2400, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS, timeout=10) Håper noen har noen tips eller innspill til meldingene. ?
  14. Jeg har kikket litt på denne disse trådene for lesing av HAN. Jeg har endt opp med å bruke en ferdig M-Bus til TTL modul fra aliexpress koblet til en ESP-8266 ESP-01 versjonen med RoarFred sin Arduino kode: https://www.aliexpress.com/item/TSS721-Module-Board-M-BUS-To-TTL-with-RX-TX-Indicator-STM32-Development-Board-Free-Shipping/32751482255.html Dette fungerer feldig fint på det korte meldingene med kun Power(W) sendingene fra HAN koblingen, men når de lengre meldingene med strøm/spenning så feiler 1/3 av meldingene av å bli lest av ESP modulen. Jeg har aldri fått lest kWh meldingene fra HAN koblingen. Etter å ha sjekket litt med oscilloscope så fikk jeg se dette som er på bildet: Her ser vi øverst signalet direkte på HAN koblingen (M-Bus). Nederst TTL singalet ut fra M-bus til TTL konverteren. Her ser det ut som at konverteren ikke klarer å lage TTL signalet mot slutten av meldingen. Mot slutten så halveres spenningen på signalet fra 5V til ca 2.2v. Dette er litt for lavt for at ESP modulen detekterer signalet. Er det noen der ute som kan gi meg noen tips på hva jeg kan sjekke for å få konverteren til å fungere ordentlig?
  15. Trønderenerginett åpner HAN-porten, men hvilket utstyr skal man koble til? Hva har folk på forumet her koblet til som virker og logger data ett sted? Har Z-Wave-enheter fra før - så topp om det er kompatibelt - men ikke noe krav.
  • Medlemsstatistikk

    7 014
    Totalt antall medlemmer
    1 891
    Flest pålogget
    haugeSander
    Nyeste medlem
    haugeSander
    Ble med
×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.