Lars1

Sparepære giver normalt ikke de problemer som Lachris beskriver. Hvis det er sparepære, som tænder igen, så vil man normalt se det ved at lampen tænder automatisk efter at være blevet slukket, og somregl vil den blive ved med at tænde igen når man slukker den. Lachris problem er at han er nød til at slukke lyset før han kan tænde det, selvom der ikke er lys i lampen. Det plejre at være en program fejl. Jeg har ikke adgang til Visual PT. så jeg har ikke mulighed for at checke den pågældende FB, men prøv at smide dit program op her, så er der sikkert en af kode hajerne, som kaster sig over det.

Hvis adaptive fartpilot, ABS etc. ikke fra fremme på det tidspunkt hvor din bil blev designet, vil jeg give dig ret i din betragtning. Problemet med de oldnordiske krypterings og hash algorithmer er at afløserne har været definert og tilgængelige i browser m.m. i mere end 10 år. De var med andre ord klar da HW 6.1 controlleren blev designet, men LK valgte som mange software producenter at ignorer de nye standarder. For SW producenter er dette ok, da deres produkter sjældent har en levetid på mere end 5-10 år. Men en IHC controller har en forventet levetid på 10-20 år, så her er det ikke akseptablet at man designer noget HW, så det på design tidspunktet ikke kan understøtte seneste version af de protokoller og metoder man benytter.

Den fejl du beskriver, lyder som noget andre også har oplevet. Jeg kan ikke huske om der var en fejl i nogle af LK's tidligere FB's eller om det bare var tilbagemeldingen, som manglede, men det er helt sikkert en programerings fejl i dit Visual program.

Nu skrev jeg gennemsnitlig :-) En gateway som f.eks. IHC Captain, IHC Bridge etc. benytter sig somregl af krypterings og hash algorithmer fra det OS som de køre på. På et eller andet tidspunkt dropper dette OS også de old nordiske algorithmer, præcis som Apple nu har gjort med iOS11. Så med mindre disse gateways koder deres egen kommunikations interface, med egne krypterings og hash algorithmer, vil disse gateways også holde op med at virke på et tidspunkt.

Du kan ikke rigtigt sammenligne IHC systemer med anden IT, da IHC systemer er designet til el-installationer, som har en gennemsnitlig levetid på 10-20 år, mens IT udstyr som PC'er, tablets, smartphones, AV udstyr etc. har en gennemsnitlig levetid på 2-5 år. At IHC systemer kan bruge samme med smartphones etc. betyder ikke at man med rette må leve med at den korte levetid, men det betyder at man med rette må forvente at selvom IHC udstyret er 10 år gammelt, så kan det fortsat bruges med moderne smartphones etc. hvis man sørger for at det bliver software opdateret når der kommer ny firmware.

Det er lidt pudsigt at det er ok at bruge 4-6.000 om året på en ny telefon hvergang der kommer en ny iPhone, men det er ikke ok at bruge 4-6.000 på en ny controller hvert 10 år. :-) Bortset fra det, er jeg enig i at det er under alt kritik at HW6.1 ikke længere undersøtter seneste version af Java og IOS, men det er snart 5 år siden at den sidst har supporteret seneste Java, så den eneste reelle nyhed er at supporten for seneste IOS nu også ryger.

Jeg tror din elektriker skal sætte sig lidt bedre ind i IHC inden han udtaler sig. Hvis du har en HW 6.1 controller og nyeste Java, så funger f.eks. ServiceView, etc. heller ikke medmindre du manuelt går i en config fil og reenabler MD5. At lade være med at opgrader Java svare til ikke at opgrader til det nye Apple OS. Så med andre ord. Hvis du bare bruger LK IHC som avancerede kip relæer, så har du ret, så har det ingen betydning at den gamle HW 6.1 controller ikke understøtter moderne krypterings og hash algorithmer. Men hvis du som flertallet her på boardet laver forskellig integrationer med LK IHC, eller bruger LK IHC apps, så er en HW 6.1 controller idag værdiløs

Jvf. villedningen til den nye controller, så er LK endeligt kommet ind i det 20'ende århundrede på punkt. Den nye controller skulle kunne firmware opdaters via netværket, USB eller SD kortet. De gamle kan kun firmware opdateres via USB.

Såvidt jeg ved er det processoren i HW 6.1 som ikke er kraftig nok til at understøtte de moderne krypterings og hash algorithmer. Kig f.eks. på MD5 som er blevet udfaset i Java, browser etc., men som HW 6.1 controleren fortsat bruger og som man er nød til at enable i Java hvis man har en HW 6.1 controller. Med firmware 2.8.4 og en HW 6.2 controller er dette ikke nødvendigt.

Problemet er de oldnordiske krypterings algorithmer som HW 6.1 stadigvæk lever med. Ligesom Java, og de fleste browser har droppet supporten af de oldnordiske krypterings algorithmer hopper Apple nu også med på den vogn. Så jeg tvivler stærkt på at LK kan lave en app, som vil virke med LK IHC HW 6.1. De vil i såfald være nød til at implementer deres egen krypterings algorithme.

Det afhænger af hvor god din udsugning er. I et normalt hus vil du aldrig opleve at dugpunktet kommer over rum temperaturen under normale forhold. Hvis det sker har du et seriøst fugt problem.

Pas. Det er snart 20 år siden jeg forlod branchen. Men de fleste elektrier giver normalt gerne et overslag ganske gratis.

Dugpunktet fortælle dig hvornår vanddampen i luften fortættes til vand. Det er en beregnet værdi. Du kan f.eks. bruge den til at hvis dugpunktet nærmere sig rum temperaturen kan du skrue op for varmen, og dermed udgår at vanddampen fortætter sig på vægge, møbler etc.

Det er et spørgsmål om definitioner. Med ren wireless har du ikke brug for I/O moduler. Faktisk kan du lave det helt uden controller, men dine muligheder vil være begrænset. Når du har wireless tryk og output moduler har du en blandet installation. Du har sandsynligvis også et par wireless lampe udtag.

Som jeg skrev. Få en elektriker til at kigge på opgave. De afgiver normalt gerne tilbud inden de går igang. Du må alligevel ikke selv lave ændringerne i tavlen, og det lyder ikke umiddelbart til at du har så meget styr på det, så det kan være meget farligt at prøve selv.

Det kan godt lade sig gøre at fjerne alt IHC, men du skal få en elektriker til at kigge på opgaven for dig. Dels er det farligt selv at rode i el-tavler, og dels vil du ikke have nogen output moduler hvis alt køre wireless, så IHC bruges sandsynligvis til mere end bare lys styring. En dygtig IHC elektriker vil kunne fortælle dig det på under 1 time, og samtidig give dig et overslag på hvad det vil koste at fjerne IHC helt.

Firmware .199 understøtter ikke fugt sensorne. Det er kun den seneste firmware til HW6.1 som gør det. HW mæssigt er temp sensorne med gulv føler og temp. sensorne med fugt føler de samme. Det er bare føleren som er til forskel samt hvordan det benævnes i programmet, hvilket styres af produkt koden i visual programmet, og det er denne som mangler i den gamle firmware, hvilket er årsagen til at du ikke kan uploade programmet. De 55 grader er din luft fugtigheds procent.

Prøvede du om rebuild metoden som er beskrevet i Visual 3 villledningen virkede før du relinkede?

I betragtning af hvor lidt forskel der er på den gamle og den nye controller, vil jeg blive MEGET overrasket hvis den ikke funger sammen med IHC-Bridge.

Tja. eftersom der er en reset knap på den nye controller, er det nok meget tænkeligt at man kan genstarte den ved at trykke på reset, eller via genstart i admin view. Hvis dette ikke er nok kan man tage strømmen. Bortset fra reset knappen, er det præcist som på alle tidligere Visual controller. Der er allerede et par stykker som har haft Visual 3 controlleren i hånden, og skrevet om det her. Alle uden undtagelser har skrevet at det er minimalt med nyheder og at de ikke er imponeret af den nye controller.

Prøv at læse nogle af de mange indlæg her på boardet. Både Lars Jacobsen og jeg har sammenlignet de 2 controller ud fra de medfølgende manualer. Konklusionen er at det stortset ikke er nogen forskel. Brugergrænse fladen er præcis den samme på dem begge. Der er enkelte nye funktioner, som S0 indgang for energi måler og gange/divider. Men det er stortset også de eneste nye funktioner. Stabiliteten er det umuligt at sige noget om før mindst 10 af de aktive bruger her har opgraderet og har haft den nye controller kørende i mindst 6-12 mdr. Indtil da vil du ikke have et brugbart datagrundlag til at konkluder om stabiliteten er bedre i den nye controller. Ringer kan den næsten ikke blive.

Alle hoteller reklamer med at de ikke skifter håndklædet, hvis man hænger det på knagen, men hænger du det på håndklæde tørren, så hænger der et nyt og pænt foldet håndklæde når du kommer tilbage efter dagens dont. Det giver jo ikke meget mening hvis formålet med en håndklæde tørre på et hotel er at tørre håndklæder. Det gælder både Radisson, Scandic og Hilton. Det skal dog siges at jeg inden for de sidste 10 år kun har haft 3 hotel nætter i DK, men +1000 på hoteller i udlandet.

Har du wireless enheder i din IHC installation, og hvis ja, kunne du så skifte fra Visual 2 til Visual 3 controlleren via rebuild funktionen uden at skulle genlinke alle dine wireless enheder?

Normalt behøver man ikke en håndklæde tørrer for at et håndklæde fint at blive tørt mellem 2 bade, hvis man kun bader 1 gang om dagen. Det har de i hvertfald gjort alle de stedder jeg har boet gennem de sidste +50 år. I min verden er basis formålet med en håndklæde tørrer at der er varmt håndklæde når man har været i bad. Jeg mindes ikke at have skrevet noget sted at håndklæde tørrer på hotellerne først starter når man går i bad. Hvis du læser længere oppe, vil du da også se at jeg netop har pointeret at håndklæderne ikke når at blive varme mens man er i bad. Håndklæde tørrene på hotellerne køre da normalt også 24 timer i døgnet, men eftersom de fleste hotel gæster går i bad om morgen og håndklæderne ofte bliver skiftet når der er rengøring om formiddagen, er håndklæde tørrene der næppe for at skulle tørre håndklæderne. Tja. Jeg bruger gulvvarmen som primær varme kilde på mit bade værelse, og suppler med varme fra håndklæde tørren. Det giver den bedste komfort og mest konstante temperatur.

IHC controlleren har IKKE noget ModBus interface. Den har et RS485 interface, men det betyder ikke den understøtter ModBus. RS485 definer bare Bits Per Second, spænding etc. Den fortæller intet om hvilken protokol interfacet understøtter. RS485 blev brugt meget i industri og f.eks. landbrug, hvor man køre alm. seriel kommunikation over interfacet, da RS485 har en længere rækkevide end RS232, og er mere støj imum. Hvorvidt det er IHC controlleren eller Schneider PLC'en som bruges til ModBus kommunikationen er irrelevant. Fakta er at LK's tumbede Nilan integration bygger på en Schneider PLC, som kan tale ModBus, og at Schneider PLC'en kræver at være master på denne ModBus. Dermed bliver Master/Slave forhold'et på ModBus'en relevant, da der kun kan være 1 master på en ModBus, men mange slaver.