gert

@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?

Ronniehl skrev (På 14.8.2023 den 10.16):

 

Docker eller node nå, men må kjøres som ekstern tjeneste. Jeg har lite erfaring med python, og jeg har allerede drøssevis av custom integrasjoner jeg har laget selv som kjøres i docker, så det ble den enkleste løsningen for min del. 

 

Edit:

Ser for meg å bygge den som en addon etterhvert, det vil forenkle prosessen for de som kjører på rpi og andre installasjoner med addon-store. Jeg har bare ikke mulighet til å teste det siden min installasjon kjører i, you guessed it, docker 😅

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.

aleks skrev (På 5.9.2023 den 21.54):

Jeg har hatt mest flaks med å bruke esphome proxies for L3 yale doorman. De fungerer svært godt vs en BT dongle (faktisk offisielt anbefalt å bruke proxy over dongle da proxy er raskere). Det du ikke må glemme er å klikke på settings på integrasjonen og aktiver konstant tilkobling. Da reagerer den lynraskt. Den bruker mer batteri når den står i den modusen, men er i hvert fall svært rask respons. Ikke umulig å sette en automasjon som slår av den konstante tilkoblingen når en sover og er borte slik den ikke står og holder på tilkoblingen.

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.

Ruben_L skrev (På 15.6.2023 den 23.15):

Mulig du kan lage en arduino basert fjernkontroll. Vet du hvilken frekvens IR den bruker? Hvor fant du IR-kodene? Jeg har selv en takvifte jeg kunne tenkt meg å smartstyre.

 

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"?

ogagits skrev (På 12.11.2022 den 0.12):

Lage spesifike brannmur regler kan bli jobb og følge opp, eks når døra plutselig ikke får kontakt med serveren - om leverandøren bytter IP.

Legg de IoT på forskjellige VLAN via AP. 
TVn hadde jeg knyttet til hjemmenettverket med tanke på streaming som du skriver. 
Når hver av enhetene er på VLAN kan man ta jobben, om man vil med og lage ekstra brannmur regler.

Virker som du har gjort mye av jobben allerede

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?

L-A skrev (16 timer siden):

Muligens dumt spm, men kan ikke hele utbyggingsboksen fjernes? Ser ingen ledninger som går inn/ut av den på bildet, ergo bør alle ledninger gå inne i veggen.  Da kan du sette namron rammen rett på veggen.

Som du selv skriver så er ikke målene på en namron- og en elko-ramme like. Singel Elko er 83,6mm og Namron er 80,7mm (utvendige mål).

 

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.

Thorbjørn skrev (8 timer siden):

Namron følger samme standard rammestørrelse på 55x55 så de skal lett gå inn i standard Elko rammer. Men samtidig så følger det og med ei ramme som er helt grei Elko-style om du kun skal ha en bryter.

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.

mongojarle skrev (På 25.8.2022 den 17.56):

Jeg er mye mer komfortabel med javascript enn YAML også.

 

Men, det kan bli rimelig uoversiktlig og rotete i nodered også altså. Dette er bare for å lade en bil... Og det er ikke ferdig, mangler noen funksjoner jeg gjerne ville hatt.

 

😆

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?

Moskus skrev (På 25.8.2022 den 8.37):

Det står vel ingenting her om kobling til fast strøm...

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.

Thorbjørn skrev (2 timer siden):

Eller man kan ha en med to eller tre vippebrytere. Så kan en være dimme opp, og en være dimme ned? Gitt at senderen man monterer støtter det så klart.

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.

Moskus skrev (2 timer siden):

Ser ikke sånn ut:

 

Jeg tolker det som en 4 kanals sender som du kan koble til en vanlig bryter.

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..

evest skrev (På 23.2.2022 den 15.52):

Den kommer med USB plugg som bygger nada på den ene siden (inn i padden) og en helt vanlig USB A som bygger mye på andre siden. På veggen har jeg en helt vanlig dobbel USB kontakt fra Elko:

 

 

 

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.

stigvi skrev (På 18.12.2021 den 16.09):

Her, August - Home Assistant (home-assistant.io) står det at doorman L3 ikke er støttet, men ser i denne tråden at noen bruker det. Hva skal en forholde seg til?

Dørklokkenotification fungerer ikke. Det er litt synd, for jeg hører ikke den innebygde ringeklokken opp på hjemmekontoret.

Men alt annet fungerer fint med min L3.

Kranglefant skrev (12 timer siden):

Du kan jo bruke flere enkle stikk med styring i en kombinasjonsramme og påveggskappe.

Hm, har du tips til noen enkle stikk som kan egne seg til dette? Synes de jeg har sett ser litt større/høyere ut enn vanlige enkle stikk, men kan være jeg tar feil.

Vi har behov for å montere noen nye stikkontakter i gangen, både til lamper, ovner m.m. Siden flere av disse helt skal kunne styres (kamera skal ikke ha strøm når noen er hjemme, elsykkelbatteri skal ikke lade hele natten, osv) hadde det vært fint med stikkontakter med innebygget styring. Men det eneste jeg finner er doble stikk der ett uttak kan styres. Og det kommer jeg ikke så langt med. Da er det bedre, eller i hvert fall mer praktisk, å montere to doble stikk og så montere et treveis grenuttak av hvert i dem som festes til veggen. Ellers blir det mange enkeltplugger som må stå i permanent og stikke et stykke ut av veggen, siden det er påvegg og ikke innfelt som er aktuelt.

Finnes det noen bedre produkter her som jeg ikke har funnet?