Kandersen

Nej - indgangen er default ON. 

https://www.greenline.dk/led-paerer/led-diverse/stojkondensator

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. 

Hej igen
Nu fik jeg slettet alle mine dobbeltkonfigureringer - og det løste problemet!
Så tusind tak for hjælpen - den havde jeg ikke selv kunnet regne ud 
Og så rigtig god ferie forresten 
mvh Niels Jørgen

Jeg nåede ikke at kigge på det i går. Men at Henning kigger på det og kommentere, så kan du ikke ønske dig bedre hjælpe 
 

Du har generelt brugt den samme output adresse til flere komponenter, hvilket er en dårlig ide. Den "gamle" visual 2 kunne ikke li det, om den nye visual 3 er lige så følsom har jeg aldrig testet.
Du bruger også to tryks styring, ét til hhv. tænd og ét til sluk, det er normalt også en dårlig, og dyr, fremgangsmåde. Hvis du i stedet bruger indgangen "Kip" så tænder og slukker lampen på ét tryk. Med denne metode kan du halvere antallet af tryk, og du får en langt lettere betjening.
 

Godt nyt fra LK
Efter den sidste opdatering af FW til Visual 3 og LED lysdæmperne, kan de nu også bruges i de mere avancerede programmer. Dvs. programmer hvor kunden, også efter elektrikeren er færdig, selv kan indstille, om lyset i de enkelte rum skal slukke ved "Godnat", "Sluk Alt" eller blinke ved dørklokke, spisetid og alle de andre muligheder for for høj komfort og stor fleksibilitet.

Yes, jeg har køleskabe (2 stk.), fryser og alt net (modem, router, PoE switch og Mac Mini til vidoeovervågning) samt IHC Power kørende på hver deres kombi. 4 stk. i alt.
Har én gang prøvet at tømme fryseren for alt indhold efter HPFI slog fra. Den omgang kostede langt mere end investeringen i de fire kombirelæer...

Version 1.51 er ude:
Fejlrettelse Løst Hue fejl efter opdatering af Hue Controller (Firmware 1939070020 (Bridge V2)) Fejlrettelse Løst fejl hvor andre brugere end admin ikke kunne tilgå de sektioner de tilføjede Nyt Tilføjet mulighed for at slukke RPI ved forbindelsesproblemer ved opstart af IHC Captain Nyt Tilføjet mulighed for at gemme log til udklipsholder Forbedret Forbedring af ramdisk håndtering http://jemi.dk/ihc/#changelog

Nej, derfor skrev jeg også, at det er ikke et stort problem.
Mine bedste bud er skudt af:
1. Manuelt tryk. Dvs manuelt afkobling af skalsikring.

2. Skal det være automatisk afkobling, så ser jeg ingen anden løsning end at kombinere det med så meget som muligt, evt inkl tid.
Her er det husstandens rutiner der er afgørende, hvorfor netop et individuelt program, som du er mester i, vil være at foretrække. 

3. En kombination af ovenstående.

Der har været lidt stille - det skyldes jeg faldt i et nyt projekt 
http://jemi.dk/ihc/webvisual
Det er et forsøg på at lave en webbaseret version af LKs IHC Visual - så kan man altid ændre og kode i sit IHC program. Lige pt. er det kun et preview hvor man kan bygge og simulere en funktionsblok.
Der er en række mangler som f.eks.
- Sortering af rækkefølge i programmerne
- Skift af navne på indgange/udgange og programmer
- Man kan ikke lave forskellige Enum/Arrays
Det er lavet pt. er dog:
- Fuld simulering
- Fuld debug af simulering
- Fremhævning af ubrugte indgange/udgange (vises med gul)
- Link visning mellem ressourcer og programmer (hold musen over) så man nemt kan se hvor tingene bruges og hvordan
- Delvis mobil og tablet support
- Ctrl+klik for at folde helt ud/ind af blokke/træ
- Ret en regel uden af dragge og drop
- Indsæt alle typer input/output etc.
- Alle programmeringstyper er understøttet
- Visning af antal løbende timere - nemt at se om en timer løber løbsk/videre.
Af ting jeg har tænkt på så er der minimum:
- Langt bedre debug - vis hvor henne i programmet tingene sker + breakpoints
- De manglende ting 
- Automatisk dokumentation
- Upload
- FB bibliotek som kan deles med andre brugere - måske feedback/rating
- Sortering af input/output baseret på typen
Det er alt sammen for sjov men kan være det en dag kommer med direkte i IHC captain eller som standalone så man kan rette og vedligeholde hele IHC projektet direkte deri. Og ikke andet så kan Mac/apple folket jo være med på sigt  
Men giv mig gerne noget feedback

Jeg fik lavet en lille serie af minimoduler, hvortil der kan tilsluttes 14 svagstrømstryk.
Minimodulet tilsluttes 4 indgange på et IHC Input 24 modul og en tilhørende funktionsblok overfører signalet, fra den tast der er trykket, til det program (typisk Kip tænd sluk) der skal aktiveres.
Herved kunne jeg forøge antallet af indgange fra 16 til 56 på et IHC Input 24 modul.
For dem der er stødt ind i lignende problem, med manglende indgange, eller bare er interesseret, har jeg lagt funktionsblokke, produktbeskrivelse og dokumentation ud på Google drive her:  https://drive.google.com/drive/u/1/folders/1PdKghZ8j1VPnH1peUcG3Qugtv0dsBeLw
Modulerne sælger jeg for kr. 150,- pr stk.
 
Min historie
Jeg stod i den situation, at jeg var endt op med 225 indgange fordelt på to etager. 176 indgange var svagstrømstryk, resten er PIR og magnetkontakter.
I installationen er der uderligere et IHC 230V 8 indgange, og et IR input, som hver tager en Controller indgang.
Ved sammenkobling af to Controllere anvendes der en indgang på begge Controllere. Dette efterlader 12 Controller indgange fordelt på to Controllere, der giver mulighed for tilslutning af (12 x 16) 192 indgange.
Udbygning med en 3. Controller er der ikke plads til i teknikrummet (skabet), så jeg gik i tænkeboks. Her opstod ideen om, at det måtte kunne lade sig gøre, at dele indgange på IHC Input modulet med flere svagstrømstryk.
Resultatet er er blevet til, at jeg fik lavet en lille serie af “1-14 input Decimal-to-BCD Encoder” moduler, som har løst mit problem. 
I min installation har jeg flyttet 94 svagstrømstryk over på 2 IHC Input 24/24 moduler, så det gav plads til alle indgange.

Lige en vigtig opdatering - hvis du benytter IHC Captain til styring af HUE lyskilder og benytter mine "standard" funktionsblokke så hent venligst de opdatere på min hjemmeside:
http://jemi.dk/ihc/#huelight
Direkte link: http://jemi.dk/ihc/download.php?HueStyring.zip
Der er en fejl i de blokke jeg har lavet som kunne få din controller til at gå i selvsving/loop og dermed blive sløv.
 

Inspireret af Zafranski´s indlæg fra August 2019 om Roth varmestyring, så kommer her en lille hurtigt vejledning til, hvordan man får IHC varmestyring til at virke med openHAB2 og Google Home. 
Det forudsætter at man har opsat sin openHAB2 med forbindelse til myopenhab.org cloud. openHAB skal/bør helst være version 2.5. eller nyere. 
Det er IKKE tiltænkt som en guide til openhab generelt. Det forudsætter derfor man har en vis viden om things og items, eller i det mindste kan gennemskue det grundlæggende.

Der er brugt en temperatur & fugt sensor fra Zigza, men en "original" IHC gør præcis det samme. 
Der er brugt IHC avanceret varmestyrings blok 5.2.05.c på en HW6.2 controller med firmware 2.8.4.

Bemærk - Det er opsat med en things fil, fordi man skal bruge setpunkt i varmestyrings funktionsblokken. Setpunktet er ikke tilgængelig via produktet, desværre. Det er muligt man kan hekse noget på een eller anden måde. Spørg en IHC ekspert :-)


ihc.things:
ihc:controller:elko [ hostname="IP", username="username", password="password", timeout=10000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: // Stort bad - Rum Type number :stortbad_temperatur_fb "Stortbad Temperatur" [ resourceId=7986196, direction="ReadOnly" ] Type number :stortbad_temperaturSet_fb "Stortbad Temperatur setpunkt" [ resourceId=7989780 ] Type number :stortbad_fugtighed "Stortbad Fugtighed" [ resourceId=13699623, direction="ReadOnly" ] Type number :stortbad_sensorfejl "Stortbad sensorfejl" [ resourceId=7989522, direction="ReadOnly" ] Type switch :stortbad_telestat "Stortbad Telestat" [ resourceId=6144859, direction="ReadOnly" ] } Forklaring:
things filen gør intet andet end, at den laver dels laver selve bridge (broen) mellem openhab og IHC controlleren.
Og nedenunder defineres channels manuelt, ud fra de resourceIDére som man skal bruge (dem der står i [  ] klammerne). direction=ReadOnly" giver sig selv. OpenHAB læser kun fra IHC controlleren på disse resourceIDére. Der hvor der ikke er sat noget direction, der er det ReadWrite, fordi det er default. Og det er netop det man skal bruge til setpunktet, for at man kan skifte temperaturen (setpunktet) på en IHC "termostat" fx via Google Home. 
 
ihc.items:
//Stort Bad Group g_Stortbad_TSTAT "Stort Bad Termostat" [ "Thermostat" ] Number stort_bad_Temperature "Stort Bad Temperatur [%.1f °C]" <cu_heating> (g_Stortbad_TSTAT) [ "CurrentTemperature" ] { channel="ihc:controller:elko:stortbad_temperatur_fb" } Number stort_bad_Tempsetpunkt "Stort Bad Temperature setpunkt [%.1f °C]" <temperature> (g_Stortbad_TSTAT) [ "homekit:TargetTemperature" ] { channel="ihc:controller:elko:stortbad_temperaturSet_fb", autoupdate="false" } Number stort_bad_fugt "Stort Bad Fugtighed [%.0f %%]" <Humidity> (g_Stortbad_TSTAT) [ "CurrentHumidity" ] { channel="ihc:controller:elko:stortbad_fugtighed" } String stort_bad_Mode "Stort Bad Mode [%s]" (g_Stortbad_TSTAT) [ "homekit:TargetHeatingCoolingMode" ] Switch telestat1_stort_bad "Stort Bad Telestat [%s]" <cu_switch> (g_Stortbad_TSTAT) { channel="ihc:controller:elko:stortbad_telestat" } Forklaring:
Først skal der laves en Group item. Den hedder i det her tilfælde g_Stortbad_TSTAT. Og den skal bruge Google Home tagget [ "Thermostat" ]. Denne group fortæller Google, at der er tale om en termostat.
Derefter tilføjes de items som skal bruges til samme group for at Google kan forstå og arbejde med denne termostat korrekt. Dvs items som har disse tags:
"CurrentTemperature", den reelle temperatur. 
"Homekit:TargetTemperature", der reelt er setpunktet. <- (Derfor skal den channel være ReadWrite) 
"Homekit:TargetHeatingCoolingMode" som gør det, at den fortæller hvilken "mode" termostaten er i.

Normalt vil man have en "rigtig" termostat som sender et nummer, alt afhængig af om den er heat, cool, ON, OFF eller fx Auto. 
Sådan en funktion har vi ikke med IHC sensorene og varmestyringen, da den reelt "bare" er sensorer/følere, der sender data retur til controlleren, så så kan tænde/slukke en telestat. Derfor er der ikke linket til nogen IHC resourceID for Mode status. Men vi kan sagtens bruge Mode alligevel, og ret smart endda. 

Det gør vi ved at bruge en String type item til "Homekit:TargetHeatingCoolingMode". Ved brug af den og telestaten fortæller vi simpelthen Google om "termostaten" varmer eller ikke-varmer(køler). (heat eller cool). Simpel logik.   

Men først et par billeder af "termostaten i Google Home, når det er sat op, og man har synkroniseret sine enheder. Det ser således ud i Google Home (virker også i Google Nest Hub):

 
Bemærk, det er samme termostat men den er rød på det ene billede og blå på det andet. Det er her Mode og String type item og en simpel rule kommer ind.. 
Den aktuelle temperatur aflæses under teksten "Indendørs". På begge billeder er aktuelle temperatur altså 22.5. Men dreje knappen er den man stiller setpunktet på.
På det røde billede er setpunkt sat til 23grader. Men da temperaturen kun er 22.5 grader, så er den altså i varmetilstand. Telestaten er tændt.
På det blå billede har jeg skruet setpunktet ned til 22 grader. Altså mindre end den egentlig temperatur. Og derfor er den i køletilstand. Telestaten er slukket.

Det her er ikke noget Google selv finder ud af.. Det laves via en simpel rule som benytter telestaten til at fortælle Google, via Mode, hvad status er. Den ser således ud:
rule "heatingmode stortbad" when Item telestat1_stort_bad changed then if (telestat1_stort_bad.state.toString == "ON" ) { stort_bad_Mode.postUpdate("heat") } else { stort_bad_Mode.postUpdate("cool") } end Hvis man har en smule indblik I openhab, så vil man lyn hurtigt gennemskue denne rule. 
Den betyder simpelthen:

Hvis telestat1 er ændret
  så
       Hvis den er ændret til ON
       Sendes "heat" til item stort_bad_Mode
ellers
       Sendes "cool" til item stort_bad_Mode
end

Kort sagt - Er telestaten ON, så sættes Mode til "heat" og ellers er telestaten OFF, og Mode sættes til "cool". 

Det er netop det der trigger Google Home termostaten - "heat" så er den rød, "cool" så er den blå.
Og dette kan vi gøre, fordi det er en String item type. 
 
Selve telestaten styres helt normalt via IHC og setpunktet i varmestyringsblokken. Og fordi vi har ReadWrite på setpunktet, så kan vi også skrue op/ned for setpunktet i IHC varmestyringen via Google Home. 

Så nemt er det faktisk.

Det virker i Google Home app (både Android og IOS). Det virker med Google Nest Hubs, (dem med skærm). Og det virker med stemmekontrol. 
Spørger jeg fx Google "Hey Google, hvad er temperaturen i stort bad" - Så får jeg svaret 22.5 grader. 
Hvis jeg beder Google om at ændre termostaten til 23 grader, så gør Google også det, og setpunktet ændre sig til 23 grader i IHC varmestyrings blokken.
Fordi det er en temperatur og fugt sensor, så kan jeg også sige, "Hey Google, hvad er luftfugtigheden i stort bad". Og Google svarer retur, hvad luftfugtigheden er. 

Man kan IKKE se luftfugtigheden angivet nogle steder.. Der er faktisk ingen der kan forklare, hvorfor man ikke kan se det. Men det er en feature som Google åbenbart ikke mener er nødvendig at kunne se, men som man skal spørge ind til.. Lidt mystisk holdning, men det er altså Google´s skyld. 

Thats it.. Håber det kan bruges til noget. 
Spørgsmål - Så bare skyd løs.

 

Nu er det et stykke tid siden jeg sidst søgte. Og der var der to windows programmer. Det ene fandt jeg aldrig ud af, og det andet IMST troede jeg at jeg forstod, men heller ikke det. 
Udover det har jeg ikke fundet andre. 

Fixer det lige. Tak for feedback

Ok. 
Jeg har løst problemet. Så dette er blot en opdatering til hvis nu der skulle være nogen der - ja. Det er der nok ikke.
Men, altså. Det er jo til en kvaje-bajer. Jeg fulgt for 117. gang ledningerne fra controller til output modul. Alt var godt. Så skiftede jeg ledningerne helt. Og opdagede. At. Jeg havde haft output-modulet forbundet til INPUT på IHC-controlleren...
Ja. Skal vi ikke bare lade det ligger hér...

Nyt Mulighed for at hente projektfilen fra IHC controller, og samtidig mulighed for at gemme de aktuelle kørselsværdier (runtime). Funktionen ligger i menu: IHC Administrator. Nyt Visning af interne IHC ID'er (både hex og decimal) - hold ctrl og klik på et "ressource navn" Nyt Pushover har nu fået tilføjet prioritet 2 med mulighed for callback: https://pushover.net/api#priority Forbedret Forbedring af hvordan genstart/nedlukning håndteres Fejlrettelse Små hastighed og optimeringerne http://jemi.dk/ihc/#changelog

Det er et Nilan Comfort 300LR (årgang 2016/17).
Jeg må op på loftet og hive det fra hinanden (endnu engang). Kender snart det anlæg bedre inde i end udenfor, altså lige bortset fra det spjæld, som jeg selvfølgelig ikke lige havde skænket en tanke 

Det kan du - ihverfald hvis vi har det samme anlæg. Forpladen af - riv i stroppen omkring krydsveksleren og så sidder den lige der bagved:)
 

Jeg har et Nilan Comfort 300LR som jeg kører via modbus til en Rpi med openHAB2. Funger perfekt.. 

Mht Nilans Co2 løsning, så har jeg direkte fravalgt dette af flere årsager. 
Den oplagte årsag, prisen.. Det er himmelråbende idioti at betale 4K for det her. Nok er Co2 følere rimelig dyre, men den pris er bare vanvittig. 

En anden årsag er - Hvad når man nu har Co2 føler.. Hvad så?
Her mener jeg man lige skal gøre sig nogle tanker om, hvad det er man vil. Nilans løsning med en Co2 føler i aggregatet, det er efter min mening ikke helt gennemtænkt. Når Co2 indholdet stiger, så sættes hastigheden op.. Fair nok, men spørgsmålet er, hvorfor Co2 indholdet stiger, og om det er hele boligen eller kun dele af boligen. Og her kommer et ventilationsanlæg som Nilan (og andre lign løsninger) faktisk til kort. Det giver ingen mening at sætte hastigheden op på anlægget, og dermed få ventileret (samt nedkølet) hele boligen, hvis det kun er et enkelt rum som har et højt Co2 niveau. Men det er den eneste måde disse anlæg kan fungere på, desværre. 

Derfor har jeg bevidst fravalgt den løsning. Den vil efter min bedste overbevisning bare give anledning til en del frustrationer men også rent økonomisk forværre alt. 

I stedet vælger jeg at fokusere på decentrale løsninger med Co2 følere i så mange rum som mulig, (foreløbig 1 rum). Når Co2 niveauet er for højt, så kunne en alarm, lampe eller lign. tænde i det pågældende rum, for at gøre opmærksom på, at der bør ske noget. 
Vi har fx en Netamo vejrstation, hvor indedelen har Co2 føler. Den er placeret i vores stuen. Når Co2 niveauet er for højt, så får jeg en melding (på mobilen). Hvis jeg ikke havde Netamo forbundet til openHAB2, så kunne jeg istedet vælge at gøre noget manuelt. Men nu er vi heldigvis så priviligeret, at vi har 4 stk elektriske Velux ovenlys vinduer i stuen, som også er styret af openhab2. Og det er derfor oplagt at simpelthen åbne disse automatisk, for på den måde at få luftet ud i stuen, mens resten af huset ikke behøver at "lide" af dette. 
Men hvis jeg ikke havde disse vinduer og dermed denne smarte/automatiske løsning, så kunne en anden løsning være, at man lige manuelt åbner en terrassedør/vindue eller lign og igen får luftet ud. 
Min erfaring med at skrue ventilationsanlægget op på fuld skrue viser, at det tager simpelthen enormt lang tid at få luftet ud på den måde. (mindst ½-1 time). Hvorimod det at åbne et par vinduer i 5-10 minutter bringer Co2 niveauet lyn hurtigt ned. Og det sker dermed kun i det rum, hvor Co2 niveauet er for højt. 

Derfor mener jeg, at man skal lige tænke over, hvad det er man vil med de målinger man får og hvor man får dem fra. 

En Netamo vejrstation kan erhverves for relativ få penge, ca 1200,-. Og ekstra indedele kan tilføjes for ca. 500,- stk. 
Alternativ er det som Claus (Zigza) laver med Fuga co2 sensorer, hvis man har pladsen/muligheden for det. Jeg ville ønske jeg havde den mulighed, for så skulle det da helt klart laves i alle rum. Men jeg har ikke et ekstra 1-modul i hvert rum til dette. Men det ville være vanvittigt optimalt og langt mere meningsfyldt i forhold til Nilans (og andre ventilationsanlæg) centrale løsning. 

Det er ihvertfald min mening. Jeg hører gerne hvis nogen har en anden mening.

Er enig med Henning (men jeg tror han mangler et "ikke" i hans sætning ).
Men hvis man fx kun brugte standard blokkene. Så kunne man/LK jo fint opdatere dem uden problemer. 

Så er fejlen fundet der var defekte udgange 

Hvis du har lavet dine items i PaperUI, så har du IKKE en items fil. Så lad vær med at lede efter den 
Mht til dit egentlige problem, så er det ikke i items du finder "direction", men derimod i channel. Så vælg en channel, så kan du se. Jeg er dog ret sikker på, at medmindre du har manuelt ændret den, så burde den står til read/write, da det er default. 
Så noget andet må være galt med dit setup.. Har du tjekket loggen? Og i øvrig, hvor ser du at du ikke modtager opdateret værdier?

Tak - det er fixed nu