Lars1

Om 2.7.190 er før eller efter 2.7.199 er ligegyldigt. Det vigtigste er at 2.7.199 bliver installeret før du installer 2.7.220 eller højre. Bortset fra det mener jeg at firmware nr'erne er de samme i alle lande.

Du kan sagtens ændre SSL porten til noget andet end 443. Du skal bare huske at skrive https: i starten af URL'en, og slutte af med :<port nr>

Nej. Serviceview poller kun for de informationer som kan ses på din skærm. Hvis en FB er foldet sammen, poller serviceview ikke for data i den FB. Men du har kun de gamle krypterings algorithmer, som ikke kræver så meget af controlleren, som de algorithmer der ligger i 2.8.4, og det er en STOR forskel.

Hvilken URL bruger du efter du har ændret portene? Har du en FW eller router mellem din PC og IHC controller?

Jeg tror forskellen ligger i hvordan de forskellige systemer kommuniker med controllerne. Jeg kan godt forstille mig at OpenHab og ICH Captain, spørger efter masser af parameter ganske ofte, mens IHC Remote og IHCtablet nok er mere præcis i deres forspørgelser og ikke spørger så ofte. Men bortset fra det mener jeg er er nogen som har skrevet at de ikke kan komme på deres HW6.2 controller hvis IHC remote or tablet køre.

Jeg husker måske forkert men jeg mener det var Øresundsbanen.

Alt hvad du skrev i det pågældende indlæg er faktuelt forkert, men jeg orker ikke længere at forsøge at forklare det for dig.

Nej. IHC står for Intelligent House Control. Jeg ved ikke lige hvor du ser nogen drøfte anvendelsen af IHC til professionnelle datacenter. Jeg sammenligner oppetiden mellem systemer hosted i en cloud løsning og i et lokalt datacenter for at anskuelig gøre hvorfor jeg mener cloud løsninger til IHC ikke giver mening. Men bortset fra det, så havde BaneDanmark faktisk på et tidspunkt et sikrings anlæg som var bygget på LK IHC. Det er dog blevet skrottet for flere år siden såvidt jeg ved.

Og det synes jeg er prisværdigt, men funktionelt burder der ikke være nogen forskel på om du bruger en public cloud løsning eller installer din SW på en lokal host. Jeg synes det du har lavet ser godt ud. Det hostes bare det forkerte sted IMHO. Cloud løsninger er gode til mange ting, men der er også ting de ikke er så gode til. IMHO er IHC en af dem, primært fordi du primært bruger din IHC når du er hjemme, og du er f..... når der ikke er forbindelse mellem din IHC installation og cloud løsningen. IHC's event styring gør det endnu mere kritisk at der ALTID er forbindelse mellem cloud løsning og IHC installationen. Hvis du f.eks. bruger en tids funktion i clouden til at tænde for varmen 6 timer før du kommer fra ferie. Så vil det være pænt irriterende at huset er koldt når du kom hjem, fordi at der ikke var forbindelse på det tidspunkt hvor cloud løsningen skulle sende event trickeren. Vi har det med at blive afhængige af den automatik vi bygger ind i vores IHC løsninger, og vi (familien) har ikke nogen lang lunte når det ikke virker. De fleste af de kunder jeg arbejder med, bruger cloud løsninger til deres salgs og marketing systemer. Disse systemer tilgåes ofte fra kunde sites og indeholder sjældent data, som er omfattet af EU's data privacy lovgivning, så her er det en fordel at bruge cloud løsninger. HR systemer har været cloud løsninger i et stykke tid, men jeg har for nylig fået den første forspørgelse på at flytte det inhouse, grundet cloud leverandøren ikke kunne garanter at data ikke blev opbevaret eller tilgået fra en lokation uden for EU. Produktions systemer er altid inhouse, og somregl lokalt på fabrikkerne, alene af den grund at hvis der ikke er forbindelse til systemerne, så kan fabrikken ikke producer, og det er RIGTIGT dyrt.

Jeg er godt klar over du ikke er igang med at erstatte IHC controlleren med en cloud løsning, men jeg går udfra at du laver cloud løsningen fordi det er meningen den skal bruges, og når først den bruges, så har du baladen med familien når det ikke virker, og som du kan se i mit svar til Peter, så er cloud løsninger ikke ligefrem de mest stabile. Jeg bruger dem professionelt i mit daglige arbejde, så jeg ved hvad jeg taler om. Sikkerhed på LK IHC er jo ikke ligefrem state of the art og som jeg skrev tidligere, så ser jeg ikke kommunikationen med IHC controlleren som den største sikkerhedsrisiko, men derimod sikkerheden i cloud løsningen. Problemet med de fleste cloud løsninger er at du ikke kan få nogen information er overhovedet om sikkerheden i den bagved liggende infrastruktur, og der har været flere sager hvor en cloud løsning er blevet hacket via den bagved liggende infrastruktur. Men bare fordi jeg ikke kan se ideen med cloud styrede IHC løsninger skal ikke holde dig fra at fortsætte. Der er helt sikkert mange som ikke har samme fokus på sikkerhed og oppetid som jeg har.

Mobilt internet løser da heller ikke problemet. Vi bruger det på arbejdet til nogle af vores mindre salgs kontore, og der er udfald på det flere gange om måneden. Sommetider i halve og hele timer. Dertil kommer at cloud løsninger ikke ligefrem er så stabile som cloud udbyderne gerne vil gøre dem til. Alle kritiske systemer hos os køre i vores eget datacenter, men vi har nogle mindre kritiske løsninger kørende i forskellige cloud løsninger. Ingen af disse har til dato kunnet holde en oppetid på 99%, og flere af dem har været nede i en hel weekend grundet system opdateringer, og du har INGEN indflydelse på hvornår de laver system opdateringer etc. Tilsammenligning har samtlige vores kritiske systemer inden for de sidste 12 timer haft en oppetid på over 99,99% og dette er incl. downtime til patching, systemopdateringer etc. Hvis konen eller ungerne kommer hjem og ikke kan tænde lyset så bliver der ballade. Hvis solfanger anlæget køre temperaturen i buffebeholderen over 90 grader, risiker jeg at varme slangerne smelter. Kom selv på flere eksempler hvor det ikke er godt at din IHC installation ikke fungere fordi du har baseret den på en ekstern cloud løsning.

Prøv at læse højre oppe. Der skriver mikkel noget om at IHC Captain ikke virker på PI3. Jeg mener ikke han er kommet med opdateringer siden. Derudover havde jeg et problem første gang jeg installerede IHC Captain på min PI2. Jeg mener rod html cataloget var ændret i PI imaged, men jeg kan ikke huske hvad der skulle tilføjes i URL'en for at komme til IHC Captain.

Jeg har den grundlæggende holdning at min varmestyring, alarm og lysstyring m.v. skal virker, også når TDC har klippet min internet forbindelse og er 3 dage om at reetabler den. Så hvis du har en udgave, som kan installeres på en af mine Raspberry's så vil jeg være interesseret. Ellers vil jeg bare ønske dig held og lykke med dit projekt, som bliver uden min deltagelse. Derudover skriver du ikke meget om hvordan adgang til IHC cloud løsningen er sikret. Det er fint nok at man kan begrænse adgangen til controleren til en enkelt IP, men det hjælper jo ikke meget hvis adgange til cloud interfacet er frit tilgængeligt. Hvis dette er tilfældet (formoder jeg ikke) vil det være værre end at give fri adgang til controlleren, da det trods alt er sværre at gennemskue LK's serviceview for uvedkommende end et bruger venligt cloud interface.

OpenHab og Raspberry er næsten gratis såvidt jeg ved, så hvorfor ikke prøve. Du kan jo altid droppe det igen hvis det giver problemer.

Gid det var så vel. Hvis det var sandt, så var vi sluppet for mange problemer med LK IHC. En PLC er status styret. Hvis den misser en status ændring på en indgang så er det ikke den store katastrofe. Den vil fange den under næste program gennemløb, som er mindre end 1 sek. senere. LK IHC er event styret. Hvis den misser et ændring på en indgang er du f..... Den vil ikke fange ændringen før du igen ændre din indgang. Dertil kommer at den er nød til at holde styr på sine event's samt i hvilken række følge de kommer ind. Jeg vil ikke være overrasket hvis det som sommetider for IHC controlleren til at crashe er at event stack'en løber fuld. Det vil alrig ske på en PLC.

De nye krypterings algorithmer kræver desværre en del mere af processoren. ZigZa's sensor sender desværre data ca. 10 gange så ofte som LK's temp. sensor, så de hjælper ikke ligefrem på stabiliteten, men det burde kunne køre alligevel, dog med den workaround at du sikkert ville være nød til at stoppe IHC Captain og homebridge når du skulle connecte med Visual. Hvorfor du har mistet dine wireless links fatter jeg ikke. Det burde ikke ske, medmindre det skete i forbindelse med at du loadede et tomt program eller en reset firmware.

Der er pænt stor forskel på hvor meget processor kraft de 2 forskellige algorithmer kræver. Det gælder ikke kun LK IHC. Hvis jeg stopper IHC Captain, er der ikke noget problem med at connecte til min HW 6.2 controller. Hvis jeg downgrader til en firmware med de gamle krypterings algorithmer kan jeg sagtens connecte til min controller selvom IHC Captain køre.

@Ahave. Prøvede du at genstarte din controller da du havde problemer, eller gik du direkte til downgrade?

Det afhænger lidt af hvad du har kørende. Hvis du som jeg har 10 temp. sensor, og IHC-Captain kørende, så belaster du din controller mere end hvis du kun har temp sensor eller IHC captain kørende. Jeg kan ikke få Visual til at forbinde til min controller, med mindre jeg stopper IHC Captain.

De fleste ISP'er tillader ikke man sender mail's direkte til modtagerne. De kræver somregl at du bruger deres mail GW, og den køre ofte på port 25. Men det er forskelligt fra ISP til ISP og afhængig af hvilken internet forbindelse du har fra ISP'en. Hos YouSee er der f.eks. forskel på om du har en VDSL linie som du selv betaler for eller en VDSL som din arbejdsgiver betaler for. Den sidste betragtes som en erhvervs forbindelse med flere muligheder, selvom router etc. er præcis den samme som på den private udgave.

IHC er ikke specielt besværligt IMHO, men det bygger på et tudse gammelt design, og har ikke rigtigt fulgt med tiden, så man skal arbejde lidt som man gjorde for 10-20 år siden. Alle ændringer laves via Visual programmet, men adminview, serviceview etc. er Java programmer som afvikles via web. Du skal kun have Java installeret for at kunne afvikle dem, og alt efter firmware version og Java version kan du finde workarounds til alle kendte Java problemer i tråden Java problemer igen igen igen.

Log ind i adminview på din controller. Der står HW versionen. Du kan også slå model nr'et som står på forsiden af controlleren op på internettet. Er det 820BA400, så er det en HW 6.2 controller. Men hvis den er fra 2015 så burde det være en HW 6.2 Det er dog ikke nok at din controller er HW 6.2. Du skal også være på seneste firmware eller mindst på en firmware efter 2.7.220. 2.7.220 indeholder kun de gamle krypterings algorithmer, som iOS11 ikke længere understøtter. Firmware level kan du også se i adminview

De 2 step er rigeligt. Jeg har haft IHC i mere end 10 år, og den eneste gang jeg har set LK skrive noget om at man ikke kunne gå direkte til seneste firmware version var da 2.7.220 blev frigivet. Faktisk mener jeg at du kan gå direkte til 2.8.4. Det er såvidt jeg ved kun 2.7.220, som kræver at du går på 2.7.199 først, men det skader ikke at gå på 2.7.199 før du går på 2.8.4, så det vil jeg også gøre hvis jeg stod i din situation.

Prøv at genstarte din controller. Det kan være den ikke er kommet helt rigtigt op efter opdateringen. Har du ændret i dit program i forbindelse med opdateringen? Der findes desværre ikke nogen måde at reetabler wireless links på uden manuelt at skulle linke dem alle igen. Du kan evt. prøve at indlæse den seneste backup af dit program, hvis ikke genstarten løser problemet.

Prøv lige at læse mine indlæg igen. Jeg skriver ingen stedder at brummeriet har noget med belastningen at gøre. Når jeg skriver om 3 faset belastning er det for at forklare forskellen på at bruge et relæ og et 400V output modul. Selvom at et 400V output modul kan håndter 3 faser, kan det ikke altid erstatte et relæ, grundet hver enkelt udgang styres individuelt, mens et relæ altid vil bryde alle 3 faser samtidig. Et relæ skal ikke brumme selvom du trækker 110% på 1 fase og 0% på en anden. Elektronik, herunder transformator skal heller ikke brumme. Gør de det alligevel er det typisk fordi de er af dårlig kvalitet eller defekte. En køle kompressor i et køleskab eller en fryser vil altid brumme lidt, da der sidder en mekanisk motor, som driver kompressoren. Det er den du kan høre arbejde. Der sidder ikke nogen kondensator i et relæ, så det er næppe derfor at relæet brummer. Men som skrevet tidligere. Nogle relæer brummer. Det er typisk fordi spolen eller jernkernen ikke sidder 100% fast. Editeret 5/10 i et forsøg på at gøre indlæget mere forståeligt.