Upgrade/Downgrade - advarsel ikke spørgsmål

[ahave]

EDIT: Læs hele tråden hvis du er endt her. Efter nedenstående svar/hjælp har jeg lavet diverse forsøg, men opgradering og efterfølgende nedgradering fungerede ikke særlig godt for mig og slet ikke med 3. parts usupporterede produkter som Openhab og IHCcaptain.

---

Bemærk, dette er ikke et spørgsmål - blot et informationspunkt til dem som vil opgradere til 2.8.4 og efterfølgende forsøger at nedgradere igen.

For igen at få min LK app til at virke efter iOS 11, opgraderede jeg min v6.2 controller til 2.8.4. Det virkede sådan set fint og LK's app fungerede. Problemet var blot at controlleren blev frygtelig langsom og at tænde et lys kunne tage 10 sekunder. Det er en stort set ren wireless installation og jeg har 2 servere, en med IHCcaptain og en med openhab/homebridge. Læste at 2.8.4 ikke var glad for 3.parts forbindelser, hvilket blev løst ved at lukke de to virtuelle servere.

Da jeg gerne vil gøre brug af diverse smarte features besluttede jeg mig at nedgradere igen til 2.7.220 og droppe LK's app. Det medførte at controller begyndte at genstarte ca hver 10. minut, hvilket i praksis betyder med opstartstid var min installation ubrugelig. Forsøgte derfor at nulstille til fabriksindstillinger, genopsætte controller og lægge programmet ind igen.

Desværre for mig stod alle enheder med rødt udråbstegn(EDIT: Det sker ved en nulstilling, pinligt at jeg ikke undersøgte dette) og der skete pudsige ting når jeg trykkede på et batteritryk. Stikkontakter virkede til en vis grad, men lampesteder fuldstændige uforudsigelige. Heldigvis virkede de fortråede telestater(varme) og trådløse puckrelæer(ventilation) fint.

Kunne ikke forbinde med IHC visual til controlleren længere over netværk, kun USB(har styr på netværk). Forsøgte at unlinke/linke diverse batteritryk og lampesteder uden stort held. Noget virkede noget gjorde ikke.

Nu har jeg igen opgraderet til 2.8.4, alt står stadig med røde udråbstegn og ikke meget virker men til gengæld kan jeg nu styre min installation via LK's App og forbinde via visual over netværk. Har fået linket et par lampeudtag med batteritryk, det er dog ikke altid at det virker at genlinke. Formodentlig kan det være gamle hjemmelavede tænd/sluk baseret på scenarier som giver dette problem efter opgradering/nedgradering af firmware.(EDIT: det var ikke gamle hjemmelavede FB)

Pudsigt nok virker alt via serviceview så controller har informationerne, men programmerne virker ikke. Næste skridt bliver formodentlig at unlinke og slette alle lampeudtag(ca 20) + linke og genetablere.

Lang post, men hvis jeg kan hjælpe bare én med at tage beslutningen om at opgradere(som benytter openhab eller IHCcaptain) var det tiden værd. Måske skulle jeg købe en ny controller nu hvor jeg alligevel i bedste fald blot skal genlinke alt....

/ahave

 

[Kandersen]

5 timer siden, Lars1 skrev:

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.

Det hænger stadigvæk ikke sammen, for hvad med service view? Den har jo noget nær realtime forbindelse til controlleren.

Og som jeg forstår, så opstår problemerne nu her med firmware 2.8.4 (altså den som understøtter IOS11). Så hvis vi skal konkludere noget som helst ud af det, så er det meget muligt at HW 6.2 er "nyere" hardware end 6.1. Men det må være en ringere hardware, for min 6.1ér med firmware .199 kan drive praktisk talt det hele, på een gang. Dvs:
Service View
IHCremote
IHCtablet
IHC Captain
OpenHab2

Jeg gentager lige - Dem alle på een gang! (det ER afprøvet).

I forbindelse med OpenHab2, så er det efterhånden alt som jeg "samler" op fra controlleren i OpenHab2. Det er immervæk en hel del meldinger den suser afsted, bla fordi det er 12 Zigza temperatur og fugt følere, der nærmest konstant står og melder ind. (dog kun 2 temp/fugt). Men ellers er der div. tryk, status, wireless, PIR´s

De eneste problemer jeg har, det er periodisk haft Visual2 meldt fejl, når jeg har ville hente programmet fra controlleren. Og ligeledes har Service view. Men det er kun sket et par gange siden jeg byggede varmestyringen, hvilket uden tvivl har presset controlleren nu. Men jeg bemærker det kun når jeg skal sende/hente program i Visual2. I daglig drift mærker jeg intet. 

Så du kan måske forstå, hvorfor jeg er lettere rystet over at høre, at HW 6.2 har de problemer. Og som nogle siger nu, nærmest umulig at bruge sammen med andet, hvis man bruger firmware 2.8.4. Det er jo dybt grotesk!

Men LK skal ikke dø i synden uden jeg har haft en finger med i spillet. Jeg har fået fat i en HW 6.2 controller, som forhåbentlig dukker op een af dagene. Så må jeg se hvad jeg kan drive ud af den. Virker det ikke tilfredsstillende, så kommer der ikke den nye firmware på. I værste fald smider jeg 6.1éren på igen. 

[Kandersen]

6 minutter siden, ahave skrev:

Her kan man se polling fra Openhab og den er kontinuerlig på alle items defineret i IHC.items.

Det må da være det samme for LK´s ServiceView? Ellers ville den jo ikke kunne fungere. 

[Lars1]

8 timer siden, Kandersen skrev:

Det hænger stadigvæk ikke sammen, for hvad med service view? Den har jo noget nær realtime forbindelse til controlleren.

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.

 

8 timer siden, Kandersen skrev:

Og som jeg forstår, så opstår problemerne nu her med firmware 2.8.4 (altså den som understøtter IOS11). Så hvis vi skal konkludere noget som helst ud af det, så er det meget muligt at HW 6.2 er "nyere" hardware end 6.1. Men det må være en ringere hardware, for min 6.1ér med firmware .199 kan drive praktisk talt det hele, på een gang. Dvs:
Service View
IHCremote
IHCtablet
IHC Captain
OpenHab2

Jeg gentager lige - Dem alle på een gang! (det ER afprøvet).

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.

[Kandersen]

2 timer siden, Lars1 skrev:

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.

Så hvis man åbner alle Fbérne, så vil service view også få controlleren til at kaste håndklædet i ringen?

 

2 timer siden, Lars1 skrev:

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.

Den er jeg med på. Der hvor jeg har min tvivl er:
1. Om belastningen i virkeligheden er så stor, altså CPU mæssig.
2. Om HW 6.2 i virkeligheden er skruet sammen 'lige til øllet', og der derfor ikke skal ret meget til at få den til at gå i knæ. Fx. en rimelig stor installation plus en enkelt udefra tilsluttet 3.part (IHC Captain, OpenHab, Service view, IHCremote, IHCtablet eller andet).
Hvis det sidste er tilfældet, så er det nemlig spørgsmålet om ikke også HW 6.2 skulle have været droppet (dvs. den nye firmware) og ikke kun 6.1.

Forstå mig ret - Hvis LK er klar over, at HW 6.2 er ekstremt presset, med en almindelig installation og firmware 2.8.4, så burde de måske slet ikke have lavet den firmware, da den med stor sandsynlighed bare vil give brugerne problemer før eller siden.

Egentlig begynder den teori at give mening. Og det er derfor vi så HW 7 komme ind fra sidelinien nærmest som dug for solen, og med ekstrem små ændringer. Det er ihvertfald ikke et produkt som der har været arbejdet intenst med særlig længe, det er jeg ret sikker på. Og med Apple´s udmelding, som de muligvis har fået adskillige måneder før, så har de godt kunne se hvor det bar hen, og måtte lyn hurtigt lave en controller, der rent hardware mæssigt kan håndtere de "nye krypteringsformer" uden at controlleren går i knæ, hvis de overhovedet skulle holde nogen form helst former for liv i IHC konceptet fremover. På den måde ved de godt at:

HW 6.1 er død og borte.Brugerne af disse må bare købe en ny controller. Har man købt en controller med HW 6.1 frem til 2012 (5 år), så er det bare sur røv. 
HW 6.2 kører på pumperne, og blot med spørgsmål om tid før det går galt. Der kommer nok en såkaldt "ny krypteringsform" igen.
HW 7.0 er pt. det eneste som holder liv i konceptet, endnu. 
Forretningsmæssig er det en ganske smart detalje, da det nærmest tvinger alle over på den nye, uden at de reelt får noget som helst nyt ud af det, (eller rettere, noget der ligner en reel tynd kop the for de almindelige brugere).

Selvfølgelig kan man argumentere for, at de installationer som ikke laver nogle ændringer, de kan snildt køre videre med det de nu engang har. De skal bare ikke lave mange ændringer, så render de ind i problemer. Men det vidner lidt om, hvad det er for et produkt man har købt, og ikke mindst, hvilke forventninger man skal sætte til nyere produkter (nyere controllere). Hvem tør fx stole på, at HW 7 ikke får en eller anden form for problem fra nu og 5 år frem? Problem som vel at mærke ikke skyldes brugeren, men derimod at tiden ændre sig.

[Lars1]

5 timer siden, Kandersen skrev:

Så hvis man åbner alle Fbérne, så vil service view også få controlleren til at kaste håndklædet i ringen?

Pas. Jeg har aldrig prøvet, men det kan du jo prøve når du får din 6.2 controller monteret. :-)

5 timer siden, Kandersen skrev:

Den er jeg med på. Der hvor jeg har min tvivl er:

1. Om belastningen i virkeligheden er så stor, altså CPU mæssig.
2. Om HW 6.2 i virkeligheden er skruet sammen 'lige til øllet', og der derfor ikke skal ret meget til at få den til at gå i knæ. Fx. en rimelig stor installation plus en enkelt udefra tilsluttet 3.part (IHC Captain, OpenHab, Service view, IHCremote, IHCtablet eller andet).
Hvis det sidste er tilfældet, så er det nemlig spørgsmålet om ikke også HW 6.2 skulle have været droppet (dvs. den nye firmware) og ikke kun 6.1.

Nu supporter LK jo ikke trejdeparts produkter som IHC Captain etc. så jeg tivler  på at dette har spillet en rolle da LK droppede HW 6.1 supporten og kom med de nye algorithmer i HW6.2

Hvorvidt en HW 6.2 er lige til øllet, tror jeg afhænger af flere ting, som f.eks. antallet af temp/lux/fugt sensor, komplexiteten i IHC programmet samt dit brugs mønster.

[Kandersen]

1 time siden, Lars1 skrev:

Pas. Jeg har aldrig prøvet, men det kan du jo prøve når du får din 6.2 controller monteret. :-)

Prøvede det lige på 6.1. Mærkede ingen forskel :-)

1 time siden, Lars1 skrev:

Nu supporter LK jo ikke trejdeparts produkter som IHC Captain etc. så jeg tivler  på at dette har spillet en rolle da LK droppede HW 6.1 supporten og kom med de nye algorithmer i HW6.2

Det er spørgsmålet. For hvis 3.part forbinder på samme måde som IHCremote/tablet, så er det jo det samme.

 

1 time siden, Lars1 skrev:

Hvorvidt en HW 6.2 er lige til øllet, tror jeg afhænger af flere ting, som f.eks. antallet af temp/lux/fugt sensor, komplexiteten i IHC programmet samt dit brugs mønster.

I realiteten kan man have 112 sensorer, (8 x 14 indgange). Så det burde den jo være bygget til. At det så er urealistisk er en anden snak. Et "normalt" hus har nok noget der ligner 8-12 sensorer (i forbindelse med varmestyring), hvilket kun er lige godt en 1/10 af det maksimale. Oven i det er der selvfølgelig mange andre muligheder, i form af PIR´s, lux osv. Men jeg tror stadigvæk kun et "normalt" hus kommer i nærheden af 50%. Og så er det endda skudt højt.
Jeg har 13 sensorer temperatur med gulv/fugt og 7 PIR´s tilsluttet pt.
  
Selv tryk (fortrådet) kan næppe være det der belaster controlleren ret meget, medmindre man er blæksprutte og kan håndtere mange tryk på een gang. Selvfølgelig kan en større familie ryge ind i nogle scenarier, hvor flere trykker på samme tid. Men det er nok sjældent det vil ske. 

Så er der det trådløse. Det er selvfølgelig en afdeling for sig selv, da det faktisk godt kan være det der trækker en hel del. Så vidt jeg husker er controlleren bygget til 64 wireless produkter. Jeg har kun 7, (fire Uni250 og tre 2tast tryk). Så det er næppe det der lægger controlleren ned. 

Selvom de såkaldt nye krypteringsformer belaster controlleren en del, så burde der stadigvæk være massere af plads. Der sidder jo også et RS485 interface, som i mit tilfælde slet ikke bliver brugt, endnu. Når/hvis der ikke er plads i controlleren til at drive et 3.part samtidig, så tvivler jeg også på, at den vil kunne belastes ret meget mere end en installation der svare til 50%. 

Så ja, jeg har tænkt mig at gøre forsøget, når 6.2 controlleren dukker op. I værste fald kan man vel bruge 2 controllere, når jeg engang fatter hvordan det lige foregår :-)

[Lars1]

30 minutter siden, Kandersen skrev:

Det er spørgsmålet. For hvis 3.part forbinder på samme måde som IHCremote/tablet, så er det jo det samme.

Men det gør de jo ikke. IHCremote/tablet poller jo kun for de parameter som du har konfigureret dem til at polle for (såvidt jeg ved, har dem ikke selv), mens IHC Captain etc. poller for samtlige parameter hvergang. Hvert parameter req. skal krypteres, og så har du jo pludselig et pænt stort load på en HW 6.2 controller med de nye krypterings algorithmer, or det load bliver expotentionelt større jo flere parameter du har. Dertil kommer at temp./lux og fugt sensor bruger floating points til at angive deres værdier. Disse er væsentlig tunger at krypter end en on/off værdi. Hvis du bruger mange tekst værdier i dit program, øger du krypterings loadet endnu mere.

[Kandersen]

9 minutter siden, Lars1 skrev:

Men det gør de jo ikke. IHCremote/tablet poller jo kun for de parameter som du har konfigureret dem til at polle for (såvidt jeg ved, har dem ikke selv), mens IHC Captain etc. poller for samtlige parameter hvergang. Hvert parameter req. skal krypteres, og så har du jo pludselig et pænt stort load på en HW 6.2 controller med de nye krypterings algorithmer, or det load bliver expotentionelt større jo flere parameter du har. Dertil kommer at temp./lux og fugt sensor bruger floating points til at angive deres værdier. Disse er væsentlig tunger at krypter end en on/off værdi. Hvis du bruger mange tekst værdier i dit program, øger du krypterings loadet endnu mere.

Jeg kan godt følge dig. Jeg synes bare ikke det mærkes sådan. Måske fordi min 6.1ér slet ikke er belastet nok endnu.. Men jeg skal nok nå det :-)

[Lars1]

1 time siden, Kandersen skrev:

Jeg kan godt følge dig. Jeg synes bare ikke det mærkes sådan. Måske fordi min 6.1ér slet ikke er belastet nok endnu.. Men jeg skal nok nå det :-)

Med HW 6.1 har du jo kun de gamle kryptering algorithmer, som kan knækkes af en alm. standard hjemme PC på under 1 time. Det er begrænset hvor meget load de lægger på en CPU sammenlignet med de algorithmer som er standard idag, og som det tager år for en alm. standard hjemme PC at knække.

[Kandersen]

1 time siden, Lars1 skrev:

Med HW 6.1 har du jo kun de gamle kryptering algorithmer, som kan knækkes af en alm. standard hjemme PC på under 1 time. Det er begrænset hvor meget load de lægger på en CPU sammenlignet med de algorithmer som er standard idag, og som det tager år for en alm. standard hjemme PC at knække.

Du skal se det den anden vej rundt.
6.1 fik ikke firmware opdatering fordi den (i følge nogen) ikke er kraftig nok til ny kryptering.
6.1 kører, her hos mig, som en drøm, med flere 3.part løsninger som poller controlleren konstant. 

6.2 fik firmware opdatering, fordi den (i følge nogen) er kraftig nok til ny kryptering.
6.2 kører ikke med 3. part løsninger som poller controlleren konstant.

Min pointe - 6.2 er lige præcis så belastet med den nye firmware, og kører på pumperne. Uanset om det skyldes ny kryptering, vind og vejr.  Og derfor kan den ikke trække 3.part løsninger. 
Så spørgsmålet er, hvornår 6.2 heller ikke kan mere i den almindelige installation. (næste gang Apple ændre krypteringsalgoritme).

Hvis ovenstående antagelse er korrekt, så gjorde LK selvfølgelig ret i, at ikke lave en firmware opdatering til 6.1. Spørgsmålet er om opdateringen til 6.2 måske også skulle have været undgået. Men LK har nok følt sig presset til at gøre noget, da de ellers ville stå med rigtig store problemer, hvis hverken 6.1 eller 6.2 virkede med deres egne apps. 
Men resultatet er, at 6.2 nu kører på pumperne, så den måske ikke engang er i stand til at drive det som den reelt burde, (112 sensorer der gennemtæver controlleren med info konstant. Bare for at nævne et overdrevet men ikke umuligt eksempel). 
Jeg har ikke 112 sensorer. Ellers var det sådan noget jeg kunne finde på at afprøve, bare fordi man kan 

[Lars1]

Jeg forstår ikke din pointe, så jeg tror vi stopper den diskution her.

[Kandersen]

Er lidt ærgerlig du ikke forstår pointen og bare giver fortabt. Så jeg prøver lige en sidste gang, visuelt. Du kan bare vælge at ignorere det, hvis du fortsat ikke forstår det.

Det er vigtig at understrege.. Det er ikke selve tallene/indikeringen. Det er princippet jeg mener. Jeg har desværre ingen mulighed for at måle selve CPU belastningerne i controllerne. Men jeg tror nu at jeg har rimelig ret i princippet. 

Min pointe er så: 
Såfremt dette holder stik, så betyder det at HW 6.2 sandsynligvis er enormt presset (kører på pumperne) med den nye firmware. Og måske så slemt, så den måske slet ikke kan drive en større installation mere.. Eller en ekstrem installation fx med 112 sensorer. 
Du har ret i, at det er meget afgørende for, hvor stor en installation man har og ikke mindst hvor mange komponenter man har tilsluttet. Måske endda hvor meget trådløs/ikke trådløs der er i installationen. Men mit argument er, at hvis controlleren allerede er voldsomt presset i forvejen pga. firmware opdateringen til de nye krypteringsformer, så er det altså kun et spørgsmål om tid, førend man rammer loftet på den. 

[Lars1]

Jeg forstår stadig ikke din pointe.

Bortset fra enkelte detaljer er den eneste forskel på en HW 6.1, HW 6.2 og HW 7 controller mængden af RAM og CPU. Hvornår du ramme loftet i de enkelte controller afhænger mange faktore. Firmware er en af dem. Dit program er en anden. Typen af enheder du har tilkoblet samt dit brugs mønster er en trejde. Integration med trejde parts produkter er en fjerde. Du kan sikkert selv finde på flere. Hvornår du rammer loftet på en HW 6.2 afhænger af din kombination af bl.a. ovenstående faktorer. Jeg tror ikke der er nogen som kan forudsige hvornår man rammer loftet.

[Kandersen]

14 minutter siden, Lars1 skrev:

Hvornår du rammer loftet på en HW 6.2 afhænger af din kombination af bl.a. ovenstående faktorer. Jeg tror ikke der er nogen som kan forudsige hvornår man rammer loftet.

Enig. 
Men du er vel så enig med mig i, at den nye firmware til HW 6.2 der jo understøtter disse "nye" og såkaldt  "voldsomme" krypteringsformer - Den firmware vil i sig selv have rykket grænsen for, hvornår man rammer loftet? Ellers sagt på en mere visuel måde - Den nye firmware har fjernet noget mere af det luft som HW 6.2 controlleren havde at give af. Vi ved ikke hvor meget eller hvor stor betydning det her. Om det holder eller ej, det er helt op til den enkelte installation (og evt udvidelser). 
(Dette er i øvrig skrevet helt uden hensyntagen til 3.part som poller controlleren).

Årsagen til at det er ret vigtigt, det er for dem der fx planlægger udvidelser eller omlægninger i deres installation. Fx en installation der i dag er drevet med primært fortrådet komponenter, der udskiftes til trådløse. Hvis det trådløse interface i forvejen er en stor belastning for controlleren, så vil man alene ud fra det sandsynligvis ramme loftet længe før man ville med den gamle .220 firmware. 
Det er ren og skær gisninger, da jeg ikke har en mulighed for at testet det. Men i og med at netop krypteringen belaster så meget, jf forklaringen fra HW 6.1 controlleren, så er det i sig selv en nærliggende tanke. 

---
Konklusionen vil, i det tilfælde jeg har ret i mine antagelser, være: 
Controlleren kan ikke længere leve op til forventningerne, fordi den nye firmware, med de nye krypteringsformer, simpelthen belaster den for meget i sig selv. Fx controlleren kan ikke længere drive 112 sensorer og/eller 64 trådløse enheder, (eller andet som belaster den meget). 
Og man er enten nødsaget til at nedgradere firmwaren (så ryger IOS11 igen), eller købe den nye controller.

Den konklusion (resultatet) er pudsigt nok præcis den samme som er tilfældet med HW 6.1 - Men den controller tog LK  beslutningen for inden, sandsynligvis fordi den allerede havde ramt loftet alene pga den ny kryptering.

Det var min pointe med det her. 
Man behøver ikke være enig i det. Det er som sagt også usikkert, i og med jeg ikke kan måle belastningen, og umiddelbart har jeg ikke mulighed for at stress teste controlleren med de "rigtige" komponenter. Men simpel logik ud fra det som er kommet frem mht HW 6.1 controlleren der ikke kunne klare det. HW 6.2 controlleren der nu har store, nærmest endegyldige problemer med 3.part part. Så mener jeg det ligger lige til højrebenet at antage - HW 6.2 controlleren har ikke længere den samme CPU kraft til rådighed. Og derfor skal man heller ikke forvente, at man kan presse den tilsvarende, efter den nye firmware.