Kandersen

Mja. Altså jeg vil sige, jeg har jo ikke gjort tingene nemmere for mig selv/controlleren og IHC komponenter, med alt det jeg efterhånden har koblet til af 3 part. Så en evt fejlsøgning her, det bliver endnu mere udfordret. Jeg tror min oplevelse måske har været en kombination af flere ting. Men jeg har ikke boret så meget mere i det, da det er den eneste "oplevelse" jeg endnu har haft. Sker det igen eller oftere, så er det må jeg i gang med en større udredning. Jeg undrede blot over, det udtag pludselig begyndte at te sig på den måde, når de 3 andre (som fysisk er placeret ved siden af), ingen problemer havde.

Forleden prøvede jeg også med et ø80mm lampeudtag, at jeg kunne tænde på tryk, men det var forkert niveau den tændte LED lyset på. Jeg kunne ikke dæmpe op/ned. Men jeg kunne slukke igen. Efter flere forsøg, så gjorde den pludselig som den skulle, og det har virket lige siden. Lampeudtaget havde kørt uden problemer i et par måneder, indtil problemet forleden.

Så er det fordi han har en gammel version liggende til download. Hentede den forleden af fra hjemmesiden da jeg skulle teste den, og det er den jeg har problemer med

Hmm I thought all installations modes was the same.

Jeg kaster mig nok også i krig med HA inden længe, mest af alt bare fordi man kan, som så gør mig nysgerrig. Openhab virker sådan set okay. Den største udfordring jeg har med OpenHab, det er et ordentligt UI. Jeg kan simpelthen ikke skabe et ordentlig UI på min tablet, som er til at holde ud at se på. I Habpanel er skaleringen helt hen i vejret. Og det irriterer mig at man skal være html/css guru for at skabe noget der bare er nogenlunde ordentligt. Så er det muligt jeg sadler lidt om, så Openhab eller andet HAS (Home Automation System) primært bliver brugt som overvågning/rapportering med et begrænset omfang af muligheder for at styre noget, udover varmestyringen. Det forudsætter dog, at jeg kan skabe et ordentligt UI på en tablet. Udvendig PIR projekt bliver gennemført på den en eller anden måde. Muligvis også med video overvågning i et vist omfang og dermed "optisk skal-sikring". Indvendig pir/motion sensor er stadigvæk på tegnebrættet. Jeg er dog så småt i gang med det med foreløbig to rum med pir overvågning i. Det har dog været af praktiske årsager, og derfor nok ikke den endelige løsning. Det ene rum bruger jeg alarm pirén til at tænde lyset med, når skumring er on. Det virker men er ikke optimalt. Mit næste lille projekt (hængeparti) er at anskaffe to stk zwave garageport overvågnings sensore. https://detintelligentehjem.dk/z-wave-vision-garage-port-detektor.html 2 stk fordi jeg vil have styr på, hvor porten befinder sig, hvis den ikke er åben eller lukket. Faktisk overvejer jeg flere end 2, da det giver mig en endnu mere præcis indikation, men jeg starter lige med 2. Til den pris, så kan jeg simpelthen slet ikke lade være med at prøve det. Og så skal jeg seriøst i gang med at se mere dybt på rules, bla for at sætte forskellige kriterier for, hvornår noget skal rapporteres og hvornår det ikke skal. Fx om alarmen er koblet til/fra, er jeg hjemme, er nogen hjemme, hvad er klokken, er klokken mange og al lyset slukket, så betyder det nok familien snork sover.. osv osv. Der er ufattelig mange kriterier og muligheder, når man først begynder at gå i dybden med dette. Og det er i virkeligheden det der er mest interessant og styrken i sådan et system, efter min mening

Hmm.. Jeg tror du skal tage eet skridt ad gangen. 1. Find den pokkers event log.. Den gør det meget nemmere at følge med i. (Den SKAL ligge på port 9001, jeg har fundet den i dokumentationen for setup. Connect to the openHAB Log Viewer (frontail): http://openhabianpi:9001 2. Lav din items for dit tryk, og intet andet. dvs een items fil med kun een linje i. 3. Test dit tryk og hold øje med event loggen. Når dit tryk bliver registreret, så kan du/vi gå videre. Selvom det er en atypisk situation du vil teste med, så er det stadigvæk banalt og grundlæggende. Det SKAL virke.

Jeg tog et billede af ledningerne som jeg havde liggende ved siden af, da jeg skiftede controller. Samtidig havde jeg en liste over alle datalinjerne, så jeg kunne følge ledningerne op, hvis jeg være den mindste smule i tvivl. Jeg endte med at afmontere den øverste del først, tage controlleren ned af DIn skinnen, opsætte den nye controller, mens den gamle var hængt op ved siden af. Så var det kun oversiden jeg skulle være urolig for

Edit..Sorry!

Har helt glemt denne her, LarsC. Beklager jeg. Her er en items. Jeg har lavet items til samtlige rum i huset. Dette er items fra vores store badeværelse. De første tre linjer (under den linje der starter med //Stort Bad) er til temperatur/fugt føler og setpunkt. De næste fire linjer er tryk på et 4tast tryk. Den sidste linje er en Uni400 lysdæmper. Den kan tændes og slukkes men ikke dæmpes via OpenHab, da OpenHab ikke fatter kort/langt tryk. Håber det kan bruges. //Stort Bad Number stort_bad_Temperature "Temperature [%.1f °C]" <cu_heating> ["TargetTemperature"] {ihc="13699860"} Number stort_bad_Tempsetpunkt "Temperature setpunkt" <temperature> {ihc="7989780"} Number stort_bad_fugt "Fugtighed [%.1f %]" <Humidity> ["TargetHumidity"] {ihc="13699623"} Switch stort_bad_OEV "Tryk øverste højre" <light> ["lighting"] {ihc=">[ON:20058:100]", autoupdate="false"} Switch stort_bad_OEH "Tryk øverste venstre" <light> ["lighting"] {ihc=">[ON:20314:100]", autoupdate="false"} Switch stort_bad_NV "Tryk nederste venstre" <light> ["lighting"] {ihc=">[ON:20570:100]", autoupdate="false"} Switch stort_bad_NH "Tryk nederste højre" <light> ["lighting"] {ihc=">[ON:20570:100]", autoupdate="false"} Switch stort_bad_halogenlys "Dimmer status" <light> ["lighting"] {ihc="5540626", autoupdate="false"}

Har den ikke eksisteret længe? Jeg synes jeg har set den før. Og nej, den er ikke specielt køn. Hvad går den brede kant ud på med riller i, helt ude til højre på billedet?

Du kan læse meget mere om rules her. http://docs.openhab.org/configuration/rules-dsl.html Bemærk dog, der er ingen "and" mulighed (hvilket faktisk undre mig en hel del). Jeg tror det er fordi "and" er en selvfølge hvis du har flere kommandoer. Fx: rule "lys ON" when Item kokken_t10_nh changed from OFF to ON item kokken_lys_bord = OFF then kokken_lys_bord.sendCommand(ON) end Men jeg er ikke sikkert. Rules er efter min mening een af de ting der er rigtig dårligt og rodet beskrevet. Det er et af de steder hvor man virkelig mærker, at det her er lavet af nørder for nørder. Der er også en rules i PaperUI. Den er godt nok skrabet og i en såkaldt beta version, (den skal installeres manuelt også i PaperUI). Jeg har kun prøvet den ganske kort for længe siden. Den benytter sig af "When", "then" og "but only if". I mit første forsøg for flere måneder siden, der måtte jeg opgive den. Har ikke kigget så meget på den siden.

Men at han ligefrem taber linket til hans wireless enheder og de skal linkes igen, det er vel ret atypisk? Det som jeg har forstået omkring støj, det er "blot" at man ikke kan få kontakt til nogle wireless enheder i perioder. Men synes ikke jeg har læst, at de skal linkes påny.

Lk skriver også, at HW 6.1 ikke understøtter IOS 11, (dvs firmware 2.8.4). Lk skriver også, at de vil komme med spændende nyt i forbindelse med Visual 3. I det hele taget siger/skriver LK meget. Det er bare rigtig meget af det, de ikke har specielt godt held med. Så at følge LK´s råd.. tja, spil lotto i stedet, det er mere sikkert

Har du kigget på blokken? Den gør præcis det som du beskrev i første indlæg. Du skriver godt nok en puls indgang nu, men du kan da ikke tænde lyset på den måde med en indgang, som du beskrev i første indlæg. I den blok jeg vedhæftede, der er puls udgang for alarm til og fra koblet, samt scenarier for samme. Se vedhæftet, hvor jeg bruger den i begge tilfælde med scenarier (til/frakoblet alarmen).

Ja, hvis du bruger den rule som jeg har skrevet til det formål, så gør den faktisk som du ber den om Tryk på trykket = ON Slip trykket = OFF I rulen er det defineret at den skal sætte lyset ON og OFF ved trykket.. Altså tænder lyset når du trykker knappen ind, og slukker når du slipper. Ikke lige velegnet til dit formål. Men igen, det giver slet ingen mening at tænde lyset på et IHC tryk og går via OpenHab for at tænde noget IHC lys. Hvis du skal gøre det, så skal du have OpenHab til at forstå, at det er en push button. Men du kan ikke definere en push button i items filen. (En massiv hage ved Openhab hvilket har givet rigtig mange mennesker grå hår i hovedet, inkl mig). Det du skal, det er at aktivere touch input på funktionsblokken ligesom du ville gøre direkte i IHC controlleren. Men i stedet for at trække trykket over på touch på funktionsblokken i IHC, så linker du i stedet denne touch som en item i OpenHab. Husk at fjerne trykket i IHC programmet. Så har du to items igen: 1. item fra dit tryk 2. item fra touch på din funktionsblok. Og så burde du kunne gøre det med den samme rule, (bare husk at skifte items til det rigtige), fordi touch på din funktionsblok blot skal have en puls. Og rulen i OpenHab laver i realiteten bare en puls fra dit tryk (ON=ON/OFF=OFF = Puls). Jeg har ikke prøvet det, da jeg ikke ville gøre det sådan, hvis det var mit valg. Men nu lyder du ret insisterende Til gengæld fik det mig lige trigget i mine uendelige forsøg på at lave langt/kort tryk.. Jeg har faktisk ikke forsøgt det på denne måde, kommer jeg lige til at tænke på.. Hvis det virker, så har løsningen ligget lige til højre benet, og jeg har snork sovet i timen

Der tror jeg heller ikke jeg ville opdatere den.

Fedt det virker. Men jeg forstår ikke hvorfor du overhovedet har det problem, den er jo nærmest identisk med mine. Og de virker 100%. Een ting er dog sikkert. Ovenstående items er ikke korrekt. du har en [ for meget " [[lighting]" i den linje. Stop lige op og pust ud et øjeblik mens du får lidt ilt til hjernen. Dine punkter skal du vist lige tænke lidt mere over. Hvad er det præcis du gerne vil? Nu har du bevist at din IHC controller kan kommunikere med din OpenHab2 server. Så er det nu du skal tænke over, hvad det så er du vil bruge det til. Som jeg nævnte tidligere, så giver det ingen mening at bede OpenHab2 gøre noget, som IHC controlleren gør mindst lige så godt. Når jeg læser dine punkter herover, så virker det som om du i gang med at gå over åen efter vand. Det kan jeg absolut kun fraråde. Selvom det er muligt, så giver det som sagt ingen mening. Udover det er det en masse unødig arbejde og kommunikation du skal lave i OpenHab2 og IHC controlleren. Så: (lidt lang og måske kedeligt forsøg på pædagogisk forklaring, som jeg ville gøre det og har opfattelsen af, at man bruger en enhed som OpenHab bedst til samme med IHC). Defintion logik: Logik i IHC controlleren = Funktionsblokke Logik i OpenHab = Rules/automatik. A. IHC tryk eller hændelser der skal styre andre IHC komponenter - Hold logikken i IHC controlleren. B. Openhab tryk/komponenter/hændelser (things/items) der skal styre IHC komponenter - Hold logikken i IHC controlleren. C. IHC tryk eller hændelser der skal styre andre (OpenHab) komponenter (things/items) - Hold logikken i Openhab. D. OpenHab komponenter (things/items) der skal styre andre OpenHab komponenter (things/items). Hold logikken i OpenHab. Du skal opfatte OpenHab som et binde-led mellem flere "ting", hvor IHC controlleren er en "ting". Det der adskiller IHC controlleren fra mange andre "ting" er, at den har logik styring og automatik i sig selv, ligesom fx en Philips Hue også har. Det betyder ikke at man SKAL bruge denne logik styring/automatik, men det giver nogle andre muligheder i forbindelse med påvirkninger ud og ind. Og det kan i netop IHC´s tilfælde være en væsentlig fordel at holde logikken i IHC controlleren. Et eksempel på to "ting", der arbejder sammen via OpenHab. 1. ting - IHC controlleren 2. ting - en Zwave PIR. Målet er at bruge zwave PIR til at skabe en hændelse i IHC, fx tænde et (IHC) lys i en bestemt tid. I IHC har mit udvendige lys. Det er dette jeg vil tænde på zwave PIR. Jeg opretter en funktionsblok til PIR styring i IHC, hvor logikken er i, og udgangen til mit udvendige lys også er forbundet. PIR indgangen på denne funktionsblok oprettes som en "item" i OpenHab: item ihc_pir_indgang Zwave PIRén oprettes ligeledes som en "item" i OpenHab. item: zwave_pir Nu kender OpenHab de to "ting" som der skal påvirkes. Nu skal jeg bare kæde dem sammen som var mit mål. Dvs når zwave pir går ON, så skal pir indgangen i IHC funktionsblokken også gå ON. Og når den går OFF, så skal PIR indgangen også gå OFF. Og det gør jeg via en simpel rule som er lig med den jeg sendte tidligere: rule "zwave pir ON" when Item zwave_pir changed from OFF to ON then ihc_pir_indgang.sendCommand(ON) end rule "zwave pir OFF" when Item zwave_pir changed from ON to OFF then ihc_pir_indgang.sendCommand(OFF) end Jeg kunne godt have lavet al logikken i OpenHab, og så sendt en kommando direkte til lys udgangen på IHC controlleren. Men det er her det snedige med IHC controlleren kommer ind. For funktionsblokken i IHC har jo allerede givet mig den logik styring/automatik, som jeg ellers skulle lave i OpenHab. Så hvorfor pokker skulle jeg så ikke bare udnytte det. Egentlig tror jeg også at ovenstående kunne gøres uden en rule, ved at linke de to items direkte sammen. Men jeg har ikke forsøgt det, plus at det ikke giver mig en garanti for, at når den ene er OFF så skal den anden også være OFF, og omvendt. Men jeg vil tro det kan lade sig gøre. Årsagen til at det er så simpelt, det er fordi det bare er en simpel slave funktion. ON=ON / OFF=OFF. I OpenHab kunne man godt have udvidet det til at indholde flere andre hændelser og eller forudsætninger, fx at ovenstående rule kun skal køre, hvis jeg er hjemme (OpenHab kender min mobil/tilstedeværelse). Så ville jeg skulle tilføje en 3. ting, item min_mobil, og så lade den indgå som en forudsætningen i rule i OpenHab, som jeg mener skal gøres med en AND funktion. (har ikke studeret den del så meget endnu, men det kommer jeg snart til). Så: Brug logikstyring/automatikken, der hvor det giver mest mening, nemmest og bedst egnet. Dvs du skal ikke lade et IHC tryk gå ind over OpenHab, for at tænde et IHC lys (uanset om det er wireless eller ON/OFF). Men det kan være en ide at definere dem alle som items i OpenHab, fordi så har du muligheden for at fx lade et andet tryk (zwave tryk) tænde det IHC lys, og et IHC tryk tænde fx en Philips Hue pære. Håber det giver bedre mening og forståelse. Det er meget banalt eksempel jeg stiller op her. Men når man først fanger ideen, så åbner der sig pludselig en helt anden verden, hvor der nærmest ikke er nogen grænser for, hvordan du kan kæde tingene sammen, kombinere dem og bruge det hele på kryds og tværs, og udnytter de enkelt "ting", der hvor de har deres styrke. I Philips Hue, som jeg også har, der har jeg defineret scener. (dvs i selve Hue brigden). Jeg bruger så IHC Captain til at aftaste IHC tryk. Så når jeg trykker på et bestemt IHC tryk, så tænder lamperne i stuen med en bestemt scene, (dvs farve og lysstyrke). Igen, jeg kunne godt definere scenen i OpenHab, (dvs sætte lamperne op i OpenHab via en rule). Men hvorfor gøre det, når nu Philips Hue giver mig en mulighed for at gøre det på en lidt nemmere måde, og jeg så kan bruge IHC Captain til at "kalde scenen". På et tidspunkt vil jeg måske ændre dette, så OpenHab overtager denne del af logikken. Men pt synes jeg det er nemmere i Philips Hue appen og IHC Captain. Så det handler altså også om, hvor man selv synes det er nemmest. Og så udnytte den del. En sidste lille detalje som jeg var lige ved at glemme: OpenHab har også UI (user Interface. BasicUI, ClassicUI eller Habpanel). Og nu bliver det først rigtig "sjovt". Det betyder at du direkte i OpenHab UI kan lave virtuelle items, som du kan bruge til at påvirke udaftil. Fx et virtuelt tryk i BasicUIl, som tænder dit IHC lys. BasicUI kan du så gå til via din PC, mobil eller lign. Dine virtuelle items kan du også kombinere i rules på kryds og tværs. Fx hvis du har defineret et virtuelt tryk i BasciUI som skal tænde dit IHC lys, så kan du i en rule sige, at det kun må lade sig gøre, hvis klokken er noget bestemt, eller skumring er ON, vinden blæser fra nord, solen er gået ned, konen har gjort sig sengeklar osv osv. Er det fx skumring, og du allerede har et skumringsrelæ på din IHC, så kan det igen give mening at bruge logikken i IHC controlleren. Dvs du definere skumringsrelæet som en item i OpenHab. Og vupti - så er du i samme princip som ovenstående eksempel. Min opfattelse er, at hvis man holder tungen lige i munden og tænker over hvad mål man har med fokus på, hvor ens "ting" har hver deres styrke, så kan man virkelig drive det her vidt. Man kan også skære igennem og køre et fuldt ud OpenHab setup, hvor man er ligeglade med alle "tingéne" og deres styrke, og laver alt i OpenHab. Min opfattelse er bare, at det er ikke noget man bare lige såen gør fra den ene dag til den anden. Plus at OpenHab på desværre mange punkter har en rigtig dårlig dokumentation og decideret manglende. Derfor er jeg startet ud med det basale og forsøger hakke mig igennem de udfordringer som OpenHab giver mig. Jeg har endnu ikke knækket nødden med kort/lang tryk. Min foreløbige opfattelse er, at det ikke kan lade sig gøre i OpenHab. Det giver desværre visse begrænsninger fx i forbindelse med fortrådet lysdæmpere Nok om det.. du har en spændende tid foran dig PS - Bemærk at når jeg skriver "ting" så er det med "". Det er fordi det hedder "Thing" i OpenHab. "Thing" har "items". "items" er dem der er interessante og som du bruger til at lave din styring/automatik. Fx min zwave PIR er en "Ting" med 6 forskellige "items" i sig. Motion PIR. Alarm, rystekontakt, lux, temperatur og hmm.. den sidste

Har kontaktet ham omkring hans alternative service view. Btw. firmware 2.8.4 virker også på en HW 6.1 controller. Også selvom LK siger den ikke gør Stabiliteten kan jeg dog ikke svare på, da jeg ikke nåede at bruge min HW 6.1 så længe førend jeg skiftede til en HW 6.2. Men jeg ved andre herinde også har opdateret en HW 6.1 controller. Man skal bare bruge en ældre firmware loader til det (mener det er 1.3.3, som også kan hentes herinde fra forumet).

Sidder lige og bladre igennem din log. (den er heldigvis ikke så lang ) 1. Din IHC.items fil har fejl, og den bliver ignoreret. Men det er sekundært problem, indtil du får løst pkt 2. 2. OpenHab får ikke fat i din controller. 2017-11-28 17:00:49.905 [INFO ] [nhab.binding.ihc.internal.IhcBinding] - Connecting to IHC / ELKO LS controller [IP='192.168.1.3' Username='admin' Password='******']. 2017-11-28 17:00:49.908 [WARN ] [nhab.binding.ihc.internal.IhcBinding] - Can't open connection to controller org.openhab.binding.ihc.ws.IhcExecption: org.apache.http.conn.HttpHostConnectException: Connect to 192.168.1.3:443 [/192.168.1.3] failed: Connection refused Er du 110% sikker på at brugernavn og pw er korrekt i ihc.cfg filen? Hvis ja, så ved jeg ikke hvorfor den ikke vil forbinde. Men jeg har en lille mistanke. Prøv at skift porten på din IHC controller fra 443 til noget andet (jeg bruger 777). Derefter skal du ændre i ihc.cfg filen under /services/ hvor du indsætter controllerens IP:porten du har valgt. Hvis det virker derefter så kan det evt skyldes din Synology allerede bruger 443. Men det er lidt et skud i tågen må jeg erkende. Og husk, når du har ændret porten på IHC controlleren, så skal LK´s apps eller andet som forbinder til controlleren også ændres.

Tjek lige denne tråd her. Det lyder som en Fb Torben lavede til mig for et par uger siden og virker helt perfekt.

Ved du om den virker med firmware 2.8.4 ? Jeg prøvede lige hans alternative serviceview. Den kunne jeg ikke få til at virke. Anyway, så er det nok bedre at lave en ny tråd om HA, specielt hvis jeg skal kaste mig over den

Er det noget du selv bruger? Og kan du evt fortælle, hvorfor den binding ikke er på den officielle liste?

Nix, var ikke klar over at der fandtes en ihc binding til Home Assistant. Sidst jeg kiggede efter det fandt jeg ikke noget, hvilket alene gjorde at jeg droppede tanken om det.

Hvis problemet er timeout til IHC controlleren, så løses dit problem jo ikke umiddelbart, medmindre du starter forfra med jævne mellemrum. Dine Xiaomi problemer burde jo være binding baseret og ikke så meget afhængig af OpenHab versionen. Så hvis det er samme binding i begge versioner, så burde resultatet være det samme. Jeg kunne godt være fristet til at opdatere min OpenHab til 2.2. for at se hvad der sker hos mig. Jeg skal bare lige finde en snedig måde at gøre det på. Pt er det jo en test (efterhånden komplet) opsætning jeg har, så i værste fald betyder det ikke så meget hvis det hele braser. Bare jeg ikke mister mine items, rules osv filer. (minder mig om jeg skal huske backup ). Jeg synes generelt jeg godt kunne bruge nogle flere ligesindede brugere i forbindelse med OpenHab2 <-> IHC brugere, der har fokus på at have eksterne sensorer til at påvirke IHC installationen. Jeg er ikke bleg for at prøve ting af, netop fordi mit setup ikke er et "nødvendigt" setup. Mit fokus er, at det skal være simpelt, effektivt og smart. Jeg synes det er voldsomt smart og genialt, det du nævner med din dørklokke. Jeg er dog ikke så meget til, at Rpién skal sidde til TVét og slår over på en HDMI port der. I den retning søger jeg mere en mulighed for, at have en tablet hængende på væggen, og/eller på mobiltelefoner, som automatisk skifter til et kamera ved døren, ved bevægelse. Jeg har et gammel IP kamera som jeg skal have gang i og lege med, for at se om jeg kan få det til at virke. Pt leger jeg bare med en zwave pir. Den som jeg har, har dog skuffet mig lidt mht til batteriet. Efter et par uger, som godt nok blev til intenst brug, så er der 50% tilbage Min planer/tanker er at bruge flere former for sensorer, Pir, temp, lux og evt fugt, og så lade det indgå i en samlet styring der alle skal påvirke kilder enten direkte eller via IHC controlleren. Fx når jeg engang finder ordentlige batteridrevet pir, som kan sidde i udhæng, og som kan justeres til at kun fange i en bestemt højde og bestemt begrænset område, så bliver samtlige hjørner på huset klistret til med dem, til styring af udendørslyset. På den måde kan jeg fange i hvilken retning en person bevæger sig, og styre lyset ud fra det. Og når den del er på plads, så kan evt kamera overvågning også gøre brug af det på samme måde. Samt at det i realiteten dermed også bliver en slags optisk skal-sikring, der ikke lader sig påvirke af åbne vinduer. (dvs den kan bruges om natten i varme sommermåneder). Jeg har fundet små pirs. Men de er ikke trådløse. Og så er de ikke helt så justerbare som jeg kunne tænke mig. Til gengæld koster de en krig, 600+ Indendørs leger jeg lidt med tanken om indvendige pir til samme formål, så der konstant er styr på, hvor en personer bevæger sig fra/til. Udfordringen her bliver, når en person bevæger sig i een retning, samtidig med en anden person bevæger sig i en anden retning. Jeg har også gang i noget personbaseret overvågning/tilstedeværelses indikering. Men det er også lidt mere tricky. I dag bruger jeg en Ubiquiti binding til Openhab2 , som registrere mobiltelefoner på lokal nettet. Men selvom jeg kan inddele det på AP niveau, så er det ikke helt godt nok, da huset så skal dækkes af væsentlig flere APére. Og der hvor APérnes dækning overlapper, der bliver det rigtig svært. Og så er det i øvrig unødvendigt for dets formål med wireless data dækning. Det bedste ville være små kameraer med ansigtsgenkendelse. Men de findes ikke rigtigt endnu til det formål, eller så kender jeg bare ikke til dem. Det ville åbne en helt anden og ny verden af muligheder. Fx personlig lysindstillinger osv. Det ville være en fed detalje. Kameraer har dog en begrænsning i lav belysning, så det skal være med nogle virkelig gode IR. Og så forsvandt muligheden for batteri drevet nok helt. Mht temperatur/fugt/lux, så kunne jeg godt bruge nogle rumfølere med display, med mulighed for at indstille setpunkt. Men jeg vil have dem, så de bliver strømfødt via ledning, gerne 24 eller 12volt dc, for så kan jeg udnytte det allerede eksisterende kabel, som i dag går til zigza følerne, bare som strømforsyning. De findes desværre bare ikke. Det er enten batteri eller 230volt Oven i det, så stoler jeg ikke helt endnu på OpenHab2 til, at jeg vil lade den overtage varmestyringen. Men det kommer nok en dag, hvis jeg kender mig selv ret.

Log filen findes også på en fysisk placering. Skal se om jeg kan finde stien. Og så håber jeg ikke der er forskel på Rpi som jeg bruger, og så på din Synology intallation. Prøv evt at kig her: /var/lib/openhab2/etc Ellers står der en masse her om det også: http://docs.openhab.org/administration/logging.html Men jeg bliver lidt bekymret her. Jeg kan simpelthen ikke lige finde nogen info om, hvordan man default kommer ind i event loggen. Jeg har den bare liggende som en genvej i min browser, så det sker af sig selv.. Een ting er dog sikkert, jeg har ikke siddet og prøvet mig frem med portene. Så et eller andet sted står det skrevet. Jeg kan bare ikke finde det nu