gert

Må si jeg likte disse bryterne: Men artikkelnummer 704.085.95 er tydeligvis historie. Mulig ette er gammelt nytt for de som følger mer med enn meg, men ble litt skuffet da jeg skulle ha et par til. De er små, diskrete, relativt intuitive (selv mamma skjønner hva som er av og på når hun er på besøk) og de passet på standard vippelokk til lysbrytere. De nye er jo rett og slett ikke særlig pene: Det blir i hvert fall ikke spesielt pent å feste disse utenpå eksisterende lysbrytere, som er løsningen jeg har gått for der jeg har satt smartpærer i eksisterende lamper med bryter montert på vegg. Typisk at de fjerner produkter jeg synes er bra og erstatter dem med noe jeg synes er dårligere. Jaja, jeg får flytte noen av de frittstående gamle jeg har der jeg trenger brytere på eksisterende lysbrytere, og benytte de nye som frittstående. De er jo ikke direkte stygge, de heller.

@Ronniehl har du fått sett noe på bug-en jeg beskrev på forrige side, og er det noe mer jeg kan finne frem av debug-logger for i finne ut hvorfor homely-mqtt kun sender config messages for tre enheter (evt hvorfor det bare plukkes opp tre av mosquitto i HA)? Mqtt explorer viser at bare te enheter har fått config topic under homeassistant-topicen. Alle enhetene dukker opp under homely-topicen, men for de enhetene det ikke finnes noen config topic for, hjelper ikke det, de dukker uansett ikke opp i Home Assistant. Av de tre sensorene som dukker opp, er det både særnorske tegn (ø) og mellomrom, så det er jo rart om det er noe tegnkoding eller tilsvarende som gir problemer. Jeg ser imidlertid i debuloggen at programmet ser ut til å iterere over en del variabler uten å fylle dem dem med data, men er usikker på om det er relevant. I tilfelle kan jo det tyde på at noen variabler av en eller annen grunn ikke er satt, eller ikke blir hentet korrekt. Eks, etter at den har gått gjennom og matchet sensorer med ulike topics(min gjetning): [17:20:59.048] DEBUG (502951): Matched Fjernet_serienummer on Kjøkkenvindu with temperature.states.temperature.value [17:20:59.051] DEBUG (502951): publish :: message `%s` to topic `%s` [17:20:59.051] DEBUG (502951): publish :: qos [17:20:59.052] DEBUG (502951): MqttClient:publish: packet cmd: %s [17:20:59.052] DEBUG (502951): _sendPacket :: (%s) :: start [17:20:59.052] DEBUG (502951): storeAndSend :: store packet with cmd %s to outgoingStore [17:20:59.052] DEBUG (502951): _removeTopicAliasAndRecoverTopicName :: alias %d, topic %o [17:20:59.052] DEBUG (502951): noop :: [17:20:59.052] DEBUG (502951): _writePacket :: packet: %O [17:20:59.052] DEBUG (502951): _writePacket :: emitting `packetsend` [17:20:59.053] DEBUG (502951): _writePacket :: writing to stream [17:20:59.053] DEBUG (502951): _writePacket :: writeToStream result %s [17:20:59.053] DEBUG (502951): _writePacket :: invoking cb [17:20:59.053] DEBUG (502951): noop :: [17:20:59.053] DEBUG (502951): _sendPacket :: (%s) :: end [17:20:59.053] DEBUG (502951): publish :: message `%s` to topic `%s` [17:20:59.053] DEBUG (502951): publish :: qos [17:20:59.053] DEBUG (502951): MqttClient:publish: packet cmd: %s [17:20:59.053] DEBUG (502951): _sendPacket :: (%s) :: start [17:20:59.053] DEBUG (502951): storeAndSend :: store packet with cmd %s to outgoingStore [17:20:59.053] DEBUG (502951): _removeTopicAliasAndRecoverTopicName :: alias %d, topic %o [17:20:59.053] DEBUG (502951): noop :: [17:20:59.053] DEBUG (502951): _writePacket :: packet: %O [17:20:59.053] DEBUG (502951): _writePacket :: emitting `packetsend` [17:20:59.053] DEBUG (502951): _writePacket :: writing to stream [17:20:59.054] DEBUG (502951): _writePacket :: writeToStream result %s [17:20:59.054] DEBUG (502951): _writePacket :: invoking cb Her antar jeg at de ulike variablene helst skulle hatt et innhold, utenat jeg blir klok på hvorfor det ikke er tilfelle. $SYS-topicen til mosquitto viser 0 dropped messages. Kjøkkenvindu er forøvrig ikke en av de sensorene som har noe config topic. Resultatet er det samme uansett om jeg kjører som en local addon direkte på Home Assistant, eller kjører npm-appen direkte fra laptopen, men debuglogen er hentet fra laptopen.

Jeg fant bug-en som gjør at state topic settingen ikke fungerer i discover.ts fra linje 11: const configTopic = config.get<Config['mqtt']>('mqtt').topicPrefixes?.config ?? 'homeassistant'; const stateTopic = config.get<Config['mqtt']>('mqtt').topicPrefixes?.config ?? 'homely'; De henter samme verdi. Så hvis du setter dem, vil state topic også bli det samme som config topic. Men om du ikke setter dem, går de for defaultveriden (som er ulik). Jeg snakker imidlrtid ikke typescript, og forstår ikke hvor det går galt i gjennomgangen av sensorer. Eller om det er der det går galt. Jeg sjekket loggen, og der så det ut som om det ble laget config-messages for flere enn de tre sensorene. Å poste de samme beskjedene til mqtt-brokeren igjen resulterer i at enhetene blir oppdaget (eller enheten, jeg testet kun med to entities.) I og med at det hjalp for Teryeah å skru av Ringmqtt, lurt jeg litt på om det kan ha noe med at mqtt-brokere blir overbelastet å gjøre, men det er jo helt usannsynlig at dette skal skje etter akkurat tre config messages hver gang, og å skru av zigbee2mqtt hjalp heller ikke. Jeg finner ikke noen måte å få detaljert nok debug-info ut, men dersom det skyldes en ovebrelastning et sted, er vel det mest sannsynlige er vel at QOS 2-prosedyren for mqtt-pakker med Publish - Publish received (PUBREC) - Publish released (PUBREL) - Publish complete (PUBCOMP) feiler, enten pga. en feil i pakken din Ronniehl, eller i mosquitto brokeren i repoet til home assistant. Det kaaaan jo være mosqutto-broker, men mulig det kan være noe i dett prosjektet som feiler også?

Jeg har feilsøkt litt, og det viser seg at homely_mqtt kun sender en discovery message for tre enheter. jeg har sjekket med Mqtt explorer. Kun de tre enhetene det sendes en discovery message for, ukker opp i Home Assistant (logisk nok. Jeg er usikker på hvorfor den bare sender en discovery message for tre enheter. Men dette var de tre første enhetene i dahsbordet i Homely-appen, utover alarmentralen. Jeg er usikker på om det er tilfeldig, eller om det har en sammenheng. Å endre rekkefølge på enhetene i dashboard i appen har ikke noen effekt, så det kan hende det er en tilfeldighet. Jeg har forsøkt å slette innholdet i databasen i pluginen ( reset: true) og endog bygge pluginen på nytt, det er alltid de samme tre sensorene som dukker opp. Selv etter å ha endret navn på dem. Så et eller annet tyder på at den støter på en feil når den går gjennom listen over sensorer og skal lage discovery messages. En annen bug: state option under topic prefixes i config-filen fungerer ikke. Dersom jeg setter en verdi her, publiserer den state messages under homeassistant topic, i stedet for homely-topic, og ikke til verdien jeg angir under state. Entity prefix fungerer imidlertid Forøvrig publiseres state på alle sensorene tilsynelatende korrekt, og jeg kunne antakelig lagt de til manuelt i home assistant-konfigurasjonen, men det er veldig rart at den bare publiserer discovery message for tre enheter, når den publiserer state for alle. Noen spesielle debugging-steg jeg kan ta, @Ronniehl? Et forbedringsforslag/ønske med det samme: Det er en fordel om state topic er navnet på enheten, ikke serienummeret(?). Det gjør både debugging og håndtering av enhetene lettere når man nøster i ting. I tillegg ser det ut til å være standard for andre mqtt-dingser, enten de kjører tasmota, openbeken eller kommer fra zigbee2mqtt.

Så, dette fikk jeg først opp og gå uten docker. Så fikk jeg til å pakke det som en home-assistant local addon, som både startet og listet opp alle sensorene mine. Etter å ha fjernet div debugging, tenkte jeg jeg skulle teste en siste gang før jeg delte den her, og nå virker det ikke lenger. Jeg får kun følgende feilmelding: nodemon] 3.0.1 [nodemon] to restart at any time, enter `rs` [nodemon] watching path(s): *.* [nodemon] watching extensions: ts,json [nodemon] starting `ts-node index.ts index.js` (node:136) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. (Use `node --trace-deprecation ...` to show where the warning was created) [21:38:49.844] INFO (136): topic: "homely/notice" message: "Homely is online" [21:38:52.209] INFO (136): Starting service [21:38:53.143] WARN (136): Application encountered a fatal error and will exit. [21:38:53.143] ERROR (136): Invalid time value err: { "type": "RangeError", "message": "Invalid time value", "stack": RangeError: Invalid time value at Date.toISOString (<anonymous>) at Authentication.<anonymous> (/app/homely/auth.ts:31:9) at Generator.next (<anonymous>) at fulfilled (/app/homely/auth.ts:5:58) at processTicksAndRejections (node:internal/process/task_queues:95:5) } [nodemon] clean exit - waiting for changes before restart Dette var kun endringer i Dockerfile og run-scriptet i home assistant addon-en, og jeg jeg har vondt for å se at noe av det skulle forårsake denne feilen, men det er jo alltids litt spøkelser i maskineriet. Noen tips til hva dette kan være? Jeg forsøkte også å teste med test-sdk.iotiliti.cloud, men får samme feil. jeg ser funksjonen er i tilknytning til henting av token og kalkulering av utløpsdato(?) for denne. Kan det være at denne funksjonen feiler fordi jeg f.eks. nylig hentet en token, før jeg slettet addon-en og installerte den på nytt for å teste endelig versjon (iny container)? En eller annen from for tidsbegrensning eller noe fra Homely, muligens. edit: Får akkurat samme feil når jeg forsøker å legge inn helt feil passord. Så antar det er noe på Homelys side, mulig IP-addressen min ikke får lov å logge inn på en stund. 😛 har dobbeltsjekket at passordet er korrekt i hvert fall. Får se om jeg får tid til å kikke på det i morgen. Ny edit: Det skyldtes antakelig noe tilgangsbasert. Nå er den oppe og går som addon, men ikke helt klar for prime time enda, den nekter å mate inn mer enn tre enheter. Fant du hva problemet ditt skydtes @Teryeah? Virker som du hadde samme issue. Jeg har ingen andre mqtt-addoner enn zigbe2mqtt, som jeg ser av loggen at du også hadde. Hos deg var det bare Ring-addonen som skapte problemer?

Takk, jeg er ikke så kjent med docker, de mgangene jeg dessverre må forholde meg til det, er jeg stort sett vant til at de kommer med alle filene i en github, så man bare gjør en git pull, og fyller inn compose-filen selv. Mulig jeg heller bare prøver å kjøre node-prosjektet direkte, siden jeg fant githuben din. Da kan jeg kanskje kjøre det direkte på TrueNAS-serveren også, og slipper å prøve meg frem med å få det inn som en container i Home Assistant.

Jeg stusser litt på dette docker-opplegget du har valgt. Kjører en docker pull, legger config filen der den skal være iflg. compose-filen, men ser det er mange environment-variabler du har hardkodet i compose-filen i stedet for å la være variabler som hentes fra config. Kan ikke skjønne at det der mulig å kjøre denne fra docker image. Hvis meningen er at alle må bygge basert på compose-filen, hvorfor legge den ut på docker hub som et image?

Si ifra hvis du vil ha noen til å teste addon, jeg har nettopp bestilt Homely-pakke. Gikk for Homely over Atlo til tross for litt dyrere månedspris, nettopp på grunn av API-et og muligheten for sanntidsinfo fra sensorene. Orker ikke dobbelt opp med sensorer.

Ok, takk for feedback til begge, Etter å ha hatt litt ubudne gjester luskende rundt i hagene her på nattestid i det siste, har vi gått for alarm fra Homely, som lar seg integrere via home assistant (kun med lesetilgang) så vi slipper å ha dobbelt opp med sensorer, men kan automatisere basert på hendelser fra sensorene i alarmsystmet. Homely har plug-in modul til L3, så kan hende jeg like gjerne går for den, men faller vel like fullt for fristelsen til å prøve å sette det opp direkte med BT bare for å se om jeg får det til. 😛

Jeg får utelukkende "No devices found on the network" fra Yale Access-pluginen. HA-boksen har null vegger mellom seg og låsen, og klar siktlinje, men avstanden er 4-5 meter. Har kjøpt en av BT donglene HA anbefaler, pg er ikke supergira på å ha en esphome-dings limt opp på dørkarmen for å få dette til å fungere. Lurer på å mekke til noe, men vil bare sjekke først at dette fortsatt fungerer for deg, @feddiriko? Ser at L3 ikke er i listen over støttede enheter, og at L2 kun har begrenset støtte, så orker ikke styre med dette hvis de har kuttet støtten.

Nei, visste ikke engang at frekvensforskjeller var en greie på IR. Nå endte vi med en sånn flytbar aircondition i stedet for vifte, som kom med fjernkontroll, så jeg har ikke gjort noe mer research enda. Men det var flere esp-prosjekter med IR som virket lovende, når man ikke hadde for høye krav.

Jeg har ikke lyst til å bli flådd og betale 700kr for en IR-fjernkontroll til en takvifte som er planlagt innkjøpt. Så vidt jeg kan se, har noen vært så vennlige å dele IR-koden allerede. Og siden jeg ikke har tenkt å kjøpe fjernkontrollen, hjelper ikke "self learning"-fjernkontroller meg - de finner jeg mange av. Men finnes det en smart, liten, fjernkontroll man faktisk kan programmere inn med "rådata"?

Jeg tenker alt av montering, inkludet lodding, hadde vært riktig DIY-nivå for min del. Post gjerne info når du har fått til aluminiumsprofiler. Så ser jeg det etter et par måneder neste gang jeg er på forumet. 😛

Dette var jo helt utrolig kult! Av en eller annen grunn syntes jeg nesten det var mest fascinerende at den bokstaverer ut IP-adressen. Og det selv om det tar kortere tid å sjekke i ruteren, enn å vente på at den blir ferdig, så det strengt tatt er unødvendig - for meg i hvert fall, for å selge et ferdig produkt kan det nok være en veldig greit info. Språklig sett er det vel "riktig" å ha grensedragningene ved kvarterene. Dvs. så lenge man sier kvart på, er det IMO riktigst å si fjorten over halv, kvart på og fjorten på. Men her finnes det vel neppe en Språkrådet-"fasit". Jeg kunne også vært interessert i en versjon med "klokken", uten å være helt bergenser. Lurer også på om bokstavene burde vært bittelitt mindre/lavere? Synes ikke lyset fyller hele E-ene f.eks. men dette kan jo være noe et annet diffusjonslag kan avhjelpe. Jeg ser det bare ligger en ferdig variant ute på Finn nå, jeg ville nok vært mer interessert i et kit. Da kan jeg også eksperimentere med diffusjonsmateriele o.l. Veldig spennende hvis du finner en kurant løsning på et annet frontmateriale så man ikke trenger plast foran. Usikker på hvor mange man måtte bestilt for å få dette skåret ut hos en bedrift med egnet utstyr, av f.eks. aluminium? Dette må jo kunne være en crowdfundingidé

Hehe, det er jo i og for seg det jeg vil høre, men man kommer jo innimellom over artikler fra folk som går veldig langt i å sette opp relativt rigide brannmurregler og alt mulig annet. Openwrt bør nok være up to the task, og jeg husker relativt ofte på å sjekke om det kommer en oppdatering. Men tenker jo f.eks. på om jeg burde sørge for at dingsene på IoT-trådløsnettet ikke kan snakke med hverandre. Og har litt lyst til å begrense TV-en litt også, jeg stoler ikke akkurat på atPhillips er kjapt ute med (sikkerhets)oppdateringer. Egentlig en uting at smart-tvfunksjonaliteten skal ligge i selve TV-en, spør du meg.

De fleste dingsene mine er zigbee, og de fleste dingsene som går via wifi er flashet med esphome, slik at jeg er ganske trygg på både sikkerheten, og at de ikke gjør noe "galt" med vilje. Men enkelte dingser kommer jo bare i wifiversjon med proprietær firmware, og i tillegg må de ha internettilgang fordi de ikke kjører noe lokalt API. Disse føler jeg kanskje jeg burde ha noe mer kontroll på, enn jeg har i dag. Jeg kan være ganske nerdete på det meste, men akkurat nettverksoppsett, ruting, brannmur m.m. har jeg aldri vært helt fortrolig med. Jeg har jo likevel ikke lyst til at dingsene mine skal bli en del av botnett, eller bli kompromittert på annet vis og i verste fall gi tilgang til hjemmenettverket, andre smartdingser e.l. vil gjerne ha noen tips til om jeg tenker sånn ca riktig her, og gjerne tips (og lenker til guider). Jeg kjører openwrt på en TP-Link Archer C2600-ruter btw. I dag kjører IOT-dingser primært på et eget wifinett, som ikke får lov å snakke med resten av nettverket mitt. Men de har fri tilgang til hverandre, og de har fri tilgang til internett, så nyttige botnet-deltakere kan de fortsatt bli. Vaskemaskin, varmtvannsbereder, utendørs smartplugg: Jeg anser disse for å utgjøre en svært begrenset risiko. Vaskemaskinen (en LG) må være skrudd på for å kunne kommunisere med. Noe sensitive data inneholder den jo heller ikke. Varmtvannsberederen (Høiax Connected) er innenfor reklamasjonstid i fem år til, og har vel fysiske sikkerhetsanstaltninger som sikrer at den ikke kan bli en trykkoker-bombe. Den utendørs smartpluggen styrer en lyslenke. Ikke akkurat kritisk. Bør jeg gjøre noen ytterligere sikkerhetsforanstaltning på slike dingser? Er det verdt jobben med å lage egne brannmurregler for hvem av dem som kun lar dem kommunisere med whitelistede IP-er e.l. Er det verdt styret? Bør de isoleres fra andre dingser på IoT-nettverket (og i tilfelle hvordan)? Dørlås (Yale L3) Kjøres på samme IoT-nettverk som alle andre dingser. Antar at et eventuelt angrep på disse låsene vil komme via Yale/August sin skyløsning og ikke lokalt. Men den bør kanskje likevel isoleres fra resten av IoT-dingsene? Hvordan, i tilfelle? Kamera (Tapo C200) Når vi er hjemme er kameraet vendt mot veggen, og i tillegg strømløst. Nr vi er hjemmefra, har det strøm, og er vendt mot inngangsdøren. Kjøres på samme IoT-nettverk som alle andre dingser. Antar også her at et eventuelt angrep på kameraet vil komme via leverandørens skyløsning og ikke fra andre dingser lokalt, eller tileldige angrep på nettet (antar dette ikke er direkte kontaktbart fra nett, som utgangspunkt. Men kameraet bør kanskje isoleres fra resten av IoT-dingsene? TV (Phillips 55OLED803 - Android TV) Denne er per i dag koblet på det "ordentlige" wifinettverket. Må jo ha relativt fri internettilgang, den skal jo streame fra diverse apper. Er på hjemmenettet pga. problemer med casting og streaming når den er på eget nettverk. Tips. Forventer ikke at noen skriver en lang og detaljert redegjørelse på alt dette altså, men om noen har noen generelle tips, tas det imot med takk.

Varmtvannsberederen trenger enten bytte av blandingsventil eller utskifting, og siden den er 17 år gammel, frister det med en ny. En ny bereder må selvfølgelig være smart, og også kvalifisere til Enova-støtte: https://www.enova.no/privat/alle-energitiltak/smart-varmtvannsbereder/ Ett av kravene, som tilbyr planlegging utfra strømpris innebyget eller via leverandørens løsning er det et eget separat krav at: "Berederen skal også være tilrettelagt for styring fra ulike typer smarthus-system som en del av helhetlig strømstyring i boligen. Det betyr at berederen må kunne kommunisere via de vanligste åpne kommunikasjonsprotokollene for smarthusteknologi." (min utheving) Og her stusser jeg veldig på Høiax connected. Den leveres nemlig ikke med noe annen støtte enn wifikommunikasjon via deres lukkede og proprietære løsning. Jada, den løsningen igjen, har et API. Men det går via deres skytjeneste. Så vidt jeg kan se, kan ikke Høiax connect-beredere kommunisere med NOEN av de vanligste åpne kommunikasjonsprotokollene for smarthusteknologi. Den kommuniserer via wifi, som med kan sies å være en protokoll som er vanlig for smarthusteknologi, men det er ikke mulig å kommunisere med berederen via dette. Berederen kan tilsynelatende utelukkende kommunisere med Høiax sin skytjeneste. Den ser ikke ut til å støtte hverken Zigbe, Zwave, eller wifi-tilgang lokalt. Jeg ser Høiax markedsfører ENOVA-støtten sammen med produktet, så jeg antar at det er en mangel dersom produktet ikke kvalifiserer, og at det er trygt å bestille. Men jeg kan altså ikke skjønne at løsningen oppfyller akkurat dette ene obligatoriske kravet, selv med relativt store doser godvilje til en regntung onsdag å være. Og jeg er ikke helt sikker på om jeg stoler på at Høiax sin skyløsnig er der om 25 år, men det mener jeg berederen bør være. Er det noen andre som har stusset over dette?

Ikke dumt spørsmål i det hele tatt! Snarer dumt at jeg ikke tenkte på det. Det er jo åpenbart den beste løsningen, hvis det er plass. Jeg så vant til å tenke løsninger som ikke krever elektriker, med modifisering av vippelokk og diverse, at jeg ikke tenkte "bredt" nok. Som L-A skriver, er ikke de utvendige målene like, dessverre. Så elko-bokser og rammer er større enn Namron sine utvendig. Men målene inne i rammen (55x55) er kompatible.

😆 Noen ganger er ting enklest i node red, noen ganger er et enklest i yaml eller noe annet. Jeg syntes det var null stress å lage en .yaml til esphome for å styre fire forskjellige uttak med ulike trykk på en enkelt knapp, med enkelt-, dobbellt-, og trippelklikk samt to ulike trykk+hold-deteksjoner, men har revet ut noe hår i forsøket på å lage en node red flow som gjør noe av det samme for en annen bryter som allerede styrer noe i node red (for akkurat det var enklest der) og som jeg ikke har lyst å ha to steder...

Jeg har enkelte lys styrt av bevegelsessensor, der det dels pga WAF og mye for å unngå forvirring fra gjester, er ønskelig med en gammeldags kontroll også. Jeg kjøpt derfor noen Namron ZigBee 4 i 1 vridimmer. Jeg har en elektriker innom fra tid til annen om dagen i forbindelse med baderomsrenovering (dessverre) og fikk ham til å fjerne en bryter/innmaten i en boks. Men jeg er ikke imponert over resultatet: Det er en standard Elkoboks på veggen (eller i hvert fall stod det en Elko-bryter i), og Dimmerfjernkontrollen skal være "Tilpasset standard veggbokser og rammer." Så dette synes jeg er litt rart. Elektrikeren jobber ikke for meg men for badeentrepenøren, så jeg synes liksom ikke jeg kan ringe og bry ham heller. Han skal imidlertid bytte en dimmer på badet som ikke pusses opp og gjøre noe småplukk for meg neste gang han er innom, på min regning (men uten noe kjøretilleg og materiellpåslag 😃) og det hadde jo vært fint om jeg kunne ha funnet en annen, penere løsning enn dette til da. Han kan jo helt sikkert ta med noen standard Elko-rammer til den boksen (og kanskje gjerne en grunnere boks). Standard Elkoramme passer rundt dimmeren av bryteren, hvis jeg tar av rammen som fulgte med, det har jeg testet, men det vil jo ikke matche helt med namron-bryteren. Jeg vil helst bruke rammen som følger med, men er usikker på hva slags boks som passer hvis denne boksen ikke passer. Er det noen som har disse dimmerfjernkontrollene i en boks som ser pen ut, og i tilfelle hvilken?

Nei, derav "Men når jeg ser på det igjen,(...). Kikket bare litt kjapt første gang, så koblingsskjema, og tenkte "strøm" litt forhastet. Da må du fortsatt velge mellom halvparten så mye funksjonalitet eller dobbelt så mye plassbruk. En dobbelt vippebryter hadde jo vært genialt til disse.

Jeg trodde også det først, men så så jeg et koblingsskjema, og trodde det motsatte. Men når jeg ser på det igjen, antar jeg at man bytter ut strømledningene i bryteren med ledningene til namron-bryteren, og at den føler når kretsen er lukket. Man må jo da få plass til både namrondingsen og en wago-klemme e.l. for å sammen med bryteren i boksen, men det kan vel gå. Ikke det helt store bruksområdet for all funksjonaliteten med vanlige brytere riktignok, de er jo enten av eller på, og langtrykk for å dimme lyset blir jo da vanskelig Hvis man nå bare fikk pene dobbeltbrytere som liknet ELKO-materiell og hadde impuls både opp og ned, hadde det jo være ekstra nyttig, med vanlige brytere blir jo dimming rimelig knotete å sette opp. Skal man finne brytere med impuls både opp og ned, er det vel greie å bare bytte ut hele bryteren. Mulig det er markeder der impulsbrytere er vanlig denne egner seg best for. Går jo an å bruke den som basis for å mekke lite et eget bryterpanel da, et sted det ikke er så nøye om det passer utseendemessig med noe annet. Man kan jo mekke til noe med små brytere og få mye kontroll på liten plass. Synd det fortatt er såpass dårlig med zigbee-brytere som passer standard 55x55 rammer, du har noen zigbee green power/firends of hue-varianter, men de er litt knotete.

I min jakt på brytere som ser pene ut og passer i standard Elko-bokser, har jeg funnet denne: https://www.elektroimportoren.no/namron-zigbee-foh-bryter-batteri/4512736/Product.html Ettersom jeg primært kjører smarte pærer, er jeg ikke ute etter brytere/dimmere som faktisk er bryter eller dimmere, men fjernkontroller. Er det noen som har testet denne? Dokumentasjonen synes jeg er knapp/dårlig. Men slik jeg forstår det. kobles den til eksisterende brytere som er aktive, altså koblet til strøm? Da faller jo så vidt jeg kan skjønne mesteparten av vitsen bort. Hvis du tar strømmen til lampen med bryteren, skrur den seg jo av, helt uten at denne dingsen er involvert. Er det noe jeg ikke skjønner med bruksområdet til denne? kanskje styre flere pærer på en annen kurs, parallelt med des som er koblet til bryteren man kobler denne til? Men hva er så poenget med dimmerfunksjonalitet? Merkelig..

Usb-vinkeladaptere tar ikke stor plass. de kan jo også bare plugges i panelet, ogligge omtent inntil veggen. F.eks: https://www.aliexpress.com/item/1005001460210050.html Jeg ville ikke betalt for å få montere noe i veggen nå med USB som ikke støtter PD 3.0 med PPS, det er ikke mye fremtidssikkert. Usikker på utvalget der da. Men med PD 3.0 og PPS kan du via adaptere som bygger omtrent null og niks hente ut hva du vil mellom 3.3V-20V i fremtiden.

Hei Jeg liker prisen på denne termostaten: https://www.elektroimportoren.no/namron-zigbee-touch-termostat-16a-hvit/4512737/Product.html?utm_source=Voyado&utm_medium=email&utm_campaign=W1022+-+mandag men jeg er usikker på om den gamle gulvtemperaturføleren er av en type den støtter. Den har en liste på side 2 i bruksanvisningen, er dette så standardisert at slikt "alltid" er kompatibelt? Eller risikerer jeg at den ikke vil fungere. Badet er fra 2012. I dag er det en gammel dum termostat der med et hjul som lar deg angi gradene, så jeg håper at den i hvert fall har en temperaturføler. Jeg antar dette er urealistisk mye styr å eventuelt bytte ut, de er vel fort støpt ned i gulvet? Egentlig kunne jeg tenke meg å benytte en romtemperaturføler i baderommet (termostaten sitter på utsiden av baderommet, så den innebygde vil ikke være til mye hjelp. Men det virker ikke som om det er mulig å basere seg på å sende zigbee-kommandoer eller manuell programmering for å angi en viss effekt, man må basere seg på å sende den en temperatur.