NilsOF

Nei, de bruker kun 2.4ghz båndet. Det er nok noe annet som gjør at boksene isolerer seg eller deler av seg. feil port, feil vlan, dårlig kabel er også kandidater.

Man vil ikke se feks zigbee på en vanlig WiFi-mottager. Men det skal være en ganske iherdig zigbeedings som konstant klarer å blokkere DHCP. Isolering fra resten av nettet kan skje om det er en nettverksloop på noe vis og spanningtree ikke fungerer også. Om disse boksene har mesh, så slå det av når boksene også har kablet uplink.

Sjekk om DHCP-spoofing er aktivt på en eller flere av boksene. Noe er det som isolerer seg fra deler av nettet.

sjekk IP, gateway og nettmaske klientene faktisk får. ellers kan man gjette så mye man vil uten at det fører noe sted..

Produktene ser jo brukbare ut. Men dersom produksjonen er lagt ned så er de jo omtrent verdiløse?

Bare sørg for at disse Popp utendørs har sterke naboer i z-wave -meshet. De fungerer dårlig når signalet blir marginalt. For å få fruens motorvarmer i garasjen tilå virke så satte jeg en Aeotec extender i nabostikket for å få Poppen til å virke..

Den Nexaen er i utgangspunktet ett potensialfritt rele. I praksis for ditt bruksomeråde så utgjør ikke en loddekladd kontra wago noen forskjell. 🙂 Det man må huske på er at den ikke lengre er å anse som potensialfri da ene relekontakten blir modifisert fast til 220volt.

Potensialfritt betyr at relekontaktene er helt uavhengig av drivspenning. Derfor må reletilkoplingene være fysisk adskilt fra drivspenning.

Det vil sikkert fungere siden det er ett potenisalfritt rele, men det kan skape litt forvirring når releet må skiftes en gang i fremtiden. Tror ikke du får noen elektrikker til å godkjenne det heller. 🙂

Nei, de publiserer ikke. Om de da ikke har begynt med det de to siste måneder. Men, de nyere Hue pærene har bluetooth som muligjør oppdatering via Hue-appen.

Dette er ett reelt problem med "symfonisk". Den fyller opp zigbee-meshet når hjulet roteres, så ikke noe rart at enkelte systemer får problemer. Min erfaring/intrykk er basert på sniffing av zigbee-nettet. Antallet pakker som hjulet spytter ut er rett og slett brutalt.

Jeg har Ubiquiti aksesspunkter, tre stk. er nok til å dekke ett langt trønderlån inndelt i to husstander. Disse er matet fra en Ubiquiti poe switch. Dette fungerer utmerket. Ubiquiti sine routere/brannvegger fant jeg for "lett" Jeg er av den formening at så lenge aksesspunktene er matet med ethernettkabel så er man godt forspent. Ordet "Mesh" får mine gardiner til å blende av fullstendig. Om man nevner streaming/video samtidig, da har jeg bygd mur 😉 En DHCP -server/scoope pr. nettverkssegment/VLAN er en selvfølge.

Jeg skulle også hatt noe zigbee halvfabrikata for spesialtilpassede dingser. Disse kanskje: https://www.digistore.com/category_s/2862.htm Så spørs det hvor enkelt det er å få greiene til å henge samen med diverse zigbee-definisjoner. Selve detaljene i Zigbee er enkle i seg selv, mens hele spesifikasjonen kan best beskrives som enorm 🙂

Avhengig av bruksomerådet; man trenger i de fleste tilfelle USB-porter og ethernett port.

En Adalm pluto aka. Pluto-sdr. Bakgrunnen er at jeg vil se hvordan Zigbee og de andre greiene på 2.4ghz samspiller. Så gjenstår det å se om jeg klarer å få noe matnyttig ut av dette 😄

@gert Jeg fikk samme problem med deformert jordingsforbindelse på Ikea sin plugg her nå.. 😕 Ved nærmere inspisering av jordingsforbindelsene er jeg skeptisk til å ratingen på 16 A på disse. Nåvel, man får nok som man betaler for.. Men hold oss gjærne oppdatert hvordan det går med Deltaco pluggene!

Dette vil jeg høre mere om! 😄 Jeg har siktet meg inn på snapcast som multi-roms løsning, mest sansynlig med no rpi, som faktisk er kapabel til å kjøre no DSP i sw. Mitt problem er at jeg ikke finner tid til å gjøre dette...

Sameksistent med div fabrikat fungerer fint. Jeg har ennå tilgode å teste -25 grader. Men siden radioen genererer litt egenvarme tror jeg det vil gå bra. Jeg har hatt noen tilfeller med at Ikea-pærene faller ut av meshet når 220volt speninngen har vært ustabil. Hue-pærene har tålt det. Ganske irriterende. Jeg kommer til å gå for White Ambiance Hue-pærer fremover. Jeg liker muligheten for automatisk justering av fargetemperaturen.

Jeg har ikke tid til å studere loggene dine i detalj nå. Du må nesten se om du klarer å finne noen mening eller rød tråd i dette selv med litt prøving og feiling 😉

Jeg gjør akkurat som du beskriver, med en miks av zigbee og z-wave. Fordelen er at man kan velge fra 2 standarder på hvilke dingser som passer bruken best. Foreløpig er Zigbee mest brukt utendørs, da det er praktisk for meg å bruke zigbee-pærer/lys for å utvide meshet. Resultatet er at jeg har lengre rekkevidde på zigbee en det er på z-wave. (4 hopp-grense i z-wave og stort areal med flere bygninger å dekke)

@putrid Når en endring gjøres fra openhab så vil en "xxx predicted to become aaa" -linje komme i event.log (dvs, det sendes ut i meshet) Når verdi kommer inn fra dings til openhab logges "xxx changed from aaa to bbb". MEN, når en dings ikke er på nett kommer også denne linja opp i loggen og "bbb" er da siste motatte verdi fra dings. Jeg sjekket akkurat dette i men egen logg på en lampe som ikke har strøm. Z-wave må ha litt tid på å stabilisere seg. At systemet passerer "Heal time" hjelper når nye dingser legges til. Alternativt kan man kjøre "Syncronize network" manuelt på z-wave-stikka. Jeg kjører "Heal the device" manuelt via Habmin på ny (eller flyttet) dings, samt de nærmeste naboene. (I Habmin velg z-wave-dingsen og trykk "Tools" i høyre hjørne oppe, velg "Show advanced settigs" og trykk "Tools" en gang til. Man bør ikke ha for mange "Heals" i køen på en gang. Man kan lett overbelaste meshet på denne måten. Det kan ta et par timer før de er ferdige. Samme med "Syncronize network", som vel egentlig er en serialisering av "heals" på alle nodene. Jeg har to kjørbare filer. En for å slå på debug-logging, og en for å sette tilbake til info-logging: (bitfrost er navnet på Openhab maskina mi) nils@xps13:~/bin$ cat oh-debuglog-zwave #!/bin/sh ssh -p 8101 openhab@bitfrost "log:set debug org.openhab.binding.zwave" nils@xps13:~/bin$ nils@xps13:~/bin$ cat oh-infolog-zwave #!/bin/sh ssh -p 8101 openhab@bitfrost "log:set info org.openhab.binding.zwave" nils@xps13:~/bin$ I debug-modus vokser logg-fila ganske fort! Det kan være lurt å ta ett utsnitt av loggfila å laste utsnittet opp på https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer Den "dekoder" muligens z-wave trafikken til noe forståelig. Noen ganger må man studere rå logg.. (i skrivende stund så er det noe rart med webserveren) Men la meshet få stabilisert seg først. Likevel, det henger ikke helt på grep dette. Noen feilmeldinger i openhab.log? Edit: Debug modus leses i openhab.log

Openhab faller tilbake til siste kjente verdi når det ikke er kontakt med dingsen. Men det stemmer ikke helt med loggen din. Du må nesten slå på debug-logging for å se alle detaljene. edit: hvordan er det med naboer til Namron-dimmeren? (du finner de i Habmin) Samtidig så er Paperui ikke helt å stole på når det gjelder faktisk status på dingsene. Det ordner seg som oftest med en reload i nettleseren.

Z-wave er stabilt når dingsene er av god kvalitet software og firmware -messig. De problemene jeg har hatt med z-wave skyldes: 1. Dårlig radiodekning, enten pga. dårlig radio i dingsene eller for stor avstand mellom dingsene. 2. Feil i firmware.

Snekret samen ett Python-script som forenkler endring av navn på items. En kjøring endrer navn i *.items, *.rules og *.sitemaps. Vurderer om jeg skal endre i influxdb også. Bakgrunnen er at jeg har vinglet kraftig med standardiseringen på navnene. Og kjenner jeg meg selv rett så vil det bli endringer i navnestandarden senere også.

Må nesten anskaffe meg en sånn Heltun og prøve 🙂 🙂 Med alle de hullene man kan gå seg ned i med nye produkter. Den finnes ennå ikke i OpenHAB sin database, så det må lages en .xml .. https://www.heltun.com/z-wave-high-load-relay-switch