Kandersen

Det er sgu da også nørdet at tænde sin computer fra et IHC tryk, i stedet for at bruge tænd/sluk knappen på computeren Spøg til side - Jeg kan sagtens se at en funktion som dette kan give mening i visse tilfælde.

Det er jo slet ikke LK´s mening at hun skal se dette. Det har vel aldrig været hverken via Visual, serviceview eller andet. Er det hele ikke primært tiltænkt netop elektrikerne? Ved at de nu har lavet det sådan, så kan "nørder" som os netop bruge informationer, før vi går i krig med at fejlrette i installationen. Fru Jensen forstår stadigvæk ikke et klap af det, medmindre du i din brugerflade til hende giver hende informationen, som hun så kan give videre, når hun rekvirerer en elektriker til at fejlfinde på hendes lys

De giver da mening i openHAB (eller lign) da det er meldinger man kan sende videre (modtage) såfremt der sker en fejl. Kan de ikke også bruges i Sceneviewer? (eller hvad den nu hedder).

For at kunne bruge PIR til den automatisering, så er du nødt til at have den ind over et input relæ. Ellers ved controlleren ikke hvad PIR laver. At du mister kontrollen (håber du mener forbindelsen) til din kombidimmer må være et andet problem. Selv programmeringen burde være lige til, men jeg har ikke selv erfaringer med at bruge ur, så den del overlader jeg til andre mere kompetente folk, fx Henning, der sikkert kan det her med bind for øjnene.

Could you please be a bit more specific? As far as I recall, the magnetic contacts are auto discovered. So they should be available as a thing inside openhab -> PaperUI -> Configuration -> Things -> Your IHC controller. From there you just link it to an item.

Det kan du reelt også, men det vil ikke være den bedste og mest fleksible måde. Meningen med IHC er jo netop det skal være fleksibelt. Så hvis du lader en PIR styre direkte på fx en kombidæmper, så mener jeg du dermed har udelukket for at bruge PIR i andre tilfælde.. Du kan i realiteten lige så godt lade den gå helt uden om kombidæmperen, og bare lade den styre lyset direkte. Så er det helt uden om alt IHC.

Det gjorde de også med de gamle dæmpere, selvom de sagtens kan trække flere. Jeg tror det er noget med "en vis garanti". At dæmperen sagtens kan trække flere, men LK vil ikke sige god for mere end max 10.

Linkning og parring er i dette tilfælde det samme. Som jeg forsøgte at forklare, så kommer det til at virke såen wireless/trådløs agtig, ligesom man parre bluetooth. Men her er der jo tale om en fortrådet enhed. Derfor bliver det, i min verden, lidt skævt at bruge sådan et begreb.

Jeg tror ikke de magter det bedre. Plus at man nok ikke ønsker at smide mange flere penge i det. Det høres også mellem linjerne, når de praktisk talt intet nyt har at komme med. Webinar i dag, er en information til deres kunder (elektrikerne) om, at IHC kan også andet. Men de vil ikke selv bruge mere krudt på det, end det webinar (og måske kommende), fordi det er forholdsvis udgiftsfrit, men omvendt kan højne salget af deres komponenter. Og også på det område synes jeg det er en skam, at dit fantastiske værktøj, som jeg selv har brugt meget, slet ikke bliver nævnt, når de alligevel er ude og snakke om 3.part. Jeg tvivler kraftigt på de selv kommer til at bidrage. Jeg vil tro Søren gør det, som privat person i HA gruppen. Men ellers kommer vi ikke til at se LK der ligefrem bidrager med andet end information, som dette webinar. Og det er måske også godt det samme, for det kan de i det mindste ikke fuc** up! Du er ikke alene med den tanke.. Siden jeg fik fingre i Velbus for snart et år siden, der har det knaget i knolden på mig, om jeg skulle rive hele IHC installationen ned og smide Velbus ind i stedet. Desværre ryger jeg ind i problemer med dåserne, da Velbus bruger EU dåser, og hele vores hus er klistret til med Fuga Jeg synes stadigvæk IHC er godt og enormt fleksibelt. Men udviklingen er for langsom (eller helt manglende), plus der er nogle ting som jeg helt klart mener burde være betydelig bedre for længe siden. At sende en ny controller ud for 2 år siden, og en ny tavle LED dæmper 2½ år efter (måske) som det eneste, hvoraf controlleren i bund og grund ikke rigtig bidrager til noget særligt nyt.. Det er simpelthen for langsomt og for ringe for et firma af den kaliber. Jeg tror bare ikke længere på, at der sker mere på IHC fronten, andet end alm vedligeholdelse.

LK´s Webinar i dag.. Kommentar! Jeg synes egentlig det er okay.. Jeg tror bare vi var mange "rigtige" nørder som synes niveauet var lidt for lavt. Men jeg må rose LK for at vove at tage dette spring på den måde. Selvfølgelig spejler de sig i det på andres bekostning. Men det er en naturlig udvikling, når ikke de selv vil stå for det hele. Det er også okay, at de har valgt HA, selvom jeg ikke er den store tilhænger af det system. Jeg er nok indgroet Openhab2 mand :-) Men jeg kunne måske godt have tænkt mig, at de havde lagt lidt mere fokus på, hvad man så kan bruge det til, fremfor den sparsomme HomeKit løsning. Hele integrationen åbner jo op for et hav af muligheder. Og som der var flere der var inde på, så havde det være smart, hvis de var gået lidt mere i dybden og fx vist integration med varmestyring, ventilation og vinduer, fordi det derved havde passet perfekt ind i deres eget koncept, og de som allerede bygger IHC installationer i dag kan forstå den rigtige sammenhæng. Og så er jeg lidt ked af, at de ikke på lige fod nævnte Google Assistant integrationen. Der er desværre for meget fokus på Homekit og Siri, selvom Google Assistant faktisk alle vegne betegnes som den absolut bedste af de to. Jeg bemærkede de nævnte Claus (Zigza) som værende potentiel frontløber for en wireless temperatursensor.. Se at komme i gang Claus :-) Nåja, så savnede jeg sgu noget kredit til @Mikkel Skovgaard for hans IHC Captain. Den integration (og i det hele taget Mikkels arbejde), fortjener langt mere fokus! 45 minutter er nok bare ikke nok til at være rigtig nørdet!

Er nødt til at se lidt mere af din opsætning en dette.. things og items. Bemærk i øvrig om der overhovedet sker noget i loggen

Jeg tror ikke de har noget nyt, andet end "integration" med andet. Og jeg tvivler stærkt på vi ser noget særligt nyt fremover. Jeg har ihvertfald svært ved at se hvad det skulle være, når man satser på denne "integration", som jo i sig selv åbner helt andre døre, som ikke nødvendigvis har noget direkte med LK at gøre. En lille sidenote jeg glemte at nævne - Jeg synes det er voldsomt foruroligende at LK nu officielt har meldt ud, at både HW6.1 og 6.2 er færdige, hvilket bla betyder, at der ingen mulighed for den nye lysdæmper den vej. Det må potentielt være ret mange forbrugere der sidder med håret i postkassen, da HW6.2 hvis ikke den stadigvæk er til salg rundt omkring, så har kunnet købes indtil fornyligt.

Synes det er okay nede på jorden. Men savner lidt "gå-på-mod" mht til spørgsmål der hvor ihc (LK) virkelig har seriøse problemer. Fx holder LK tilsyneladende fast i, at Visual HW 6.1 skal bruge .220 firmwaren. Desværre forholder de sig ikke til, hvad man så gør, hvis man har investeret i deres IHCremote (til apple) eller IHCtablet. Alle ved den kombination ikke fungere. Og nu vi er ved det. Hvorfor pokker skal disse to app være så sindsyg dyre? 13.40 inde.. "java er kommet, ihvertfald på IHCén". Hmm Java har snart eksisteret i en menneskealder. Og selvom det til dels er okay at bruge, så synes jeg de skøjter hen over det, som om det aldrig har været eller aldrig vil blive et problem. 14.40 "På sigt får vi også åbnet for vores open API". I sammenhæng med integration med andre systemer, så burde dette punkt ikke være "på sigt". Det er nu og her det er nødvendigt. 16:30 - Det sagde han bare ikke... Et af de helt store emner i flere år har netop været IHC varmesystem, der faktisk er ganske god. Men der mangler simpelthen rumfølere med mulighed for display og indstilling.. Hvad gør folk med en Visual HW 6.1 firmware .220 og varmestyringen? Men selvfølgelig, med integration med andre systemer, så er dette ikke længere aktuelt fra LK´s side.. Jeg synes bare det er møg ærgerligt, at et system som IHC ikke laves komplet på netop dette punkt. 24.00 inde. En privat ønsker kursus. Ikke en mulighed LK har. De henvender sig til det proff. marked. Hvordan det så hænger sammen med deres kommende "gateway" som kører på HA, det er mig lidt en gåde, og virker reelt ret selvmodsigende. HA er netop det private marked. (og så er det i øvrig open source). Jeg har al mulig respekt for, at LK endelig træder ud af deres egen lille boble, men her vælter de altså hårdt ned imellem to stole. Det skal blive spændende at se på torsdag (i morgen).

Jeg går ud fra du bruger openhab 2.4 så? Pt er det bedste nok at få fat i seneste version af bindingen. At opdatere til 2.5 er lige nu ikke et godt tidspunkt, selvom der kom en RC1 tidligere i dag. Den er vist ikke helt stabil alligevel. Og 2.5M6 er endnu værre. Jeg kører selv med 2.5M2, lidt endnu.

Jeg er først med på torsdag. Men vil også meget gerne høre mere om det i dag.

Jeg troede du brugte den seneste version af bindingen eller openhab 2.5

Thanks Pauli.. But he is already using hostname. This is his config file.. ihc:controller:1 [ hostname="192.168.1.10", username="jakob", password="xxxx", timeout=5000, loadProjectFile=true, createChannelsAutomatically=true ] I do worry about the bridge definition ihc:controller:1 as I believe the 1 (number) could be an issue.. Am I right? (I havnt´tried this myself, as I always use letters).

Jeg ved det kun fra openhab, da der er nogel stykke at vælge imellem. Jeg har prøvet tre af dem, men GoogleTTS er helt klart bedst.

Jeg ved ikke lige om det er det, men der er flere steder i openhab, man ikke må bruge tal som det første eller i det hele taget i typer.. (fx i items). Jeg kan se du bruger ihc:controller:1 Måske du skulle prøve at lave den om til noget der ikke er tal efter det sidste kolon. Jeg kunne personligt ikke finde på at bruge tal, men jeg kan godt se det kunne give mening, hvis man havde flere controllere.

Og derfor er der brug for dig og IHC Captain. Hmm jeg har da ikke mødt en udbyder endnu som ikke ville lade mig bruge det. Men det er korrekt, man skal registreres og have en "token".

Ups.. Glemte lige en vigtig detalje til ovenstående.. Der er flere "read-only" i min things fil, som i realiteten er linket til et input i funktionsblokken (eller tryk). Disse er read-only af sikkerhedsmæssige hensyn, da jeg oprindelig IKKE ønskede at openhab skulle kunne aktivere/deaktivere alarmen eller andet, mens jeg stadigvæk ville have status med over i openhab.. Derfor kan man bruge read-only. Hvis man ønsker at openhab skal kunne styre disse input funktioner (eller tryk), så skal read-only fjernes i things filen. (IHC bindingen har read-write som default).

Helt enig, openhab er en tidsrøver.. Men hvis man kan begrænse sig til IHC, så tror jeg man kommer hurtigt ind i det.. Mit problem er det sædvanlige - jeg evner ikke at begrænse mig selv Min dørklokken er pt noget bras af en fridhof (mener jeg den hedder) som desværre er trådløs. Og jeg kan ikke umiddelbart få et kabel igennem til trykket, fordi tosserne som har bygget huset ikke lige synes de gad spendere få kroner på en fortrådet dørklokken. Så jeg er igang med nogle massive cowboy tricks med en 433mhz modtager. Faktisk har jeg lige fået en simpel DVB-T modtager hjem som er rtl-sdr kompatible. Med den kan jeg aflæse alle frekvenser fra 200mhz og op til 2Ghz.. Det bliver et ret vildt openhab project. Der er ingen tvivl om, at hvis man har flere tryk til dørklokken i huset, så skal man selvfølgelig kunne adskille disse fra hinanden.. Intet mindre

En lille hjælp til opsætningen af alarm i openhab for @Sorensen1212 og andre som måtte have interesse. Her er min things fil ang alarm. Helt til højre har jeg angivet farverne i parrentes som skal holdes op imod det billede af visual som jeg vedhæfter. Der hvor samme farve er i begge sider, er det fordi det er valgfrit. Der hvor der er to farver ud fra samme funktion, er fordi jeg var en klovn at linke til den samme to gange.. Men det skader ikke :-) Håber du kan bruge det og giver mening, ellers så skyd løs. // Alarm Type switch :alarm_sabotagekreds "Alarm sabotagekreds" [ resourceId=3139345, direction="ReadOnly" ] (LILLA) Type switch :alarm_status "Alarm status" [ resourceId=3142418, direction="ReadOnly" ] (BLÅ) Type switch :alarm_total "Alarm tilkoblet" [ resourceId=3144722, direction="ReadOnly" ] (LYSBLÅ) Type switch :alarm_totalFra "Alarm frakoblet" [ resourceId=3138065, pulseWidth=300 ] (GRØN) Type switch :alarmLedArmOk "Tilkoble Alarm Ok" [ resourceId=3455067, direction="ReadOnly" ] (GUL) Type switch :alarmLedArmed "Total Alarm tilkoblet" [ resourceId=3455323, direction="ReadOnly" ] (ORANGE) Type switch :alarmLedIndikering "Alarm indikering" [ resourceId=3455579, direction="ReadOnly" ] (RØD) Type switch :alarmLedSabokredAaben "Sabotagekreds aaben" [ resourceId=3455835, direction="ReadOnly" ] (BRUN) Type switch :alarmMagnetKredsAaben "Magnetkreds aaben" [ resourceId=3142930, direction="ReadOnly" ] (LYS LILLA) Type switch :alarmMagnetkredstilkobl "Magnetkreds tilkoblet" [ resourceId=3144978, direction="ReadOnly" ] (LYS BLÅ) Type string :alarmStartetVia "Alarm startet via" [ resourceId=3145743, direction="ReadOnly" ] (LYS GRØN) Type datetime :alarmStartetTid "Alarm startet tid" [ resourceId=3145997, direction="ReadOnly" ] (LYS ORANGE) Type datetime :alarmStartet "Alarm startet dato" [ resourceId=3146254, direction="ReadOnly" ] (ROSA) Mine items.. // IHC Alarm status Switch alarm_sabotagekreds "IHC Sabotagekreds [%s]" <light> (alarm) { channel="ihc:controller:elko:alarm_sabotagekreds" } Switch alarm_status "IHC Alarm status (Grøn=klar. Rød=ikke klar.) [%s]" <switch> (alarm) { channel="ihc:controller:elko:alarm_status" } Switch alarm_totalalarm "IHC Total Alarm tilkoblet [%s]" <light> (alarm) { channel="ihc:controller:elko:alarm_total" } Switch alarmLedArmOk "Tilkoble Alarm Ok [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmLedArmOk" } Switch alarmLedArmed "Total Alarm tilkoblet (Grøn=klar. Rød=ikke klar.) [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmLedArmed" } Switch alarmLedIndikering "Alarm indikering [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmLedIndikering" } Switch alarmLedSabokredAaben "Sabotagekreds aaben [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmLedSabokredAaben" } Switch alarmMagnetKredsAaben "Magnetkreds Åben [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmMagnetKredsAaben" } Switch alarmMagnetkredstilkobl "Magnetkreds tilkoblet [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmMagnetkredstilkobl" } String alarmStartetVia "Alarm Startet via [%s]" <light> (alarm) { channel="ihc:controller:elko:alarmStartetVia" } DateTime alarmStartetTid "Alarm Startet tid [%1$tH:%1$tM:%1$tS]" <time> (alarm) { channel="ihc:controller:elko:alarmStartetTid" } DateTime alarmStartetDate "Alarm Startet d. [%1$td.%1$tm]" <calendar> (alarm) { channel="ihc:controller:elko:alarmStartet" } Og til sidst mit sitemap: Frame label="Alarm" { Text item=alarm_status Text item=none Text item=alarm_totalalarm Text item=alarm_sabotagekreds Text item=alarmLedArmOk Text item=alarmLedArmed Text item=alarmLedIndikering Text item=alarmLedSabokredAaben Text item=alarmMagnetKredsAaben Text item=alarmMagnetkredstilkobl Text item=alarmStartetDate Text item=alarmStartetTid Text item=alarmStartetVia }

Synes måske også det er overkill at bruge en sonos til det. Men funktionen med at sende en lydfil er skam helt perfekt, og kan have mange formål, (fx ringeklokke funktion). Personligt er jeg dog til lidt mere avanceret brug. Jeg bruger GoogleTTS (Text-to Speech) i openhab. Dvs jeg kan lave en hvilken som helst text og sende til en hvilken som helst trådløs højtaler, (forudsat at openhab kender den) som så lyder som om Google taler.. Fx har jeg en regel som sender en besked, "Der er nogen ved døren", når PIR ude foran døren registrere bevægelse. Denne TTS kan jeg så sende til en hvilken som helst højtaler jeg vil, fx en home i et rum, hvor jeg ved der er mindst en person i, (pga andre bevægelsessensorer). Eller jeg kan sende beskeden til alle eller bare en gruppe af højtalere. (Jeg sender den også som push til min mobil, hvis jeg ikke er hjemme). Text-to Speech, når det vel at mærke lyder ordentligt, er en sindsyg genial ide, efter min mening.. Det eneste er bare, at det kræver man forud definere teksten.. Desværre er enhederne ikke så intelligente endnu, så de selv kan regne ud, hvilken TTS man vil høre At afspille en lydfil er lidt ala det samme princip, bare i en noget mindre fleksibel udgave, da man i stedet for at angive tekst skal sidde og optage/selv indtale. Jeg er kæmpe fortaler for sådanne funktioner.. TTS og voice respons har i min verden bestemt ikke levet forgæves, tværtimod åbner det op for så meget spændende funktioner og potentiale, at man nærmest aldrig bliver færdig. Og jeg har ventet på det i snart en menneske alder på det.. Det er det eneste som giver rigtig god mening, når det skal være virkelig smart og effektivt. Det geniale er netop, når man kan købe små billige højtalere, (Google Nest Mini fx) som faktisk kan agere på alle måder. Dvs reagere på voice, samt at man kan sende TTS/lyd til dem, ud fra simple triggere... Og så placere dem rundt omkring i huset.. (jaja, Googler lytter med.. Fair nok, hvis de der lytter synes jeg er skide interessant.. Jeg glæder mig til den dag det er millarder af mennesker de skal forsøge at lytte til :-) ).

Tak Henning, du er en knag Nu kan jeg give dem et ordentlig navn. Underligt de (LK) ikke selv har tænkt det i sin tid.. EDIT - Er det bare den linie 7 (locked) som rettes fra yes til no ? (mere så jeg ved det til en anden gang)