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.