Lars1

Det må være noget nyt i Visual 3. Det findes ikke i Visual 2. Imiddelbart vil jeg gætte på at du kun får mail's når en wireless device rapporter lavt batteri niveau. Med andre ord. Du får ikke mail's for de wireless enheder som allerede havde lavt batteri niveau da du konfigurede mail opsætningen.

Bare fordi du har konfigureret mail server, er det ikke ens betydendemed at du får mail's med alarmer etc. Jeg bruger ikke selv mail, men såvidt jeg husker skal du lave et sceneview hvor i du kan konfigurer regler for afsendelse og modtagelse af mail's. Om Lavt batteri niveau kan sættes op til at sende en mail ved jeg ikke, men prøv at læse IHC villedningens kapitel om mail kommunikation. Alternativt burde du se en rød diode lyse på din IHC controller når en wireless enhed har lavt batteri niveau. Jeg mener også at Mikkel har lavet noget i IHC Captain som kan fange lavt batteri niveau.

Hvis der er konstant lys i den grønne diode, så skulle controlleren være død og kan blive byttet gratis ved at henvende sig der hvor man har købt controlleren.

Jeg har ikke før hørt at en firmware loader kan være for ny til at forbinde til en controller. Når vi normalt taler om at en firmware loader er for ny, er det i forbindelse med firmware check i firmware loaderen, som forhindre at firmware 2.8.x i at bliver uploadet i en HW 6.1 controller. Problemet lyder umiddelbart mest som et PC problem. Muligvis nogle sikkerheds indstillinger som er lidt for strikse. Kan du få forbindelse med controlleren via web over USB (http://usb eller http:10.18.93.2). Prøv også om du kan få forbindelse via Visual ved brug af 10.18.93.2 som IP addrese.

Nej. Jeg vil ikke oplyse hvad jeg giver for el materiel. Det er en special aftale jeg har.

Jeg har ikke hverken iPhone eller iPad, men såvidt jeg husker kræver Apple OS10 og op firmware 2.8.x eller højer

Hvilken PIR der er "køn" kan diskuteres til uendelighed. Jeg har indtil videre ikke fundet en PIR, som jeg personligt finder smuk. At have en PIR siddende og flagre på muren er en øjenbæ IMHO. LK anbefaler den PIR jeg linker til fordi det er den eneste de har i deres program og som kan bruges udendørs. Som Henning skriver kan du bruge en hvilken som helst PIR sålænge den kan levere en ON/OFF signal når den bliver påvirket. Jeg valgte LK's PIR fordi jeg kan få den billigt, fordi man kan begrænse sensor feltet i den og fordi den kan forsænkes i muren.

Alle LK's wireless dimmer har samme tilbagemelding, men Ø80 dimmeren er den eneste som findes i en udgave som ikke har noget minimums forbrug og dermed den eneste som du har en chance for at få til at virke med LED's. Som PIR bruger jeg selv denne. https://www.elvvs.dk/p/opus-74-ihc-pir-control-24v-180-udendoers-komplet-med-underlag-erstatter-opus73-1601585/ og er ganske godt tilfreds med den. Den har masser af muligheder for at begrænse sensor feltet som er meget vigtigt hos mig. Den som jeg linker til er reelt en pakke bestående af en indendørs fuga sensor og en udendørs OPUS74 adaptor som gøre at indendørs sensoren kan bruges udendørs. Den funktions blok du skal bruge tror jeg du kan finde her i download sektionen eller i en anden tråd. Du er ikke den første som spørger efter den funktionalitet og det er samme funktionalitet som jeg har lavet hos mig.

Konstant grønt lys skulle være ensbetydende med en død V3 controller jvf. Mikkels indlæg for et par uger siden. Så som Lars Jacobsen skriver. Tag fat i den leverandør hvor du har købt controlleren og resten burde være en form sag. FAT32 var vist bare en dårlig undskyldning indtil de fandt ud af hvad der reelt går i stykker. Jeg har ikke hørt den brugt længe. Men bortset fra det giver jeg dig ret. Et fejl formateret SD kort bør ikke kunne tage livet af en IHC controller. Men det er lidt bekymrende at problemerne nu også begynder at opstå ved program opdatering. Såvidt jeg husker er der flere som har leget med deres V3 controller og konstateret at den booter fint uden SD kort og at hverken firmware eller programmet ligger på SD kortet. Man kan opdater programmet i controlleren ved at lægge det på SD kortet og boote, men man skal vist selv slette det igen, ellers vil det over skrive evt. opdateringer ved næste boot.

Prøv at uploade et tomt program, genstart og derefter det original program igen. Med en Visual 3 controller kan du uploade programmet ved at lægge det på SD kortet og genstarte controlleren. Dit fejl mønster kan også tyde på en overbelastet strømforsyning. Hvis du har tilføjet enheder, i forbindelse med program opdateringen, som øger strømforbruget i din IHC installation kan dette være årsagen.

Nej du har ret. Det er ext3, og det kan læses af windos. I den tråd er der også en henvisning til Ejvind's SD kort image

Jeg har ikke nogen IHC V3 controller men min windos 7 PC læser fint ext2 formaterede SD kort og jeg har ikke installeret noget specielt program for at kunne gøre dette. Såvidt jeg husker er SD kortet ext2 formateret, men de fleste filer ligger i en skjult folder. Jeg tror det var Ejvin (sikkert stavet forkert) som har lavet et image af SD kortet og fundet de skjulte filer etc. Der er en tråd om det emne her på boardet.

SD kortet er IKKE FAT32, og må IKKE formateres til FAT32. Det står tydeligt i villedningen såvidt jeg husker, og var vist årsagen til en del problemer da controlleren blev released. SD kortet kan bruges til firmware opdatering, program opdatering m.m. Det står altsammen i villedningen til controlleren. Mikkel havde fat i LK for nylig, og hvis jeg forstår hans efterfølgende indlæg korrekt, så skal controlleren byttes hvis dioden lyser konstant grøn under boot, men prøv selv at læse hans indlæg. Det er under 2 uger gammelt.

Løftede de sløret for hvad det er der går galt?

Jeg kender ikke HA, men et problem kan være autonegotiation på netværket mellem din switch og Raspberry'en. Hvis du ikke kan disable autonegotiation på din router/switch, så prøve at gøre det i det image du flasher din Raspberry med. Min Synology NAS kommer aldrig på nettet hvis jeg fysisk tager strømmen efter at have lavet shutdown. Efter at jeg har disablet autonegotiation på min switch er problemet væk.

Kunne de hjælpe dig til at løse problemet selv eller er det en bytter?

Du læser som sædvanlig mine indlæg som en hvis person læser biblen. Men jeg orker simpelhen ikke at forsøge at forklare dig hvor du går galt i byen, og jeg er ret sikker på at alle andre ved hvad jeg mener, så jeg tror bare vi stopper her.

Med spændvide mener jeg systemer som favner ligeså bredt som LH IHC, hvor du har stortset alt det basale i et system og hvor du, hvis du forstår hvordan, kan lave stortset alt hvad du har lyst til. Henning er unik fordi han gider sætte sig ind i hvordan LK IH virker og gider bruge tid på at lave nogle avancerede bruger grænse flader. Det mener jeg ikke er noget som hverken LK eller den alm. elektriker kan forventes at gøre. LK's rolle er at designe et ramme værk. Elektrikernes rolle er at installer det og lave basal programering og opsætning. Vil du have noget mere avancerede tager man fat i folk som Henning.

Hvilke andre smart house produkter med sammen spændvide som LK IHC kender du, hvor det ikke kræver personer som Henning for at få det fulde udnyttelse?

Ofte er det genstarten som er mandatory ved en firmware upload som får tingene til at virke igen.

Det er de også i Visual 2. Når man linker wireless enheder til en controller, bliver controllerens ID også gemt i de wireless enheder. I Visual 2 kan dette ID ikke ændres, hvilket det kan i Visual 3 og dermed kan man udskifte en Visual 3 controller uden at skulle genlinke manuelt. Det kan man ikke i Visual 2.

Kan du nå controlleren trådløst via Visual?

Jeg har aldrig før hørt om Visual lukker ned når du henter programmet fra controlleren. Får du nogen fejl melding? Langsom serviceview, adminview etc. er kendt på Visual 2 controller hvis du også bruger trejdeparts produkter som f.eks. IHC Captain, OpenHab etc. Visual kan også have problemer med at forbinde til controlleren hvisdu har serviceview åben når du starter Visual. Men jeg har ikke hørt om disse problemer på en Visual 3 controller. Har du prøvet at genstarte controlleren ved at tage strømmen i mindst 10 sek.?

Et rigtigt gennemført smart house forlader sig ikke på en kalender. Målet for google etc. er at integrer deres smart house devices med adaptive learning, AI (Artificial Intelligence) og big data. Når alt dette spiller sammen får man et hus som kan forudsige din næste handling og dermed tilpasse sig og evt. udføre handlingen for dig før du når at gøre det. Det lyder måske som fremtidsmusik, men når man som jeg jævnligt er involveret i tilsvarende projekter er det lidt skræmmende at se hvor langt man er kommet allerede.

Det at du oploader et tomt program, clear en masse cached data. Man kan så diskuter om fejlen ligger i controlleren eller programmet, men end of the day. Det var data fejl som fik program afviklingen til at fejle. Det er mange år siden jeg sidst så en fysisk device med Java som rent OS. I dag bliver Java installeret oven på et andet OS, men Jave er designet som et selvstændigt OS. Java bliver fortsat brugt rigtig mange stedder. Rigtig mange af de SOA (Service Oriented Architecture) systemer som bruges i alt fra B-2-B portaler, offentlige systemer som BRS, Skat, motor registeret, tinglysningen etc. har en ESB (Enterprise Service Bus) med en Java engine som ligger oven på Linux server. API'et i LK IHC følger for 90% standarden for ESB kommunikation så det er ikke så underligt at LK har brugt Java. De sidste 10% er en blanding af dårlig implementering og manglende opgradering til nyeste standarder