Kandersen

Den plast bagplade ændre da ikke ved, at der er en krydsfinér plade umiddelbart imellem tavlerne.

Den lov er en del nyere end min tid Må man så heller ikke lave "gennemføring" i en træplade? På loftet har jeg tre tavler siddende på en stor krydsfinér-plade. Der har jeg boret huller strategiske steder i tavlerne og trukket ledninger (fase, nul og lampeledninger) igennem og opsat UNI250 1-modul og 80mm lampeudtag dimmere på bagsiden. Principielt er det jo praktisk talt det samme

@Pauli Anttila I need some help with controling a input for functionblok 1.1.04.c (følg/inverter). I have tried all sorts of combination. But I simply cant get this work. If I link the channel directly to the resourceID of the input and using the pulseWidth, then nothing happens at all. Like this: Type switch :Nilan_brugerfunktion "Aktiver Nilan brugerfunktion" [ resourceId=14474513, direction="WriteOnly", pulseWidth=1000 ] The item I have linked to the channel receives ON just fine. But nothing happens in the IHC controller. <-- thats the weird part. If I link the channel to a push button resourceID without pulseWidth, the input goes ON, but does not return OFF. (due to not using the pulseWidth I assume). Like this: Type switch :Nilan_brugerfunktion "Aktiver Nilan brugerfunktion" [ resourceId=20570 direction="WriteOnly" ] For now, the only way to get this to work is to use the last option, and then use a rule to turn the input (switch button) to turn OFF again. I´m pretty sure this has something to do with the functionblok. But it´s way over my head, as it works just fine when pushing the push-button manually. This is a screendump of the funtionblok as well as the product: I have tried both input (function blok) and output (product side). Whenever I use pulseWidth, I get nothing through the IHC controller.

@Pauli Anttila is it possible to set the read/write direction in the items file rather than in the things file? Most of my output items only require a direction="ReadOnly". But when default is read/write, I have to create an thing, only for this. In the old binding we could make use of <> as for direction.

@Pauli Anttila I just tried the 2.5.0 snapshot version (downloaded link). I cant get it online.. This is the logfile: EDIT - Works now..Forgot the hostname

@Pauli Anttila I just tried the 2.5.0 snapshot version (downloaded link). I cant get it online.. This is the logfile: 2019-03-14 21:54:01.874 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR) 2019-03-14 21:54:02.287 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING) 2019-03-14 21:54:02.331 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED (HANDLER_CONFIGURATION_PENDING) to UNINITIALIZED (HANDLER_MISSING_ERROR) 2019-03-14 21:54:02.340 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:elko' has been updated. This is my cfg file: ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="adminIHC0101", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: Type switch :stortbad_dimmer_fb "Stortbad dimmer Trigger" [ resourceId=5537553, direction="WriteOnly", pulseWidth=200 ] Type switch :stortbad_dimmer_state "Stortbad dimmer state" [ resourceId=5540626, direction="ReadOnly" ] Type switch :sove_80mm_fb "Soveværelse 80mm Trigger" [ resourceId=17073937, direction="WriteOnly", pulseWidth=400 ] Type switch :sove_80mm_state "Soveværelse 80mm lampeudtag" [ resourceId=26459, direction="ReadOnly" ] Type switch :bryggers_dimmer_fb "Bryggers dimmer Trigger" [ resourceId=12059409, direction="WriteOnly", pulseWidth=200 ] Type switch :bryggers_dimmer_state "Bryggers dimmer state" [ resourceId=12062482, direction="ReadOnly" ] Type switch :bryggers_skabslys_fb "Bryggers skabslys Trigger" [ resourceId=1317905, direction="WriteOnly", pulseWidth=400 ] Type switch :lillebad_dimmer_fb "Lille Bad dimmer Trigger" [ resourceId=12208913, direction="WriteOnly", pulseWidth=200 ] Type switch :lillebad_dimmer_state "Lille Bad dimmer state" [ resourceId=12211986, direction="ReadOnly" ] }

Man kan sagtens bruge samme metode til at angive hvor et kabel kommer fra og går til. Men det er efter min mening lidt dobbeltarbejde, for så er man netop ovre i, om man også skal definere hvilken indgang/indgang/komponent osv i kabelnavngivning. Disse informationer er jo allerede en del af Visual, så længe kablet vel at mærke ER monteret/i brug. Problemet opstår, når/hvis kablerne ikke er monteret endnu/i brug. Så skal de være identificerbare i sig selv. Og i begge ender, hvis flere kabler ender samme sted, som du er inde på med x-felter. Heldigvis er min installation ikke sådan, eller.. Hmm, jo det er det faktisk, fordi jeg har 2 "undertavler". Den ene går der heldigvis kun et kabel til fra hovedtavlerne til undertavle ved manifold/fyr, (til varmestyringen). Det er som udgangspunkt nok i sig selv, selvom en unik identifikation ville være klart bedre, for tænk nu hvis der bliver trukket et kabel mere. Den anden undertavle sidder på modsatte side af hovedtavlerne, og der er trukket løse ledningerne i mellem dem. Dem nægter jeg simpelthen at mærke op (principielt bør det betragtes som samme tavle, da det er "intern" montage).

Jeg gik fornylig i gang med navngivning af svagstrøm kablerne, (i en installation som ER monteret). Jeg tog dem "bare" i slavisk rækkefølge ud fra rum i Visual. xx.yy angiver rum:kabeltype/kabelnummer. fx 01.01 Dvs: Første rum svagstrømskabler: Kabel: 01.01. (01 = første rum. 01 = første kabel) Kabel: 01.02. (01 = første rum. 02=andet kabel) Første rum stærkstrømskabler: Kabel: 01:31. (01 = første rum. 31=første kabel) Kabel: 01.32. (01 = første rum. 32=andet kabel) Tredje rum svag og stærkstrømskabeler: Kabel: 03.04. (03=tredje rum. 04=fjerde svagstrøms kabel) Kabel: 03.32. (03=Tredje rum.32=andet stærkstrømskabel kabel) og så videre..... Jeg har ingen kabler hvor der er blandet svagstrøm/stærkstrøm i samme kabel. Det er en forudsætning at der ikke kommer mere end max 19 svagstrømskabler i hvert rum. Antallet af stærkstrømskabler pr rum er op til 99 pt, eller mindre ligesom svagstrøm, hvis man finder på noget andet/anden type ved yy. Er der mere end 99 rum, (næppe realistisk) så lave man det bare således: xxx.yy. Det er ligeledes en forudsætning, at rum rækkefølgen ikke ændre sig i Visual. Jeg har ikke gjort noget ud af at nummerer brugsgenstand som Henning beskriver herover, fordi det allerede er angivet i Visual, efter min mening. Men hvis man benytter klemmerækker eller lign, så bør man gøre det som Henning, da det giver et væsentlig hurtigere overblik på klemmerækken. Det bliver mit næste træk, fordi jeg har opsat klemmerækker til alle ledningerne i stærkstrømskablerne. Og så har jeg tænkt mig at bruge xx.yy-zzz, hvor zzz indikerer klemmerækkenummeret. Jeg har også overvejet at lave alle svagstrømkablerne om (igen). Og så starte ud med, på hvilket modul de er monteret. Det er fordi det er lidt nemmere at finde kablet i tavlen sådan, uden at man pinedød skal ind i visual for at se, hvor et kabel er monteret. Men jeg ved endnu ikke om jeg "gider det". Jeg ville allerhelst lave alle svagstrømskablerne om så de ender i LSA klemmer, fremfor i modulerne. Jeg har bare ikke pladsen til det . Problemet uden klemmer og bruge modulerne som "rettesnor" opstår, hvis man laver om på noget, (hvilket jeg har gjort i de sidste 2 år). Så jeg er lidt vildrede lige pt. hvad det angår. Nummersystemet xx.yy-zzz fastholder jeg dog. Ps. Det er bevidst jeg altid bruger 0 foran ´et tal, for at sikre man ikke bliver i tvivl, når man runder ti. Fx et kabel hvor der står 1:04, er det måske et manglende 0 og derfor første rum? Eller måske et manglende 1´tal og dermed rum 11? Ved at sætte et 0 foran, så er man altid klar over, hvad det rigtige er. Jeg er lidt "arbejds-skadet" hvad dette angår

Et måleinstrument på bunden og derefter toppen af automatsikringen ville være det første sted at starte. Er man ikke fagkynding på området, så få fat i en der er det, og få det målt. Det vil lyn hurtigt afspejle, hvor problemet ligger. Som billedet viser fra lampen, så er de ledninger ikke årsagen, medmindre de er samlet forkert et andet (ikke synligt) sted, vi ikke kan se. Btw. Når man tilslutter en lampe og bruger farvekoder, så er normen: BLÅ = 0 og Sort/brun = L (Vær dog opmærksom på den sorte. I gamle bygninger kan sort også være = 0, her vil der ofte være en hvid eller grå, som så vil være L. "Anden farve" = M, (Rød er ofte nuling/Jord, så den skal man passe rigtig meget på)). Men der bør ikke ske nogen skade ved at bytte rundt på sort/blå, i din situation. Til gengæld er jeg ikke helt sikker på, at den sorte er M (Lampe/Mellemledning), fordi der er 3 sorte ledninger i samlemuffen. Det er efter min mening atypisk for en installation, medmindre det er ført videre til to andre lampeudtag/huller i loftet. Ikke dermed sagt, at det ikke kan være M. Det er bare en lidt spøjs måde med 3 lampe/mellemledninger og eet udtag/hul i loftet. Hvis SORT er en fase, og du slutter den til din lampe sammen med den BLÅ på den anden klemme, så kan du ikke slukke lampen. Og andet sker der ikke ved det.

Jeg er på ingen måde nogen ørn til regler mm, men kommer det ikke an på hvornår boligen er bygget. I mine yngre dage (læs forrige årtusinde) lavede vi det da altid sådan. Jeg er af den "gamle skole". Og i min tid, der gjorde vi ikke noget ved en pl dåse, som sidder på den anden side af loftbrædderne. Men der kom altid et lampeudtag på, med længere skruer, så de kunne nå.

I know.. But that´s the main core openHAB system. Thats what I was asking for

Why this change?? Wouldn´t it be better to allow both options? Where to download just the binding (.jar)? I dont want to install/upgrade my openhab 2.4 (yet)

Okay,. great. The above is a UNI400 wired dimmer. Unfortunaltly it doesn´t have a "real" output state. Thats why I use the function blok. I know it´s a small risk, but it´s the best these kind of dimmers can do. And I have never seen it do out of sync, yet. Other devices I monitor the output state on the product side.

Nej det er jeg klar over (nu).

Hi @Pauli Anttila I tried the above. And it works fine.. However, I get a warning when I use direction="ReadOnly" for my light state. (the update still works though). This is my things file: ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="adminIHC0101", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: Type switch-channel :bryggers_dimmer_fb "Bryggers dimmer Trigger" [ resourceId=12059409, direction="WriteOnly", pulseWidth=200 ] Type switch-channel :bryggers_dimmer_state "Bryggers dimmer state" [ resourceId=12062482, direction="ReadOnly" ] } This is my item: Switch bryggers_DimmerLys "Bryggers Halogenlys [%s]" <light> [ "Lighting" ] { channel="ihc:controller:elko:bryggers_dimmer_fb", channel="ihc:controller:elko:bryggers_dimmer_state", autoupdate="false" } And this is the warning I get, when the item is triggering. 2019-03-11 23:48:54.603 [WARN ] [ding.ihc.internal.handler.IhcHandler] - Read only channel, skip the update to ihc:controller:elko:bryggers_dimmer_state This is the resourceID´s I use.

Det er præcis det en Rpi med fx openHab gør. Det er gateway imellem alt. I vores tilfælde er det IHC, med Philips Hue, Z-wave enheder, Zigbee, vores solcelleanlæg, Nilan ventilationsanlæg (modbus). En del logik ligger stadigvæk i IHC controlleren, fordi det er nemmest sådan. Men reelt set kunne jeg lade al logik blive styret fra openHab. Jeg kunne også installere KNX her, og lade det køre igennem openHab.

Jeg tror nu mere, det er fordi jeg opfatter ON som at dimmeren er tændt. Ligesom den er ON, når man bruger touch. Og ja, Fben kan selvfølgelig ikke vide det, når der ingen tilbagemelding er.

I´ll have to give it a try. Thats the least I can do

Ikke helt det samme. Som jeg skrev, Fbén indikere jo, at Dimmeren er ON. Det er i dette tilfælde ikke korrekt. Haha, ja, blame it on the electrician.. De er altid klaphatte I det her tilfælde er det nok nærmere dem der fik huset bygget, som ikke fik korrekt rådgivning om, hvad de kunne få af muligheder.. Måske fordi de ikke ville betale for det. Eller de fik rådgivningen, men stadigvæk ikke ville betale for det. Tror desværre det er en kombination af flere ting. Det siges huset har kostet over 5.5mill at bygge i 2007 priser). Så det er næppe de 4 stk ekstra output moduler til 14 UNI dimmere, som skulle have væltet budgettet. Så falder det tilbage på rådgivningen

Ahh okay, så misforstod jeg.

Møg dimmer.. Det er jo galt den skriver ON, uden at være det. æv!

Jeg er uenig i, at kabeltræk ikke har fremtid i installationerne. Faktisk vil jeg vove den påstand, at jo mere vi efterhånden smider over på trådløst, desto større problemer skaber vi for os selv, fordi trådløs simpelthen ikke er effektivt nok til alt. At alt derimod er software baseret, det kan jeg sagtens følge. Men jeg mener ikke det er KNX vejen fremtiden byder på. Tværtimod er det nok mere i retning af Velbus eller lign, som stadigvæk kræver kabeltræk, men hver enhed er en "controller" i sig selv, og det hele går op i en højere endnu i en "main-controller/server ligende opsætning" . https://www.velbus.eu/ Det er reelt sådan IHC er i dag, men enhederne er primært "døde" og langt fra smarte. Og det er det som jeg mener IHC har problemer med idag. Selve mulighederne i controlleren er jo helt i orden, efter min mening. Det er enormt fleksibelt. Men maskineriet er sløvt, og programmering komplet vanvittig. Kabeltræk er nødvendig for at bla at kunne modtaget inputs fra andre produkter. Derfor er input modulerne efter min mening enormt vigtige. Jeg vil nødig undvære dette. Problemet med IHC ligger på produkterne. Og så selvfølgelig controlleren og dens software. Men det er efter min mening en smal sag at ændre på det. Hvilket også gjorde det så vildt overraskende, at LK kom med HW7 controllerne for 1½ år siden, der praktisk talt ikke rigtig bød på noget nyt. Det er noget jeg nærmere vil betegne som en "svinestreg" og et udtryk for, at man reelt er pi** ligeglad med kunderne. Jeg nægter at tro på, at udviklerne hos LK/Schneider ikke kunne magte mere end det på 5-6 år. Egentlig kunne jeg godt acceptere, at LK fortsatte deres eget system, som de hele tiden har gjort. Der er som udgangspunkt ikke et behov for, at IHC skal kunne snakke sammen med andre systemer/andet. Men behovet opstår, LK netop ikke udvikler på et seriøst plan.

I do understand most part of it. What I´d fail to understand (misunderstood) is the puls sending ON and x=ms after sending OFF. This part it not noticable in the logfile, if it´s a switch channel, (ie a wired dimmer on the "touch" resourceID). Thats why I wrongly used a rule to trigger the item OFF. Yes, thats what I learned the hard way, which the 2.4 binding My original idea was to let openhab simulate all human aspect, (ie pushing buttons, which is why I focused on linking the buttons. But in many cases it seems more effective to link to the actual product itself (functionblok). However, this requires to create the channels manually, cause it requires channels options/paramters, like when linking to a wired dimmer. I can not used the auto created channel in that situation. This is okay, but I would have prefered to use the auto created channel, as it makes things alot easier.. However.. This example you just showed here, I believe it would be a problem tagging for Google Home controle.... How would you Tag that item? It´s both an ["Lighting"] and a ["Switchable"], cause you have both the trigger and the state in the same item? The above is almost like I have done it now, except, I had to use two items as well. One for triggering the "touch" resourceID of a wired UN400 dimmer. And the other resourceID for state of the UNi400 dimmer. Google Home Tag has to be set to the triggering item like this: Switch kitchenLightTrigger ["Lighting"] { channel="ihc:controller:elko:trigger" } And state like this: Switch kitchenLightState { channel="ihc:controller:elko:state" } I assume this is the correct way of doing it? (notice, without autoupdate="false")

Hmm, men FBén skriver jo, at dimmeren er ON, når jeg aktivere en af mem indstillingerne.. Det er det jeg synes er meget underligt. Og umiddelbart forstår jeg heller ikke hvorfor det ikke virker. Det er jo bare en puls, der aktivere dæmperen (i det niveau man nu engang har gemt). Og output modulet er jo "dødt" indtil udgangen trækker, eller hvad? Touch virker jo også fint nok fra serviceview. Men den er selvfølgelig også fortrådet. Ideen var at jeg ville prøve at bruge openhab til at aktivere dæmpere´s mem indstillinger ved at påvirke indgangene, altså uden at de er fortrådet til output. Men jeg kan godt se ideen går lidt af, hvis jeg alligevel skal fortråde dem til et output modul. Kan man på nogen måde snyde den?

Et nyt spørgsmål til UNI400 IHC/SA dimmeren. Jeg forsøger at gemme niveau på mem 1 og mem 2 via serviceview. Det fungere også fint. Serviceview skriver, at den gemmer. Men når jeg, igen via serviceview, aktivere mem1 eller mem2, så tænder lyset ikke. Serviceview skriver, at den tænder på mem1 eller 2, men lyset tænder ikke på de niveauer jeg har gemt. Er det normalt? Det virker fint på touch indgangen. Det er bare som om, at mem slet ikke virker.. Det skal lige siges, at mem klemmerne er ikke fortrådet. Jeg forsøger aktivere dem udelukkende via serviceview. Det burde da virke, eller?