Wireless delen og WEB delen død

[Bjarne Sørensen]

Nå så kom de wireless problemer nok også til mig

Visual 2 HW 6.2 FW 2.8.4

Hvad jeg oplever:

• Min controller var underlig til morgen. Jeg tændte lyset i gangen (wireless Ø80 ver 2 dimmer) på tryk, da det ikke lige passer med tænd-tiderne om morgen på det virtuelle skumringsrelæ for tiden.
• Nå men lyset tændte i gangen.
• Da jeg ville tænde det i stuen (wireless Ø80 ver 2 dimmer) og køkkenet (relæudgang) reagerede tryk ikke, så jeg bandede over at controlleren var ved at genstarte.

Da vi skulle ud af døren var lyset tændt:

• I et værelse (wireless Ø80 ver 2 dimmer)
• I stuen (wireless Ø80 ver 2 dimmer)
• I gangen(wireless Ø80 ver 2 dimmer) og
• I badeværelset (wireless Ø80 ver 2 dimmer)

Hvad sker der:

• Intet kunne slukkes.
• Da vi slog alarmen til slukkede det heller ikke (via sluk-alt)
• Da jeg så ville slukke det via IHC-Remote, connecter den men står bare og snurrer oppe ved 4G (iPhone) og opdaterer ikke I/O.

• IHC-Captain vil heller ikke sende push-beskeder ved til-/frakobling af alarmen og heller ikke da vaskemaskinen var færdig.

Hvad nu?

• Jeg er kommet hjem til et hus med lyset tændt de nævnte steder.
• Wireless udtag kan stadig ikke tilgås.

Fejlfinding:

• Jeg kan heller ikke komme på Administrator eller serviceview, heller ikke fra USB. Men alt fortrådet virker.
• Jeg har taget netværksstikket ud og prøver via USB,. Controllerens forside kommer frem, jeg kan donwloade lava-filen til administartor osv, køre den men den får ikke fat i controlleren. Den skriver bare "Forbindelse til controlleren forsøges via USB, men den står bare og tænker og tænker.
• Controllerens grønne LED blinker hurtigt selvom jeg ikke har forbundet noget til den.
• Den blå wireless-LED på controlleren blinker når jeg aktiverer et wireless tryk, men controlleren afvikler ikke den tilhørende FB, (relæ til porten trækker ikke).
• Jeg kan heller ikke få IHC-Captain til at forbinde. 
• Firmwareloader kan forbinde og vise firmware version.
• Information om controlleren, serie nr, HW version, ur etc kan ses fra Visual.
• Ø80 dimmerne kan betjenes på knapperne 1&2.
• Det hjælper ikke at tage strømmen til dimmerne. 

Hjælp

• Jeg vil jo gerne fejlfinde på det, jeg er klar over hvis jeg genstarter controlleren virker alt igen, men så er det også umuligt at fejlsøge på det.
• Hvad vil i foreslå jeg gør for at undersøge det nærmere?
• Jeg har oplevet dette en enkelt gang i uge 5 da vi var på vej til Østrig og IHC-Tablet stoppede med at svare, der måtte jeg have min far forbi og genstarte controlleren (ikke så nemt igen når den kører på UPS). Der var huset ubeboet men jeg sad og rettede i noget layout med el-måler FB'er.

Redigeret April 2, 2019 af Bjarne Sørensen
Tilføjet lidt fakta. Redigeret overskriften til en mere sigende.

[Kandersen]

Lige nu, Bjarne Sørensen skrev:

Han roste faktisk 6.2'eren for at være kraftig nok, han kom ind på 3'eren ja, men han anbefalede ikke et skifte direkte.

Hold da op.. Det er nye toner.

[Henning Pedersen]

Hvis dine funktionsblokke bruger den "gamle" metode til slukning, dvs. "Reg ned" efterfulgt af "Stop reg" så ville jeg skifte til blokke som fremkalder "Sluk senarie" når lyset skal slukkes.

 

[Kandersen]

1 minut siden, Bjarne Sørensen skrev:

144 kb pr stk og jeg har 17 stk lige nu (ny og gammel version).

2.5Mb. Der er jo langt ned til det som han anbefalede så. Måske han skal have en ny kugleramme 

[Kandersen]

1 minut siden, Henning Pedersen skrev:

Hvis dine funktionsblokke bruger den "gamle" metode til slukning, dvs. "Reg ned" efterfulgt af "Stop reg" så ville jeg skifte til blokke som fremkalder "Sluk senarie" når lyset skal slukkes.

 

hvilke blok er det?

[Henning Pedersen]

Lige nu, Kandersen skrev:

hvilke blok er det?

Ingen anelse - livet er for kort til LKs blokke. Bruger 100% kun mine egne.

[Bjarne Sørensen]

5 minutter siden, Henning Pedersen skrev:

Hvis dine funktionsblokke bruger den "gamle" metode til slukning, dvs. "Reg ned" efterfulgt af "Stop reg" så ville jeg skifte til blokke som fremkalder "Sluk senarie" når lyset skal slukkes.

 

Jeg kører scenarie på en FB du har lavet. I det ene rum som triggede fejlen sidst.

[Bjarne Sørensen]

7 minutter siden, Henning Pedersen skrev:

Hvis dine funktionsblokke bruger den "gamle" metode til slukning, dvs. "Reg ned" efterfulgt af "Stop reg" så ville jeg skifte til blokke som fremkalder "Sluk senarie" når lyset skal slukkes.

 

PÅ det udv. lys som triggede fejlen denne gang ser det sådan ud:

 

[Henning Pedersen]

De kører begge på den gamle måde, send mig lige en kopi af min blok, så ændre jeg det.

[Kandersen]

Jeg bruger 1.2.03.d på alle mine wireless dimmere. 

[Lars Jacobsen]

Hvis jeg kikker på hvilke FB der "fylder" og trækker tænder ud så er det "standardhus" og alle de nye varmestyrings FB.

Den smule kode vi putter i hjemmelavede FB er ingenting sammenlignet med do. Og ej heller tællerproblematikken.

Mente også mit projekt var omkring de 7 Mb men har lige kontrolleret og jeg er "kun" på 4,7 Mb. + 1 Mb til Sceneview. Men det er så i den gamle HW 6.1 som efter sigende skulle have mindre RAM.

 

[Kandersen]

Mit program er på 3.8Mb. På en 6.2 controller. Jeg bruger varmestyring fra Visual, men kun almindelig blokke, ikke boligkoncept.

[Bjarne Sørensen]

2 timer siden, Lars Jacobsen skrev:

Hvis jeg kikker på hvilke FB der "fylder" og trækker tænder ud så er det "standardhus" og alle de nye varmestyrings FB.

Den smule kode vi putter i hjemmelavede FB er ingenting sammenlignet med do. Og ej heller tællerproblematikken.

Helt klart en pointe Lars.

Det er også noget underligt noget at give skylden for nedbrudene. Projektet har været sådan i flere år kun rettet lidt småting i.

Jeg indrømmer gerne at min projektfil er rodet og primitivt opbygget med flere blokke istedet for specielle lavet til formålet, det virker i dagligdagen, men det er fordi meget har jeg lavet for ti år siden og ikke rørt ved, jo måske flækket lidt ekstra ting på.

Jeg burde renovere hele skidtet, så vil det heller ikke fylde helt så meget, men det kan ikke blive halv størrelse. 

[Bjarne Sørensen]

4 timer siden, Henning Pedersen skrev:

De kører begge på den gamle måde, send mig lige en kopi af min blok, så ændre jeg det.

Tak Henning.

Dimmer og pir ver2 (Henning).ifb

[Bjarne Sørensen]

4 timer siden, Henning Pedersen skrev:

De kører begge på den gamle måde, send mig lige en kopi af min blok, så ændre jeg det.

I resten af huset kører jeg med 1.2.04.a og med 1.2.03.d, måske du vil lave en der kan bruges til disse, helst i en og samme blok da det er med og uden nat, og med mulighed for at sætte en tid hvor udgangen selv slukker igen.

[Henning Pedersen]

Opdateret version.

Med hjælp fra blokken fra dig fandt jeg den oprindelige blok

5 minutter siden, Bjarne Sørensen skrev:

I resten af huset kører jeg med 1.2.04.a og med 1.2.03.d, måske du vil lave en der kan bruges til disse, helst i en og samme blok da det er med og uden nat, og med mulighed for at sætte en tid hvor udgangen selv slukker igen.

Jeg har rettet 1.2.04.d fra V3, 1.2.03 har jeg ikke.

1.2.04 er ikke rettet 100% da den har funktion til at fremkalde sidste niveau, hvilket sker efter samme princip som sluk. Men hvis du ikke bruger det, så burde det ikke give problemer.

bjarne.vis

[Bjarne Sørensen]

28 minutter siden, Henning Pedersen skrev:

Opdateret version.

Med hjælp fra blokken fra dig fandt jeg den oprindelige blok

Jeg har rettet 1.2.04.d fra V3, 1.2.03 har jeg ikke.

1.2.04 er ikke rettet 100% da den har funktion til at fremkalde sidste niveau, hvilket sker efter samme princip som sluk. Men hvis du ikke bruger det, så burde det ikke give problemer.

bjarne.vis 121 KB · 0 downloads

Mange tak Henning.

De bliver implementeret i morgen 

[Lars1]

8 timer siden, Bjarne Sørensen skrev:

Jeg laver lige et nyt opslag til det en af dagene, så må du meget gerne hjælpe med en "How to guide", for jeg er lidt blank på at få oprettet den fil i IHC-Captain og få skrevet til den løbende.

Jeg køre fortsat på den gamle 0.996 version. I den er det faktisk ganske simpelt at sætte logging op.

1. Start IHC Captain.
2. Find den FB og parameter du ønsker at logge
3. Klik på +opret
4. Under regl fane bladet vælger du "forskellig fra", "den sidst aflæste værdi" og "gem til disk"
5. Under gem til disk fane bladet vælger du hvor du vil gemme dine data. Jeg mener default er "/var/www/html/captain/data/". Du kan godt gemme data fra flere parameter i den samme fil, men jeg vil forslå at du laver en fil for hver parameter. IHC Captain opretter selv filerne hvis de ikke allerede eksister.
   Derudover skal du vælge det format data skal gemmes i. Jeg bruger "[date],[time],[newval]"
6. Tryk på gem, og du er kørende.

 

[Lars1]

8 timer siden, Bjarne Sørensen skrev:

Jeg har lige talt med LK, og supporteren mener at fejlen skyldes at min projektfil er for stor da den er på 9,6Mb. Normalen er på 3-4Mb siger han..

Jeg har fuld varmestyring og nok 10 el-målerblokke der står og tæller op fra målere.Men når jeg oplever fejlen har huset været i dvale, de eneste målere der har talt lidt er stand by forbrug på min hoved-måler, 1000p/kwh, og gasmåleren der kun tæller 10 pulser/m3 så det er ikke meget.

Fejlen er hver gang opstået når en wireless dimmer er blevet tændt. Lyset tænder og controlleren genstarter og havner i den tilstand hvor wireless og web-adgangen blokeres.

Så jeg skal slette 2/3 af projektet så vil det virke igen efter en nulstil_factory og gen-link af de 11 dimmere, 1 stk wireless tryk og en WL remote.

LK's forklaring lyder noget søgt. For mig lyder det mest som at de ikke har nogen idee om hvad der sker.

At fejlen opstår når du du gør noget som skal ændre på wireless skyldes IMHO mere at wireless og netværks adgangen er de 2 dele af IHC firmwaren som har API'er, og dermed den største exponering til memory leaks og extern påvirkning. Hvis du brugte netværks adgangen ligeså ofte som du påvirker en wireless enhed, vil du sandsynligvis se et 50-50 split mellem hvad der trigger en genstart.

Hvis du har mulighed for at sætte netværks sniffing op, kunne det være interessant at se om der bliver send data til app'en hvis du ændre lys styrke på en wireless dimmer via et fortrået tryk. Hvis dette er tilfældet, tror jeg mere at det er netværks API'et end wireless som er skyld i dine genstarts.

[Bjarne Sørensen]

9 timer siden, Lars1 skrev:

Jeg køre fortsat på den gamle 0.996 version. I den er det faktisk ganske simpelt at sætte logging op.

1. Start IHC Captain.
2. Find den FB og parameter du ønsker at logge
3. Klik på +opret
4. Under regl fane bladet vælger du "forskellig fra", "den sidst aflæste værdi" og "gem til disk"
5. Under gem til disk fane bladet vælger du hvor du vil gemme dine data. Jeg mener default er "/var/www/html/captain/data/". Du kan godt gemme data fra flere parameter i den samme fil, men jeg vil forslå at du laver en fil for hver parameter. IHC Captain opretter selv filerne hvis de ikke allerede eksister.
   Derudover skal du vælge det format data skal gemmes i. Jeg bruger "[date],[time],[newval]"
6. Tryk på gem, og du er kørende.

 

Det ser jeg lige på tak.
Nu kører jeg lige uden IHC-Captain og IHC-Bridge (ikke sat op igen efter et nedbrud, men er tilsluttet) et par dage.
Så vil ge prøve din guide.

[Bjarne Sørensen]

9 timer siden, Lars1 skrev:

LK's forklaring lyder noget søgt. For mig lyder det mest som at de ikke har nogen idee om hvad der sker.

At fejlen opstår når du du gør noget som skal ændre på wireless skyldes IMHO mere at wireless og netværks adgangen er de 2 dele af IHC firmwaren som har API'er, og dermed den største exponering til memory leaks og extern påvirkning. Hvis du brugte netværks adgangen ligeså ofte som du påvirker en wireless enhed, vil du sandsynligvis se et 50-50 split mellem hvad der trigger en genstart.

Hvis du har mulighed for at sætte netværks sniffing op, kunne det være interessant at se om der bliver send data til app'en hvis du ændre lys styrke på en wireless dimmer via et fortrået tryk. Hvis dette er tilfældet, tror jeg mere at det er netværks API'et end wireless som er skyld i dine genstarts.

LK manden mente at controlleren havde meget travlt på webdelen (han fik ikke at vide at jeg kører IHC-Captain- spurgte ikke) og det kunne stresse den.
Måske man skulle se på om det er en hacker udefra der prøver et ddos angreb?  Og det er derfor den brækker sig.

[Lars1]

2 minutter siden, Bjarne Sørensen skrev:

LK manden mente at controlleren havde meget travlt på webdelen (han fik ikke at vide at jeg kører IHC-Captain- spurgte ikke) og det kunne stresse den.
Måske man skulle se på om det er en hacker udefra der prøver et ddos angreb?  Og det er derfor den brækker sig.

Med memory leaks hacker angrebet kan være sket flere timer tidligere, men først i det øjeblik at du åbner din app, ryger memory leaks over threshold og controlleren genstarter. Men det reelle problem er hvorfor den ikke kommer rigtigt op efter en genstart, og her tror jeg desværre ikke der er nogen vej uden om at du må igennem reset firmware etc. for at får ryddet ordentligt op i controlleren.

[Bjarne Sørensen]

6 minutter siden, Lars1 skrev:

Men det reelle problem er hvorfor den ikke kommer rigtigt op efter en genstart,

Enig, det er det der er det store problem, altså jeg gætter på at den genstarter for controlleren er helt utilgængelig lige der hvor jeg opdager et wireless kommunikation dør, men det er jo ikke til at bevise umiddelbart da jeg ikke kan kontrollere det i Administrator.

Men det er i den eneste situation at controlleren ikke kommer rigtigt op igen efter en genstart.

Og haha, jeg kom lige i tanke om at LK supporten i går spurgte til hvor tit den genstarter og jeg sagde hver 30. dag, det var meget tit sagde han 
Jeg synes ellers at den er klippestabil og genstarter meget sjældent, han var ikke enig 

Min controller genstarter ikke når jeg tilgår den via app'en.

Og forrige gang da mit wireless frøs prøvede jeg ikke at tilgå den via app'en med det samme, først en time senere. Så ja det må være wireless der slår controlleren ud af kurs eller noget andet på LAN-porten.

[Lars1]

12 minutter siden, Bjarne Sørensen skrev:

Enig, det er det der er det store problem, altså jeg gætter på at den genstarter for controlleren er helt utilgængelig lige der hvor jeg opdager et wireless kommunikation dør, men det er jo ikke til at bevise umiddelbart da jeg ikke kan kontrollere det i Administrator.

Men det er i den eneste situation at controlleren ikke kommer rigtigt op igen efter en genstart.

Og haha, jeg kom lige i tanke om at LK supporten i går spurgte til hvor tit den genstarter og jeg sagde hver 30. dag, det var meget tit sagde han 
Jeg synes ellers at den er klippestabil og genstarter meget sjældent, han var ikke enig 

Min controller genstarter ikke når jeg tilgår den via app'en.

Og forrige gang da mit wireless frøs prøvede jeg ikke at tilgå den via app'en med det samme, først en time senere. Så ja det må være wireless der slår controlleren ud af kurs eller noget andet på LAN-porten.

Du kunne lave en FB, hvor der kun er en power up event, og så sætte IHC Captain til at logge når denne event køre. Eneste ulempe er at power up eventen vil køre hvergang du uploader en ny version af dit program, men du vil stadigvæk for et bedre overblik over hvortidt din controller reelt genstarter.

[Mikkel Skovgaard]

1 time siden, Lars1 skrev:

Du kunne lave en FB, hvor der kun er en power up event, og så sætte IHC Captain til at logge når denne event køre. Eneste ulempe er at power up eventen vil køre hvergang du uploader en ny version af dit program, men du vil stadigvæk for et bedre overblik over hvortidt din controller reelt genstarter.

IHC Captain opdager faktisk hvis IHC Controller ikke svarer/skifter status - overvejer at lave en event på det

[Bjarne Sørensen]

18 minutter siden, Mikkel Skovgaard skrev:

IHC Captain opdager faktisk hvis IHC Controller ikke svarer/skifter status - overvejer at lave en event på det

Det kunne være fint. Og så kunne man koble et relæ på et af Pi'ens GPIO og genstarte controlleren på den måde, som en ekstern watchdog