Terje2k

Takk! Helt enig. Om det har passet når jeg har møtt elektrikere siste tiden har jeg spurt om dette, flere har sagt at de har ment det er nok med type-A ihht. installasjonsmanualen...

Jeg merker det er store forskjeller på hva folk setter som standard. Det du beskriver med Telia er i min verden alt annet enn "elegant". I min verden ville det vært en solid strykkarakter.

Har ikke tu pluss så får ikke lest, men det lille man kan lese, ikke sjokkerende: https://www.tu.no/artikler/easee-trenger-mer-tid-jobber-med-a-bygge-opp-nok-dokumentasjon/542657 Samtidig virker det som de nesten prøver å skygge over med disse PR artiklene i håp om at de skal bli fanget opp istedenfor: https://www.shifter.no/nyheter/krise-easee-matte-kutte-staben-til-beinet-men-na-ansetter-de-igjen/305694 https://www.shifter.no/nyheter/easees-redningsmann-det-er-ekstremt-krevende-og-jeg-holder-pa-a-ga-under/305808 Syns det er spesielt at de publisterer to artikler samtidig... Hva skjer hvis de dytter rettsaken så langt frem at man har gått over utbedringsfristen for eksisterende installasjoner (som er 1.03.24 hvis jeg husker korrekt) ? Er det vi ser en måte å trenere / utsette den fristen på?

Du utelo noe. Jeg bruker tibber pulse med lokal MQTT server, da slipper man å bruke deres app/skytjeneste. Se her: https://github.com/toreamun/amshan-homeassistant/wiki/Lesere-MQTT#tibber-pulse Kjører man HA kan man feks. bruke "amshan" for å tolke MQTT data enkelt: https://github.com/toreamun/amshan-homeassistant Newsflash, tibber pulse bruker også WIFI!!!!!!!!! ESP32, så hvis du virkelig vil programmere selv kan du bare kjøre på.

Nå er det vel kanskje litt lite å dra konklusjon ut fra når du ikke har sagt mye, men svaret ditt på 2 viser vel at du kanskje ikke helt forstår nettverk/problemstillingen. Jeg regner med det er en eller annen form for RF mellom det du kaller "knutepunkt" og forflåte? Og sikkert RF mellom forflåte og merd? Uansett, jeg vil anbefale dere å leie inn noen som kan nettverk med kunnskap om real-time low latency videostrømming, det bør dere ha penger til når dere skal sentralisere forsentral.

Dette er vel ikke tilfeldigvis oppdrettsbransje? Du sier heller ingenting om transportmetoder (hele veien fra videokilde til konsument). Er det fiber 100% av veien? RF på hele/deler? LTE/5G på hele/deler? osv... d Hvilket kamera / videokilde brukes? (encoding, modellnummer ++) Sender dere rått over UDP, eller er dette pakket inn i RT(S)P eller lignende? Hvor store buffer har dere? Er det dere som har satt opp BGP eller leverandør av IPVPN?

Det brukes masse i praksis. Bla. alle de store tilbyderne av TV / IP-TV (Altibox, Telenor, Telia ++) bruker Multicast for distrubisjon av alle live tv-kanaler i sitt stamnett og helt frem til TV-dekoderne. Ser man på VOD/pauser live sendingen hopper man fra multicast over til unicast. Det med IPv4/IPv6 er vel egentlig irrelevant da mulicast fungerer på begge og det blir opp til standard/transportnett/klienter om man kan klare seg med v6-only eller om man må støtte dual-stack. Uansett, multicast fungerer på begge. Multicast brukes også massevis av andre plasser, bla. : Tidskritiske systemer (hvor X noder må få noe data "samtidig" eller hvor det er en-til-mange situasjon, ex. distrubisjon av sensordata eller status som mange noder har nytte av) CCTV (typisk etter NVR for visningsklienter) Infoskjermsystemer Musikkutstyr for studio/scene (bla. Dante) Sonos osv..

Min erfaring med "fast trådløst bredbånd" fra Telenor tilsier at det man nedgraderer deluxe er ping og jitter. Jeg ville aldri hatt dette som primær-abonnement hjemme, hadde en lengre periode hvor jeg betalte dobbelt, da Telia leverte helt møkk koaks (via borettslag, løsning = flyttet) og jeg kjøpte meg "fast trådløst bredbånd" fra Telenor som alternativt nett. Spør du meg så kan det ikke måle seg med fiber for de mer tech-savvy, for de som kun surfer web og netflix/buffered streaming fungerer det greit. Man ser også mye samme symptomer med mye mer aggressiv deling av kapasitet enn det ex. Altibox gjør på fibernett (jeg bor i en av de større byene i Norge, basestasjon var ca 100 meter unna, fri sikt). Så hvis du har ping og FPS-spill hvor lav og/eller jevn latency er viktigere enn kapasitet, tror jeg nåværende "fast trådløst brebånd" ikke er noe for deg. Alternativt, du får vel 14 dagers angrerett, så du kan jo eventuelt være kjapp med å angre hvis det skjærer seg (gjerne del erfaring hvis du går for det). Jeg har/hadde riktignok en litt eldre NR7101, men tror største årsaken til høyere ping og mye variasjon i ping ligger mer i transport/kapasitet på basestasjon og kjernenett. Pr. dags dato ut fra det jeg vet så sendes alle 4G og 5G radiosignaler inn i 4G kjernenett. Jeg forventer at man får vesentlig bedre ping når de fikser nytt kjernenett. Når det skjer vil denne posten være utdatert. Skrev også litt om det i svaret her:

Har det vært noen saker tidligere på grense mellom: hva DoC deklarerer og hva som skrives i salgsmateriell/installasjonsmanual Når kan man bli tatt på mangel av korrekthet mellom disse? Jeg tok en liten runde nå, finner referanser til integrert RCD flere plasser, eksempelvis på efobasen står følgende:

Ja, men det er det som er greia, jeg trodde det samme som deg og at de kunne bli tatt på dette. De sier at kun A er nødvendig, men elektikere skal nå ta en: Og oppdage selv at det Easee sier i sin egen installasjonsmanual angående integrert RCD ikke oppfyller hva NEK 400 krever. MAO. kun gå ut fra DoC, de må velge type-B, uavhengig av hvor villedende installasjonsmanualen er. TBH: Easee tar en spansk en, bevisst lager forvirring med å si noe i manual som veldig mange elektrikere ikke kan følge pga. mangler i DoC (dette gjelder mange flere land enn Norge). Men ved dette "trekket" får de flyttet ansvaret for den eventuelle feilen over på elektriker og ikke produsent. De burde i det minste ha påpekt dette i installasjonsmanualen at det er fraværer av relevante standarder i DoC når de nevner/skryter av denne funksjonaliteten. Feks. med "elektriker må sjekke kravene til denne funksjonaliteten mot lokale krav". Følger norske elektrikere manualen til Easee nå (installerer etter den, kun type-A) er det de som har ansvaret for feilen, ikke Easee. For Easee har aldri lovet noe i DoC.

Nei, ikke lengre, fordi DoC nevner ikke det med ett eneste ord. Så er det elektrikers ansvar å oppdage at DoC ikke inneholder relevante standarder for RCD. Selv om jeg syns dette er utrolig stygt å skrive slik i installasjonsmanual uten å nevne fraværet av en eneste relevant standard for den funksjonaliteten.

Okei jeg er enig. I praksis dytter Easee alt av risiko på elektriker/installatør. Får håpe for gudsskyld at de får med seg dette, for jeg føler dette er på kanten av lureri i måten de både uttaler seg på og skriver installasjonsveiledningen. Håper også at tilsynsmyndigheter får med seg dette "smutthullet" som jeg opplever det er. Sidespor: Når jeg tidligere har vært med på godkjenningsløp og det har vært igjen rester av funksjoner i manual av en funksjon man droppet fordi man feilet test (feks. nice to have, droppet funksjonen enn å rette i hw feil for å møte tidspress) har godkjenninghus påpekt at det måtte fjernes fra manual & blokkeres i firmware før de vil sette sitt stempel på. Har vi bare vært offer for noen som er mer rigide enn det TÜV Rheinland er?

https://download.easee.com/m/3fab321ee2d91d1e/original/NO_ChargeLite_InstallerGuide.pdf Se i installatørveiledninga deres ?!: Her sier de jo innebygd jordfeilvern, så de "forleder" elektrikere til at den har DC beskyttelse, men DoC backer ikke denne. Jeg syns det også er på kanten at de fortsatt nevner 30 mA AC.

Tja. Her opplever jeg at Easee smører en feit nugattiboks på en liten ritzkjeks. For vil bare påpeke at dette kun gjelder samsvar med RED direktivet. Så syns Easee skriver noe på kanten når de sier: Så ut fra det papiret som ligger der, har TUV kun sjekket samsvar med RED. Ikke "alle relevante standarder" ? (eller er det jeg som tar feil her nå?) DVS. ut fra det jeg ser --> dette beviser ingenting når det kommer til bryteevne på de integrerte rele'. Og det faktum at de fortsatt legger opp til i brukermanual at denne enheten skal brukes som at den har integrert RDC-DD beskyttelse (kun forankoblet type-A jordfeilbryter) men ingen beviser på at den oppfyller IEC 62955, hverken standard eller "tilsvarende sikkerhet/bryteevne" er en gåte for meg. For en ting er sikkert, RED direktivet var/er aldri ment mot powerelektronikk alene. Ikke av det jeg har jobbet med iallefall. MAO. Det er fortsatt enten trøbbel med DoC (at de mangler en standard som er *relevant standard*), eller i bestefall "villedende instruksjonsbok" som medfører at de som installerer dette ihht. vil faktisk ikke være i samsvar fordi relevant standard mangler i DoC ? EDIT: Korriger meg om jeg tar feil , for er genuint åpent for at jeg kan ta feil. Men klarer bare ikke å se hvordan RED dekker det de (egentlig) har trøbbel med. EDIT2: Easee har en villedende instruksjonsbok som ikke samsvarer med sin egen DoC, iallefall for alle land som har lagt DC beskyttelsenivået på linje med IEC 62955 (slik som her i Norge / NEK 400). Se forøvrig under.

https://www.shifter.no/nyheter/svenskene-truer-easee-med-boter-etter-varsler-om-nygamle-ladere/293701

Ja og for å da sammenligne "fair" må det borretslaget betaler (fellesdelen, pr. enhet) summeres sammen med hva man betaler selv for "oppgraderingen" for å sammenligne 1:1. Noen borretslag betaler jo alene 400-600 kroner pr. abonnement fordi de har valgt en "stor" grunnpakke.

Som jeg prøvde å forklare og @Uderzo er inne på: Da avhenger det av hvilken overføringsteknologi du/din jobb bruker mellom deg og serveren. For veldig mange overføringsmetoder vil den sterkt begrensede opplasningshastigheten sette en real demper på reell hastighet du får. Og jo flere ledd det er mellom deg og serveren (ex. hvis din jobb ikke har serveren plassert i Telia nett, men må nedom Oslo for å peere mot en annen leverandør) så blir effekten av skjevheten ofte større. Jeg fikk aldri i "praksis" 1250 Mbps når jeg hadde det, så jeg gidda ikke å betale for det mer enn 1 mnd. På speedtest så fikk jeg ish det når det ikke var kveld og mange brukte nettet, meeen hva skal jeg med det. Dessuten du får jo "kun" 50Mbps på upload. Så når du skal laste opp filer går det jo "treigt" uansett. Hadde det vært meg ville jeg heller ha spurt de om 750 linje og betalt for "dobbel opplastning" eller hva de kaller det nå. Måtte ringe inn å spørre for å få det (eksisterer ikke på "Min side" eller de offentlige sidene, da de mest sannsynlig vil ha færrest mulig kunder med "høy" upload). Alternativt hvis de kan gi deg 500/50 linje (altså at du kan få opplasningshastigheten til toppabonomentet på 500 linje ville jeg mye heller ha valgt det og brukt "overskuddspengene" på noe annet).

Sorry til tråden, dette er fort heftig OT, legger det i spoiler:

Nåja. Sterkt uenig inntil videre. Og det er definitivt ikke grunnen til at data er begrenset. Det er $$$$$, kan de melke penger fra oss og vi betaler. Da vil de tjene/melke de kronene. Det er vel ganske enkel business og kapitalistisk markedsøkonomi. Fra et teknisk perspektiv: hvis det skjer vil 4G/5G backhaul (kobling fra basestasjon til kjernenett//oslo) OG kjernenett bli overbelastet som medfører dårligere opplevd tilbud for folk flest -> kan ikke konkurrere med fiber. Uansett hvor mye Telia og Telenor reklamerer for 5G så er det pr. nå: 5G NR med "5G NSA" (non-standalone) "over 4G kjernenett" (sånn "forenklet forklart" -> medfører like "dårlig" latency og kjernenett-kapasitet som før). Når de får 5G kjernenett vil denne kapasiteten øke, men hver basestasjon vil fortsatt være en *mye mer delt ressurs* enn det et fibernettverk er. Dette gjelder både i byer (hvor frekvensene & støy er utrolig delt ressurs) Men også på bygda hvor backhaul ofte er problemet (gjerne ikke fiber til basestasjoen, men en radio-link, radio-linkene vil også øke latency, sett opp mot FTTH fibernettverk)

Spørsmålet er vel om du vil gjøre slik prioritering på lag 2 eller lag 3. Fordeler med lag 2 er jo åpenbart lavere kompleksitet. Men ulemper er feks. at du får et (større) brudd ved failover og du kan få brutte forbindelser, VoIP samtaler (hvis det forekommer), video-strømmer +++. For å få til dette så har du skjønt det virker det som: Bare sett en mye høyere path cost på switch1-p1 og switch3-p4 så vil den linken være "minst foretrukket" og legges som "backup" eller hva man skal kalle det (blocked). Går du denne ruten sjekk også ut RSTP som har raskere konverteringstid (raskere "switch over"). På lag 3 blir ting fort mye mer "avansert" med medfølgende fordeler og ulemper. Kort oppsummert er vel at du kan få mye mer dynamisk balansering og tilnærmet "usynlig" faliover. *Men* Det vil ikke nødvendigvis være problemfritt på lag 3 heller når ene path'en er en radiolink. For hvordan er kapasiteten her? Og Latency/Jitter etc.. for kjører man failover til en link som har mindre throughput enn hva som brukes på primær vli det bli trøbbel uansett hvilket lag man gjør det på. Jeg har også ville sørget for at MTU er lik over hele fjøla. Jeg har vært borti noen radiolinker som har lavere MTU enn vanlig (sikkert fordi de pakker det inn i et lag ekstra, enten ISP/Leverandør eller HW'n (Q-in-Q eller whatever som gjør at "de spsier" av HW MTU)). EDIT: Usikker på hvor mye du vet om (R)STP, men annen ting du kan styre dette på er ved å sette bridge priorities. Hvis du setter høyest prioritet (lavest tall) på switch 2, vil switch 1 og switch 2 velge "korteste path" (lavest hopp) mot det som heter "root bridge". Setter du alle til samme prioritet er det MAC-adressen som de "velger" root bridge fra. Så min anbefaling er at du eksplisitt velger en switch til å være "root bridge" for å unngå at oppførsel endrer seg om du over tid bytter en switch med ny MAC.

Men nå sammeligner du eple og pære og jeg vil påstå Altibox er på ingen måte verre. Nå er jeg helt enig i at Altibox er heller ikke billig. Stort sett ingen av leverandørene i Norge er billige, absolutt alle har økt prisene voldsomt siste 3-4 år uten at de har økt kvaliteten eller kapasiteten på leveransen noe nevneverdig. Altibox (sjekket vikenfiber) tar 1329 pr. måned for 1000/1000. Telia tar 1379 for 1250/50... Jeg hadde ANY DAY, valgt 1000/1000 fremfor 1250/50. Sistnevnte er kun et "markedsføringsstunt" fra Telia hvor de kan "skryte" at de leverer raskere nett enn andre, men ved at man har så sterkt begrenset upload vil det i praksis si at man ikke klarer å utnytte download på samme måte som synkrone hastigheter ---> Enkel win for Telia, da de kan overselge kapasitet mer enn hvis de hadde levert synkron. Altibox leverer synkrone hastigheter på dedikert linje Ingen GPON eller DOCSIS, hvor begge er delt medium og har teknikker/kryptering/modulering ++ som medfører økt latency+jitter+bufferbloat. Telia leverer på delt medium (mer aggresiv deling av kapasitet ute i aksessnett) SPESIELT Telia som kjører med kraftig overbelastet upload i HFC, det er iallefall min erfaring her, jeg flyttet nylig (solgte bolig) fordi jeg var så lei HFC nettet til Telia. Det er desidert det dårligste internettet jeg har hatt siden jeg hadde ADSL. Hos meg var Jitter + Latency på upload veldig sammenlignbar med jitter + upload man får over 4G. Faktisk så var Telia 4G periodevis (kveldstid) bedre enn uploaden var på HFC. Telia leverer massevis over koaks, mao. man sliter med el-støyproblematikk som man ikke får på fiber Da vil du vel bli skuffet, med så strupet upload vil du mest sannsynlig få en enorm asymmetri i requests som gjør at forespørsler fra din PC hoper seg opp (står i kø) som gjør at du får ikke utnyttet nedlastningshastigheten. Både og, hvis man får levert usymmetrisk linje vil denne effekten bli større. MAO. Ved at Telia leverer usymmetriske hastigheter vet de at throughput i nettet deres nedstrøms (mot kunder, "download") vil gå ned, for klientene til kundene klarer ikke å forespørre servere/andre på samme rate --> lettere for de å overselge kapasitet også nedstrøms. På speedtest og lignende så vil ikke dette synes da speedtest vil sende mer forespørsler mot klient enn det man faktisk forespørrer (for man avtaler, "send meg så masse som mulig og ta tiden"). Derfor vil du også se at du klarer å bruke kapasiteten på tjenester som bruker tilsvarende mekanismer med flere strømmer og gjerne over UDP hvor server kan "dumpe" mer data mot klient, uten at klient faktisk forespørr denne dataen individuelt. Worst case her som demonstrerer dette godt er om man har en VPN forbindelse som går over TCP. I TCP må pakker "ack'es" og da setter begrenset upload en stor demper på "reell throughput" også om latencyen er høyere på upload Sidespor: latency i HFC-nett er på ingen måte synkron, når mange kunder på kveldstid bruker nettet samtidig øker latency på upload kraftig da den er en oversolgt ressurs ---> Blir mer fri kapasitet på download fordi kundene står i "upload kø". Poenget mitt her er vel at dette feltet er ganske mye mer komplisert enn bare hva man får på speedtest og that's it. Usymmetrisk hastighet kan "se fint ut" på en speedtest, og fungere knall til 10x Netflixstrømmer, men fungere svært dårlig på 10x VPN tuneller eller annen trafikk som ikke kan "utnytte" samme prinsipp med å pushe masse data en vei uten "toveis kommunikasjon" mot klient. Og i tillegg til dette, generelt sett når man snakker hastigheter over 100-500 Mbps (ish): Der er mange serverleverandører som "shaper" enkeltkunder slik at en kunde ikke skal stjele all kapasiteten til serveren. Det gjelder spesielt de som har server med 1 Gbps tilkobling (mindre tilbydere). Peeringavtaler hos ISP (hvem kobler til hvem), kapasitet på disse og CDN nettverk får en mye større innvirkning på "reell througput" man faktisk får. Høyere latency mellom klient/server medfører også redusert throughput (og det igjen er sterkt avhengig av teknologi, routing paths og peering)

For meg: Slipper nedetid når de firmwareupgrader hjemmesentral Utstyr som passer bedre i rack og ofte er "dyrere" (mer pålitelig, ex dual PSU osv) "KISS", ved SFP inn i en switch jeg uansett må ha -> Mindre komponenter som kan ryke Når jeg hadde Telia: ~4-5 ms mindre ping Sidespor, men fatter ikke det var mulig, fikk 4-5ms høyere ping i bridgemode, tror de måtte ha software bridget eller noe slikt latterlig, var en inteno boks Har alltid "backupplan" med hvordan deres boks skal kobles i igjen, kobler den alltid inn, bekrefter feil med deres utstyr også før jeg ringer support om det skulle være noe Veldig glad de ikke har GPON så alt dette er mulig

Helt enig! Forøvrig seneste på saken er at 23.10.23 har ESV sendt en "purring" på at Easee må komme med dokumentasjonen de skulle sende inn i september. Easee har nå fått ny frist på 3 uker.

Sant sant, dumt de har valgt et dårlig rele. Men kan det være at Svenskene har gjemt et poeng her?: For hvem slutt-kontrollerer et anlegg når bare bakplata blir installert? Jeg har selv sett her i Norge på et nybygg hvor de installerte maaaange bakplater (tipper over hundre) uten at en eneste kontroll/test med ladeboks ble gjennomført. Altså slik som de beskriver her: https://easee.com/wp-content/uploads/2023/08/EN_Ready_IG_V1_01.pdf Her er det ingen spor å se av etter det en elektriker normalt sett bør gjøre ved sluttkontroll. Altså både funksjonstest, men og "eurotest" av løsningen (el tilsvarende). Så da blir det fort et "hull" mellom installasjonen og faktisk bruk. Er det feks. beregnet riktig vern ifht. ikmin & sett opp mot "fordelingsnettet" fra en felles sikring? Hva med ladeboksen på enden som har mest kabel mellom forankoblet vern og boks? osv osv... EDIT: Altså det jeg mener her er vel mer at Easee da mangler forståelsen for disse problemstillngene og skulle krevd slik kontroll eksplisitt av de som installerer større anlegg hvis de kun skal installere bakplate? Enten kun i manual, eller manual og installatørapp. Ved å ha gjort det, så hadde de vist til svenskene at de har tetta dette "hullet" mellom installasjon og forbruker som kommer med en "berry" i ettertid.

Nåja.... Jeg opplever dette mye som "samme svada" som før jeg? De sier: Men i installasjonsmanual, så står det fortsatt kun forankoblet type-A RCD og DoC erklærer ikke samsvar med IEC 62955. ---> "IKKE ETTER NEK400 BOKEN". MAO. Dette er ikke ihht. anbefalingene fra NEK (400) og med andre ord legger de mer av ansvaret på installatør, som mest sannsynlig ikke klarer å verifisere om det er tilfredsstillende bruddevne i EVSE (Easee Charge Lite) ved alle tilfeller og må dermed installere type-B eller "ulovlig" installasjon ved at man ikke har tilstrekkerlig bruddevne, akkurat som før. En ting som kan endre dette, er om Easee publiserer test som beviser bruddevne på tilsvarende nivå med IEC 62955, men det gjør de ikke. Og hvis de hadde hatt en slik test hadde de nok bare erklært samsvar med IEC 62955.