torhaala

Så bra - dette ville blitt sørvendt også. Fristet med IDLock såfremt kvaliteten er utbedret ift den første versjonen. Får du byttet/satt individuelle koder via zwave kommandoer? Og slettet/lagt til en og en RFID brikke? På 101 versjonen er det alle ut på en gang, så må de leses inn en etter en.

Hei, sitter å vurderer om jeg skal bytte ut mine to IDLock 101 fra 2017 med 202 eller en Yale Doorman L3S. Hvordan er kvaliteten på de senere versjonene av IDLock (150/202)? Så en annen tråd med slitasjen på panelet, spesielt for de som hadde stått mye i solen (ikke tilfellet for min del). På min 101 flasset den hvite pulverlakkeringen på håndtakene av relativt tidlig og de er blitt ganske løse over tid. Mvh, Tor

Bare ett lite tips hvis du har Heatit termostater - Oppdater til den uoffisielle firmwaren før du evt flytter over (ref alle trådene om issues med set points osv). Bugs'ene i firmwaren lager mer problemer for open zwave enn for HS.. Etter oppdatering fungerer alt kjempefint.

Samme her, bytta fra HS til HA og har ikke angra ett sekund. Kjørte også 2 systemer en stund mens jeg bygget opp automasjonene rom for rom. Zigbee2mqtt for alt zigbee (ikea + hue belysning hovedsakelig) og zwavejs2mqtt for zwave. Flyttet bare controlleren over, utav 30 eller så noder var det bare 3 som måtte inkluderes på nytt.. 2 av dem var ID lock låsene hvor jeg ikke klarte finne passordet/frasen som ble brukt for secure inclusion i HS.

Som bruker kan du kanskje ignorere dette, men utviklere av mqtt plugins må gjøre endringer. Man blir bedt om å ignorere dette hvis det gjelder Zigbee2mqtt osv, av utviklerene deres, da de vil ha endringene på plass før endringen går live i Home Assistant. BalleClorin linket en god oppsummering (fra Z2M): "The change states that MQTT should not provide the device name in the entity names that are attached to the device. So if your upstream MQTT provider is supplying a device name inside the entity name, they should stop providing that information. They should only provide the device name to the device, not the entity." Når det er sagt så vil det nok fungere etterpå uten endringer, men man vil ende opp med en del duplicate entities.

Spoke too soon >.< Tilbake til "exec /usr/local/bin/docker-entrypoint.sh: exec format error" nå, selv om docker ikke klager på arkitekturen som tidligere (den puller linux/arm/v7). Men kanskje det er problemet? v7 er vel 32bit mens v8 er 64bit (rart docker ikke klager som tidligere) Edit: klarer ikke google meg frem til mye matnyttig informasjon her. Virker som linux/arm/v8 skulle vært ett alias til linux/arm64 eller linux/arm64/v8

Nå kan jeg pulle :latest tag'en uten problemer, når jeg får noen minutter tester jeg containeren også.. men so far so good 🙂

Takk for alt arbeidet Ronnie. Sliter desverre litt fortsatt her >.< Istedenfor å bruke portainer har jeg nå kjørt det direkte med docker via ssh for å få litt mer feedback. Slettet imagene og pullet dem på nytt via :latest og @sha256:13edfe1f501e3c6084c48796d7aafdbf8ace5c70d6a2a0d14a5261cfc4b61208 (linux/arm64v8) Når jeg spinner opp compose filen med :latest får jeg som nevnt 'no matching manifest for linux/arm/v8 in the manifest list entries', men når jeg bruker sha256 direkte får jeg 'The requested image's platform (linux/arm64v8) does not match the detected host platform (linux/arm/v8) and no specific platform was requested'. Så det kan se ut som det er 'linux/arm/v8' som mangler fra arkitekturen og ikke 'linux/arm64v8'? Er dette noe 32bit vs 64bit issue? Jeg dobbeltsjekket RPI'en med 'uname -m' som viser 'aarch64' så det burde ikke være det? Docker v24.0.2 / compose v2.18.1

Får dette når jeg pullet imaget nå (på 'latest' tagen) "no matching manifest for linux/arm/v8 in the manifest list entries".

Ah ok - Dette kjører på en RPI4 så det kan godt være 🙂

Hei Ronniehl, Har prøvd å komme igang med containeren din men sliter med at den går i en restart loop "exec /usr/local/bin/docker-entrypoint.sh: exec format error". Er dette noe jeg har fucket til med configen?. Kopierte inn eksempel configen i en yaml fil i config folderen.

samme problemet her når jeg prøver å legge til siste versjon

Takk for tråden og de mange gode innleggene! Handlet 4 termostater fra Elektroimportøren sist år som jeg hadde mye problemer med å inkludere i Zwavejs2mqtt/Home Assistant (fw versjon 4.0). Når de faktisk ble inkludert knelte feilmeldingene/spam hele zwave nettverket, men for det meste ville de ikke inkluderes engang. Løsningen ble å kjøre igang den gamle HS installasjonen og inkludere dem der. Etterfulgt av en kjapp fw oppdatering med den uoffisielle versjonen MrE linket sist over her. Nå fungerer setpoint, rapportering av gulv/intern temperatur og ingen issues med open z-wave lengre.

Hei, Ser på å bytte fra Verisure til Homely selv så dette ser jo helt super ut - takk for innsatsen 🙂 lite spm - er det fortsatt bare mulig med «read only» via api’et eller kan man skru av/på alarmen? mvh, Tor

Det har du nok rett i. Angående å bruke NR standalone, så synes jeg fortsatt HA byr på endel ting som jeg ikke har funnet andre steder. Sinnsykt mye integrasjoner som virker bra, og den letteste dashboard oppbyggingen jeg har vært borti, som at på til ser bra ut. Jeg legger jo opp til automasjon og ikke fjernkontroll, men det er fortsatt flere scenarioer hvor jeg synes det er ganske greit å ha en grei app til å overstyre automasjonen. F.eks smelle på gjestemodus, skru av smekklåsen på dørene, etc - og det hjelper skikkelig på WAF