ø80 Uni dimmer ustabil eller controller?

[Kandersen]

Havde en meget mystisk oplevelse her forleden med et (ud af 4 stk) ø80 lampeudtag. 
Det er tilsluttet i et værelse til 2 stk 35wat halogen spot. Bruger den almindelige standard dimmer Fb, hvor jeg styre scenarie via touch (touch på scenarie, niveau 35%). Ligesom de 3 andre. 

Udtaget har siden jeg opsatte det opført sig lidt underligt. Lyset kan være 2-3 sekunder om at tænde (på 35%), når man trykker på knappen. Det slukker dog altid med det samme. 
Styring af dæmp har ikke været noget problem, hverken op eller ned. Løsningen på de 2-3 sekunder har jeg ikke kunnet løse.

Men forleden, da jeg kom ind i værelset og ville tænde lyset, der ville det slet ikke tænde. Jeg trykkede indtil flere gange både korte og lange tryk, intet skete førend jeg nok har trykket omkring 20 gange. Så pludselig tændte det. Fint nok.. Men jeg kunne efterfølgende ikke slukke det igen. Uanset hvor mange gange eller hvordan jeg trykkede. Ej heller dæmpe/skrue op. 
Startede PCén op og ind i serviceview. Tryk virkede fint som det skulle. Lampeudtag stod derimod til indikering OFF. Men lyset var tændt. Prøvede at styre det via serviceview. Men det ændrede heller ikke noget...
Gik på loftet og fjernede 230volt til lampeudtaget, monterede det igen. Serviceview viste OFF. Lyset var stadigvæk tændt. Trykkede på space på serviceview, indikering skiftede til ON. Lyset var stadigvæk tændt. Og jeg kunne stadigvæk ikke slukke for det. Trykkede på space igen i serviceview. Lampeudtaget skiftede IKKE til OFF. 

Gik ind i administrator og genstartede controlleren. Endte i samme resultat. Lyset var tændt, og jeg kunne ikke slukke det.

Valgte til sidst at slukke controlleren helt ved at tage 24volt fra den, og tænde den igen efter nogle sekunder. Først derefter kunne jeg igen tænde og slukke lampeudtaget helt som normalt.

Alt det her har kørt uden problemer i 78 dage, (bemærkede jeg i administrator da jeg alligevel var der). De øvrige 3 lampeudtag som er opsat samtidig har ikke voldt nogle problemer. 

I bagklogskabens enhed fik jeg slet ikke skænket den tanke, at det kunne være linket til lampeudtaget som det var galt med. Lampeudtaget er placeret ca. 50cm fra antennen ligesom de andre, og der var ikke umiddelbart nogle ændringer i noget trådløst forinden problemet opstod. Men det Irritere mig lidt at det her problem først løser sig, når controlleren helt har været slukket. Ikke engang fjernelse af 230volt til lampeudtaget ændrede noget. Det burde det jo ellers, hvis det er linket det er galt med.  

Nogen bud på hvad der har været galt? Og kan jeg forvente det vil ske igen måske?

[Bjarne Sørensen]

2 minutter siden, Kandersen skrev:

Havde en meget mystisk oplevelse her forleden med et (ud af 4 stk) ø80 lampeudtag. 
Det er tilsluttet i et værelse til 2 stk 35wat halogen spot. Bruger den almindelige standard dimmer Fb, hvor jeg styre scenarie via touch (touch på scenarie, niveau 35%). Ligesom de 3 andre. 

Udtaget har siden jeg opsatte det opført sig lidt underligt. Lyset kan være 2-3 sekunder om at tænde (på 35%), når man trykker på knappen. Det slukker dog altid med det samme. 
Styring af dæmp har ikke været noget problem, hverken op eller ned. Løsningen på de 2-3 sekunder har jeg ikke kunnet løse.

Men forleden, da jeg kom ind i værelset og ville tænde lyset, der ville det slet ikke tænde. Jeg trykkede indtil flere gange både korte og lange tryk, intet skete førend jeg nok har trykket omkring 20 gange. Så pludselig tændte det. Fint nok.. Men jeg kunne efterfølgende ikke slukke det igen. Uanset hvor mange gange eller hvordan jeg trykkede. Ej heller dæmpe/skrue op. 
Startede PCén op og ind i serviceview. Tryk virkede fint som det skulle. Lampeudtag stod derimod til indikering OFF. Men lyset var tændt. Prøvede at styre det via serviceview. Men det ændrede heller ikke noget...
Gik på loftet og fjernede 230volt til lampeudtaget, monterede det igen. Serviceview viste OFF. Lyset var stadigvæk tændt. Trykkede på space på serviceview, indikering skiftede til ON. Lyset var stadigvæk tændt. Og jeg kunne stadigvæk ikke slukke for det. Trykkede på space igen i serviceview. Lampeudtaget skiftede IKKE til OFF. 

Gik ind i administrator og genstartede controlleren. Endte i samme resultat. Lyset var tændt, og jeg kunne ikke slukke det.

Valgte til sidst at slukke controlleren helt ved at tage 24volt fra den, og tænde den igen efter nogle sekunder. Først derefter kunne jeg igen tænde og slukke lampeudtaget helt som normalt.

Alt det her har kørt uden problemer i 78 dage, (bemærkede jeg i administrator da jeg alligevel var der). De øvrige 3 lampeudtag som er opsat samtidig har ikke voldt nogle problemer. 

I bagklogskabens enhed fik jeg slet ikke skænket den tanke, at det kunne være linket til lampeudtaget som det var galt med. Lampeudtaget er placeret ca. 50cm fra antennen ligesom de andre, og der var ikke umiddelbart nogle ændringer i noget trådløst forinden problemet opstod. Men det Irritere mig lidt at det her problem først løser sig, når controlleren helt har været slukket. Ikke engang fjernelse af 230volt til lampeudtaget ændrede noget. Det burde det jo ellers, hvis det er linket det er galt med.  

Nogen bud på hvad der har været galt? Og kan jeg forvente det vil ske igen måske?

Er lamperne forsynet fra en 12 V elektronisk trafo? Måske driller den belastning dimmeren. 

Prøv at skifte mode på den. RL/CL / kombi. 

Du kan altid sætte en 230V alm pære på i stedet for under fejlfinding. 

[Kandersen]

14 minutter siden, Bjarne Sørensen skrev:

Er lamperne forsynet fra en 12 V elektronisk trafo? Måske driller den belastning dimmeren. 

Prøv at skifte mode på den. RL/CL / kombi. 

Du kan altid sætte en 230V alm pære på i stedet for under fejlfinding. 

Yep, det er en elektronisk halogen trafo. 
Jeg prøvede faktisk at skifte mode i service view, i et håb/forsøg om at lampeudtaget så ville "resette". Det ændrede heller ikke noget. Så den er tilbage til auto.

Hmm en 230volt alm pære i en GU 5.3 fatning.. Naah :-) (forstår godt hvad du mener, men lige i situationen havde jeg ikke vildt med tid til den store fejlsøgning på den måde). Da jeg gik på loftet tænkte jeg, det måtte være nok at fjerne 230volt til udtaget. Det var det så ikke. 
Det er derfor jeg er lidt i tvivl, om det her overhovedet har været et problem med udtaget, eller måske med controlleren. Det virkede jo først efter jeg havde haft taget strømmen til controlleren. Muligvis en kombination.

[Bjarne Sørensen]

3 minutter siden, Kandersen skrev:

Yep, det er en elektronisk halogen trafo. 
Jeg prøvede faktisk at skifte mode i service view, i et håb/forsøg om at lampeudtaget så ville "resette". Det ændrede heller ikke noget. Så den er tilbage til auto.

Hmm en 230volt alm pære i en GU 5.3 fatning.. Naah :-) (forstår godt hvad du mener, men lige i situationen havde jeg ikke vildt med tid til den store fejlsøgning på den måde). Da jeg gik på loftet tænkte jeg, det måtte være nok at fjerne 230volt til udtaget. Det var det så ikke. 
Det er derfor jeg er lidt i tvivl, om det her overhovedet har været et problem med udtaget, eller måske med controlleren. Det virkede jo først efter jeg havde haft taget strømmen til controlleren. Muligvis en kombination.

Det virker bare som de problemer jeg selv har haft med LED på hw 1.X

Der kan det hjælpe med DimBob, kondensator osv i nogle tilfælde. 

Skift trafoen til en god gammeldags jernkerne model hvis du har en. 

[Kandersen]

14 minutter siden, Bjarne Sørensen skrev:

Det virker bare som de problemer jeg selv har haft med LED på hw 1.X

Der kan det hjælpe med DimBob, kondensator osv i nogle tilfælde. 

Skift trafoen til en god gammeldags jernkerne model hvis du har en. 

Ahh jeg misforstod.. det ER en jernkerne trafo. 
Det burde ikke være nødvendig med en dimbob, når det er halogen kilder (sågar 35watt stk). Lampeudtaget er hw 2.05. Controlleren en hw6.2 med 2.8.4 firmwaren.

[Bjarne Sørensen]

11 minutter siden, Kandersen skrev:

Ahh jeg misforstod.. det ER en jernkerne trafo. 
Det burde ikke være nødvendig med en dimbob, når det er halogen kilder (sågar 35watt stk). Lampeudtaget er hw 2.05. Controlleren en hw6.2 med 2.8.4 firmwaren.

DimBob og kondensator er ikke for at få minimums belastningen op, det er for at få dimmeren til at holde sig i ro ved en drilsk belastning. 

Men nej de hjælper intet i det her tilfælde. 

Din belastning er så fin som den kan være, det er ikke der jeg ville fejlfinde. 

Hvad hvis du sætter dimmerens lydniveau direkte via slideren i app'en? Eller i serviceview og slukker dem igen der? Det virker til at det er dit programmering der driller, med mindre dimmeren er defekt. 

Har du en anden du kan bytte rundt med ville jeg gøre det som forsøg. Lad være med at Linke påny, bare flyt den i Visual. 

[Szafranski]

2 timer siden, Kandersen skrev:

Havde en meget mystisk oplevelse her forleden med et (ud af 4 stk) ø80 lampeudtag. 
Det er tilsluttet i et værelse til 2 stk 35wat halogen spot. Bruger den almindelige standard dimmer Fb, hvor jeg styre scenarie via touch (touch på scenarie, niveau 35%). Ligesom de 3 andre. 

Udtaget har siden jeg opsatte det opført sig lidt underligt. Lyset kan være 2-3 sekunder om at tænde (på 35%), når man trykker på knappen. Det slukker dog altid med det samme. 
Styring af dæmp har ikke været noget problem, hverken op eller ned. Løsningen på de 2-3 sekunder har jeg ikke kunnet løse.

Men forleden, da jeg kom ind i værelset og ville tænde lyset, der ville det slet ikke tænde. Jeg trykkede indtil flere gange både korte og lange tryk, intet skete førend jeg nok har trykket omkring 20 gange. Så pludselig tændte det. Fint nok.. Men jeg kunne efterfølgende ikke slukke det igen. Uanset hvor mange gange eller hvordan jeg trykkede. Ej heller dæmpe/skrue op. 
Startede PCén op og ind i serviceview. Tryk virkede fint som det skulle. Lampeudtag stod derimod til indikering OFF. Men lyset var tændt. Prøvede at styre det via serviceview. Men det ændrede heller ikke noget...
Gik på loftet og fjernede 230volt til lampeudtaget, monterede det igen. Serviceview viste OFF. Lyset var stadigvæk tændt. Trykkede på space på serviceview, indikering skiftede til ON. Lyset var stadigvæk tændt. Og jeg kunne stadigvæk ikke slukke for det. Trykkede på space igen i serviceview. Lampeudtaget skiftede IKKE til OFF. 

Gik ind i administrator og genstartede controlleren. Endte i samme resultat. Lyset var tændt, og jeg kunne ikke slukke det.

Valgte til sidst at slukke controlleren helt ved at tage 24volt fra den, og tænde den igen efter nogle sekunder. Først derefter kunne jeg igen tænde og slukke lampeudtaget helt som normalt.

Alt det her har kørt uden problemer i 78 dage, (bemærkede jeg i administrator da jeg alligevel var der). De øvrige 3 lampeudtag som er opsat samtidig har ikke voldt nogle problemer. 

I bagklogskabens enhed fik jeg slet ikke skænket den tanke, at det kunne være linket til lampeudtaget som det var galt med. Lampeudtaget er placeret ca. 50cm fra antennen ligesom de andre, og der var ikke umiddelbart nogle ændringer i noget trådløst forinden problemet opstod. Men det Irritere mig lidt at det her problem først løser sig, når controlleren helt har været slukket. Ikke engang fjernelse af 230volt til lampeudtaget ændrede noget. Det burde det jo ellers, hvis det er linket det er galt med.  

Nogen bud på hvad der har været galt? Og kan jeg forvente det vil ske igen måske?

Det lyder jo fuldstændig som det problem jeg har. . Efter mit sidste nødråb herinde, var Bjarne inde på om en gulvvarme evt. kunne have indflydelse. Jeg prøvede en masse forskelligt. Jeg linkede på ny, fandt ud af at den nærmeste rumtermostat manglede batteri, så det blev skiftet og undlod at sætte dæksel på Lu. Nu har det virket fint i et par dage. S-)

[Kandersen]

19 timer siden, Bjarne Sørensen skrev:

Hvad hvis du sætter dimmerens lydniveau direkte via slideren i app'en? Eller i serviceview og slukker dem igen der? Det virker til at det er dit programmering der driller, med mindre dimmeren er defekt. 

Problemet forsvandt efter jeg havde taget strømmen til controlleren. Så jeg kan ikke rigtig afprøve via appén. Via service view virkede intet. 

 

19 timer siden, Bjarne Sørensen skrev:

Har du en anden du kan bytte rundt med ville jeg gøre det som forsøg. Lad være med at Linke påny, bare flyt den i Visual. 

Yep, og det bliver nok også løsningen, lige så snart jeg har tid til at flytte dem rundt. Alene bare for at se, om det vil have nogen indvirkning på den langsomme tændning. Ikke at jeg tror det er sammenhængende med det problem jeg oplevede forleden. Men det kunne være sjovt om jeg kunne flytte den langsomme tænding. 

[Kandersen]

18 timer siden, K. "Szafranski" Nielsen skrev:

Det lyder jo fuldstændig som det problem jeg har. . Efter mit sidste nødråb herinde, var Bjarne inde på om en gulvvarme evt. kunne have indflydelse. Jeg prøvede en masse forskelligt. Jeg linkede på ny, fandt ud af at den nærmeste rumtermostat manglede batteri, så det blev skiftet og undlod at sætte dæksel på Lu. Nu har det virket fint i et par dage. S-)

Jeg har (heldigvis) ingen trådløs gulvvarme. Alt kører fortrådet, og i øvrig via IHC. Jeg tvivler også på at det er noget trådløst der genere, da problemet opstod nærmest fra det ene øjeblik til det andet, efter at have kørt i 78 dage. Men som sagt forsvandt det problem, da controlleren blev slukket og tændt på ny. Så lige nu venter jeg bare på det sker igen, om hmm... 70 dage :-)

[Bjarne Sørensen]

46 minutter siden, Kandersen skrev:

Problemet forsvandt efter jeg havde taget strømmen til controlleren. Så jeg kan ikke rigtig afprøve via appén. Via service view virkede intet. 

 

Yep, og det bliver nok også løsningen, lige så snart jeg har tid til at flytte dem rundt. Alene bare for at se, om det vil have nogen indvirkning på den langsomme tændning. Ikke at jeg tror det er sammenhængende med det problem jeg oplevede forleden. Men det kunne være sjovt om jeg kunne flytte den langsomme tænding. 

Jeps nemlig. 

Og så hvis problemet flytter med så slet link og opret igen. Så ser du om det er dimmeren fysisk der ikke virker ordentligt. 

[Kandersen]

Så gik det galt igen. Endnu engang et ø80 lampeudtag ver. 2 med dæmp, som vælger at leve sit eget liv. 
Denne gang er det lyset over spisebordet. Der er monteret 2 lamper med 8watt Osram dæmpbar LED kilder. (Dette handler IKKE om LED/Vs ikke LED, og dimbob og blablabla). 

Denne gang er det en virkelig mystisk oplevelse:

I forgårs (aften):
Jeg tændte lyset over spisebordet helt normalt på IHC trykket. Lod det stå tændt i et par timer. Da jeg ville slukke, kunne jeg ikke slukke det. Det reagerede ikke længere på IHC trykket.
(dette er samme symptom som jeg oplevede tidligere i vores soveværelse med 2x35watt halogen på jernkerne trafo og som står beskrevet længere oppe i denne tråd).

Ny form for fejlsøgning/afhjælpning:
Denne gang tog jeg min mobil, startede OpenHab appén. Ikonet og skyderen viste at lyset var tændt på 30%. Altså helt normalt. 
Jeg tog fat i skyderen (slideren i appén). Og herfra kunne jeg sagtens skrue op/ned for lyset, uden problemer. <Værd at bemærke dette> Og lyset reagerede på det. 
Jeg skruede helt ned for skyderen, hvilket betyder Openhab sender en OFF til IHC controlleren og lyset slukkede. Dette skete ganske som det skulle.

Klokken var mange, og jeg var på vej i seng, så jeg gjorde ikke mere ved det, andet end at jeg ville rode mere med det dagen efter, uden at have pillet yderligere i det.

I går aftes, (dagen efter):
Da jeg kom hjem fra arbejde prøvede jeg først at trykke på IHC trykket for at tænde lyset. Dette virkede stadigvæk ikke. 
Tog derefter fat i Openhab appén. Nu virkede den heller ikke. 
Startede derpå serviceview op for at se, om der overhovedet skete noget. 

Serviceview:
Jeg kontrollerede først, at serviceview kunne reagere IHC trykket. Det virkede helt som dette. 
Ved første tryk på IHC trykket, så skiftede dæmperen til 30% og lysindikering, (dette er normal scene). Fysisk Lys tændte ikke.
Ved fornyet tryk på IHC trykket, skete intet. Dæmperen burde slukke (gå på OFF (0%). Men dæmperen reagerede ikke i serviceview.
Holde IHC trykket inde, (skrue op/ned for dæmperen). Dæmperen reagerede ikke i serviceview

Ved påvirkning af skyderen i OpenHab app´en, der reagerede dæmperen i serviceview. Dvs jeg kunne se lysniveau ændre sig på dæmperen, sågar også til Off. Det fysiske lys reagerede stadigvæk ikke. 

Herfra gik jeg i tænke boks inden jeg gik videre med fejlsøgning.. 

Spørgsmål:
1. Hvorfor kunne jeg påvirke det fysiske lys fra OpenHab appén aftenen før, når IHC trykket ikke gav nogen påvirkning?
2. Hvorfor virkede Openhab appén ikke længere, dagen efter? 
3. Hvorfor kan jeg ikke se påvirkning af dæmperen i Serviceview, ved tryk på IHC trykket? 
4. Hvorfor kan jeg se påvirkning af dæmperen i Serviceview ved brug af OpenHab appén?
(5). Hvorfor reagere det fysiske lys ikke overhovedet.

Jeg havde ikke rigtig nogle gode svar til ovenstående, andet end, noget siger mig at der sker et eller andet i funktionsblokken mellem det fysisk IHC tryk og dæmperen. Som om forbindelse imellem helt forsvinder. Det er en væsentlig detajle.  
Måden jeg bruger OpenHab på, det er ved at påvirke dæmperen direkte i selve funktionsblokken. Dvs lysniveau, det er det som skyderen i Openhab styre.
At dæmperen reagere på dette, det fortælle mig at dele af funktionsblokken faktisk virker som den skal. Men det forklare så ikke, hvorfor det fysiske lys så ikke reagere. Så selvom dæmperen reagere, så er der altså stadigvæk noget et eller andet sted, som forhindre at det fysiske lys også reagere. 

Mit næste skridt var at gå på lofte og demontere lampeudtaget (det er fysisk placeret ved siden af IHC tavlen). 
Jeg fjernede 230volt til lampeudtaget og efter kort stykke tid monteret jeg det igen. Derefter startede jeg forfra med fejlsøgningen.
1. Jeg trykkede på IHC trykkket - Lyset tændte som som normalt.
Så troede jeg faktisk at problemet var løst, lige indtil...
2. Jeg trykkede igen på IHC trykket - Lyset reagerede ikke. 
Nu var jeg tilbage til det udgangspunkt som startede det hele aftenen før. 
3. Tog OpenHab appén. Den viste at lyset var tændt på 30%. Bevægede skyderen i appén - Kunne skrue op ned. Skruet helt ned til Off. Lyset slukkede.
4. Prøvede IHC trykket igen. Det virkede stadigvæk ikke. Men appén viste at lyset tændte på 30%. Fysisk lys tændte ikke.
5. Tog fat i appén og bevægede skyderen - intet skete, andet end det som skete tidligere. Kunne se dæmperen reagerede i serviceview, men fysisk lys reagerede ikke. 
Nu var jeg altså tilbage til det punkt lige inden jeg fjernede 230volt til lampeudtaget.

Herfra var der kun den sidste løsning tilbage, som også havde løst tidligere problem i med et ø80 lampeudtag i soveværelset. Fjerne spændingen til IHC controlleren.
Men inden jeg gjorde det, så ville jeg lige prøve noget som jeg tidligere havde tænkt på jeg ville have af/bekræftet.
Jeg startede IHC Administrator op. Her valgte jeg at genstarte controlleren.
Efter den havde genstartet, så forsøgte jeg igen med IHC trykket. Intet skete, problemet var stadigvæk eksisterende.
Med Openhab appén, så var det stadigvæk det samme. Dæmperen reagere i serviceview, men fysisk lys reagere ikke. 

Herefter gik jeg igen på loftet, fjernede spændingen til IHC controlleren i ca 30 sekunder. Monteret den igen, lod IHC controlleren starte op på ny. 

Resultat: 
Alting virker som det skal, inkl. IHC trykket. Lyset reagere som det skal. Problemet er simpelthen væk nu. Og jeg kan ikke fremprovokere fejlen 

Lidt har jeg dog fået ud af det.
1. Genstart af IHC controlleren fra Administrator, det løser ikke dette problem.
Jeg vil tro den genstart fra administrator er en slags "soft"-genstart, og efter min mening ikke en pind værd, som jeg netop fik bekræftet. Så anbefaling til andre fremover - Fjern spændingen til IHC controlleren.  

2. Når dette problem opstår, så må problemet ligge et sted i funktionsblokken, som virker delvist.
Forbindelsen mellem funktionsblok <-> dæmper lader til at virke, mens selve styringen i dæmperen (fysisk i dæmperen/produktet) må også være gået i baglås, når dæmperen kan reagere i serviceview, men fysisk lys ikke reagere. 
Forbindelsen mellem IHC tryk, funktionsblok<->dæmperen virker ikke.

3. Problemet KAN (også) være relateret til det trådløse signal.
Min fejlsøgning kan ikke afvise, at dele af problematikken kan ligge i kommunikationen mellem dæmper og controller. Det begrunder jeg med, at jeg kan styre dæmperen fra serviceview, (bare ikke med et IHC tryk). Og fordi jeg i servicview kan se, at dæmperen (produktet) ikke reagere på IHC trykket, men det reagere på Openhab appén, så må der være tale om flere problemer, som også er relateret til funktionsblokken. Og det har intet med det trådløse signal at gøre.  Men at det fysiske lys ikke reagere, når dæmper gør, det kan netop være relateret til det trådløse signal. Jeg tror dog personligt på, at problemet ligger et andet sted. For at kunne fejlsøge på dette, så kræver det at jeg kan monitorere det trådløse signal, når det sker. Det har jeg pt ikke udstyr til. Men igen, jeg tvivler på det er problemet. Det er nok mere den del med sending af signalet fra controlleren, som fejler. 

Nu venter jeg bare på det hele sker igen. Når det sker, så prøver jeg at gribe det an på en ny måde igen, evt ved at starte Visual op, fjerne/genindsætte funktionsblokken, uden at fjerne spændningen til controlleren. Og så se hvad der sker ved det.  Det er bare irriterende lang tid at gå og vente på det.

[Lars1]

Da du var i serviceview, checkede du så status på lys indikering?

Mit eneste bud på hvorfor du kan styre via openhab og ikke via den fysiske installation er hvis lys indikering af en eller anden grund er kommet ud af sync. Når du skruer op og ned via openhab, gør du det sikkert direkte på lampeudtaget, mens den fysiske installation går via FB'en.

[Kandersen]

3 timer siden, Lars1 skrev:

Da du var i serviceview, checkede du så status på lys indikering?

Yep, den var ON, når lampeudtaget var tændt (altså ikke det fysiske lys). Jeg aftaster lysindikering i Openhab på dette også, da det er min "sikkerhed" for at lyset tænder/slukker. 

Alt virkede som det skulle ved at påvirke lampeudtaget direkte, (bortset fra der ikke kom fysisk lys i LEDérne).
IHC trykket og dermed Fbén virkede ikke. Det fik ikke lampeudtaget til at reagere. Men lysindikeringen i Fbén var ON, når lampeudtaget ON (lysniveau). 
Det er derfor jeg mener, at Fbén virkede delvist, og produktet (selve lampeudtaget) virkede delvist. I realiteten burde jeg kunne styre lampeudtaget helt uden brug af en Fb forbundet. Men det fik ikke det fysiske lys til at tænde. Derfor mener jeg der er tale om to ting der går galt. 
1. Fbén er gået i baglås, eller forbindelsen mellem IHC trykket, Fbén og lampeudtaget.
2. Lampeudtaget er gået i baglås - Ellers burde det jo netop reagere vha OpenHab.    

3 timer siden, Lars1 skrev:

Mit eneste bud på hvorfor du kan styre via openhab og ikke via den fysiske installation er hvis lys indikering af en eller anden grund er kommet ud af sync. Når du skruer op og ned via openhab, gør du det sikkert direkte på lampeudtaget, mens den fysiske installation går via FB'en.

Korrekt, Openhab har fat i begge IDér på lampeudtage (venstreside i Visual). Men Lysindikering er den samme på højre side i Visual, altså samme ID, i Fbén. 
Men det forklarer ikke, hvorfor det fysiske lys ikke tænder. Det kan derfor ikke kun være Fbén.

Her er et billede af, hvor OpenHab har fat. Lysindikering i venstre og højre side har samme ID, så derfor har jeg markeret dem begge. 
 

[Lars1]

Hvis det går galt igen, må du være lidt mere grundig i dine test. Det kan være besværligt hvis man er alene, men jeg har tidligere fundet fejl i mit program ved at kigge på ind/udgange i FB's og produkter via serviceview samtidig med at en anden påvirkede tryk m.m. Det er den eneste måde jeg umiddelbart kender til hvor man kan finde ud af hvor kæden er knækket.

[Kandersen]

Well, Lars en gang imellem er den hjælpende hånd lige foran næsen på en. Serviceview har jo heldigvis en logværdi funktion. Og den brugte jeg, netop til at sikre mig, at det ikke var IHC trykket som drillede 
Men der er ingen tvivl om, at næste gang det sker, så skal fokus ligge på funktionsblokken. Jeg kan dog godt tvivle på, at jeg får noget egentligt resultat ud af det. Hvis funktionsblokken er "gået i stå", så er det sandsynligvis begrænset hvad man kan se, uanset hvor mange vi er om at trykke på knapper. 

Jeg er stadigvæk overbevist om, at når det her problem opstår, så er der flere ting som går galt i selve controlleren. Ellers burde lampeudtaget (fysisk lys tænde/slukke) jo have virket ved styring fra OpenHab, og/eller direkte fra Serviceview. Og det der sker i controlleren, det er ikke noget man bare lige kan se nogen steder. Her tror jeg mere en decideret debug log af controlleren kommandoer vil være et langt bedre værktøj. Jeg er dog ikke bekendt med, om man kan komme til sådan en, eller om den i det hele taget eksistere. Det er nok kun LK der ved det. 

[Lars1]

For at finde root cause, er første step at udelukke fejl kilder. Det gøres bedst ved systematisk at følge flowet i programmet. F.eks. når du påvirker et tryk, bliver dette så overført til indgangen på FB'en? Hvis påvirkningen bliver overført til FB'en, er det ikke trykket som er problemet, og du kan kigge på om der sker nogen ændring i FB'en? Hvis ikke må du ned i programmet og kigge om der er nogle flag som bloker for ændringer af lysstyrken. Når du styre lys niveauet via openhab, bliver det så reflekteret tilbage til FB'en?

Når du har fundet ud af præcis hvor i flowet at kæden hopper af, kan du fokuser din fejlsøgning om dette. Og tror mig. Langt de fleste fejl jeg har fundet i egne og andres IHC programmer skyldes et flag som ikke stod som forventet. En hard reset af controlleren nulstiller ofte disse flag. En soft reset via adminview, beholder ofte status.

Log funktionen er god, men du skal så logge alle ind og udgange på FB'en og tilsluttede produkter (både tryk og lampeudtag) samt alle interne variabler i FB'en. Gør man det kan loggen hurtig blive uoverskuelig.

[Kandersen]

For mig fokusere du på flere ting her. Og når jeg læser det, så virker det som om, at du dels fejlsøger, men du vil samtidig finde årsagen til fejlen.
Det kan man godt, hvis man har tiden og muligheden for det. Men hvis ikke man har det, så er man nødt til at behandle det i flere tempi. Ja, det involvere desværre, at man nogle gange må fjerne fejlen, uden at have fundet årsagen. Men sådan er det bare nødt til at være engang imellem.

Næste gang det sker, så er jeg nået længere i fejlsøgningen og kan gribe det an derfra. Jeg behøver ikke koncentrere mig om, at produktet (lampeudtaget) reagere fint ved direkte påvirkning fra Openhab (udefra), men kan fokusere på, at der intet sker indefra (Fbén og controllerens styring) ved påvirkning fra IHC trykket.  
Men jeg kommer ikke uden om, at forsøge finde ud af, hvorfor lampeudtaget, som reagerede fint ved påvirkning udefra, alligevel ikke kunne tænde/slukke det fysiske lys. Det er helt klart en detalje som jeg mener er ret væsentlig her. 

Som nævnt, så er jeg overbevist om, at der er mindst to problemer (to ting er gået galt) i det her. Om de hænger sammen, det er nok kun LK der kan svare på det. I min verden burde de ikke hænge sammen. Men meget kan være gået galt inde bag al styringen i controlleren. Og meget af det får jeg nok aldrig mulighed for at kunne finde frem til, da jeg vil tro det kræver en debug log fra controllerens interne styringer og handlinger. 

Men jeg tror enten jeg har formuleret mig dårligt, eller du har misforstået mig. Så jeg prøver lige kort igen. 

Faktum
Udgangspunkt (2. dagen, da jeg kom hjem fra arbejde) - Lampeudtaget (lyset) slukket OFF, der er ikke lys i lysindikering. Dette kunne jeg konstatere i Serviceview samt i Openhab appén:

1. Ved første påvirkning af IHC trykket - Lampeudtaget BLEV påvirket. Skyderen (slideren) bevæget sig op på 30% og Lysindikering gik ON. Dette blev konstateret i både ServiceView og Appén.
2. Ved næste påvirkning af IHC trykket - Lampeudtaget BLEV IKKE påvirket. Skyderen (slideren) forblev på 30% og Lysindikering forblev ON. Dette blev konstateret i både ServiceView og Appén.
3. Efterfølgende påvirkning fra IHC trykket ændrede ikke lampeudtaget på nogen måde.

Ved påvirkning af skyderen (slideren) i appén. 
4. Lampeudtaget BLEV påvirket hver gang, Lysindikering skiftede fra ON til OFF, alt afhængig af om slideren var i bund eller ej. 
5. Ved at "slukke" lampeudtaget via Appén eller Serviceview, så kom jeg tilbage til udgangspunktet, og pkt 1. kunne nu gentages. Dvs IHC trykket kunne nu påvirke lampeudtaget, men kun een gang og til tænd. Derefter var jeg i pkt 3. igen.  

Det er derfor jeg skrev (og mener), at Fbén virkede delvist. Ellers burde IHC trykket jo slet ikke kunne aktivere (tænde, pkt 1) lampeudtaget.
Og derfor jeg mener, at der er tale om mindst 2 fejl, fordi det fysiske lys ikke reagerede. 

I alle tilfælde reagerede det fysiske lys IKKE. 

Hvis nogen er i tvivl om, hvad jeg mener med appén så kommer her et billede, (godt ikke lige fra appén men fra Web interfacet BasicUi, som viser det samme som appén). 
Bemærk Spisebord. Det er denne skyder (slider) og pæren til højre for, som er koblet direkte sammen med lampeudtaget´s ID. Slideren styre niveau, og pæren Lysindikering. 

EDIT - Ahh I får også lige fra appén alligevel. Havde lidt problemer med screenshot på mobilen, så derfor jeg tog fra web interfacet.. Men nu lykkedes det. Så hermed tilføjet...
 

 

[Lars1]

Hvis du ikke går systematisk frem og checker hvert led i kæden et efter et, så vil du lede efter en nål i en stor høstak. Det er meget nemmer at finde nålen hvis du kan fjerne halvdelen af hø stakken.

Prøv at tænke på en juletræs kæde. Her sidder pærene i serie, og hvis en af dem springer holder hele kæden op med at lyse. Hvis du prøver at skifte dem en efter en, og gør dette ustruktureret tager det lang tid før du finder den som er sprunget. Hvis du der imod fjerner den miderster først, og måler om der er gennemgang fra midten og til stikket, kan du hurtigt udelukke halvdelen af lyskæden som en mulig fejl kilde. Herefter tager du igen den miderste pære i den halvdel som er fejl ramt. Sådan fortsætter du til du har lokaliseret den pære som er sprunget. Ved en lyskæde med 100 pære kan du finde den defekte pære med 7 tests eller mindre.

Ved fejlsøgning er det mindst ligeså vigtigt at dokumenter hvad virker, som at dokumenter hvad ikke virker. Problemet med din fejlsøgnings metode er at dine tests kan påvirke resultatet af den næste test, fordi et flag i FB'en kan ændre sig selvom lyset ikke ændre sig. Tænk bare på alle de cases der har været hvor nogen har undret sig over at de skulle trykke 2 gange på en afbr. for at lyset tænder eller slukker. Samtlige jeg kan huske skyldes at første tryk bringer FB'en i sync med lyset, hvorefter andet tryk udføre den handling man forventede første tryk ville udføre.

[Kandersen]

13 minutter siden, Lars1 skrev:

Ved fejlsøgning er det mindst ligeså vigtigt at dokumenter hvad virker, som at dokumenter hvad ikke virker.

Var netop det jeg gjorde.
Forskellen på IHC trykket, Funktionsblok og og app/serviceview påvirkning af lampeudtaget!
Der er ikke så mange andre muligheder her, selvom du virker som om du søger nogle helt specifikke, som jeg ikke lige kan få øje på. Du må meget gerne forklare mere detaljeret hvad du mener, fremfor blot at konstatere. 

13 minutter siden, Lars1 skrev:

Problemet med din fejlsøgnings metode er at dine tests kan påvirke resultatet af den næste test, fordi et flag i FB'en kan ændre sig selvom lyset ikke ændre sig.

Ikke enig.
Men du må lige korrigere mig hvis jeg tager fejl.
Er det ikke korrekt, at man kan styre et produkt (i det her tilfælde et wireless ø80 lampeudtag) direkte fra fx serviceview i venstre side? Altså helt uden brug af Funktionsblok?

Hvis det er tilfælde, så er min konklusion helt korrekt. Der ER tale om mindst to fejl.
1. Forbindelsen mellem IHC tryk <-> Funktionsblok <-> Lampeudtag (produkt <-> Fb <-> produkt). Denne virkede delvist. 
2. Direkte påvirkning af produktet, (lampeudtaget i venstre side), som virker, men fysisk lys reagere ikke.

Om den ene fejl så er skyld i den anden opstår eller omvendt, det ved jeg ikke, og det kan jeg ikke umiddelbart se, hvordan jeg skal kunne komme frem til det.

[Lars1]

1 time siden, Kandersen skrev:

Var netop det jeg gjorde.
Forskellen på IHC trykket, Funktionsblok og og app/serviceview påvirkning af lampeudtaget!
Der er ikke så mange andre muligheder her, selvom du virker som om du søger nogle helt specifikke, som jeg ikke lige kan få øje på. Du må meget gerne forklare mere detaljeret hvad du mener, fremfor blot at konstatere. 

Jeg har muligvis overset noget, men såvidt jeg kan se så må jeg sige nej. I det senario hvor en påvirkning af trykket, ikke får lyset til at ændre sig har du ikke været nede og kigge på detaljerne, som om trykket når til FB'etc. Du har genbrugt konklusionerne fra det senario, hvor en påvirkning af trykket får lyset til at ændre sig, men eftersom slut resultet her er forskelligt, kan du ikke bare assume at det som virkede før også virker her.

Som jeg plejre at sige til de IT arkitekter jeg har til at arbejde for mig på div. projekter. Assumptions are the mother of all f...ups.

1 time siden, Kandersen skrev:

Men du må lige korrigere mig hvis jeg tager fejl.

Er det ikke korrekt, at man kan styre et produkt (i det her tilfælde et wireless ø80 lampeudtag) direkte fra fx serviceview i venstre side? Altså helt uden brug af Funktionsblok?

Hvis det er tilfælde, så er min konklusion helt korrekt. Der ER tale om mindst to fejl.
1. Forbindelsen mellem IHC tryk <-> Funktionsblok <-> Lampeudtag (produkt <-> Fb <-> produkt). Denne virkede delvist. 
2. Direkte påvirkning af produktet, (lampeudtaget i venstre side), som virker, men fysisk lys reagere ikke.

Om den ene fejl så er skyld i den anden opstår eller omvendt, det ved jeg ikke, og det kan jeg ikke umiddelbart se, hvordan jeg skal kunne komme frem til det.

Der er ikke nødvendigvis tale om 2 fejl. Når du påvirker et lampeudtag direkte via serviceview, sker der en tilbagemelding til FB'en, og denne tilbagemelding kan ændre på hvordan FB'en reager når du næste gang påvirker trykket.

[Kandersen]

3 timer siden, Lars1 skrev:

Jeg har muligvis overset noget, men såvidt jeg kan se så må jeg sige nej.

Det mener jeg du gør.. Se det her igen:
 

6 timer siden, Kandersen skrev:

1. Ved første påvirkning af IHC trykket - Lampeudtaget BLEV påvirket. Skyderen (slideren) bevæget sig op på 30% og Lysindikering gik ON. Dette blev konstateret i både ServiceView og Appén.
2. Ved næste påvirkning af IHC trykket - Lampeudtaget BLEV IKKE påvirket. Skyderen (slideren) forblev på 30% og Lysindikering forblev ON. Dette blev konstateret i både ServiceView og Appén.
3. Efterfølgende påvirkning fra IHC trykket ændrede ikke lampeudtaget på nogen måde.

 

6 timer siden, Kandersen skrev:

I alle tilfælde reagerede det fysiske lys IKKE. 

Det fortælle mig, at når lampeudtaget er i slukket tilstand, så kommer IHC trykket igennem Fbén og aktivere det. Men IHC trykket kommet IKKE igennem anden gang, for at deaktivere det. 
Bemærk, lysindikering er ON. Dvs Fbén burde derfor vide, at lampeudtaget er tændt, hvilket jeg forstår er sikkerheden for at det er i sync. 
 

3 timer siden, Lars1 skrev:

Der er ikke nødvendigvis tale om 2 fejl. Når du påvirker et lampeudtag direkte via serviceview, sker der en tilbagemelding til FB'en, og denne tilbagemelding kan ændre på hvordan FB'en reager når du næste gang påvirker trykket.

Jeg har et ekstra ø80 lampeudtag (dimmer) liggende. Og nu bliver jeg sgu lidt stædig  Jeg har i sinde at afprøve det, for jeg er næsten 110% overbevist om, at jeg via Openhab kan styre lampeudtaget, uden at der overhovedet er en Fb indblandet på noget tidspunkt. Faktisk har jeg tænkt en del over det siden jeg skrev det tidligere. Jeg vil tro jeg reelt set kan strippe alt i højre side i Visual og lade Openhab påvirke samtlige produkter i venstre side, for på den måde at styre det hele via OpenHab.. Højre side er jo reelt kun beregnet til at styre logikken og dets hændelser i IHC controlleren. Men produkterne som skaber hændelserne, dem er jeg sikker på man kan styre netop ved hjælp af noget udefra, fordi hver enkelt produkt og dets funktion har en unik ID. 

Hvis min antagelse er korrekt. Så burde lampeudtaget have fungere forleden aften, (og det fysiske lys burde have reageret), uanset hvordan Fbén end opfører sig, da jeg via OpenHab påvirkede slideren (dimmer niveauet). Det var jo netop det jeg så skete i serviceview. Men det fysiske lys forblev som sagt slukket. Derfor antager jeg, at det er en selvstændig fejl i sig selv.
Årsagen KAN muligvis være opstået via en Fb. Men jeg tvivler, hvis jeg skal være helt ærlig. Jeg tror mere det er noget logik styring i/omkring selve produktet (lampeudtaget) i controlleren, som er stoppet. Alle andre produkter virkede jo fint. Så det var ikke noget der havde generel forbindelse til fx den trådløse del. 
At IHC trykket ikke kunne deaktivere lampeudtaget, det er så den anden fejl. Og her kan det snildt være Fbén som er gået i baglås. Men det kan også være noget af logikken i IHC controlleren som også på denne del er gået i baglås. Jeg er ikke sikker på, at jeg vil kunne se det på Fbén, næsten gang det sker. Faktisk så den jo helt normal ud. Derfor tror jeg det er en lidt dead end.. Men det er helt klart noget jeg vil kigge nærmere på, næste gange det sker. Evt ved at prøve at udskifte Fbén som det eneste, hvis ikke der umiddelbart er noget at se. 

[Lars1]

11 minutter siden, Kandersen skrev:

Det fortælle mig, at når lampeudtaget er i slukket tilstand, så kommer IHC trykket igennem Fbén og aktivere det. Men IHC trykket kommet IKKE igennem anden gang, for at deaktivere det. 

Bemærk, lysindikering er ON. Dvs Fbén burde derfor vide, at lampeudtaget er tændt, hvilket jeg forstår er sikkerheden for at det er i sync.

Jeg må indrømme at jeg kan ikke følge dine tests. Når du skriver at lampeudtaget bliver påvirket, er det så at lyset ændret sig, eller at du i service view kan se at lys styrken ændre sig i lampeudtags produktet?

13 minutter siden, Kandersen skrev:

Jeg har et ekstra ø80 lampeudtag (dimmer) liggende. Og nu bliver jeg sgu lidt stædig  Jeg har i sinde at afprøve det, for jeg er næsten 110% overbevist om, at jeg via Openhab kan styre lampeudtaget, uden at der overhovedet er en Fb indblandet på noget tidspunkt. Faktisk har jeg tænkt en del over det siden jeg skrev det tidligere. Jeg vil tro jeg reelt set kan strippe alt i højre side i Visual og lade Openhab påvirke samtlige produkter i venstre side, for på den måde at styre det hele via OpenHab.. Højre side er jo reelt kun beregnet til at styre logikken og dets hændelser i IHC controlleren. Men produkterne som skaber hændelserne, dem er jeg sikker på man kan styre netop ved hjælp af noget udefra, fordi hver enkelt produkt og dets funktion har en unik ID.

Nu bruger jeg ikke openhab, så jeg ved ikke hvordan den styre lampeudtag m.m. Men det ændre ikke ved at du via serviceview kan styre lampeudtaget manuelt og direkte uden brug af FB'en, men når du gør dette sker der en tilbage melding til FB. Hvis du f.eks. går fra 50% til 0%, så går lys indikering off. Om lysniveauet også bliver sendt tilbage til FB'en er jeg i tvivl om. Jeg bruger fortsat de gamle touch FB'er.

[Kandersen]

Lige nu, Lars1 skrev:

Jeg må indrømme at jeg kan ikke følge dine tests. Når du skriver at lampeudtaget bliver påvirket, er det så at lyset ændret sig, eller at du i service view kan se at lys styrken ændre sig i lampeudtags produktet?

Det er faktisk lige præcis det jeg skriver. 
Lampeudtaget bliver påvirket. Dimmer Niveauet ændre sig i serviceview, Lydindikering går ON.
De fysiske LEDére (lyset) tænder IKKE. <--- Dette ændre sig ikke på noget tidspunkt under forløbet. LYSET TÆNDER IKKE. 

Det er derfor jeg siger, at der må være tale om mindst 2 fejl. 

[Kandersen]

4 minutter siden, Lars1 skrev:

Nu bruger jeg ikke openhab, så jeg ved ikke hvordan den styre lampeudtag m.m. Men det ændre ikke ved at du via serviceview kan styre lampeudtaget manuelt og direkte uden brug af FB'en, men når du gør dette sker der en tilbage melding til FB. Hvis du f.eks. går fra 50% til 0%, så går lys indikering off. Om lysniveauet også bliver sendt tilbage til FB'en er jeg i tvivl om. Jeg bruger fortsat de gamle touch FB'er.

Hov, glemte at svar på denne..

Openhab operere direkte på de fysiske IDér som produkterne og dets funktioner har. 
Prøv at start Visual op, load dit program ind. Hold CTRL tasten inden, mens du holder musen over en eller anden funktion på et produkt (produkt siden). Så vil du se funktionens fysiske ID. 
Du kan gøre det samme i Fbérne hvis du vil det.. 

Hmm, nok nemmere at vise som screenshot.. Skal se om jeg kan hitte ud af det mens der er infomation på vinduet..

[Lars1]

4 minutter siden, Kandersen skrev:

Det er faktisk lige præcis det jeg skriver. 
Lampeudtaget bliver påvirket. Dimmer Niveauet ændre sig i serviceview, Lydindikering går ON.
De fysiske LEDére (lyset) tænder IKKE. <--- Dette ændre sig ikke på noget tidspunkt under forløbet. LYSET TÆNDER IKKE. 

Det er derfor jeg siger, at der må være tale om mindst 2 fejl. 

Blinker den blå diode på controlleren når du ændre på lysstyrken?

2 minutter siden, Kandersen skrev:

Hov, glemte at svar på denne..

Openhab operere direkte på de fysiske IDér som produkterne og dets funktioner har. 
Prøv at start Visual op, load dit program ind. Hold CTRL tasten inden, mens du holder musen over en eller anden funktion på et produkt (produkt siden). Så vil du se funktionens fysiske ID. 
Du kan gøre det samme i Fbérne hvis du vil det.. 

Hmm, nok nemmere at vise som screenshot.. Skal se om jeg kan hitte ud af det mens der er infomation på vinduet..

Jeg ved godt hvordan man finder ID'erne, men det fortælle mig fortsat ikke hvordan openhab styre lyset.

[Kandersen]

1 minut siden, Lars1 skrev:

Blinker den blå diode på controlleren når du ændre på lysstyrken?

Tjekkede jeg ikke. Det ER en mulig fejl jeg skal kigge nærmere på næste gang. 

 

2 minutter siden, Lars1 skrev:

Jeg ved godt hvordan man finder ID'erne, men det fortælle mig fortsat ikke hvordan openhab styre lyset.

Ganske simpelt - Openhab sender værdi fra 0 til 100 direkte ind på IDén på fx niveauet. 
På lysindikering´s ID modtager OpenHab ON eller OFF. OpenHab kan reelt set også sende ON/OFF den anden vej. Det vil bare ikke give noget mening at sætte lysindikering ON, hvis lampeudtaget er slukket. Så det gør man selvfølgelig ikke. 
Det var mere for at forklare, hvor simpelt det reelt er.