Lars1

Prøv at tage fat i din ISP. Det er ikke alle som tager betaling for offentlig IP, hvis du ikke ligefrem kræver fast IP. Hvis du kan leve med at den skifter fra tid til anden er det ofte gratis. Du kan jo også prøve at argumenter for at du før router skiftet havde offentlig IP, og det vil du gerne have igen på samme vilkår. Men når det er sagt, så er det faktisk en fordel ikke at have offentlig IP, medmindre man skal bruge det. Man slipper for RIGTIG meget virus og hacker angreb, når ens router ikke kan nåes fra internettet.

Jeg kan ikke mindes at have set et lampeudtag uden nul. Og hvis du tager et kig her http://www1.lk.dk/katalog/vejledning/019D903522_01.pdf så vil du se at der ikke længere skal bruges belastning når man linker, men de fastholder godt nok minimums belastningen.

Du skal have fat i din ISP, og have dem til at lave mapning mellem din 185.x.x.x offentlige IP, og din routers 100.x.x.x internet IP. Det der er gået galt er at enten har du fået ny "internet IP" i forbindelse med router udskiftningen, eller også er mapningen røget i forbindelse med din "internet IP" er blevet mappet til en ny IP.

Din internet IP i din router og den offentlige IP du ser på myip.dk bør være den samme, medmindre du har endnu en router mellem din router og internettet, eller du har flere offentlige IP adr. tilknyttet din internet aftale. Hvad er det første tal i din internet IP? Kan du ikke beskrive helt præcist hvilket udstyr du har mellem det kabel som kommer ind i huset udefra, og din IHC controller. Rækkefølgen er også vigtig. Jeg går ud fra at switchen sidder efter din Cisco router? Nu ved jeg ikke lige hvordan Cisco har implementeret DMZ i denne router, men sommetider er det internet IP'en man skal angive. Jeg tror dog mere at det er forskellen mellem myip.dk og din internet IP i din router, som er problemet. Klik på administration i menuen, og se hvad der ligger af log menupunkter derunder. Myip.dk fortæller dig hvilken IP du har når du browser på internettet. Dette er normalt din offentlige IP. Den IP der står som internet IP, er den IP din router har på din ISP's netværk. Det er ikke altid at den kan nåes fra internettet, men den kan godt nåes fra dit interne netværk. De fleste ISP'er idag laver dog mapning af den IP du ser på myip.dk til den IP du ser som internet IP, hvis den ikke er den samme. Hvordan de gør det er forskelligt fra ISP til ISP. Nogle ISP skal gøre det manuelt, mens andre gør det automatisk. Hvis det skal gøres manuelt, glemmer de det sommetider når kundens rotuer bliver skiftet.

Jeg ved dette er ret basale spørgsmål, men min erfaring er ofte at det er de samme basale fejl der begåes, især af professionelle. Den offentlige IP du prøvede med er den samme som du ser med myip.dk? Den offentlige IP du kan se i din Cisco router er den samme som på myip.dk? Du har ikke andre router mellem din offentlige IP og din IHC controller end den cisco router du har vist billedet af? Din Cisco router har tilsyneladen DMZ support. Dette er ofte en eller flere specifike interfaces på routeren. Hvis din IHC controller sidder på en af disse porte skal der måske konfigureres DMZ regler også. Dertil kommer at nogle router kun tillader inbound traffik til DMZ zonen. Er der nogle logs under administration, som giver nogle fejl? Hvad sker der helt præcist når du siger det ikke virker?

Prøv lige at checke din offentlige IP. Det er ikke unormalt at man får en ny offentlig IP, når man får en ny router. Brug evt. http://myip.dk/

Glad for at jeg kunne hjælpe. Der er somregl en logisk forklaring på selv de mærkeligste hændelser, men de kan sommetider være svære at finde, og vi har en tendens til at lede de komplexe stedder først.

Findes der nogen lysdæmper hvor du ikke har et spændings fald, selv når der er skruet helt op for lysstyrken?

Jeg troede at den "fejl" netop var rettet i HW2. De behøver i hvertfald ikke længere belastning for at blive linket, så den "fejl" er rettet.

Kommer der også en lille installations vejledning til Domoticz? Jeg indrømmer blankt at jeg kun har brugt 5 min. på at kigge på Domoticz installation, men da jeg ikke er expert i Linux virkede det meget forvirende for mig.

Det er LK vi tale om. De kan ikke engang finde ud af at sørge for at certifikaterne i deres firmware ikke udløber 3 mdr. efter de frigiver en ny version. Jeg tror faktisk kun at vi har haft firmware med valide certifikater i sammenlagt 6 mdr. de sidste 5 år.

Når nu din elektriker har brugt tid på at monter klemmer for fase og nul, så kunne man godt ønske sig at han også havde afsat klemmer til mellem ledningerne. Men for at svare på dit spørgsmål. Hvis du ikke har styr på hvad der er fase og nul, så bør du lade din elektriker monter bypassen.

Du kan sagtens bruge en FB pr. udgang og trække temp sensoren over på dem begge. Det giver bare ikke mening, medmindre du køre med forskellige setpunkter på de 2 FB'er. Den mest økonomiske opvarmning får du i midlertid når alle radiator i samme rum altid har den samme temperatur, og det får du bedst ved at forbinde begge radiator til den samme FB.

Prøv om du du kan følge mellem ledningen fra en af dimmerne. Et eller andet sted i din tavle, bør den gå over i et kabel til dit lampested, hvor der også er nul.

Hvis du opgrader til firmware 2.7.220 slipper du for at disable TLS1.1 og 1.2. Du risiker dog at få en ustabil controller, men der er også bruger, som ikke har problemer med 2.7.220. Firmware 2.7.199 er tilsyneladende den mest stabile firmware pt. men den har problemer med TLS 1.1 og 1.2 Begge firmware har udløbne certifikater, og LK kan ikke sige noget om hvornår der kommer en firmware med opdaterede certifikater.

Problemet med IHC net basis er at man kun har de 2 par som kræves for 100Mbit netværk tilrådighed for data forbindelser. De 2 andre par er reserveret til TV og telefoni. Gigabit kræver alle 4 par, og enkelte gigabit autosense implementeringer checker ikke om alle 4 par er tilrådighed. De spørger kun om enhenden i den anden ende kan køre gigabit. Kan den det satser de på at forbindelsen mellem dem er ok, også har man baladen.

Jeg har ikke nogen forklaring, men generelt er LK's IHC produkter ca. ligeså stabile som m$ windos.

Nu har jeg ikke selv 2 controller, men hvis jeg havde kunne jeg godt se en fordel i at IHC captain kunne fungere som en bridge mellem dem, for det eneste LK tilbyder er at man overføre on/off signaler ved at forbinde en indgangs port på controller 1 til en 2 udgangs port på controler 2 og omvendt. På den måde kan man så overføre 16 on/off signaler hver vej. Jeg kan sagtens forstille mig at man også vil have god brug for at overføre temperature etc. Såvidt jeg huske kan visility boarded (http://visility.com/) bridge 2 controller, men det er PÆNT DYRT desværre.

Hvis en PC virker på stikkene, bør et access punkt også gøre det, så jeg tvivler lidt på at et special kabel vil løse noget. Forhåbentlig kan din svoger returner det hvis det ikke virker. Jeg talte med en kollega idag, og han nævnte at problemet muligvis kan være at Cisco routeren og access punktet tror de kan køre GigaBit, hvilket IHC Net Basis ikke understøtter. For at komme uden om det problem, skal i logge på routeren og tvinge den til at køre 10 eller 100Mbit på den port som er tilsluttet access punktet. Det vil ikke være første gang at der er problemer med autosense porte. Da HP kom med de første 100Mbit switche med autosense porte, skulle jeg prøve at sætte sådan et par stykker op hos en kunde. Det fungerede fint, bortset fra hvis jeg forsøgte at forbinde uplink portene på 2 ens HP switche med hinanden. På dem var man nød til at sætte hastighed etc. manuelt. Forsøgte man at forbinde uplink portene til f.eks. en Cisco switch var der ikke noget problem, så fandt de selv ud af at køre 100Mbit full duplex.

Det bliver ikke kønt i programmet, men der burde ikke være nogle problemer med den metode.

De kan ikke opdateres. Der er 2 måder at kende forskel på HW 1 og HW2. Der sidder et lille klistermærke med HW2 på bagsiden af HW2 lampeudtagne. HW2 modellerne kræver såvidt jeg husker ikke belastning for at man kan linke dem. HW1 gør.

Det kan også være TLS 1.1 og 1.2, som skal disables i JAVA.

Virker adgangen til den første controller fortsat? Jeg går udfra at din anden controller svare på port 80 og 443 når du bruger den interne IP. Ellers skal du rette din forward til at pege på de port, som controlleren bruger.

Så har jeg snart ikke flere gode ideer. I har selvfølgelig checket standard ting, Samme port på routeren til access punktet hvergang, så i kan udelukke at der er et port konfigurations problem. Samme patch kable som bruges til PC'en når i tester på det stik, så i kan udelukke at der er tale om et defekt patch kabel. Hvis det er muligt at logge på Cisco routeren ude fra, kan i sende mig login informationer i PM, så kan jeg prøve at kigge på den ende når i tester næste gang. Hvis det er på sjælland kunne jeg evt. også kigge forbi en dag.

På hvilket nr.?