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?

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.