Kandersen

Det kræver jo han kan ændre setpunktet på radiatoren :-)

Det bliver ikke nødvendigt. Jeg suser igennem Solrød/Køge Bugt motorvejen hver dag til/fra arbejde. Jeg tænker lige et øjeblik...

Hvor i landet?

Så er det Appén (IHCtablet) Henning mener? (Har den selv, ligesom jeg har IHCremote til iPhone. Men bruger ikke den til ipad, synes den er lidt tung at danse med).

Men er det scenedesign på tablet eller? Personligt ser jeg kun et behov for en monitor. Jeg tror ikke på en tablet/mobil som man render rundt og trykker på. Dertil er stemmestyring alt for oplagt. Til gengæld en status over husets tilstand, det ville være helt perfekt.

Jeg er lidt tabt her.. Hvad er det der er bedre på en ipad fremfor at bruge scenedesign?

Hvordan kan han få en bedre oplevelse, ved at droppe noget? (Hint - mangler der ikke en forklaring til, hvad han istedet kan gøre, når han har en iPad og er på hjemmenetværk?)

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.

Okay så er jeg med.

Står det ikke på låget til anlægget hvad det er for en model?

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.

Men når den går off, så kan man vel ikke tilkoble alarmen? (og sirenen starter som det der skete i første indlæg)

Jeg har ikke nået at rode så meget med det efterfølgende, og sabotagekredsen har stadigvæk ikke være off siden jeg fjernede strømmen til controlleren. Men jeg har tænkt lidt mere over det. Vi er enige om, at det er denne indgang, ikk? Hvis indgangen er default ON, og på en lukkede kreds. Hvad er det så der får den til at gå OFF ?

Jeg kan desværre ikke hjælpe med homekit, da jeg ikke bruger det. Men jeg undre mig lidt over din items LysAllrum, og channel settings for denne. Kan du forklare den nærmere. Det ser ud som om, at du bruger forskellige tryk til samme item? Din items (dit tryk) opfører sig i øvrig helt korrekt, hvis du har sat dit tryk op som: PulseWidth i openhab. Så vil den gå ON, når du trykker på trykket, og få ms. efter, så vil den gå OFF. Hvorfor har du behov for at vide status på trykket i Homekit? Trykket vil jo pr. definition altid være OFF, medmindre du trykker på det (manuelt) ?

Hej Klaus. Hvad er forskellen på disse sensorer, og så dem du solgte for et par år siden?

Ok, så har jeg da helt misforstået det..Tak for det.

Ja hun var bestemt heller ikke helt tilfreds med det Kablet, der som det eneste indeholder sabotagekreds, det går fra kodetastaturet og til klemmerække i tavlen, og fra klemmerække til input modulet. Disse samlinger har jeg været igennem, og der er ingen tegn på løs forbindelse. (Skruer er spændt, og jeg har hevet i ledningerne). Det eneste sted jeg ikke har kigget efter, det er der hvor ledningerne går ind i kodetastaturet (altså bag på tastaturet). Så vidt jeg husker, så er det samlet i fast forbindelse. Teoretisk kunne det godt være der, eller en decideret fejl i kodetastaturet. Men.. Der har ingen problemer været med sabotagekredsen siden jeg fjernede strømmen fra controlleren. Så jeg hælder mest til, at problemet er opstået et andet sted. Mja. Og så alligevel ikke. Openhab har ikke write-adgang til sabotagekredsen. Dvs openhab kan fysisk ikke ændre status på den indgang. Det er et fast princip jeg har med openhab, når det gælder alarmen eller andre vitale funktioner. Så vidt det er muligt, så lægges alle vitale funktioner over på det "normale". Dvs jeg kan fx ikke slå alarmen fra via openhab. Men jeg kan godt tilkoble alarmen, da det ikke er "farligt" for uvedkommende. (tværtimod :-) ). IHC Captain er anderledes, for der skelnes ikke imellem read/write adgang. Så ja, det kunne sådan set godt være sket den vej igennem. Hmm.. Nok bare mig der har læst vejledningen indforstået. Men jeg synes bestemt jeg læste, at hvis ikke sabotagekredsen er ON, så kan man fx ikke tilkoble alarmen. Så hvis jeg fjerner sabotagekredsen, så skal jeg vel ind i blokken og tvinge indgangen til ON, ikk?

Det er egentlig ikke så meget et spørgsmål, udover, om der er andre der nogensinde har oplevet noget lign... Kort historie lang: I går eftermiddags forlod vi huset, og som normalt tilkoblede jeg alarmen via kodetastaturet. Et par timer senere kommer min datter hjem, og hun taster koden ind for at slå alarmen fra. 1-2 sekund efter, så starter alarmen. Jf loggen, så skriver den sabotagekredsen har aktiveret alarmen. Dette er helt normalt, hvis der er noget galt med sabotagekredsen. Det underlige er, at det sker stort set samtidig med, at hun slår alarmen fra. Hun ringer til mig, og jeg fortæller hende hun skal taste koden ind igen, (normalt burde det ikke virke, hvis det er sabotagekredsen som ikke er intakt). Mens jeg er i røret hører jeg hun taster koden ind igen, og alarmen stopper, og alt ser normalt ud. Altså, lige bortset fra at jeg selvfølgelig ikke fik tænkt mig om, for hun er jo reelt nødt til at taste koden ind to gange, da første gang (da alarmen var i gang), der vil den jo tilkoble alarmen. Det betød at kort tid efter, så starter alarmen selvfølgelig igen. Og så går hun ellers i panik, (forståligt nok), og vælger at gå uden for og vente på mig, fordi jeg er alligevel på vej hjem. Jeg skulle selvfølgelig have sagt, at hun skulle taste koden ind 2 gange. Først for at tilkoble alarmen, og anden gang for at koble den fra igen.. Anyway, jeg var næsten hjemme, så hun fik lidt efter frisk luft. Da jeg kommer hjem er alarmen selvfølgelig sat til, (kan jeg se på kodetastaturet). Og jeg slår den fra helt normalt, og alting virker som om, at der intet er sket. Jeg gennemgår derefter loggen i service view. Og der kan jeg se, at det er sabotagekredsen der to gange har startet alarmen. Det er som sådan ikke forkert, for hvis sabotagekredsen fejler, så skal alarmen lyde. Det underlige er, at sabotagekredsen ikke er afbrudt, og umiddelbart ser det heller ikke ud til den har været det. Min datter ville heller ikke have kunnet tilkoble alarmen igen, hvis sabotagekredsen havde været brudt. Det skal lige siges. Jeg bruger ikke sabotagekreds, udover den til kodetastaturet, som man ikke kan undgå. Så den er egentlig bare en lus på klemmerne, fordi kodetastaturet kræver det. For god ordens skyld gik jeg alligevel igang med at rode med kodetastaturet, for at se om jeg kunne fremprovokere en evt fejl. Det lykkedes ikke, selvom jeg synes jeg var hårdhændede nok. Nå, jeg lod alting være, for det lod umiddelbart til at alt var normalt igen. Ca. et par timer efter så lyder alarmen igen (denne gang var vi hjemme, og alarmen var derfor ikke tilkoblet). Igen kunne jeg se i loggen, at det var sabotagekredsen som skulle have aktiveret alarmen. Men den var stadigvæk intakt, (kunne jeg se i service view ganske få minutter efter). Klokken var på dette tidspunkt næsten 22:30, og jeg gad virkelig ikke rode med det. Så jeg startede Visual op, hentede programmet fra controlleren, fjernede linket til sirenen, (så vi i det mindste ikke skulle høre på den lige pludselig i løbet af natten). Oploadede programmet igen til controlleren igen.. uden fejl. Herfra gik det helt galt.. Da jeg havde oploadede programmet så forsøgte jeg starte service view igen, fordi jeg ville aktivere loggen på sabotagekredsen. Men nu kunne jeg ikke komme ind i service view. Den kom ikke med nogen fejl med stod bare og "kørte" som om at den forsøgte at få forbindelse.. Okay tænkte jeg, så tager jeg da bare administrator og genstarter controlleren. Men heller ikke administrator kunne forbinde til controlleren. (Stadigvæk ingen fejl). Okay, så tager vi sgu da bare IHC captain, der kan jeg genstarte controlleren fra.. IHC captain havde stadigvæk forbindelse til controlleren, (det havde openHAB2 også, men jeg fik ingen status melding retur), Så ind i kontrolpanelet i IHC captain og og tryk på genstart controlleren. Det viste sig at være en dårlig ide, for controlleren kom aldrig til live igen. Og nu havde hverken IHC Captain, OpenHAB2 eller Visual forbindelse mere. Så er der kun een vej tilbage. Op på loftet og sluk for strømmen til controlleren.. Hvad der i øvrig overraskede mig meget var, at alt lyset fungerede tilsyneladende helt normalt i huset, sågar pir styringer/timere.. Det burde jo ikke kunne lade sig gøre. Nå op på loftet, fjerne strømmen et par minutter og så slå strømmen til igen.. På dette tidspunkt var klokken vel ved at være 23:15.. Controlleren kom op og køre, og alt havde igen forbindelse til den, sågar administrator og service view. Så jeg gik fluks ind i Service view og aktiverede loggen til sabotagekredsen. Min mistanke var helt klart, at sabotagekredsen simpelthen ikke fejler noget, men det er controlleren som har fået kuk!. Status siden i går ved 23:30 tiden (23 timer siden). Der har absolut ingen fejl været på sabotagekredsen. Den står nærmest fastgroet på ON, helt som jeg forventede, til trods for, at jeg har rodet med alt, hevet i ledninger, tilkoblet og frakoblet alarmen et par gange.. Der er absolut ingen fejl at finde.. Så det må siges at være en oplevelse ud over de sædvanlige, og som jeg i øvrig ikke håber kommer igen. Nu har IHC installationen kørt med alarm funktion siden jeg lavede det for lidt over 3 år siden uden een eneste fejl-alarm. Så sgu fanden da stå i, at det lige pludselig begynder på den måde. Btw.. Er der nogen der ved OM man kan slå den forbandede sabotagekreds fra? Jeg ved godt der er nogen der vil mene det er en dum ide. Men nu er kabler lagt sådan, så en evt ubuden gæst vil blive fanget af alarm PIR (og inden længe dør/vindue sensorer), inden han overhovedet kunne nå ledninger/kabler. Så sabotagekredsen tjener efter min mening ikke rigtig noget formål, udover at generer mest muligt, når/hvis den ikke er intakt.

præcis!

Den der nerdis kan vistnok flashes med tasmota. Og så ka du via mqtt få den over i openhab eller lign og derigennem styre den fra IHC.

Dimbob er sindssyg dyr. Du kan købe en kondensator og sætte på, den skulle gerne løse problemet med blinkeriet. Jeg har dog ikke selv prøvet det. Søg efter Fibraro kondensator til Led. Findes også i andre mærker, men fælles er de koster ikke specielt meget.

Jeg bruger ikke rigtig appen til noget specielt.

I hvilken forbindelse bruger du det?

["Switchable"] er mit bud. Men jeg bruger ikke homekit, men derimod Google Assistant. Og jeg mener det er samme tag til begge.

Udover jeg synes det med farver er plat, (jeg har haft siden kom på markedet, og efter den første "sprøde" tid, så brugte jeg slet ikke farver mere), så har Hue trods alt også den fordel, at det er direkte integrerbar med fx Google Assistant og Alexa. Med IHC skal man via noget 3.part, som du selv nævner i andet indlæg.