Lars1

Lux/temp. sensoren er ikke så slem. Den sender max data en gang pr. 30 sec. eller noget i den stil. Problemet er controllerens resource prioritering. Højeste prioritet ser ud til at være I/O moduler, dernæst wireless, så trejde parts kommunikation, og tilsidst Visual/program upload/download. Dit hus behøver ikke være særligt avanceret. Hvis dit program er noget rod så risiker du problemer ligegyldigt hvor stort dit program er. f.eks. kan controlleren ikke lide produkter der er defineret, men som ikke er tilsluttet og/eller ikke brugt i programmet. Det samme gælder f.eks. en temp. sensor som er monteret, men ikke defineret. Helt galt går det hvis en temp. sensor er monteret på en indgang, som er defineret som alm. tryk. Sommetider hjælper det at genstarte controlleren lige før man skal hente eller sende programmet.

Hvis din motor er 0-10V styret, kan du ikke bruge LK IHC, men hvis den køre fuldt åben/fuldt lukket, så bør du kunne bruge en standard LK FB. Puls styringen funger jo netop ved at der skiftevis sendes ON (åben) og OFF (lukke) signaler til telestaten.

Direkte kommunikation - nej. Via IHC Captain, IHC Bridge, Openhap etc. og lidt kodening - meget sandsynligt.

Har du checket om du ikke kan bruge en af LK's standard varmestyrings FB's. Jeg mener de har en med puls stying som det du efterlyser. Når du skal fejlsøge på et program i controlleren, er log funktionen i serviceview ofte en god hjælp. Det er ofte et flag eller tilsvarende som står anderledes end forventet.

Der er ganske rigtig ikke plads til 1,5 kvadrat i svagstrøms trykkene, men LK IHC har også 230V input moduler, og der er intet i vejen for at bruge alm. tryk på 24V. Du må bare ikke blande 24V og 230V i samme kabel.

Du kan bare opgrader din HW 6.1 controller med seneste firmware til HW 6.2. Du skal bruge en af de gamle firmware loader uden versions check for at gøre det. Der findes flere her på boardet. LK påstår at du kan skade controlleren ved at gøre det, men vi er flere her på boardet som har gjort det uden problemer. Faktisk har fler af os fået en mere stabil controller efter opraderingen. Jeg kender godt teamviewer. Den funger ved at den din PC åbner en tunnel til teamviewer serveren. Denne tunnel bruges så til at forbinde sig tilbage til din PC.

Det afhænger helt af hvilken router du har. Min TDC router laver f.eks NAT som default hvis man ikke beder den lade være. Jeg tror faktisk at Visual virker selvom der ikke er lavet NAT i routeren, men jeg har ikke haft brug for det MEGET længe, så jeg er ikke sikker.

Hvis din router laver NAT (Network Address Translation, hvilket er standard idag), så tror IHC controlleren at du kommer fra lokal nettet, selvom du rent faktisk sidder i f.eks. USA. Det som i IHC controlleren hedder internet, dækker alt som ikke sidder på samme subnet som IHC controlleren, og vil ikke være i brug hvis din router laver NAT. Derudover mener jeg at det kun er IHC adminview, som du ikke kan køre fra "internet". Visual mener jeg virker fint. Det kræver portforward til den krypterede port, normalt 443.

Eftersom Obenhab styre wireless enhederne gennem IHC controlleren tvivler jeg stærkt på at det er spændingen på IHC strømforsyningen som er problemet. Det er mest sandsynligt at problemet ligger i dit program, eller hvis de tryk som virker langsomme er wireless tryk i kommunikationen mellem dem og controlleren.

Du skal jo også lave portforward fro at nå teamviewer, så hvorfor ikke lave portforward, så den kan nå IHC controlleren direkte uden at skal gennem teamviewer først? Selvom du har dynamisk public IP, vil du sjældent få en ny IP medmindre du slukker din router i et par timer eller mere.

Prøv at stoppe Openhab og evt. andre trejdeparts produkter og se om det ændre noget. Prøv også at checke dit program. Hvis dit tryk laver ændringer på flere wireless enheder på engang, kan der være en vis forsinkelse med at sende data til dem alle.

Hvilken port du skal bruge afhænger af din portforward. Hvis du ikke har andre enheder, som kan tilgåes fra internettet, skal du lave portforward på både port 80 og 443, så behøver du ikke angive port nr. når du kommer fra internettet. IHC controllerens forside køre altid ukrypteret (normalt port 80), mens ServiceView, AdminView etc. køre krypteret (normalt port 443) IHC administrator kan kun tilgåes fra lokal nettet, men alt efter hvordan din router/forward laver portforward, kan det være den også laver NAT og så tror IHC controlleren at du kommer fra lokal nettet, hvilket gør alle instillinger under internet i IHC controlleren ligegyldige.

Prøv at stoppe din IHC bridge og se om du så ikke kan komme på controlleren. Sometider hjælper det også at genstarte controlleren.

Det er et kendt problem med HW 6.1 og HW 6.2 controller at der er problemer med at connecte til dem når trejde parts produkter som f.eks. IHC-bridge køre. Sommetider kan serviceview give de samme problemer. Jeg ser ikke selv problemet efter jeg opgraderede til firmware 2.8.6

Njaa. Meget af det IT udstyr jeg arbejder med til dagligt, har muligheden for at man kan lægge en user fil, ny firmware, program update eller tilsvarende i et specifikt område på et SD kort eller tilsvarende. Disse filer bliver læst når udstyret booter og kan så overskrive de tilsvarende data i udstyrets normale storage. Når de er læst bliver de automatisk slettet, så de ikke næste gang overskriver igen. Det er en ret brugt metode til at resette HW.

For at sammenligne 2 controller skal man have dem begge i brug samtidig, ellers på anden måde have faktuelle data at sammenligne. Alt andet er baseret på fornemmelse. Som jeg skriver kan jeg tydeligt mærke at min HW 6.2 controller er hurtigere end min HW 6.1 controller. Eftersom min HW 6.1 kun køre alm. tryk og udgange, samt 10 wireless dimmer eller stikkontakter, mens HW 6.2 controlleren har 10 temp. sensor og en puls tæller tilsluttet, tør jeg godt påstå at HW 6.2 controlleren er hurtigere end HW 6.1 controlleren. Da jeg flyttede varmestyringen til HW 6.2 controlleren kunne jeg også mærke en tydelig performance forbedring på HW 6.1 controlleren, men det er primært under up/download af programmet at jeg kan mærke det.

Hvis du kigger nærmere på den tegning vil du se at 12V er angivet som + og -. Det kan tyde på at de er direkte forbindet til batteriet i backup modulet, og der derfor ikke er noget 0V potentiale i 12V kredsen. Jeg er dog ikke sikker på dette, og kan ikke finde nogen dokumentation for det.

Såvidt jeg kan se er der kun 24V i din tegning. Brugeren spørger efter 0V potentialet på 24V og 12V. De PIR han har er sikkert alarm PIR, eftersom der er 12V i dem.

Når du opgrader, skal du huske at sammenligne med samme program, firmware version og 3 parts produkter hvor det kan lade sig gøre. Hvis du sammenligner HW 6.1 uden temp. sensor, viewer og IHC Captain, med HW 6.2 med temp. sensor, viewer og IHC Captain, så er det muligt at du ikke vil se den store forskel. Der er omkring 6-8 år mellem HW6.1 og HW6.2. og det samme mellem HW 6.2 og HW7. Hvis du ikke ser nogen performance forbedring, så er der noget galt med HW opgraderingen. Jeg har selv både en HW 6.1 og en HW 6.2. HW 6.1 køre fortsat alt mit wireless da jeg skal flytte møbler for at migrer dette, mens HW 6.2 køre alle mine temp. sensor, lux måler, el-måler etc. HW 6.2 controlleren er klart hurtigere end HW 6.1 controlleren. Det mærkes mest når jeg laver program ændringer. HW 6.2 programmet er ca. dobbelt så stort som HW 6.1 programmet, og selvom IHC Captain køre mod HW 6.2 er det hurtigere at upload og download programmet i HW 6.2 controlleren end i HW 6.1 controlleren.

Man behøver ikke skifte til V3 for at kunne bruge seneste Java version, men hvis man får den gratis vil jeg også opgrader, alene fordi V3 er hurtigere end V2, men jeg vil ikke offer penge på at opgrader. For at få HW 6.1 eller HW 6.2 til at understøtte seneste Java version kan man bruge en af nedenstående metoder. Opgrader til seneste firmware for HW6.2. Den virker også på HW 6.1 selvom LK påstår det modsatte, og giver faktisk en mere stabil HW 6.1 controller Følg workarounds i tråden Java problemer igen igen igen. Brug LK's java starter.

Eftersom din eksisterende installation ikke er med certificerede Gigabit komponenter er det ligegyldigt hvilke connector du benytter, så længe de er cat 5e eller højre. Dog mener jeg IHC NET BASIC kablerne er skærmede, så derfor bør du benytte skærmede connector, hvilket den du linker til er. Brug evt. denne boks https://www.elvvs.dk/searchresults.php?query=5703302150286 til at monter kablerne i der hvor din IHC NET BASIC box sidder pt. Så slipper du for at kablerne hænger og flager når du fjerne IHC NET BASIC boksen. Det samme gælder patch kablerne. Alle fabrikater kan bruges, sålænge de er til Gigabit eller højre. Patch kablerne behøver ikke være skærmede.

Kablerne og vægudtagne er muligvis ikke certificeret til Gigabit, men eftersom de kan klare 700MHz TV signal, vil der ikke være noget problem i at køre Gigabit gennem dem. Udover det vil jeg sige som Martin. Go Go Go.

Hvorfor ikke opgrader til V3 med det samme? Det er samme arbejde, men du får en hurtigere controller. Desværre er det dog den eneste fordel du får ved en V3 fremfor en V2 controller

Har du prøvet at genstarte controlleren kort før du connecter med Visual?

Hvis du har IHC Captain eller andet trejdepart SW kørende, så prøv at stoppe det mens du connecter med Visual. Det samme gælder hvis du har serviceview eller tilsvarende kørende.