Kandersen

Ja det var lidt det jeg også tænkte.

Basalt set behøver du ikke fjerne noget overhovedet, hvis ellers dine lampeudtag allerede har fasen på udtaget. Så er det her du tilslutter dine lamper. Hvis fasen ikke er i udtaget, så må du lægge mellemledningen om fra output modulet til fasen. (kan gøres ret ukønt ved at smide alle ledningerne over på den respektive fase på output modulet, hvis de kan være der.. Det er alligevel samme fase du skal bruge. Alternativ så er det i gang med muffer/klemmer eller andet). Sikringer behøver du ikke. De sidder allerede hvor de skal og som de skal. Dit wireless udtag har allerede fasen direkte på, men det er så vidt jeg husker på bagsiden af lampeudtaget. Så udtaget skal nok skiftes til et almindeligt. Tryk osv. behøver du heller ikke fjerne. Men det er klart, at det vil se kønnere ud uden, når nu de ikke er i brug alligevel. Her har du stor fordel i, at det er de trådløse tryk. Men hvis der er dåse bag alligevel (fordi der måske engang har siddet et alm tryk), så skal de vel blændes af. Hue switch (trykkene) kan du evt opsætte ved siden af. Jeg kom netop i tanke om, at jeg fornylig læste om en der havde bygget en Hue switch ind i en 1½ modul fuga ramme. Men jeg kan ikke finde siden nu. Det ville være en optimal løsning. Og det så faktisk ret godt ud, hvis man altså kan lide Hue Switch tryk. (jeg kan ikke li Hue Switch, men en fuga ramme kan måske gøre underværker). På den måde behøver du ikke at blænde evt dåser af, men kan smide Hue switchen direkte hen over, så vidt jeg lige husker. Jeg skal lige understrege, jeg har ikke arbejdet som elektriker i snart 30 år, så jeg ved ikke om reglerne er ændret i forbindelse med at hr og fru DK selv med montere en lampe direkte på fasen på lampeudtaget, eller om fasen overhovedet må være der mere på et lampeudtag mere. Og jeg kan selvfølgelig heller ikke anbefale dig selv at gøre det, medmindre du har "lov/ret" til det. Så vidt jeg erindre om lampeudtag, så betragtes de vist som værende værre end fx stikkontakter. Så det vil ikke undre mig, om du ikke selv må gøre det.

Hvis man styre ventilation via fugtighed, så ville det da starte længe før dugpunktet kommer så højt, vil den ikk? (jeg ved godt det forudsætter man sætter den relative fugtighedsprocent lavt nok, men et sted mellem 30-60% er vel et normalt område for fugtighedsprocenten). PT står Nilan anlægget til 50% (kan vist ikke komme højere). Så jeg ville forvente det starter før dugpunktet når så højt som til vanddampen fortætter sig.

Ja det anede mig, der var noget der. Jeg var godt nok lidt bekymret for, at det krævede en HW 6.2 controller. Jeg må nok indse, at jeg skal opdatere firmwaren, og så håbe på den er stabil som .199 er. Hmm.. Okay det er lidt overraskende.. Så er der jo reelt ingen grund til at opdatere firmwaren alligevel. Den virker jo som den skal, altså bortset fra at den ikke benævnes fugt. Så er det kun dugtpunkt som mangler. Men jeg kan ikke helt gennemskue, hvad den reelt er til.

Jeg har lidt en udfordring her. Jeg har skiftet to af temperatur sensorene (i begge badeværelser) til sensor med fugt & temperatur. Jeg har også skiftet produktet i Visual 2 til samme, altså til fugt og temperatur. Når jeg uploader det program til controlleren, så for jeg en fejl. Den melder at den ikke kan sende programmet til controlleren. Controlleren er en Visual 2 (uden viewer) HW 6.1 med firmware .199 Er der nogen der har en ide til, hvad der er galt? Pt har jeg kørt det gamle program ind igen, og det virker med de samme nye sensorer.. meeen jeg mangler jo ligesom fugt.. Og så bemærkede jeg lige i service view, at nu har får jeg en gulvvarmetemperatur på ca. 55 grader (Jeg har ingen gulvvarme føler). Med de andre sensorer var gulvvarme temperaturen 0.0 grader

Som Ejvind siger, så skal du over i noget 3. part for at det virker. Pt er OpenHab det eneste jeg kender som har en virksom binding til IHC controlleren. Der findes også en binding til Domoticz, men jeg kunne ikke få den til at virke. Jeg tester selv i øjeblikket med zwave, hvor jeg har en UBZ1 zwave controller (USB key størrelse) tilsluttet en Rasberry Pi 3 og en zwave Aeotec multisensor 6 kørende. Via OpenHab kan jeg praktisk talt manipulere med alt på IHC systemet. Dvs hvis jeg ville, så kunne bruge denne multisensor til at tænde/slukke lyset hvor som helst i boligen. Det kunne lige så vel være en røgalarm (afmelding/pause/tilkobling) eller hvilket som helst andet. Et af problemerne med OpenHab er, at det er ikke altid lige nemt. Det er nu ikke OpenHab´s skyld, men til gengæld IHC enhedernes. Har du fx Uni dimmere i din IHC installation (bagkant, DIN skinne), så er det lidt en udfordring at styre disse via OpenHab, lige så snart de skal andet end at tænde/slukke. Jeg døjer lidt med at kunne skrue op/ned for lyset på en UNi400 dimmer. På wireless dimmerne, der er det simpelt nok. Et andet problem med OpenHab er, at dokumentationen er efter min mening skrevet så indforstået, så det er de færreste der bare lige springer ind i det. Det er til gengæld typisk for denne slags linux-baseret open source programmer. Det er lavet af nørder, for nørder. Og dokumentation/tonen er derefter. Min plan er, at jeg med tiden vil udbygge systemet, så det i langt større grad bliver styret og overvåget via zwave enheder. Men IHC systemet skal forblive uberørt, så jeg altid kan vende tilbage. Jeg havde ellers en ide om, at jeg ville prøve nogle af de zwave dimmere der findes (til DIN skinne montering). Men jeg er blevet enig med mig selv om, at i det øjeblik jeg gør det, så bryder jeg med IHC konceptet, og kan ikke bare vende tilbage, (selvom 2 ledninger i tavlen lyder banalt). Det er muligt jeg gør det alligevel en dag, primært bare fordi at prøve det. Men det vil nok også være det første skridt til en total udskiftning af IHC systemet, alt afhængig af udfaldet. Mht til zwave, så skal man også være lidt vågen. Ikke alt zwave virker med hinanden. Men hvis du bruger de mest gængse mærker og protokoller (open zwave fx), så går det ikke helt galt. Min mening er dog, at problematikken med zwave protokollerne, det er det mindste problem, i forsøget på at kombinere zwave og IHC. Overvej evt om du skal have en controller, der kan andet end lige zwave. Jeg springer muligvis på en Fibaro Home Center controller på et tidspunkt. Og så håber jeg, at der måske kommer en binding til deres Home Center software og IHC controlleren. Hvis ikke, så skal jeg stadigvæk via OpenHab.

Det er nødvendigt. Ellers ender man med den der standard skydeknap. Det var det der var mit problem. Med mappings som i dit eksempel, så fungere det i sitemap.

Jeg er nødt til at have det her switch een gang til, for prins knud! Hvis jeg bruger denne (Claus´s eksempel 3.2) i items: Switch ihc_tryk2 {ihc=">[ON:0x14268d11:100]", autoupdate="false"} Og denne i sitemap: Switch item=ihc_tryk2 Så ender jeg ud med en switch i sitemap som IKKE tilbagestiller sig selv. Hvordan det er lig med et IHC tryk 1:1 det er mig en gåde?? Indtil nu har jeg brugt en rule som tilbagestiller knappen (switch). Men som jeg forstod på Claus´s indlæg, så skulle ovenstående være uden brug af en rule. Eller har jeg misforstået det? I øvrig, hvad er det præcist den der autoupdate="false" gør? Og hvorfor var det lige man skulle indsætte et > før IHC syntaks?

Okay, så giver det mening. Jeg troede faktisk at de begge kørte modbus.

Lars, jeg kender godt LK´s underlige løsning med en plc. Men jeg fejler i at forstå, at controlleren har et RS485 interface og kan vistnok kommunikere modbus. Nilan anlægget har et RS485 interface og kommunikere modbus. Men de kan ikke snakke med hinanden. Og når det er sådan - Så er det vel, ret beset, irrelevant hvilket master/slave forhold der er.

I realiteten er det vel også ligegyldigt om Nilan er slave, da IHC controlleren alligevel ikke kan/vil snakke sammen med Nilan anlægget direkte på modbus. Er det ikke korrekt forstået? Eller sagt på en anden måde. Hvorfor kræve et anlæg skal være slave på modbus, når man alligevel ikke kan snakke direkte sammen med det..

Jeg kan godt se det system du beskriver. Men på billedet fra i går, der sidder en brun ledning på en grå rækkeklemme med nummer 100, (til venstre for en blå 101 og gul/røn 101). Den brune ledning kan jeg simpelthen ikke få til at passe ind i din logik beskrivelse. Er du sikker på det ikke er en fejl, og den skulle have heddet 101?

Det er noget rigtig bras med tangenterne i de fortrådede tryk. Netop som Henning siger, så skal man have hele trykket ud. Og selv der kan det drille.

Bjarne, dit billede kræver vist en mere indgående forklaring end blot, at kalde jordledningen det samme som kablet. Når jeg kigger på det, fra venstre, så er brun, blå og jordledning med samme nummer 103. Mit gæt er, at du bruger kabelnummeret til både jord, nul og fase, hvilket kan være smart nok.. Men det hænger ikke sammen jo længere til venstre man kommer, for der er pludselig en brun 100, blå 101 og jordledning 101. Inden det, så kommer problemet med den sorte og den hvide (igen set fra venstre mod højre). De hedder begge 10. Og længere til venstre en brun der hedder 10, en sort der hedder 7, og endnu en sort der hedder 11. Findes der en dybere forklaring på dette? Det er selvfølgelig svært at se, når ikke man kan se selve kablerne, hvilket muligvis ville forklare en hel del nærmere. Pointen er jeg dog helt med på, at kalde jordledningen (evt også fase og nul, i de kabler der har fase og nul (sikkert de fleste)) samme nummer som kablet. Så bør man slet ikke være i tvivl om, hvilket kabel de kommer fra, når man bruger klemmerækker.

Som nævnt i en anden tråd om samme, så er der ikke rigtig nogen nemme løsninger. Meget kan dokumenteres i Visual. Men der er også noget der kommer til at mangle. Der er ikke mange andre løsninger end at markere kabler og ledninger, og så ellers bruge noter, der hvor Visual ikke rækker direkte.

Rules er efter min mening det absolut stærkeste ved OpenHab, synes jeg. Der er næsten ingen grænser for, hvad man kan. Til gengæld skal man virkelig vide nogen om "programmering" og gerne også java, hvis man skal være virkelig avanceret. Den der rules i habadmin eller add-on i paperUI, den er meget begrænset, og i øvrig beta i paperUI. Editoren er sikkert god, men den hjælper ikke meget mht syntaks, commandoer osv. Der skal man have indgående kendskab til OpenHab og java. I hvertfald sådan jeg forstår det. Forleden faldt jeg over en som havde lavet noget varmestyring i Habpanelet. Jeg mener også der var rules/scripts med til. Det nemmeste er at søge i tags på Openhab´s hjemmeside. Din natsænkning kan du godt bruge ved at linke til dine døgn indstillinger i Fbén sammen med driftformen. Og så ellers "If" dig ud af det i rules. Men som nævnt, så er rules et område jeg først selv er ved at prøve at sætte mig ind i. Jeg tror det vare meget længe førend jeg kan de mere avanceret former, desværre

Det kræver blot at du linker din "ude" funktionen til driftform "ubeboet" i IHC controlleren med FB 5.2.01.h (avanceret varmestyring) til din OpenHab. Derved kan du lave en rule, hvor du styre dine termostater præcis som på samme måde, som hvis du gjorde det i IHC. Jeg er ikke så stærk i de der rules endnu. Men det er noget med: when "ude"=ON then command <sæt setpunktet/temperaturen for temostaterne til x-antal grader> end Du er nok også nødt til at have en rule der beskriver, hvad setpunktet skal være, når du så er hjemme. (altså driftform "beboet"). Det kan du evt gøre ved, at bruge "ude" i OFF position. Dvs. når "ude" ikke er ON, så må den være OFF. Men personligt synes jeg det er en lidt usikker måde at gøre det. Du kan linke direkte fra driftformerne fra varmestyrings blokken til OpenHab. Du skal også have to virtuelt tryk i OpenHab, som du kan sætte driftformen på. (Tre tryk hvis du også vil bruge driftform frostsikring). Hvis du er vant til Visual, så er jeg ret sikker på, at du gennemskuer dette lige så snart du ser Fbén. Natsænkning er mere "kryptisk" da du skal definere et tidspunkt/døgnur.. Og så langt er jeg slet ikke nået endnu. Jeg mener dog jeg læste der var en der nærmest havde lavet en skræddersyet løsning til netop varmestyring på Openhab community. Openhab er uden tvivl enormt smart og brugbart til mange ting. Men for pokker hvor er det dog også langhåret at komme igennem. Alt skal nærmest kodes i hånden. At manuelt lave items fra IHC projektet er i virkeligheden den nemmeste del af OpenHab.

Jeg er 110% sikker på, at de var slettet i Visual. Nu tog jeg og uploadede projektet igen til controlleren, og gik derefter ind i IHC captain, som selvfølgelig skulle loade hele projektet igen. Denne gang uden fejl. Og nu var de gamle Fbére væk derfra.. Så der skulle altså bare en ekstra omgang til. Men mystisk det kan ske.

Jeg tror du misfortolker det som folk har givet udtryk for. Kritikken har primært drejet sig om, hvad den nye controller kan eller mangel på sammen. Det er svært at udtale sig om controllerens stabilitet, når meget af det er skrevet førend den overhovedet har været frigivet.

Kom der nogensinde en løsning på dette? Jeg har netop erfaret problemet. 2. gang virkede det dog. MEN, IHCcaptain har altså gemt nogle ting, som ikke længere er i controlleren. Jeg udskiftede nogle Fbére i Visual og uploadede programmet til controlleren. Derefter gik jeg ind i IHC Captain for at få den til at opdatere. Men det har resulteret i, at nu har IHC Captain både den gamle Fb og den nye. Det virker ikke helt rigtig at jeg kan se både den gamle Fb og den nye, og jeg kan ikke umiddelbart få den til at "opdatere" databasen eller hvad den nu end bruger. Jeg har prøvet at logge ud og ind flere gange.

Er det normalt, at når man har skiftet driftform til ubeboet (15 grader) så vises setpunktetet i IHCtablet stadigvæk det oprindelige? Pt har jeg nogle værelser som kører ubeboet og derfor er sat til 15 grader jf Fbén. Men når jeg trykker på temperatur ikonet i IHCtablet, så vises det almindelige setpunkt, (22 grader fx). Jeg har tjekket i serviceview, at den har skiftet driftform til ubeboet.

Jeg har ingen erfaringer med SceneSwitch. Men det er samme princip som Hue dimmer switch, hvor man med flere tryk på knappen kan skifte imellem scenerne. Jeg har brugt HUE dimmer switch på denne måde i ca. 2½ døgn, så blev jeg træt af at skulle stå og trykke flere gange for at ramme den scene man vil have, mens lyset skifter. Hue Dimmer switch kan styre 4 scener. SceneSwitch har, som jeg lige kan se det, 3 scener. Så måske er det lidt mere tåleligt med kun 3 scener. Det er selvfølgelig ikke et stort problem, men jeg kan forestille mig, at jo mere presserende sted det sidde, desto mere bliver man påvirket af det.. fx hvis man er lige ved at "rende over" og skal skynde sig på potten, at man så lige skal trykke 2 (4) gange på trykket, inden man rammer det lys man skal bruge. Eller hvis man står i indgangen med favnen fuld af poser/pakker/osv, og skal tænde lyset med albue/næse/hæl, eller hvad man nu kunne finde på at bruge.. I mere "rolige omgivelser", der vil jeg tro at det snildt kan gøres til en vane, som man kan leve med, fx i daglig stuen, alrum, værelser osv. Så med det i minde kan det sikkert godt fungere. Jeg brugte Hue dimmer switch i stuen. Hvis jeg skulle bruge forskellige scener i dag der, så tror jeg at jeg vil finde på en eller anden stemmestyring løsning i stedet, der direkte sætter scenen.

Så vidt jeg kan se i Visual, så er det er kun det som er i direkte relation til IHC styringen, som du kan dokumenter direkte. Eksempelvis jordledning kan du ikke dokumentere direkte. Hvis du vil det, så kan du evt bruge noter og kabelnummer. (hver jordledning tilhører jo et kabel). Som Bjarne siger, så kan du nummerere jordlederen ud fra kablet. Men direkte i IHC Visual, der kan du ikke dokumentere den ledning andet end i noter/beskrivelser/oa. Eller så har jeg ikke lige fundet den mulighed i Visual. I vores IHC tavler er/var det oprindeligt lavet, som vist på det vedhæftet billede med en 12 klemme-række (kronemuffer). Det er 5 stk 3x1.5mm2 kabler der kommer nede fra garagen, hvor "hoved" tavlen sidder med alle sikringer i. Deri sidder 5 stk 2polet sikringsgrupper, som er ført op til den klemmerække du ser på billedet. Det fungere og er muligvis også lovligt. Men det ser ikke godt ud, samt at der ingen som helst overblik er over de enkelte faser/null ledninger. Elektrikeren har ikke nummereret eller angivet klemmerne. På sikringerne i garagen der er de angive som , IHC1, IHC2, IHC3 ... osv. Heldigvis hænger det også sådan sammen på klemmerækken, talt fra venstre. Men det kunne lige så vel have været anderledes, når de ikke er nummereret. Kablerne er der skrevet på, hvis ellers man kan læse "herogryfer". I IHC dokumentationen har man så angivet, hvilken sikringsgruppe en funktion tilhører. Så på den måde kan man godt sige det hænger sammen. Men det er bestemt ikke pænt eller optimalt, da der mangler det led imellem den klemmerække og videre til komponenterne. Fx på 230v modul i IHC Dokumentationen kan jeg se, at den ene fase høre til IHC(x). Dvs så ved jeg at der går en ledning (fase) derfra og ned til klemmerækken som svare til IHC(x). Fair nok. Men fordi der sidder flere ledningerne (faser) på samme klemme i klemmerækken for IHC(x), så kan jeg kun finde den rigtige, ved at følge ledningen op. Det er en møg irriterende måde at gøre det på, synes jeg. Til gengæld koster det plads at gøre det "rigtigt" eller mere optimalt, hvilket nok er årsagen til, at man i sin tid har valgt denne løsning, medmindre man sætter numre på ledningerne. Det er en løsning som jeg er i gang med at ændre på. Jordledningerne er slet ikke dokumenteret. De er bare ført direkte til top i tavlen, som du nok kan ane på billedet. (Det skal lige siges til billede, at det er taget før jeg gik i gang med at ændre det. Det ser lidt anderledes ud i dag. Men jeg er stadigvæk i gang, og derfor ikke noget nyere billede).

Har aldrig brugt Term, så jeg ved det ikke.

Denne her.. Håber den kan bruges. 7.1.02.a. Wireless med ur, skumring og pir..ifb