Bjørn Mork

1 hour ago, Fredrick said:

Det er i alle fall tydelig at den har tilkobling til SFP-modulen. 

Jada, og Input Pwr viser at du ser lyset.  Men ganske høye verdier både inn og ut hvis det der er riktig.  TIl sammenligning sier min nokså like SFP dette:

           Temperature  Voltage  Tx Power  Rx Power
Port       (Celsius)    (Volts)  (dBm)     (dBm)
---------  -----------  -------  --------  --------
Gi1/0/16     58.8       3.26      -5.2      -8.7   

og den har RX "warn" på -1 dBm og "alarm" på 0 dBm.  Tilsvarende for TX er hhv -3 og -2 dBm.  Du ligger jo milevidt over hvis de tallene der er korrekte.  Men jeg har en ørliten følelse av at de ikke er det.... Ser veldig ut som om noen har konvertert dBm til mW og glemt å fikse enheten.  Så jeg ville ikke lagt mye vekt på det.  Du ville sikkert sett noen blinkende advarselslamper hvis det faktisk var noe galt.

Uansett er ihvertfall fiberen OK. Ellers ville du definitvit ikke mottatt såpass sterkt signal.

Kanskje 10G/1G må endres manuelt på denne?

24 minutes ago, Fredrick said:

Ingen blink i SFP-porten for å indikere data. 

Det høres nesten ut som om du har et brudd et sted.  Sikker på at alle konnektorer har klikket skikkelig på plass?

Kjenner ikke denne Unifi-boksen, men har den ikke noen som helst info om signal etc? SFPer måler gjerne en drøss parametre og det er vanlig å kunne se på dette i en router/switch.  Hadde jo vært nyttig å vite om det er lys der.  Det må vel finnes en eller annen output med info om porten også, ikke bare konfigurasjon?

,Ellers skal det ikke være mer komplisert enn å bruke VLAN 102 for Internett så konfigen ser jo OK uk

1 hour ago, Fredrick said:

Vent litt.. Betyr det at en SFP+ port ikke vil fungere med en standard SFP modul?

Nei.  De aller fleste SFP+ porter støtter også SFP.  Så de fungerer som 1G-port hvis du plugger inn en SFP og som 10G-port hvis du plugger inn en SFP+.  Jeg antar det også gjelder for DM Pro uten at jeg kjenner denne.  Du skal altså være good-to-go med f.eks. en slik: https://www.fs.com/products/39135.html Lurt å velge riktig merke for å få den kodet slik at boksen din aksepterer den. Det er mange produsenter som er kranglete mht "tredjeparts optikk".   Hvis du vil ha SC konnektor (slik som Viken bruker) så må du velge Customized og spesifisere det der.  Der vanlige er ellers LC.  Men så lenge du kjøper passende patche-snor så er jo dette egentlig hipp-som-happ.

Poenget mitt med advarselen var at du  ikke kan bruke en SFP+ modul mot Viken fiber. SFP+ fiber-moduler støtter ikke 1G. Det finnes noen få unntak, men jeg tror ikke det gjelder BiDi.  Og det er i alle tilfeller så uvanlig at det ikke er noe poeng i å gruble på.

Merk at jeg skriver "fiber-moduler".  Kobber (TP) SFP og SFP+ blir noe annet og vil som oftest støtte flere hastigheter.  Men det er ikke relevant her.

7 minutes ago, tronde said:

Jeg skulle veldig gjerne visst hva logikken er i å slå beina under etablerte SI-enheter som er V og A med store bokstaver.

Hvis du ser det slik så gir jo ikke r noen mening her.  Tror poenget er at var er et nytt symbol, tilsvarende V eller A eller W,  og ikke en sammensetning av andre symboler.

18 minutes ago, MrE said:

Finnes 10G SFP+ BiDi,

Klar over det.  Men de er KUN 10G så vidt jeg vet.  Funker ikke mot 1G i den andre enden.

EDIT: Men jeg ser ærlig talt ikke problemet. Kjøp en 1G SFP nå, og bytt den ut når/hvis Viken skulle begynne å støtte noe annet.

20 hours ago, tronde said:

Nå er ikke jeg gal (håper jeg), så jeg sover fortsatt godt om natten når det står var og kvarh på skjermen. VAr og kVAr er det som bevarer nattesøvnen hos petimetre.

Jeg sover godt uansett, Men om jeg nå skulle være litt ekstra kranglete., så skal symbolet visstnok være var. Med eller uten k eller andre prefiks.  Ref f.eks. https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A31980L0181 der det heter:

Quote

Special names for the unit of power: the name voltampere (symbol 'VA') when it is used to express the apparent power of alternating electric current, and var (symbol'var') when it is used to express reactive electric power.

2 hours ago, Erlend Haga said:

Men blir vel litt som på kjøkkenet, man tar seg ikke alltid råd/bryet med å flytte stikkontakten som står fra gammelt bak en stekeovn til et skap ved siden av bare fordi man bytter stekeovn.. Selv om det er, slik jeg forstår, et krav om tilgjengelighet..?

Nå sporer det vel litt av her, men shit au... Min erfaring er at det er relativt lett å flytte en stekeovn sammenlignet med en VV-bereder.  Ovnen er gjerne bare festet med en skrue på hver side.

8 hours ago, Fredrick said:

Klar over at SFP holder, men tenkte hvis jeg først skulle bestille og hadde router til det så hadde det ikke skadet å betale noen euro ekstra for 10G.

Hvis denne skal brukes mot Viken fiber så er du vel pent nødt til å bruke det som passer dem? De færreste SFP+ støtter 1G.  Vet ikke engang om det fnnes 10/1G dual-rate BiDi?

Kan helhjertet støtte anbefalingen av fs.com.  Har brukt en av deres SFPer mot Viken fiber siden 2016.  Men nå til dags så er det kanskje enklere å heller få oppgradert "hjemmesentralen" ettersom VMG8825 kommer med en SFP som nevnt ovenfor.  På "hytta" har jeg ganske enkelt gjenbrukt denne i en ZyXEL-switch.

On 24/06/2021 at 12:48, Bjørn Mork said:

tenkte forresten tanken at jeg kunne prøve å koble opp nettien via en mitmproxy-løsning for å se om den får nøkkel via et eller annet API som kan misbrukes.  Men så slo det meg at den mest sannsynlig bare forwarder w-mbus direkte uten å bry seg med dekryptering.  Så den idéen er nok dødfødt

Har endelig somlet meg til å få bekreftet denne teorien.  Eksempel på måling mottatt fra naboens måler av rtl_433 (med options "-f 868950000 -s 1200000 -M level"):

{
  "time": "2021-11-18 17:18:55",
  "model": "Wireless-MBus",
  "mode": "C",
  "M": "KAM",
  "id": 76845462,
  "version": 27,
  "type": 22,
  "type_string": "Cold Water",
  "C": 68,
  "data_length": 41,
  "data": "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027",
  "mic": "CRC",
  "mod": "FSK",
  "freq1": 868.93299,
  "freq2": 868.95712,
  "rssi": -1.52101,
  "snr": 12.20334,
  "noise": -13.7244
}

Nettien poster da dette til https://agent.dd.onsmartliv.no/api/agent:
 

Host:                agent.dd.onsmartliv.no
User-Agent:          DeviceDrive/WRF01/5.0
Content-Type:        application/json; charset=utf-8
Accept:              application/json
DeviceDrive-Header:  {"mac":"2cf43248d7a5","firmware":"5.0","hardware":"WRF01","token":"c7fc5808155cc8d9649b042a1619858b","product_key":"1ad22182-ca0c-4087-b79b-9b7971bbc95c","version":"2.3","transfer_type":"data"}
Content-Length:      411

{
    "smartliv.netti.system": {
        "alive": 423653,
        "batt_status": "USB",
        "batt_v": 3.3,
        "conf_water_meter": "",
        "hw": "1.3",
        "sn": "191010832",
        "t": 1637252085,
        "usb": 1,
        "wifi_rssi": -70
    },
    "smartliv.netti.water": {
        "raw_water_msg": "543D2C442D2C625484761B168D200114B76522CBAA96817C787F3183F757807E0A2FECF5A6AC0C35E3CD19D02786B9",
        "water_rssi": -86,
        "water_sn": "76845462",
        "water_status": 183,
        "water_t": 1637252085
    }
}

og får innimellom en imponerende mengde 500,502 og 503 en slik ack tilbake:

Cache-Control:                  no-cache
Pragma:                         no-cache
Content-Length:                 24
Content-Type:                   application/json; charset=utf-8
Expires:                        -1
Request-Context:                appId=cid-v1:283644af-6b78-4018-bd1f-5a8797ddc96b
Access-Control-Expose-Headers:  Request-Context
Set-Cookie:                     ARRAffinity=3e6f5debd8a2718fff20e474e8397f908da7dc3bb3105a4dd67e2d68ff65108e;Path=/;HttpOnly;Secure;Domain=agent.dd.onsmartliv.no
Set-Cookie:                     ARRAffinitySameSite=3e6f5debd8a2718fff20e474e8397f908da7dc3bb3105a4dd67e2d68ff65108e;Path=/;HttpOnly;SameSite=None;Secure;Domain=agent.dd.onsmartliv.no
Date:                           Thu, 18 Nov 2021 16:21:25 GMT                                                                                                                                                                                                 

{
    "timestamp": 1637252447
}

Nettiens "raw_water_msg" er nesten en tro kopi av "data" fra rtl_433.  Nettien legger til 4 siffer først og sist (sjekksum+?), og lengde-byten (byte 0 fra rtl_433 eller byte 2 fra Netti) er økt med 2.  Kompensasjon for de to bytene på slutten?  I tillegg er to bits inne i meldingen flippet: 8d2a har blitt til 8d20.  Veldig pussig. Men det er uansett i headeren før den krypterte payloaden, så det ødelegger jo ikke noe.

wmbusmeters dekoder denne meldingen slik:

(simulation) from file "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027"
(wmbus) ff a dll crc first (calculated ccd8) did not match (expected 8d2a) for bytes 0-10!
(wmbus) parseDLL @0 43
(telegram) DLL L=2a C=44 (from meter SND_NR) M=2c2d (KAM) A=76845462 VER=1b TYPE=16 (Cold water meter) (driver multical21) DEV= RSSI=0
(wmbus) parseELL @10 33
(telegram) ELL CI=8d CC=2a (slow_resp sync prio) ACC=01 SN=14b76522 (AES_CTR session=4 time=2513777) CRC=cbaa
Received telegram from: 76845462
          manufacturer: (KAM) Kamstrup Energi (0x2c2d)
                  type: Cold water meter (0x16)
                   ver: 0x1b
                driver: multical21
(wmbus) 00: 2a length (42 bytes)
(wmbus) 01: 44 dll-c (from meter SND_NR)
(wmbus) 02: 2d2c dll-mfct (KAM)
(wmbus) 04: 62548476 dll-id (76845462)
(wmbus) 08: 1b dll-version
(wmbus) 09: 16 dll-type (Cold water meter)
(wmbus) 0a: 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte))
(wmbus) 0b: 2a ell-cc (slow_resp sync prio)
(wmbus) 0c: 01 ell-acc
(wmbus) 0d: 14b76522 sn (AES_CTR)
(wmbus) 11: cbaa payload crc (calculated e70b ERROR)
telegram=||2A442D2C625484761B168D2A0114B76522CBAA96817C787F3183F757807E0A2FECF5A6AC0C35E3CD19D027|+0
(serial) stopping manager

Har dessverre ikke klart å få ut nøkkelen fra hverken Asker kommune eller Smartliv (som mest sannsynlig heller ikke har den).  Så det der er vel  omtrent så langt jeg kommer. 

Når det gjellder "Netti" hardwaren så er det sikkert noen her som er interessert i å vite at den oppgir hostnavnet "ESP-48D7A5" og at mac-adressen i DeviceDrive-Header er korrekt.  DeviceDrive ser ut til å være et firma som driver omtrent som Tuya - selger halvferdig dingsedesign sammen med en app-/sky-løsning.  Mer info på https://devicedrive.com/download/wrf01-hardware-specification/

Litt uventet "arvet" vi en haug med Trådfri-pærer fra forrige eier av hytta, uten at jeg har funnet noen kontrollere av noe slag.  Pærene står i armaturer som er kablet opp som ordinære lamper bak standard Elko brytere.  Er helt fersk i dette gamet men har nå fått opp zigbee2mqtt og også bundet pærene til noen Trådfri brytere (E1743).  Det funker jo helt flott med styring både fra home assistant og fra Trådfri-bryter, og fremdeles fra Trådfri-bryter om z2m skulle være nede.

Men Elko-bryterne ved siden av dørene til de aktuelle rommene er fremdeles en liten brukergrensesnitt-utfordring.  Praktisk for å få resatt pærene, men ikke så praktisk når noen bruker dem til å slå av lyset...  Som jo virker ganske logisk for de fleste.

Så disse hue switch modulene virket som en perfekt oppgradering.  Men nå har jeg fiklet en liten stund og begynner å lure litt. Jeg klarer ikke å binde dem til pærene, hverken som individuelle endepunkter eller som gruppe.  Så de gjør jobben så lenge z2m og ha kjører, men ikke ellers.  Det er selvsagt et mål at det skal kjøre nær 100% av tiden, men jeg har nok grå hår til å innse at dette vil feile en gang.  Mest sannsynlig når behovet er størst.

Er det noen andre som har erfaringer med disse Hue Switch modulene?  Er det korrekt at binding ikke funker?  Eller gjør jeg noe galt?  Hvilke andre alternativer finnes?  Tenker primært på tilsvarende løsning der Elko-bryteren beholdes med smartere funksjon.

Interessant.  Synes jo fremdeles litt mer hensiktsmessig å bruke radio-telegrammene som måleren tross alt kringkaster uansett, men når det ikke er mulig å oppdrive nøkkelen så er jo dette alltids et alternativ.  Greit å vite.

Ellers havnet jeg her fra den linken du postet:

https://github.com/bsdphk/PyDLMS/blob/master/README

der vi har dette herlige sitatet som forklarte både litt av hvert:

On 26/08/2021 at 15:20, Bjørn Mork said:

Nja, nå prøvde jeg å gjenskape problemet et par ganger før jeg gadd å dra fram serie-adaptere, men det gikk jo ikke.  Prøvde bare å tvinge frakobling fra wifi, med og uten blokkering av MQTT-sesjonen, men ting spratt opp igjen uten noen reboot.

For å ikke etterlate et permanent inntrykk av problemer her:  Pow-K modulen har virket helt perfekt for meg siden jeg skrev dette.

Hele greia var nok mest sannsynlig bare WiFi-hikke hos meg.

20 hours ago, ahattest said:

Kan noen anbefale en switch til dette bruket? Forstår at det stort sett er mikrotik eller ubiquiti som er veien å gå?

Kommer an på hva du vil gjøre og hva du ellers ser for deg av utstyr.  Det meste som er managed og takler en bidi-sfp virker jo.

Jeg bruker en Cisco WS-C3560CX-12PD-S hjemme og en ZyXEL GS1900-10HP på hytta.

54 minutes ago, Bjørn Mork said:

Burde være overkommelig å teste den teorien med serieport-debugging slik at man kan se hva som skjer.

Nja, nå prøvde jeg å gjenskape problemet et par ganger før jeg gadd å dra fram serie-adaptere, men det gikk jo ikke.  Prøvde bare å tvinge frakobling fra wifi, med og uten blokkering av MQTT-sesjonen, men ting spratt opp igjen uten noen reboot.  Så det er noe annet/mer her..

OK, noe mer kjøtt på beina.  Du har nok helt rett - årsaken til feilen ligger mest sannsynlig i mitt trådløse nett.  Det som har forvirret meg er at Pow-K modulen rebooter.  Men dette er trigget av nettverksproblemene og ikke motsatt.

Var i tilstanden der modulen ikke svarte på ping.  I følge aksesspunkte var den aktiv på wifi (inactive time < 1 s):

root@u6-1:~# iw wlan0-1 station get 50:02:91:e0:4a:15 
Station 50:02:91:e0:4a:15 (on wlan0-1)
        inactive time:  910 ms
        rx bytes:       2939834
        rx packets:     62674
        tx bytes:       1578596
        tx packets:     13205
        tx retries:     7603
        tx failed:      0
        rx drop misc:   0
        signal:         -77 [-77, -83] dBm
        signal avg:     -76 [-76, -81] dBm
        tx bitrate:     54.0 MBit/s
        tx duration:    2247072 us
        rx bitrate:     6.0 MBit/s
        rx duration:    6620293 us
        airtime weight: 256
        expected throughput:    18.126Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        no
        MFP:            no
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short preamble: yes
        connected time: 27051 seconds
        associated at [boottime]:       1159508.557s
        associated at:  1629950047588 ms
        current time:   1629977098573 ms

Men IP-messig var det altså dødt.  Jeg har sett tilsvarende med et IP-kamera på dette nettet før, så jeg holder en knapp på en AP-relatert bug (halveksperimentell OpenWrt installasjon).  Trigget en reconnect, og det virket tilsynelatende som det skulle:

root@u6-1:~# iw wlan0-1 station del 50:02:91:e0:4a:15 
root@u6-1:~# iw wlan0-1 station get 50:02:91:e0:4a:15 
Station 50:02:91:e0:4a:15 (on wlan0-1)
        inactive time:  220 ms
        rx bytes:       11664
        rx packets:     179
        tx bytes:       2322
        tx packets:     21
        tx retries:     11
        tx failed:      0
        rx drop misc:   0
        signal:         -76 [-76, -82] dBm
        signal avg:     -76 [-76, -82] dBm
        tx bitrate:     48.0 MBit/s
        tx duration:    13376 us
        rx bitrate:     6.0 MBit/s
        rx duration:    46173 us
        airtime weight: 256
        expected throughput:    16.113Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        no
        MFP:            no
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short preamble: yes
        connected time: 80 seconds
        associated at [boottime]:       1186733.477s
        associated at:  1629977272509 ms
        current time:   1629977352458 ms

Men så skjer det noe.  Loggen fra DHCP-serveren viser 3 fulle runder med  DISCOVER++:

Aug 26 13:27:52 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:27:52 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:27:52 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:27:52 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:29:58 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:29:58 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:29:58 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 26 13:29:58 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 26 13:30:11 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 26 13:30:11 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 26 13:30:11 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 26 13:30:11 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15

Loggen fra aksesspunktet matcher:

Aug 26 13:27:29 u6-1.mork.no hostapd wlan0-1: AP-STA-DISCONNECTED 50:02:91:e0:4a:15
Aug 26 13:27:29 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: disassociated due to inactivity
Aug 26 13:27:30 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Aug 26 13:27:52 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: authenticated
Aug 26 13:27:52 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: associated (aid 2)
Aug 26 13:27:52 u6-1.mork.no hostapd wlan0-1: AP-STA-CONNECTED 50:02:91:e0:4a:15
Aug 26 13:27:52 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 WPA: pairwise key handshake completed (RSN)
Aug 26 13:27:52 u6-1.mork.no hostapd wlan0-1: EAPOL-4WAY-HS-COMPLETED 50:02:91:e0:4a:15
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: AP-STA-DISCONNECTED 50:02:91:e0:4a:15
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: authenticated
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: associated (aid 2)
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: AP-STA-CONNECTED 50:02:91:e0:4a:15
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 WPA: pairwise key handshake completed (RSN)
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: EAPOL-4WAY-HS-COMPLETED 50:02:91:e0:4a:15
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: AP-STA-DISCONNECTED 50:02:91:e0:4a:15
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: disassociated
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: disassociated
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: disassociated
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: disassociated
Aug 26 13:29:58 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: disassociated
Aug 26 13:29:59 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Aug 26 13:30:11 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: authenticated
Aug 26 13:30:11 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 IEEE 802.11: associated (aid 2)
Aug 26 13:30:11 u6-1.mork.no hostapd wlan0-1: AP-STA-CONNECTED 50:02:91:e0:4a:15
Aug 26 13:30:11 u6-1.mork.no hostapd wlan0-1: STA 50:02:91:e0:4a:15 WPA: pairwise key handshake completed (RSN)
Aug 26 13:30:11 u6-1.mork.no hostapd wlan0-1: EAPOL-4WAY-HS-COMPLETED 50:02:91:e0:4a:15

Og jeg ser også at vi har fått en ny "associated at" tid:

root@u6-1:~# iw wlan0-1 station get 50:02:91:e0:4a:15 
Station 50:02:91:e0:4a:15 (on wlan0-1)
        inactive time:  0 ms
        rx bytes:       1996
        rx packets:     16
        tx bytes:       1656
        tx packets:     12
        tx retries:     0
        tx failed:      0
        rx drop misc:   0
        signal:         -77 [-77, -81] dBm
        signal avg:     -75 [-75, -80] dBm
        tx bitrate:     6.0 MBit/s
        tx duration:    11968 us
        rx bitrate:     1.0 MBit/s
        rx duration:    18172 us
        airtime weight: 256
        expected throughput:    4.394Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        no
        MFP:            no
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short preamble: yes
        connected time: 0 seconds
        associated at [boottime]:       1186872.079s
        associated at:  1629977411112 ms
        current time:   1629977411318 ms

Årsaken til alt dette igjen, er at Pow-K har rebootet.  Den viser nå en oppetid på noen sekunder.  Så det ser ut til at den ikke takler denne WiFi-reconnect situasjonen.  Noe som kræsjer på seg ved andregangs initalisering av WiFi, kanskje? Muligens MQTT-klienten?
 

Burde være overkommelig å teste den teorien med serieport-debugging slik at man kan se hva som skjer.  Setter det på TODO-lista.  Ville bare si fra i tilfelle andre har lyst til å teste ut teorien.

1 hour ago, ArnieO said:

Dersom den mister kontakt med Wifi-aksesspunktet blir Wifi-indikatoren rød:

Jeg får vel bare stole på deg der 🙂

1 hour ago, ArnieO said:

Tre røde blink er en feilkode som indikerer at den ikke har kontakt med Wifi-ruteren, se kapittel "Feilsignaler" i bruksanvisningen.

Ja, jeg så det der.  Var litt usikker på om dette var 3 "blink" eller 3 gjentagelser av sekvenser med x blink.  Hvert av "blinkene" flimret som om de bestod av svært hurtig blinking.  Men i så fall var det en del av dem og frekvensen ganske høy.  Hva er sånn ca perioden for disse feilblinkene?  Det gikk vel en par-tre sekunder mellom dem dersom vi tolker det som tre lange blink.

Får ta en kikk på hva aksesspunktene sier neste gang dette skjer

56 minutes ago, ArnieO said:

Vet du om modulen var spenningsløs (ingen lys i LEDen) mens dette skjedde?

Hadde flaks nå.  Var ikke til stede tidligere mens problemet var der, men nå slo det til igjen mens jeg satt her og skulle svare.  Så da har jeg litt mer fakta og kan redusere synsingen tilsvarende 😉

Modulen blinket to eller 3 sekvenser med hurtig rød blinking, deretter en normal sekvens med lang blå pluss kort grønn blink.

Jeg tok den ut.  Da fortsatte den noen runder med røde blink mens supercapen ladet seg ut.  Ventet til det tok slutt.  Plugget den inn igjen og den startet opp og virket normalt uten rød blinking.

57 minutes ago, ArnieO said:

Hvilken liten endring var det du gjorde slik at den ble stabil?

Tømte tanken i avfukteren 😉  Dvs, la på et konstant bunn-forbruk på 300 W.

58 minutes ago, ArnieO said:

Min teori heller mer i retning av at det skjer noe i forbindelse med nettselskapets daglige trådløse avlesing av målere. Kanskje radiostøy som gjør at Wifi-signalet fra Pow-K ikke kommer ut til routeren din?

Joda, men det var så rart at det tok uker før dette slo til første gang.

1 hour ago, ArnieO said:

Hvilken RSSI har du vanligvis?

Den ligger nok kanskje noe lavt i forhold til radiostøyen i nærheten.  Typisk -75 til -77 dBm.

Bruker BLE fra RPien på toppen av skapet til å lese av noen Airthings sensorer, og RPien har også en USB3 minnepinne som systemdisk. Og en RTL2838 mottaker som jeg bruker til noen 433 MHz sensorer.  Og nå også en Zigbee radio.  Men den var ikke der når problemet oppstod, så den har jeg lyst til å frikjenne til tross for interferens-potensialet.

I tillegg står det en Netti der. Dette er en enkel smarthus-gateway som gamle Hurum kommune har delt ut.  Den har visst WiFi, BLE, og Zigbee i følge https://www.sintef.no/globalassets/project/va-dagene/2019/14-erfaring-med-fjernavleste-vannmalere2.pdf . Og åpenbart W-MBUS på 869 MHz siden mesteparten av poenget er avlesing av vanmåleren. Nettien får selvsagt ikke strøm fra HAN-porten siden jeg bruker den til Pow-K, men strømforsynes i stedet med USB.

Kamstrup-måleren har ekstern antenne montert på utsiden av skapet så det kan godt tenkes den fungerer som hub i et mesh-nettverk.  Er ikke så mange husstander i nærheten, men er jo noen.

Helt støyfritt miljø er det altså ikke.  Godt man ikke bor i Ny-Ålesund 🙂

5 minutes ago, stigvi said:

Hvorfor lete etter en sammenheng når det mest sannsynlig ikke er noen sammenheng? Mener nå jeg .......

Du har et poeng der.  Jeg leter vel mest etter en forklaring på noe som er så pussig at jeg er villig til å akseptere det som magi 😉

Problemet var ihvertfall helt fraværende så lenge forbruket var på 300+ W.  Da var alt dønn stabilt.  Men det er sikkert lurt å gi det noen uker nå og se om det er like stabilt igjen etter at forbruket er tilbake deromkring

On 14/08/2021 at 23:08, Bjørn Mork said:

Men det har vært stabilt siden 02:00 i natt, så da håper jeg det forblir sånn

Det slo ikke til.  Måleren fortsatte med å koble ut ca en gang i døgnet, men helt irregulært, den neste uken.

Men nå har den vært stabil etter en liten endring jeg gjorde for 3 dager siden, og jeg har en morsom teori å prøve på dere:

Måleren står i en fritidsbolig.  Normalt er det et minimum forbruk på minst 300 W der.  Mest pga en avfukter i kjelleren.  Problemene oppstod etter at denne avfukteren stanset (bugger tidvis og fyller opp tanken sin i stedet for avløpsslangen) uten at noen var til stede.  Forbruket sank da til ganskje jevnt 50 W.  Endringen jeg gjorde for 3 dager siden var å starte opp avfukteren igjen.

Kan det tenkes at tilgjengelig effekt til HAN-modulen avhenger av målt effekt i Kamstrup-måleren? Det synes ihvertfall som om det er en klar sammenheng med at modulen mister strømforsyningen og at målt effekt er veldig lav over tid.  Jeg må innrømme at jeg sliter litt med å fantasere frem en ingeniør-godkjent forklaring på fenomenet.  Men kanskje de rett og slett henter strømforsyningen til måleren fra måletrafoer rundt fasene?  Og at den nødvendigvis må nedprioritere den eksterne modulen når effekten er for lav til å holde alt oppe?

Hmm, høres litt for søkt ut egentlig.  Blir jo veldig vanskelig å måle 0 W på den måten der.

Andre idéer?  Eller andre som ser seg i stand til å teste teorien?  Jeg innser at det er litt utfordrende å holde strømforbruket på jevnt 50 W eller lavere i et døgn eller mer 🙂  Noe stort problem er det jo uansett ikke.

6 hours ago, ArnieO said:

Forstår jeg deg rett når du snakker om data fra to Kamstrup-målere hvorav du har en Pow-K på den ene?

Er problemet der fremdeles?

Nei, har bare en Kamstrup-måler. Med Pow-K.  Problemet forsvant, men dukket opp igjen i natt og så forsvant det igjen etter noen timer.  Veldig rart.

Men det har vært stabilt siden 02:00 i natt, så da håper jeg det forblir sånn

Pussig sammentreff på fredag 13.?  Jeg oppdaget nettopp at jeg mangler data fra Kamstrup-måleren på hytta mellom Fri Aug 13 15:30:02 2021 og Fri Aug 13 19:49:27 2021
 

Og når jeg logget på min Pow-K nå for en liten stund siden så hadde den en oppetid på kun minutter.  Merkelige greier.  Den har vært dønn stabil siden jeg fikk den. 

Loggen fra DHCP-serveren forteller meg at den mest sannsynlig rebootet flere ganger helt umotivert nå rundt kl 20:

Aug 13 19:49:27 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 13 19:49:27 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 via eth0.15
Aug 13 19:49:27 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 via eth0.15
Aug 13 20:35:53 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 13 20:35:53 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 13 20:35:53 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15
Aug 13 20:35:53 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 13 20:36:06 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 13 20:36:06 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 13 20:36:06 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15
Aug 13 20:36:06 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15

Bug i firmware på Kamstrup?  Eller samtidige firmware-oppgraderinger?

1 hour ago, The X said:

USB forlengelseskabler fås i alle lengder. 😉

Uhm, ja, men da skal du helst ikke ha for strømkrevende USB-duppeditter.  Evt få strøm fra et annet sted enn USB. 5V er ikke all verden når kabelen blir lang (og tynn, som USB kabler gjerne er).

2 hours ago, The X said:

mer stabilt en Pi med SD-kort...

Kan anbefale å erstatte SD-kortet med en USB3 minnepinne på RPI4.  Vanskelig å merke forskjell i opplevd IO-ytelse fra en PC med SSD.  Dessuten mye enklere å flytte over til en laptop ved behov for å rette opp feilkonfigurasjon av bootloader eller tilsvarende.

Nå har jeg også meldt meg inn i klubben av strålende fornøyde kunder.  Var heldig nok til å få kjøpe et ferdig kort, siden hverken evner eller utstyr tillater lodding på dette nivået.  Det var plug-and-play for meg også.  Svært enkelt å både installere og konfigurere.

Som mange andre her så har jeg akkurat nok erfaring med hobby-prosjekter til å kjenne mine egne begresninger altfor godt.  Det som imponerer meg stort med dette prosjektet er den utholdenheten som demonstreres gjennom finish både på hardware og software.  Selv har jeg en lei tendens til å gå lei når noe virker på proof-of-concept stadiet.  Dvs at hardware-utviklingen stopper på et breadboard med ledninger hit og dit og lodding som ikke ser ut i måneskinn.  Og software får aldri noensinne et annet brukergrensesnitt enn et minimum for debugging.  Dokumentasjon er noe  som kan "gjøres senere".

Derfor imponerer det stort når noen tar seg bryet med å designe og produsere hardware som ser så proff ut at det er bare er fraværet av feil som skiller det fra et komersielt produt, eller software som både ser veldig bra ut og som fungerer så bra at det åpenbart må være utviklet av noen som faktisk bruker produktet selv.

Var forresten litt skeptisk til hvor bra WiFi kom til å virke inne i det gamle og svært solide stålskapet uten særlig mange hull, med rundt 10 meter, noen vegger og et etasjeskille til nærmeste AP.  Men det funket også over all forventning.  Ingen problemer å bruke modulen med lukket skap.  Ser en RSSI på mellom -75 og -80 dBm et sted.  Det synes jeg er helt innafor.

8 minutes ago, espenvp said:

Vel, jeg skal ikke påstå at dette virker sånn for alle Altibox partnere rundt om i landet, men dette har fungert hos meg siden jeg satt det opp i Februar i år. Min leverandør er Bergen Fiber. Det virker dog uforståelig at de skal mac-filterere sine egne IPTV-bokser, det er jo disse de skal levere et produkt til.

 

PS: jeg også har også blitt tildelt VMG ruter, brukte den i kanskje ett døgn før den gikk i "arkivet".

Interessant.  Da forsvant resten av systemet. Ja, det er helt uforståelig.

Jeg har Viken Fiber og har hatt det siden 2012. De første årene med en ZyXEL P2812 som hjemmesentral og en 100 Mbit mediakonverter fra Ping. Ca 2015(?) oppgraderte de til gigabit (vi snakker link-hastighet nå, ikke produkt) og vi fikk da en HET-3012 dual-rate 100/1000 media-konverter.  Da benyttet jeg sjansen til å erstatte hjemmesentral og mediakonverter med et oppsett temmelig likt tegningen din. Det fungerte helt fint i 5 år, inkludert flytting av hele opplegget til en annen leilighet

Men i januar i fjor fikk vi pushet på oss en VMG i stedet for HET+P2812 som en del av borettslagets fellesavtale.  Jeg forsøkte meg på å bytte eske mot eske, siden jeg helst så at jeg slapp å demontere mitt fungerende nettverk.  Montøren ble litt overrasket og måtte ta en telefon for å sjekke om det var OK, men det endte med at han måtte skru opp VMGen på veggen og koble den til. Bortkastet men greit nok, tenkte jeg.  Overraskelsen var stor når jeg koblet tilbake til mitt utstyr, og TVen ikke lenger virket.  Snooping avslørte at dekoderen ikke fikk noen ip-adresse. Koblet inn VMG og alt virket.  Kjørte dhclient manuelt på VLAN 101 fra en Linux-PC med VMGens mac - og det fungerte.  Prøvde dhclient med en annen mac - og det fungerte.  Prøve dhclient med dekoderens mac - fungerte ikke.

Jeg ser ingen annen forklaring enn at Viken har lagt på et filter for å blokkere direkte bruk av dekoder på VLAN 101. De har sikkert en grunn som gir mening for dem.

Jeg endte opp med et betydelig mer komplisert oppsett for å oppnå det samme jeg hadde før:  TV-dekoder isolert på sitt eget lille VLAN.  Det krever nå en router med igmpproxy mellom dekoder-VLAN og (Vikens) VLAN 101.  Routeren bruker en mac-adresse som ligner på VMG, men er slightly forskjellig (slik at jeg skal kjenne den igjen)

Samboer skaffet seg nylig hytte med VIken fiber også, men der har vi ikke TV så jeg får ikke testet om det er samme opplegg.  Men der fikk jeg ihvertfall testet gjenbruk av SFP fra VMGen.  Den funket helt fint i en ZyXEL GS1900-10HP switch (med OpenWrt - har ikke prøvd med original firmware, men jeg vil tro det virker).