iblis

Hei @tonheim og velkommen som ny bruker på Hjemmeautomasjon.no. Ifølge ditt skjermbilde så er UZB1 konfigurert til å kommunisere via COM3 noe som igjen forteller meg at Domoticz er installert i et Windows miljø. Har du installert enhetsdriveren til UZB1 for Windows? Hvis ikke kan du laste den ned her. Er driveren installert og UZB1 kontrolleren vises korrekt i Windows Enhetsbehandling på COM3 så skal den dukke opp i Domoticz ved å gjøre følgende: Trykk på Refresh knappen som er innringet med rødt i bildet under. Etter du har trykket på Refresh knappen skal kontrolleren vises som Node 001 slik som på bildet under. Gjør den det?

Ja, vi har hatt litt problemer med Emoji ikonene. Men de fleste skal fungere nå.

Grunnen for dette er at Z-Wave.me gjorde noen endringer fra firmware v5.2 til v5.4 på grunn av en feil i hvordan UZB1 håndterte Backup/Restore funksjonen. Dette førte videre til at Restore funksjonen til HS3 kun fungerte på firmware v5.2, men feilet på v5.4. HomeSeer har i ettertid kommet med en ny versjon av sin Z-Wave plugin som nå gjør en versjon sjekk på om firmwaren er v5.2 eller v5.4 slik at den vet hvilken Restore metode den skal ta i bruk. Så feilen ligger nok i at de ikke har inkludert v5.5 eller v5.6 (nyeste) i deres versjon sjekk av UZB1. Dessverre er det ikke mulig å nedradere firmware versjonen på UZB1 som jeg vet om.

Du finner en grei guide på hvordan du kobler Fibaro FGBS-001 opp mot en ringeklokke her: https://en.robbshop.nl/about-z-wave/z-wave-projects/z-wave-doorbel

Ja, det har du rett i Fermate ;) Så fort jeg blir ferdig med utviklingen av rammeverket til hjemmeautomasjon.no så skal jeg bruke tiden min på å skrive guider og blogg innlegg om hvordan ting tikker og går her i huset. [emoji4]

Selv har jeg lært den harde veien at det beste er å ikke virtualisere NAS og FW. På mitt gamle setup kjørte jeg FreeNAS som VM med PCI passthrough av Raid kortet, samme gjorde jeg med brannmuren hvor jeg kjørte pfSense som VM med PCI passthrough av nettverkskortet. Det fungerte bra og var stabilt, men de gangene det oppsto et problem så ble det veldig komplisert å feilsøke, spesielt hvis jeg måtte gjøre det utenifra når jeg var på jobb. I dag bruker jeg en Synology RS2414+ som NAS + Datastore distribusjon via iSCSI for ESXI. For brannmur bruker jeg en selvbygd boks med et Supermicro X7SPE-HF hovedkort som kjører Sophos UTM 9. Alt annet går via ESXI boksen som VM og dette fungerer veldig stabilt og gir meg alburom til å "fikle" litt uten de helt store konsekvensene skulle det gå galt. ;)

1# Hvilken iOS versjon kjører du på de som ikke virker? Jeg gjorde bare et raskt søk på "Siri on iPad 2" og fikk dette til svar: https://discussions.apple.com/thread/6780551?start=0&tstart=0 Så ja, det er litt rart at Siri fungerer på 2 av dine gamle iPad 2 enheter. ;)

#1: Siri er dessverre ikke støttet på iPad2 og du må opp til generasjon 3 for å få støtte. #2: Merkelig. Her lukker Siri seg etter ca. 5 sekunder, men noen ganger henger hun seg opp og jeg må da gi henne en "Ha det Siri" kommando.

OK, det kan være at USB passthrough fungerer bedre på ESXI siden den tar i bruk DirectPath I/O som igjen drar nytte av VT-D. Så da kommer oppfølgings spørsmålet: Hvorfor kjører du Workstation og ikke ESXI da jeg har inntrykk av at dette blir brukt som en server?

Hmm Du har støtte for og aktivert VT-D på hovedkortet til serveren du kjører VMWare på? Selv har jeg brukt USB passthrough med VMWare ESXI i mange år uten et eneste problem.

Grunnen for at jeg ikke kjører HTTPS på hele siden, men kun på innlogging, er fordi det kan bli komplikasjoner når du tagger innhold utenfra domenet hjemmeautomasjon.no og inn i innhold/innleget. Men jeg skal kontakte Invision Power Services for å få et konkret svar om SSL faktisk blir brukt selv om du logger inn fra hovedsiden.

Jeg skal undersøke dette nærmere for å gi deg et 100% riktig svar, men jeg er ganske sikker på vi kjører brukernavn/passord gjennom SSL/HTTPS når du trykker på Logg inn fra hovedsiden. Hvis du høyreklikker på Logg inn linken og åpner den i en ny fane vil du se at den går til https://www.hjemmeautomasjon.no/login. Går du på http://www.hjemmeautomasjon.no/login så vil denne automatisk flytte deg til https://www.hjemmeautomasjon.no/login.

Takk for god input @Mastiff. Da er dette endret til Personlige meldinger slik at det ikke skal være noen tvil om hva slags meldinger det er snakk om.

Hva om vi går sammen i et DIY prosjekt hvor målet er å få til et produkt som dette:

Nå orker jeg ikke å gå inn i en lengre diskusjon om hvilket system som er best og hvorfor. Men du har helt rett når det kommer til dette. Her hjemme er det kun en fiende for systemet og det er megselv med fikle-fingrene mine

Don't get me started når det kommer til utfordringer med HS3 sin Z-Wave plugin Eller det har du allerede gjort.. så her kommer det jeg kommer på i farten: For meg er HomeSeer sin "Z-Health" løsning helt meningsløs når du ikke kan optimalisere batterinoder i samme slengen. Det at du ikke kan sette ny konfigurasjon på en batterinode uten å måtte fysisk vekke den først. Når du f.eks sender en ALL_OFF kommando for å slå av alle lys i et rom så registrerer HS3 kun den første status rapporten som kommer tilbake og ignorer de resterende. Enda verre er løsningen på problemet de kommer med hvor de anbefaler deg om å legge til en POLL kommando etter ALL_OFF kommandoen på de enhetene du slår av slik at de oppdaterer seg i systemet. Da er jo hele grunnen borte ved å bruke ALL_OFF som kun sender en kommando for å slå av alt istedenfor å sende en kommando til hver enhet om å slå seg av. Mangel på konfigurasjon-maler til z-wave enheter. Helt latterlig at på 80% av z-wave enhetene i HS3 må du fortsatt sette konfigurasjonen manuelt. Lenge leve Z-Way sier nå jeg hvor optimalisering av nettverket (inkludert batterinoder) fungerer som en drøm. ALL_OFF kommandoene fungerer som de skal og 99% av alle enhetene har riktig konfigurasjon-mal. For ikke å snakke om det innebygde topologi kartet som gir deg en enkel visuell oversikt over hvordan det står til med nettverket ditt.

Det kommer Ja, du har helt rett og jeg ordla meg kanskje litt feil. Det funger slik. En kontroller vil alltid prøve å kommunisere direkte med noden første gang. Feiler dette så vil den henvise til rutetabellen for å finne den nest beste ruten frem til noden. Feiler det igjen så vil den velge neste alternative rute (den kan velge opp til 3 alternative ruter). Uten en riktig rutetabell så kan kontrolleren ende opp med å sende 4 like kommandoer til samme node for å opprette kommunikasjon. Dette skaper stor trafikk på nettverket og du vil ha en merkbar forsinkelse i systemet. Kjører du Optimize a Network, No Return Route Changes så vil den oppdatere og ordne opp i rutenettet slik at kontrolleren raskere finner veien frem til noden og du vil ha en merkbar ytelse gevinst når det kommer til å slå på lys og andre ting du kan sende kommandoer til. Men der stopper optimaliseringen. Siden Z-Wave er en toveis kommunikasjons protokoll så vil nodene også prøve å sende en status beskjed tilbake til kontrolleren. Men i motsetning til kontrolleren har noden kun 2 valg. Den kan enten sende beskjeden direkte tilbake til kontrolleren eller velge en definert rute satt av kontrolleren på forhånd. Det vil si at den ikke tar i bruk rutetabellen for å finne veien slik kontrolleren gjør. Så hvis vi tar et eksempel hvor du prøver å slå på en lyskilde i HomeSeer med et nettverk som ikke er optimalisert kan du oppleve en forsinkelse når du sender en kommando til lyskilden om å fysisk slå seg På. Deretter vil du også oppleve en forsinkelse på selve statusen til lyskilden i HomeSeer om lyset faktisk er På eller Av. Kjører du deretter en Optimize a Network, No Return Route Changes så vil du merke en ytelse forbedring i tiden fra du sendte lyskilden en kommando til tiden den faktisk slår på lyset, men forsinkelsen på lyskilden sin status i HomeSeer vil forbli den samme da den fortsatt ikke har fått en riktig rute definert av kontrolleren til å sende statusrapport tilbake. I mine øyne så kan forsinkelser i status rapportering få store konsekvenser når det kommer til aktivering av scener og andre ting som er avhengig av riktig info fra nodene. Og det er ikke før du kjører Fully Optimize a Network at disse rutene for status rapportering blir definert og oppdatert. Ja, nesten. Kontrollen kan velge mellom direkte rute eller opp til 3 alternative ruter. Noden kan bare velge mellom direkte rute eller en alternativ rute forhåndsdefinert av kontrolleren.

Optimize a Network, No Return Route Changes Det eneste denne gjør er a sende en kommando til hver enhet på strøm om at den skal gjenoppdage sine nabo noder. Du kan kjøre den hvor mange ganger du måtte ønske uten at det vil ha noen merkbar effekt på nettverket ditt da den ikke setter rutene, men kun forteller kontrolleren hvor nodene er. Fully Optimize a Network Denne gjør 3 ting. Den sender først en kommando til enheten om at den skal gjenoppdage sine nabo noder og oppdatere node kartet til kontrolleren. Så kalkulerer den ut raskeste rute frem til enheten og tilbake til kontrolleren ved hjelp av node kartet. Deretter konfigurerer den ruten på enheten. Denne kommandoen bør du kun kjøre når du vet at node kartet til kontrolleren er oppdatert og med riktig info. Hvis node kartet ikke er helt 100% vil den ikke konfigurere enhetene med optimale ruter. Så når det kommer til spørsmålet om hvor mange ganger du bør kjøre Optimize a Network, No Return Route Changes så vil jeg si så mange ganger uten at du får noen feilmeldinger. Kjører du den 1 gang uten å få en feilmelding så betyr det at node kartet er 100% og du kan gå videre til Fully Optimize a Network og sette rutene. Kjører du den 4 ganger og fortsatt får feilmeldinger så kjører du den en gang til, fortsetter det slik og du ikke blir kvitt feilmeldingen så har du sannsynligvis en trøblette node i nettverket du bør undersøke. Poenget er at du ikke bør kjøre Fully Optimize a Network før du har kjørt Optimize a Network, No Return Route Changes uten problemer. Problemet med HomeSeer sin Z-Wave plugin er at de av en eller annen grunn ikke har implementert et køsystem for batterinoder når det gjelder nettverk optimalisering og node konfigurasjon. De fleste z-wave kontrollere på markedet i dag med respekt for seg selv har mulighet for å kjøre Fully Optimize a Network, Including Battery Nodes hvor den legger kommandoene i kø og sender de til batteri enheten når den våkner til live. En slik optimalisering tar som regel et par dager, men har ikke like stor påvirkning på nettverket når den kjøres og kan uten problemer gå i bakgrunnen.

Der er jeg ganske uenig. Ja, openHAB er vanskeligere å sette opp enn andre systemer, men når du faktisk har fått til å konfigurere systemet slik du vil ha det så er det utrolig stabilt. Når det kommer til brukergrensesnitt, har du tatt en titt på Project Rotini? Nei, men det skal jeg gjøre i løpet av helgen og deretter poste resultatet og en rask "HowTo" i denne tråden.

Ja, hvis du leser litt på de to linkene jeg ga deg så ser du at det fungerer ganske greit.

MoskusModeratorMelding ("3xM"): Splittet ut fra tråden om Stärkstrøm sitt system. Dette er faktisk ikke helt riktig i dag. Etter Z-Wave Plus ankom markedet og gjorde "COMMAND_CLASS_SECURITY" om til en slags standard har det vært mye lettere for tredje parts utviklere å implementere Dørlås støtte til sine programmer. openHAB ZWave Security Testing Z-wave (Schlage) Lock Support Hvordan selve "krypterings" lisensen til Sigma fungerer i dag etter Z-Wave Plus kom på er jeg faktisk ikke sikker på.