Ronniehl

Ditto 😑

Np! Om du synes det er lettere å kjøre node direkte er det ingenting i veien for å gjøre det nei! Docker / compose er bare for enkelthets skyld siden det er en grei "standard" som mange har ett forhold til 🙂

Du kan sende variablene enkelt inn til docker run også. Enten med en .env fil, eller i run kommandoen. Kunne selvsagt også lagt dem inn i configfilen, men liker ikke brukernavn/passord i filer som sendes inn.. Eller

Det er enda planen ja. Jeg har bare ikke fått tid til å sette opp en raspberry pi her hjemme å teste med, men håper å få begynt å se på det om ikke altfor lenge. 🙂

Overraskende ofte svaret på det meste det 😆 bra du fikk orna det!

Hvis du går til https://din-homeassistant-url/config/logs, og søker etter mqtt, så kan det ligge noe i loggen der. 🙂 edit: så du fikk det til akkurat nå 😅

Kan du se om det ligger noe i home assistant loggen? Kan virke som den ikke plukker opp entitetene 🤔

Har du sjekket om det kommer flere enheter inn på mqtt-brokeren med f.eks mqtt explorer?

Får du en feilmelding? Ellers tror jeg at @BalleClorin kjører det i unraid, kanskje han har noen tips 🙂

Jeg har pushet ny versjon nå til latest - default er det ingen prefix (så det blir f.eks `binary_sensor.motion_2`). Hvis du vil ha ett prefix i navnene, kan dette legges inn i config-filen, under `mqtt.entityPrefix` 🙂

Uffda @jorgenbl - jeg skal se på om jeg kan finne en måte å gjøre det valgfritt på med navne-prefixet. Jeg la det inn for det var utrolig vanskelig å skille dem når jeg fikk motion_1 til motion_8, så jeg la på navnet som prefix for å gjøre det enklere. Ikke bra om det skal lage problemer i fremtiden, skal finne en løsning på det iallefall!

Har du tatt pull av :latest? Den gjorde ikke det før, men nå gjør den det (hos meg iallefall). Kan du evt ta ut loggen fra containeren og sende meg på dm? Edit: Leste på ny nå, du har fjernet hele enheten 😄 Du kan sette data.reset til "true" i config-filen og restarte containeren, da vil den opprette alt på ny. Jeg skal gjøre en endring som gjør det automatisk, jeg deaktiverte det for jeg mista entiteter i hytt og pokker før når jeg begynte å skrive programmet.

Hepp! En liten oppdatering her: - Har fått det til å virke mot arm32 nå (raspberry pi f.eks) - Håndterer alarm-state endringer via websockets nå (dette var kun via polling før, ungene begynte endelig på skolen så jeg kunne herje med alarm av / på og teste!) Publisert under yusijs/homely-mqtt:latest

Skikkelig rart.. jeg publiserer både arm64 (aka arm64v8) og arm (arm32v7). Jeg må se litt mer på disse plattformene seinere, er vel bare ett flagg som må tweakes. Jeg prøvde meg igjen nå med qemu, kan du teste @torhaala? Hvis ikke må jeg prøve å få opp en rpi4 jeg kan teste med 😅

Jeg forsøkte å publisere kun arm nå, uten 64 - kan du teste det? Jeg har ikke en ledig pi4 å teste på, så får ikke verifisert 🙈

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 😅

Publisert ny nå, måtte visst spesifisere v8..

Så rart.. den er definitivt publisert: https://hub.docker.com/layers/yusijs/homely-mqtt/latest/images/sha256-3a801522b17085dcb2cb83a39c3b6b0e234a15efbcbfa05950c205ceeb97913b?context=explore Har ikke laptopen i umiddelbar nærhet her, må nesten se i morgen. Mulig du kan ta en pull direkte på sha-referansen?

Hvis du prøver å ta en ny pull nå av latest? Jeg la inn arm64 i tillegg til amd64 nå. Er mulig jeg må inn med enda flere, men vil ikke bygge for masse gamle arkitekturer 🙂 (mulig du må slette det gamle imaget med docker rmi først for å få riktig arkitektur)

Det kan virke som arkitektur-problem. Jeg skal endre bygg til å gå mot flere archs, tror jeg bare bygger for amd64 nå

Jeg har den samme bryteren, og den er litt.. snodig. Med deconz fikk jeg bare opp batterier (som deg), og den falt ut i hytt og pokker. I zigbee2mqtt får jeg opp en "Action" utløser, altså ikke egne "knapper", men da kan jeg iallefall bruke den i automasjoner:

Njaei, jeg har faktisk bevisst lagt opp til at applikasjonen kan krasje, og at restart skal håndteres av docker. Noen feil/hendelser vil uansett måtte håndteres på den måten (f.eks hvis prosessen går tom for minne, docker krasjer eller du rebooter serveren din), så det mest logiske imo er at det håndteres automatisk. Det sagt, så har websockets automatisk reconnect, så rart at det stanset hele applikasjonen. Skal se på det, og kan nok også legge inn at polling skal feile mer gracefully. Problemet da er jo hvis vi får en situasjon som i går hvor homely sitt api er nede, så vil applikasjonen kjøre som om alt er helt fint. Selv foretrekker jeg at det krasjer helt så jeg kan se at det krasj-looper og at noe er gæli 🤔 Jeg får tenke litt på det, kanskje jeg kan legge inn ett config-flagg e.l for det 🙂

Har dyttet noen endringer og publisert på latest-tag. Skal være stabilisert med logging etc nå, og har lagt inn mulighet for å definere discovery/state-topic prefixer nå i config 🙂 Ellers håper jeg på litt tilbakemeldinger på om det er ting som ikke virker som det skal, eller eventuelle forbedringer 🙂

Jeg så noe lignende når jeg feilsøkte tidligere, det er noe med debug-loggeren; hvis du setter debugLevel til info så tror jeg det løste seg for meg. Begynte å se på det, men fikk ikke helt tid til å forstå hvorfor den feilet. Ser mer i morgen, men prøv å endre logLevel så bør det funke!

Ikke uenig 😅 håper ikke det vil være normalen! Oppe igjen nå 😄 For de som lurte (@ottob), har jeg lagt inn dokumentasjon på homely apiet i github repoet mitt (github.com/yusijs/homely-mqtt)