Lars1

Jeg kan ikke huske om det betyder noget, men har du valgt 0-10V output modul i IHC visual under datalinier moduler? (sidder ikke lige med en PC med IHC visual, så det hedder muligvis noget andet)

Hvis du havde læst vejledning til 2.7.220 inden du gik igang, ville du have set at der faktisk står at du skal opgrade til 2.7.199 før du går til 2.7.220. Du kunne med andre ord have sparet 7 opgraderinger ved at bruge 5 min. på at læse release noterne til 2.7.220.

Jeg har udskiftet mit gamle skumrings relæ med den nye lux/temp. måler. Den er sat op udendørs med LK's nye adaptor for inderdørs PIR, så de også kan bruges udendørs. Det virker perfekt. Selvom den sidder i en 45 graders vinkel til en gade lampe, som er mindre end 5M væk, bliver den ikke påvirket når lampen tænder. Den siger fortsat pænt 0 lux. Grunden til at jeg skiftede var netop at jeg var træt af at skulle op på en stige for at juster skumrings relæet. Udendørs temperaturen benytter til at styre offsettet på indendørs temperaturen i min IHC varmestyring. LK's lux funktions blok har dog den kedelige fejl at den ikke husker dine parameter ændringer, når din controller genstarter af sig selv. Der udover har det haft den negative konsekvens at min controller er gået fra at genstarte hver 7 dage til hver 4 dag. Om det er lux/temp. sensoren eller fug/temp. sensoren, som jeg installerede samtidig, som er synderen ved jeg ikke. Men eneste ændring var at jeg skiftede en rum/gulv. temp sensor ud med fugt/temp. sensoren og satte lux/temp. sensoren op. Der blev kun udskiftet det ene produkt (gulv/rum -> fugt/temp) og tilføjet det andet produkt (lux/temp), incl. de nødvendige links den dag jeg fysisk monterede de 2 produkter. Alle andre program ændringer blev først fortaget 3 uger senere, og i den mellem liggende periode havde min controler genstartet ca. hver 4 dag, mod ca. hver 7 dage i de sidste 3 mdr. inden produkterne blev monteret. Det er nu snart 3 mdr. siden jeg monterede de 2 produkter, og controlleren genstarter fortsat ca. hver 4 dag.

Check trådene om JAVA indstilinger. Afhængig af din firmware version, er der forskellige JAVA security nedgraderinger du skal lave for at få det til at virke.

Pas på med at bruge SD kort. De er kun designet til få læse/skrive operationer. Kender til flere eksempler med Raspberry's som efter 1 år er holdt op med at virke fordi SD kortet blev brugt som eneste lager enhed. SD kort er fine til digital kamera etc. hvor data bliver ændret mindre end 1 gang om ugen i snit. Som lagerings enhed for data som bliver ændret flere gange dagligt dur de ikke. De bliver slidt op alt for hurtigt.

Er din IHC controller på samme subnet som inderside addressen på din ISP router?

Bare ærgeligt at den fortsat ikke kan strømfødes via PoE.

Du har selvfølgelig checket at antenne kablet sidder ordentligt fast både i controlleren og i antennen, og at der ikke er nogen som har placeret en metal spand eller tilsvarende foran antenne. Det sidst har jeg selv prøvet. wireless fungere ikke så godt, når man sætter maler bøtter af metal på hylden foran antennen. Det tager mere end et par kopper kaffe at opdage den bommeret. Hvor langt er der mellem antenne og den nærmeste wireless enhed?

Nu bruger jeg pt. kun IHC captain til at logge data, men det gør den tilgengæld fint, også efter jeg har ændret i mit program, eller min controller er genstartet. Den eneste gang jeg har været nød til at genstart IHC captain, er i forbindelse med at jeg udskiftede en funktions blok, som den loggede data fra. Der var jeg selvfølglig nød til at gå ind og opsætte data logning på den nye funktions blok.

Prøv at klikke på managede certificates i JAVA, og slette evt. trusted schneider eller LK certifikater der. Hvis det ikke er nok, så prøv at klikke på restore security promts også. Derudover bør du overveje at opgrader din firmware. Det er længe siden at LK skiftede til certifikater der er signed med Schneider som publisher i stedet for Lauritz Knudsen.

Prøv at klikke på managede certificates i JAVA, og slette evt. trusted schneider eller LK certifikater der. Hvis det ikke er nok, så prøv at klikke på restore security promts også. Derudover bør du overveje at opgrader din firmware. Det er længe siden at LK skiftede til certifikater der er signed med Schneider som publisher i stedet for Lauritz Knudsen.

Du monter bare de wireless dimmer i alm. underlag. LK har været så venlige også at lave et underlag som passer til et Ø80 lampeudtag, så der idag er frit valg på wireless hylden. Ø80 lampeudtagne findes i en HW2 udgave, som skulle være bedre til LED og lavenergi pære end HW1 udgaven. FUGA dimmerne findes kun i en HW1 udgave.

For det første vil jeg anbefale 24/3 moduler isteddet for 24/24. 24/3 er billiger i drift end 24/24 og supporter temp. sensor etc. hvilket 24/24 officielt ikke gør. Derudover skal du sikre dig at der er potential frie relæer i din alarm. Hvis dette er tilfældet forbinder du bare 0V og en af indgangene på dit IHC modul til det potentiale frie kontaktsæt på din alarm. Hvis din alarm ikke har potential frie relæer, skal du have overdragelses relæer mellem dit IHC modul og din alarm. Spolen på overdragelses relæet tilsluttes outputtet på din alarm, mens 0V og indgangen på dit IHC modul forbindes til det potential frie kontaktsæt på dit overdragelses relæ.

Har du mulighed for at sætte strøm på den, tage et screenshot af admin vinduet med firmware version, RF version etc. Hvis den køre med firmware under 2.7.199, må du også meget gerne opgrader den til 2.7.199, så vi kan se om RF modulet kan opdateres på den. Det kan det desværre ikke på alle HW 6.1 modeller.

Du skriver den har været brugt til et iHC projekt. Hvordan kommunikerede den med IHC controlleren?

48 timer i døgnet vil jeg gætte på.

Det haster ikke. Jeg fortsat fejlen, men jeg har fået MRTG til at køre. Det viste sig at cfgmaker sætter et forkert HTML katalog i forhold til rod kataloget for web serveren. Jeg ved ikke om det er IHC Captain, som satte rod kataloget til /var/www/html, eller om det er standard, men MRTG forventer det er /var/www. Dertil kommer at det tog mig lidt tid at gennemskue at cfgmaker overskriver mrtg.cfg hvergang den køre.

Jeg kan ikke lige finde det varenr. hos LK, men hvis du bor på Sjælland er jeg interesseret.

Når du har en Visual 2 controller, vil jeg forslå at du køber wireless dimmer. De har væsentlig flere funktioner en de tavlemonterede dimmer, og kræve ikke output udgange. Hvis du kan bruge Ø80 lampeudtags dimmer, er de klart at fortrække. Alternativt er der kombi dimmerne, som kommer i Fuga afbr. strørrelse. Funktionaliteten er stortset den samme, men Ø80 lampeudtagne bliver idag lavet i en HW2 udgave, som er fejlrettet på flere punkter. De er bl.a. bedre til dæmpning af lavenergi pære, LED pære og elektroniske transformatore.

Du kan vælge de ind/udgange som du ønsker at logge, ved at højreklikke på dem. Det kan også gøres i funktions blokkene, så du kan få de interne variabler med også. Men det er korrekt at det ikke er muligt at sætte et debug flag, så man får logget alle hændelser. Desværre. Det kunne ofte være dejligt hvis man kunne det.

Jeg vil gætte på at årsagen til at det virker, er at din homebox kun kan køre 100Mbit, mens din Cisco switchen og accesspoint begge kan køre gigabit, hvilket IHC net basis ikke understøtter, grundet at 2 par i hvert kable er reserveret til TV og telefoni. Cisco er ikke de eneste som har problemer med kabling hvor der mangler et eller 2 par. Jeg tror faktisk at det er en fejl i gigabit standarden, at de ikke verificer at alle 4 leder par er tilrådighed under handshake.

Hvad med at bruge standard ventilationstyrings blokken, og sætte forsinket frafald til f.eks. 30 min. Mon så ikke den får kørt de 1,5time pr. dag. Man kan godt lave en funktions blok, som gør det du ønsker, men IMHO er det at gå over åen efter vand at gøre det så komplekst som du ønsker. Jeg er selv godt i gang med at forsimple min IHC installation. Mange af de komplekse løsninger jeg lavede for 5-10 år siden har jeg stortset aldrig brugt.

Jeg har forsøgt at installer MRTG på min Raspberry, som i forvejen køre IHC captain, men jeg kan ikke får MRTG til at starte, og når jeg forsøger at køre "sudo update-rc.d mrtg defaults" får jeg nedenstående fejl. insserv: warning: script 'mrtg' missing LSB tags and overrides insserv: There is a loop between service ihccaptain and mrtg if stopped insserv: loop involving service mrtg at depth 2 insserv: loop involving service ihccaptain at depth 1 insserv: Stopping mrtg depends on ihccaptain and therefore on system facility `$all' which can not be true! insserv: exiting now without changing boot order! update-rc.d: error: insserv rejected the script header Jeg har benyttet denne inst. guide http://www.supagusti.tk/computer/raspberrypi/160-installing-mrtg-on-your-pi og "sudo cfgmaker public@192.168.0.1 >> /etc/mrtg.cfg" og "sudo indexmaker /etc/mrtg.cfg > /var/www/html/mrtg/index.html" virker fint, men "sudo /etc/init.d/mrtg start" giver "Starting Multi Router Traffic Grapher Daemon: MRTG.", men en efterfølgende "sudo /etc/init.d/mrtg restart" giver "Restarting Multi Router Traffic Grapher Daemon: mrtg: no process found" Nogen idee til hvad jeg gøre forkert?

Hvis din firmware er ældre end 2.7.199 bør du opgrader den til 2.7.199 eller 2.7.220. Den sidste er mere ustabil end den første på nogle controller. Tilgengæld er TLS 1.1 og 1.2 kryptering supporteret, hvilket det ikke er i 2.7.199. Derudover bør du checke serviceview, når du oplever problemerne. Ofte skyldes manglende reaktion at der er et flag eller tilsvarende i ens program, som står anderledes end forventet.

Du vil have samme problem med input230, samt det problem at det ikke er potential frit. Men hvis vi snakker om LK wireless og en controller, som ikke understøtter wireless, så er der jo tale om standalone installation, og så vil jeg mene man kan linke afbryderen til både et wireless relæ og en wireless dimmer, og dermed bruge relæet til at sende signalet tilbage til IHC controlleren. Jeg har dog INGEN erfaring med standalone wireless, så jeg ved ikke om det vil virke. Det næste er at en ny controller koster 5.000 hos billig IHC. Jeg vil nok overveje hvor meget krudt jeg vil bruge på at strikke en løsning sammen, som aldrig vil blive andet end Storm P, og aldrig vil give samme funktionalitet som hvis man anskaffer en ny controller. Alle I/O moduler, strømforsyning etc. kan jo genbruges.