Kandersen

Sluk og tænd for controlleren.

Jeg har oplevet mange af de symptomer du nævner. Det er ikke tit det sker, heldigvis. 
De første gange slukke/tændte jeg for controlleren, plus tog strømmen fra dæmperne et kort øjeblik. Det løste det som regel. 
Sidste gang måtte jeg først igennem den første procedure. Men det hjalp ikke. Derefter uploadede jeg et tomt program til controlleren, og derefter det originale. Det hjalp.

Sidenhen har jeg ændret retning på antennen, så den i stedet for at pege opad nu peger horisontalt. Jeg har ikke haft nogle problemer siden. Og det er vel ved at være ½ års tid siden sidst.  

Jeg ved ikke om det har betydning. Men jeg kan tælle mig frem til, at du har 22 stk wireless enheder. Jeg har 13 stk wirless dæmpere. Alle dæmpere sidder inden for 1m fra antennen (ved IHC tavlerne). 

Har du sat controlleren (i PaperUI) til at opdatere automatisk? Så bør den nemlig hente Visual filen, hver gang du starter IHC bindingen. 
Du skal kigge efter: 
loadProjectFile=true createChannelsAutomatically=true Hvis du bruger en .things fil, så ser min fx således ud:
 
ihc:controller:elko [ hostname="IP:port", username="username", password="password", timeout=10000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: Jeg bruger godt nok ikke createChannelsAutomatically=true, da jeg laver dem manuelt. Men det er den der gør, at den opdatere din liste over channels i PaperUI, såfremt loadProjectFile=true.
Hvis loadProjectFile=false så henter den aldrig opdateringen af dit Visual program, hvis du fx laver ændringer i den. Og derved kan createChannelsAutomatically=true heller ikke lave de nye channels for dig.

Hej Morten. 
Det vil hjælpe en del hvis du fortæller hvilket anlæg det er (model). Det ligner ikke en CTS602 styring du har. 

Ja delvist. Vi kan udelukke Output 24 relæet der sidder ved siden af controlleren.
De to blå ledninger går ned på input modulet på klemmerne 17 og 18. I så fald så giver de ledninger ikke rigtig nogen mening i det område du har taget billedet i.
Det virker mere som om, at de har været tilsluttet "noget", og det er dette "noget" som er væk. Kigger man lidt nærmere på det første billede i dit første indlæg, så ser det ud som om der ligger et eller andet omme bag input modulet. Noget hvidt, som normalvis ikke bør være der. Det kan være det bare er et stykke papir eller noget andet der ingen betydning har. Det kunne måske også være det som de to blå ledninger har været monteret på. Det ligner også at ledningerne har været monteret i samlemuffer eller i anden form for skrueterminaler på den måde de er bukket og trykket i det afisoleret område. Det kunne godt hænge sammen med, at de har været brugt til "noget", som er forsvundet/afmonteret.
Dvs jeg ville i første omgang ignorerer de ledninger. De har måske slet ikke noget med dit problem at gøre. Men kunne være det som jeg vil kalde dårlig efterladenskaber/manglende oprydning.  

Så er der en anden mulighed.
Det er at tage dit Visual program og se på de tryk du siger der ikke virker mere, og se hvor de sidder monteret. Det vil fremgår af Visual. Men det kræver du ved hvad du skal se efter og kan tage et screendump af Visual. På den måde fejlretter man baglæns i installationen. Måske ender du så ud med at finde ud af, hvad de to blå ledninger skulle have været brugt til. 
Ulempen ved at bruge Visual sådan er, at du skal vide på hvilke datalinjer modulerne er monteret. Og dine moduler ser ikke ud som om de er opmærket på nogen måde (det er muligt opmærkningen sidder på låget til tavlen). Hvis ikke så er der kun een vej, og det er at følge datalinjerne fra controllerne (på det input du via Visual finder ud af dine tryk sidder på), og så følge ledningerne derfra og frem til det inputmodul. Så ved du ihvertfald hvor dine tryk er monteret. Derefter er det så at finde årsagen til, at input modulet ikke virker. 
Det er bare møg svært at guide dig på den her måde, hvis ikke du er bekendt med Visual. Visual kan klares via en remote access (fx via Teamview) til din computer. Men rent fysisk er du på egen hånd i tavlerne, medmindre du kan alliere dig med en i din nærhed som ved hvad man skal kigge efter.    

Hvis Visual er udelukket, så bliver det svært. Og så vil jeg klart anbefale dig at lade en med forstand på IHC kigge på det. 
Lige et spørgsmål. Du siger alle dine tryk som er tilsluttede dimmer ikke virker - Hvor mange tryk er det?

Der findes ikke en IHC wireless PIR. 
Så ja, PIR skal altid forbindes med kabel til et input. 
Alternativ er 3.part løsninger, som fx Zigbee eller Zwave. Men det kræver du får en gateway imellem IHC controlleren og Zigbee coordinatoren/Zwave gateway. Det er omstændigt, men det fungere til gengæld. Jeg bruger selv en løsning med openhab som gateway. 

Det virker fint.. Her er resultatet jeg får:
 
2019-10-21 19:28:04.760 [vent.ItemStateChangedEvent] - test_Ur changed from NULL to 2000-01-01T07:31:00.000+0100 2019-10-21 19:28:15.777 [vent.ItemStateChangedEvent] - test_Ur changed from 2000-01-01T07:31:00.000+0100 to 2000-01-01T08:31:00.000+0100 Jeg har indsat FBén og lagt resourceID in i min manuelle things til sådan her:
 
Type datetime :testur "Test ur" [ resourceId=17534733 ] I items har jeg defineret den således:
 
DateTime test_Ur "Test Ur [%1$tH:%1$tM:%1$tS] " <time> { channel="ihc:controller:elko:testur" } Og sådan her i sitemap:
 
Text item=test_Ur Og ser således ud i sitemap:

Jeg har ikke prøvet at skrive tilbage til controlleren. Men det burde være det samme. 
 
EDIT: Jeg har heller ikke prøvet i Habpanel. Men jeg formoder det virker fint derfra, når det virker i BasicUI (og ikke mindst at jeg får data i loggen).

Yep det er via rules i openhab. 
Nu siger du at dine velux-vinduer kører via en KLF200. Det gør min vinduer også. Men der er forskellige måder at styre dem på. MED KLF200 firmware 2.xx så kan du styre vinduerne i 1-100%. Ellers kan du bruge scener som er oprettet i KLF200. Velux bindingen til openhab skulle gerne have fundet både vinduer og scener. 

Derefter er det sådan set en forholdsvis smal sag at få noget til at gøre noget andet ved påvirkning. 
fx.. 
 
rule "simple princip regel" When     item sensor changed then     velux.sendCommand(ON)  end Denne simple regel (rule) gør sådan set det som den siger:

Når sensor  ændre sig, 
 så
Send kommando ON til velux. 
Sensor er så en item fra et eller andet
Velux er en item linket til et velux vindue eller en scene på din KLF200. 

Her er min gamle (en del mere omstændig/avanceret) rule til styring af mine velux vinduer, der bla tager forbehold for, om alarmen er slået til/fra, og om det er mørkt udenfor. Og så selvfølgelig temperaturen i form af en Netamo sensor. Det skal lige siges, at den er ændret lidt i dag. Men princippet er det samme. Den aktivere scener i KLF200.
rule "Automatic control of all skylight windows" when Item NetamoUdendoersTemperature changed or Item Node13_SensorLuminance changed or Item alarm_totalalarm changed or Item dummy1 changed then // Exit the rule when there is nothing to do if(Override.state == ON) return; if(alarm_totalalarm.state instanceof Switch ) return; if(!(Node13_SensorLuminance.state instanceof Number)) return; if(!(NetamoUdendoersTemperature.state instanceof Number)) return; // Calculate which velux to send the ON command to val Number fTemp = NetamoUdendoersTemperature.state as Number val Number lux = Node13_SensorLuminance.state as Number val alarm = alarm_totalalarm.state var velux = VeluxAlleLuk // Third table if(alarm == ON) { logInfo("debug", "Third table clause") velux = if(fTemp >= 18|"°C") VeluxAlleVent else VeluxAlleLuk } // Second table, we already know alarm isn't ON so we don't have to test it for OFF here else if(lux < 10){ logInfo("debug", "Second table clause") velux = if(fTemp >= 18|"°C") VeluxAlleVent else VeluxAlleLuk } // First table, we know that alarm isn't ON and we know lux >= 20 so we don't have to test for it here else { logInfo("debug", "First table clause") switch fTemp { case fTemp >= 25|"°C": velux = VeluxAlleAaben100 case fTemp >= 24|"°C": velux = VeluxAlleAaben75 case fTemp >= 23|"°C": velux = VeluxAlleAaben50 case fTemp >= 18|"°C": velux = VeluxAlleVent default: velux = VeluxAlleLuk } logInfo("debug", "Choose " + velux.name) } // Send the command logInfo("skylight", "Sending ON command to " + velux.name + " because OutsideTemp = " + NetamoUdendoersTemperature.state + " Lux = " + Node13_SensorLuminance.state + " and Alarm = " + alarm_totalalarm.state) velux.sendCommand(ON) end
 

Se det fra den lyse side - Nu ved du hvordan man ikke skal gøre 
 
Det er hammerende irriterende, specielt at ingen kan svare på hvorfor. Der burde ikke være forskel, men Google laver det åbenbart ikke ens.
Det skal nok lykkes på et tidspunkt, når ham der laver Google integrationen kommer i gang igen. Så håber jeg at jeg i det mindste kan få at vide, hvorfor og hvor problemet ligger og evt løses.

Der findes en ganske klar og tydelig vejledning for, hvordan det hele kobles sammen.. Da jeg lavede det sidste år, der fulgte jeg vejledningen slavisk, og jeg har praktisk talt ikke oplevet en eneste fejl, ud over at et par gange når controlleren har været genstartet, eller jeg har haft loade et tomt projekt ind, så har kodetastaturet ikke virket i første efterfølgende forsøg. Anden gang og efterfølgende har det virket klippe stabilt. Men det er længe siden, så jeg vil tro at det er noget der skete på en ældre firmware til controlleren.

Vejledningen findes i beskrivelsen til FBén, samt i den fortrådningsoversigt/diagram der findes til alarm installationen, (som i øvrig følger med til kodetastaturet). Det var eneste dokumentation jeg brugte da jeg lavede det som meget "grøn" IHC "installatør". 

Principdiagram: http://www1.lk.dk/katalog/vejledning/98726_04.pdf  
Beskrivelsen for FBérne skal du finde i Visual. Klik på FBét, og tryk F1 tasten.

Det skriver min 6.1 controller også. Men det har ingen betydning for fx IHC Captain, OpenHab2 osv. Jeg ved faktisk ikke hvad LK mener med 3.part produkter der hvor de skriver det.