Gå til innhold
  • Bli medlem

roarfred

Medlemmer
  • Innholdsteller

    336
  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    7

roarfred vant dagen sist Mars 21

roarfred hadde mest likt innhold!

Nettsamfunnsomdømme

123 Excellent

Om roarfred

  • Rang
    Avansert medlem

Hjemmeautomasjon

  • System
    Fibaro Home Center
    openHAB

Nylige profilbesøk

Blokken for nylige besøkende er slått av og vises ikke for andre medlemmer.

  1. roarfred

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

    Når jeg har fått tenkt meg litt om så er nok ikke dette helt ideell måte å gjøre det på. Utfordringen er at vi i praksis snakker om en annen måler her, selv om fabrikaten er Kamstrup. ListID er slett ikke noen ID, men faktisk et tall som angir antall elementer i listen. Om Kamstrup kommer med flere modeller etterhvert, så er det stor sjans for at vi kan få en annen modell som har samme antall elementer i listen, men andre felter/rekkefølge. Det bør dermed lages en spesifikk implementasjon per modell-nummer (evt. også per firmware, men det får vi se etterhvert) Enn så lenge, så var det ingen like antall her, så det eksemplet jeg sendte funker sikkert godt nok til en test
  2. roarfred

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

    De to listene vi har definert i dag er hhv 0x19 (25) og 0x23 (35). Om vi fjerner spenning og strøm på L2 og L3 blir det fire elementer og fire til for OBIS kodene, dvs. 8 til sammen. 25-8 = 17. Føler vi er inne på gjetting-basert-programmering her nå, men det er kanskje verdt et forsøk å legge inn to nye lister på Kamstrup for disse og se om det funker? Sånn røfflig noe slik: enum class Kamstrup { List1 = 0x19, List2 = 0x23, List3 = 0x11, List4 = 0x1B }; enum class Kamstrup_List1 (...) enum class Kamstrup_List2 (...) enum class Kamstrup_List3 { ListSize, ListVersionIdentifier, MeterID_OBIS, MeterID, MeterType_OBIS, MeterType, ActiveImportPower_OBIS, ActiveImportPower, ActiveExportPower_OBIS, ActiveExportPower, ReactiveImportPower_OBIS, ReactiveImportPower, ReactiveExportPower_OBIS, ReactiveExportPower, CurrentL1_OBIS, CurrentL1, VoltageL1_OBIS, VoltageL1 }; enum class Kamstrup_List4 { ListSize, ListVersionIdentifier, MeterID_OBIS, MeterID, MeterType_OBIS, MeterType, ActiveImportPower_OBIS, ActiveImportPower, ActiveExportPower_OBIS, ActiveExportPower, ReactiveImportPower_OBIS, ReactiveImportPower, ReactiveExportPower_OBIS, ReactiveExportPower, CurrentL1_OBIS, CurrentL1, VoltageL1_OBIS, VoltageL1, MeterClock_OBIS, MeterClock, CumulativeActiveImportEnergy_OBIS, CumulativeActiveImportEnergy, CumulativeActiveExportEnergy_OBIS, CumulativeActiveExportEnergy, CumulativeReactiveImportEnergy_OBIS, CumulativeReactiveImportEnergy, CumulativeReactiveExportEnergy_OBIS, CumulativeReactiveExportEnergy };
  3. roarfred

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

    Syntes ikke dette så helt galt ut... Riktig at du mangler en E7 for avslutting, men ta en kikk på disse to sidene for å se om du ikke også har målerdata innimellom alt annet hos deg: https://github.com/roarfred/AmsToMqttBridge/tree/master/Samples/Kamstrup https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md
  4. roarfred

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

    Dette er nok riktig sted å begynne da: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical/HAN_ESP_TSS721 Her finnes også komponentliste med direkte linker til digikey. ESP er mulig ikke tilgjengelig her, men kan finnes på eks. ebay, banggood, aliexpress, kjell&co el.l. til en billig penge PS: Merk at det også finnes ferdige moduler å få kjøpt om du heller ønsker det, se evt. tråden "The easy way":
  5. roarfred

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

    Ser de forer en Raspberry Pi med denne. Hvis du vil ha kablet ethernet, så er det ikke noe dårlig alternativ å kjøre en sånn mbus konverter rett inn på en I/O pinne eller inn på USB på en Pi. Heller ikke prismessig...
  6. roarfred

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

    Ingen dumme spørsmål! Utfordringen i dette tilfellet er at kretsen baserer seg på en ESP8266 der en får en liten arduino med WiFi for 3-4 dollar. I de fleste tilfeller er det kanskje også mer tilgang på strøm enn fast ethernet i sikringsskapet, men her er jo det litt forskjeller på hvordan bygg er oppført. En tanke kan også være å patche HAN kontakten over til et sted der en kan plassere denne måleren innenfor trygge omgivelser og WiFi dekning (altså, ta HAN signalet ut av skapet heller enn å ta ethernet inn) Hva tenkte du var største utfordring med WiFi framfor kablet nett? Stabilitet, dekning eller annet?
  7. roarfred

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

    Jeg løste det ikke 🙂 hos meg er det et svakstrømskap rett under, så der kan jeg borre meg gjennom. Men, beste tipset var kanskje ringetrafoen eller en din montert stikkontakt. Din montert usb uttak lette jeg litt etter, det hadde kanskje vært mest fancy, men jeg kunne ikke finne noe slik
  8. roarfred

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

    Jeg har stort sett brukt ESP12E eller F. Bør koste rundt en tjuekroning: https://m.banggood.com/10Pcs-ESP8266-ESP-12F-Remote-Serial-Port-WIFI-Transceiver-Wireless-Module-p-1067471.html?rmmds=search
  9. roarfred

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

    Mitt lokale e-lag etterforsket dette litt og kom med følgende forklaring: (sannsynligvis er da spenningen alltid 0V på L2 hos meg)
  10. roarfred

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

    Spennende! Min umiddelbare reaksjon var at baud rate måtte være feil, men at dere leser ut spenning, frekvens og kanskje en sjekksum her sannsynliggjør at det likevel stemmer. Det som er sikkert er at dette ikke er DLMS data, da skulle alle pakker startet og sluttet med e7. Så spørsmålet er om det er en helt annen firmware som var lagt inn initielt på disse målerne. Og, kan den reverse engineeres før det deployes ny firmware til Aidon? Et lite tips ang checksum, det finnes en site her som kan hjelpe dekode, der det kjøres en lang rekke kjente checksum algoritmer på en valgfri datakilde. Se om du finner treff her: http://crccalc.com
  11. roarfred

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

    Eller hiver på en clamp rundt en av fasene, eller leser av IR måleren... Har du fysisk tilgang så klarer jeg ikke se hva du kan utrette av ekstra sikkerhet med kryptering på HAN (med de dataene som finnes der nå da). Fra avleseren må ting selvfølgelig være kryptert WiFi.
  12. roarfred

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

    Flere som har Kaifa måler? Er de levert forseglet? Ser i brukermanualen at det skal være totalt 8 forseglinger, men hos meg er det kun forseglinger i skruene til venstre. Dvs. deksel til M-bus er åpent... og rekkeklemmer og moduldeksel har forsegling i en av to skruer.
  13. roarfred

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

    Denne er spennende! Her snakker vi direkte tilkobling til den ekte M-Bus (bak det lille dekselet på Kaifa måleren) og ikke data fra HAN porten?
  14. roarfred

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

    Enig i at de burde kjørt hardt på en spesifikk output fra måleren. Litt usikker på om tidsgrensen de har satt for implementasjon er urimelig for noen...
  15. roarfred

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

    Tror vi kan skrive under på at det ikke er noe sentralt system eller en gang samme behandling av de som ønsker HAN porten åpnet. Merket meg at min henvendelse om åpning gikk fra Etne E-lag, til Valider, hvor de hadde en tekniker som fikset biffen. Valider var (er?) de som har/hadde kontroll på utrulling av Kaifa målere... Virker på meg som at det er veldig liten samkjøring på både formater og prosedyrer, og når det kommer til "sikring" av dataene så begynner det hele å bli en vits. Tror egentlig leverandørene har snakket sammen og samarbeidet, selv om det ikke er helt offisielt. Kanskje det mest spennende blir om Aidon deployer ut en løsning med 09-buggen
×