Terje2k

Det er ikke slik at man bare kan "oppdatere samsvarserklæring" fordi det kommer nye regulatoriske krav. Slikt underbygger hele CE modellen. Igjen rødt flagg, useriøst med mangel av respekt for alle installatører/kunder. Skulle de absolutt hatt støtte for dette skulle de lansert nytt produkt med ny testing som dokumentasjonspakke bak DoC.... Det er realiteten for alle andre, med påfølgende kostnader, time to market osv...

Nei, det interessante er om boksen har god nok total sikkerhet ifht. hva alle andre må forholde seg til. Kan du gjerne publisere hvor du har bekreftelsen fra annet enn en pressemelding / mediaomtale? Samsvar med IEC 62955 er vel så aktuelt som eventuell annen jordfeilvern standard. For meg ser det ut til at Easee har hatt en stor konkurransefordel ved å jukse og dermed tatt store markedsandeler av den årsak, spesielt på større ladeanlegghvor Easee har tatt store snarveier når det kommer til sikkerhet. Vi graver ikke i gamle DoCer, de jeg publiserte i går var ferske. Du viser elegant frem hvor lite du kan om dette temaet. DoC er ikke noe som skal "oppdateres regelmessig", faktisk så skal den være laget ferdig FØR produktet settes på markedet. Så bare at de redigerer på den i ettertid, også på det "nye" produktet "charge lite" et stort rødt flagg, useriøst med mangel av respekt for alle installatører/kunder. INGEN installatører/kunder kan forholde seg til "godkjent via presseomtale". Så da får vi vel bare vente å se på den "nye dokumentasjonen". Gleder meg! Hvem du stoler på er din sak, men bare så det er tydelig, hvis du går bakover i denne tråden er det bevist flere ganger at Easee har snakket usant i media når man har sammenlignet med hva som fremgår av sakspapirene. Med andre ord, du velger å stole på noen som er tatt tidligere i juks. Du om det. De har på ingen måte "sammarbeidet med de fremste ekspertene i verden!". Du går rett på markedsføringsbullshit'n deres som de har blitt tatt på tidligere. I praksis har de nå betalt masse folk for å finne smutthull. Bestilligen var vel noe ala. dette: "Vi kan betale masse om du finner en måte vi kan få 820 tusen ladebokser "godkjent" uten å endre på hardware, og du kan få bonus om du kan sette navnet ditt på det". Siden du ikke klarer å se hvordan de har lirket inn en gangbar løsning med IEC 62955, så viser du atter en gang på en elegant måte hvor lite kunnskap du har. Har du lest standarden(e)?

Hva mener du? Begge de DoC jeg refererte til her er det jeg fant tilgjengelig på nettsiden til Easee.com i dag. Sjekk selv. De to DoC var for "nytt" produkt (Easee Charge Lite) og "gammelt" produkt (Easee Charge og Easee Home). Dette stemmer ikke. DoC for charge lite (som jeg la ved) ble endret få dager før de annonserte i media..... 08.05.2024 https://easee.com/no/artikler/nyhet/easee-oppdaterer-charge-lite-samsvar/

Dette er ikke til å bli klok av, virker som Easee jobber hardt med å forvirre for å oppnå "ok". Inne i dette dokumentet https://download.easee.com/m/6ea62dff397fa08e/original/A2f_RDC-DD_Functional_Description_NO.pdf Sier de følgende: Men de glemmer å nevne at frakobling ikke er ihht. IEC 62955. Dette er morro for brukerne: Artig når nabo har jordfeil (IT-nett) og ladeboksen din låser seg.. Pga. disclaimer nederst i dokumentet legger jeg ikke ut screenshots fra vedlagt dokument: Bare jeg som syns toppen av tabell side 3 er missvisende? burde stått "RCCB + Easee" eller mener de nå at de har 60947-2 støtte, men oppgir det ikke i DoC? Prinsipptegning side 4 under "fuksjon" kapittelet: Og hvorfor har de vært så dumme at begge styresignalene går gjennom enheter med programvare? Så selv hvor mye de skryter av "redundans" i styrestrøm er de fortsatt sårbare for programvarefeil og ikke minst relefeil. Jeg fatter ikke hvorfor de ikke har koblet utgang fra detektor rett opp til secondary supply cutoff... A2f_RDC-DD_Functional_Description_NO_v1_03.pdf

Men har de egentlig byttet norm? I media sier de så, men i sist publiserte DoC for "charge lite" ser jeg ikke 61008-1 eller 60947-2 (som de nå sier de har "friskmeldt"): https://download.easee.com/m/1b8687927c80c981/original/ChargeLite-DOC.pdf (vedlagt for fremtiden) Og i sist publiserte DoC for "home / charge" så nevner de kun 61008 med en formulering jeg ikke blir klok av: https://download.easee.com/m/62220696de71b1d6/original/Declaration-of-Conformity-Home-and-Charge.pdf Hva menes med "designed in accordance", når produktet har tydelige avvik ifht. det som står i standard? Easee selv reklamerer fortsatt med at produktet deres har jordfeilvern, dette er på landing page for installasjonsdokumentene: https://easee.com/no/installere-easee/ https://easee.com/no/artikler/guide/slik-funker-jordfeilvernet-vart/ Selv om det eneste produktet de har lov til å selge ikke nevner en eneste jordfeilvern-standard i DoC. For meg virker det som at Easee fortsatt holder på med "cherry picking" av standarder. Hvor de mener det er greit å velge deler av en standard og deler av en annen ifht. hva som passer de. Dette mener jeg underbygger hele poenget med at vi har standarder. Det gjør det også vanskeligere for alle kunder å forstå hva de egentlig har av sikkerhetsfunksjoner. Da må du ta deg en titt i DoC. Produktet har flere alvorlige mangler for å kunne betrakte det som et jordfeil og overbelastningsvern. Det er godt dokumentert og hva Easee sier i media vil ikke endre de fysiske aspektene med laderne som er produsert. Slik det ser ut til prøver de å trikse til seg støtte for deler av IEC 62955 i håp om at det er nok med å kun installere en type-A/F jordfeilvern foran hvert ladepunkt. Uansett vil de ikke klare å støtte IEC 62955 til det fulle (dokumentert tidligere i denne tråden). EU DOC Charge Lite - Signed - 08-05-2024.pdf 07a_Declaration_of_Conformity_Easee_Home_Easee_Charge_240524.pdf

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.