Gå til innhold
  • Bli medlem

Søk i nettsamfunnet

Viser resultater for emneknaggene 'ams'.



Flere søkevalg

  • 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
  • Bruksområder
    • A/V-kontroll
    • Belysning
    • Klimakontroll
    • Overvåking
    • Sikkerhet
    • Strømsparing og strøm-overvåkning
    • Talestyring
  • Systemer
    • Domoticz
    • Fibaro Home Center
    • Futurehome
    • HDL
    • Home Assistant
    • HomeKit
    • HomeSeer
    • Homey
    • Indigo Domotics
    • openHAB
    • Sensio
    • SmartThings
    • Telldus Live!
    • Vera
    • Z-Way
    • Zipato
    • Øvrige systemer
  • Teknologi / Protokoller
    • Blåtann
    • irDA
    • KNX
    • 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

Finn resultater i...

Finn resultater som...


Startdato

  • Start

    Slutt


Sist oppdatert

  • Start

    Slutt


Filtrer etter antall...

Ble med

  • Start

    Slutt


Gruppe


System

Fant 7 resultater

  1. 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.
  2. 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. 🙂
  3. Jeg skriver en masteroppgave hvor jeg i høst har forsket på strømdataen jeg har fått fra min smartmåler Kaifa i Bergen og lurer på om noen har litt data å dele fra sin måler. I forskningen min har jeg sett på muligheten for å identifisere og klasssifisere laster i det totale forbrruket, altså dataen tilgjengelig gjennom HAN, slik at jeg kan med XX % sikkerhet si hvilket apparat som var ansvarlig for endingen i totalt forbruk (Nonintrusive load monitoring, NILM). Siden jeg har samlet inn data i Bergen, hvor jeg har vært koblet til et TT-nett, får jeg ikke så gode målinger som jeg tror er tilgjengelig om man er koblet til TN eller IT. På bildene vedlagt ser dere hvordan fasene er lagt opp og hvordan lastene viser seg på to faser i current_phase_1, current_phase_2 og current_phase_3. Det jeg lurer på er om disse induviduelle fasemålingene vil være "renere" hos en AMS som ikke bruker TT-nett. Er det noen som kan dele litt data, evt plots fra de induviduelle fasemålingene hos dere hadde det vært til stor hjelp! phases_and_circuits.pdf 2018-11-05:I1-Current phase 1,2,3 [A].pdf
  4. Usikker på hvor overrasket jeg er? Til Hafslund:
  5. 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?
  6. Moderatormelding: Denne tråden er splittet ut fra denne: https://www.hjemmeautomasjon.no/forums/topic/1982-lesing-av-ams-data-amshan-iot/?page=22&tab=comments#comment-30308 ————————— Utdrag fra https://kompetansetorget.uia.no/content/download/14871/270041/version/1/file/Bachelor.pdf side 35: Expensive hours In the close future the power companies will most certainly have changing consume prices through the day, but we do not know how this will be for sure. This is an example on how this can be solved. Since the AMS is not sending the price, the clock is our second option. The algorithm will turn off devices in low priority if the time is between 07:00 -> 10:00 or 17:00->20:00 based on the information in figure 34. The algorithm will not differentiate between weekends (left picture in figure 34) and weekdays (right picture in figure 34), but this should be implemented in a final product. Figure 34: Consumption throughout the day in Norway [3] Switch on devices When turning off a slave there is a chance that the total consume will go under the consume limit that triggered the controller to turn off the slave. For not having the problem off turning on and off a slave many times in a minute a timer is used on 5 minutes. All slaves share one timer and every time a slave is turned off the timer is started. If the timer runs out the algorithm will first check if the consume is under the preferred_consume_limit, and then search through all slaves and turn on the slave with highest priority that is in off state. If there is more slaves with same priority it will turn off the slave with the biggest temperature deviation. Consequently a slave might stay off for 5 minutes more than it has to. Dette indikerer at strømprisen variere i ganske fast syklus i løpet av døgnet. I en styring bør det da være tilstrekkelig å operere med "faste tidspunkter" for inn/ut kobling av lavt prioritert forbruk. "faste tidspunkter" i form av parameter som bruker kan endre. Eksempel: Ukedager 07:00 -> 10:00 Helg fra ca kl 09:00 -> 12:00
  7. Bronson

    AMS-målere (igjen)

    Har ikke lyst til å kuppe tråden til @roarfred, så har bare lyst til å tenke litt høyt her. Det er jo utrolig imponerende det arbeidet som blir lagt ned å for kunne lese ut den informasjonen man kan hente ut fra HAN-grensesnittet. MEN! Er det kun jeg som er overrasket at det ikke finnes noen produkter som er plug and play og kan lese informasjonen? Eller, for å si det med andre ord, er det noen som vet om noen produkter som dette kan gjøres med? Sendte en mail til Norgesnett nå nylig og fikk dette svaret: Altså, rulles det ut pallevis med målere rundt om i Norge og så har vi ikke klare produkter til å lese denne informasjonen? Drit i displayet og S0-puls, det er HAN-grensesnittet som er interessant. Hvis noen har allerede klart å hente ut koden, håper jeg det blir informert om. Både de som har klart det og vil klare det framover.
  • Medlemsstatistikk

    2 892
    Totalt antall medlemmer
    846
    Flest pålogget
    JML
    Nyeste medlem
    JML
    Ble med
×