Kandersen

Sådan skal det være Jeg ved ikke helt hvad det skulle være. Som nævnt tidligere, så skal du ligesom tage udgangspunkt i, hvad det er du vil med test resultaterne. Fx Ra skal testes med en farvepalette, for at give en ide om, hvordan den er, fordi Ra værdien er pærens (lyset) evne til at gengive farverne korrekt. Det er fx rigtig skidt at stå i køkkenet med et lys der umiddelbart ser godt ud, men bøffen du står og steger, den ser grå og trist ud . Endnu værre er det, at servere den på spisebordet med lys hængende over, der får den samme bøf til at se grøn ud Men sådan som du har lavet det, der synes jeg det er ret godt, specielt fordi de hver i sær netop viser, hvor store problemer de egentlig har med lyset, når det dæmpes.

Lad os endelig høre, hvad deres svar er, når du har taget røret i den anden hånd

Jeg får testet det en af dagene. Skal lige hitte ud af det med backup og restore.

Fed opstilling. Og jeg kan også godt leve med at din opstilling ikke tager hensyn til Ra værdien, da du søger lyset sammenlignet med Halogen under dine forhold. (Skal du vise Ra forskelle på en effektiv måde, så skal du have noget med farver på). Det bekymre mig Philips er så elendig når det er en Dimtone pære. Men jeg bemærker at du kun har brugt een pære (i venstre side) på Philips testen. Hvad er årsagen til det?? Fælles for dem alle er dog - De er alle elendige, når de dæmpes. Nogle meget værre end andre. Specielt Philips går det helt galt for, synes jeg. Nordtronic og Osram ligger også godt i bunden. Overraskende er Tech-line, selvom den er katastrofal ved ved 10%. Skuffende er Sunflux, når man tænker på prisen. Den er meget rød og meget kraftig ved 30%. Men over-all, så er det helt klar den der vinder denne battle. PS. Hvilken Halogen pære har du testet op imod - Det er værd at få det med. Og måske 2 sprit nye halogenpærer.

Nope har ikke set din PDF. Ved ikke lige hvor den ligger. Men skal nok finde den.

Du har også noget nemmere ved at overskue det, når du ligefrem har watt målere på dem. Det er en del af det store regnestykke, hvis man helt præcist skal vide, om det overhovedet kan svare sig. Generelt forsøger jeg at udskifte alt hvad der har med halogen at gøre, (dvs fra 20watt og opefter pr pærer). Det er lige så meget en principssag, som det er et økonomisk anliggende, for det irriterer mig at brænde så mange watt af, når langt mindre kan gøre det. Prisen på pærerne spiller kun ind i forbindelse med at finde rigtige gode pærer som giver et godt lys. Men vi er lidt spilttet herhjemme mht til, hvad der er "godt" lys. Sidst skiftede jeg samtlige Halogen ud som sidder under overskabene til Hilux S9. Jeg fik dem heldigvis til en pris på 71,- stk, så det var til at leve med. Men lyset, der er vi ikke enige. Den bedre halvdel kan ikke li dem. Jeg synes de er temmelig gode. Foreløbig lever de endnu

JA!!! (beklager, men de Osram pærer (spot) jeg har haft, de stinker ærligt talt, så lige præcis på det område er min mening, at alt er bedre). Det er til gengæld et stort spørgsmål som er enormt svært at svare på, altså før levetiden er overstået. Så spørg mig igen om 25 år Vi kan kun tro på hvad producenterne siger, og regne ud fra det. Virkeligheden har omvendt flere gange vist, at det som producenterne siger, det holder ikke. Jeg har set folk udtale adskillige LED pærer er "gået" inde for det første år. I sig selv burde det slet ikke være muligt. Ingen har dog forfulgt sagen og gået til producenten, desværre nok fordi vi simpelthen er vant til at pærerene går "jævnligt" fra de traditionelle pærer. Og det er faktisk et problem, når vi står med et produktblad som siger fx 50.000 timer. Det er lige præcis den holdning som vi bør holde fast i, som forbrugere. Altså forudsat at produktet netop er i orden. Men det kolidere også lidt med vores grundvold, der som udgangspunkt siger, at vi vil have alting billigst muligt. Det betyder at der fx også bliver plads til LED pærer med elendigt lys, og de bliver rask væk solgt, primært fordi de er billige.

Men Peter har jo lidt ret i det han skriver. Som du siger, så er det en stor udskrivning. Men det er jo en engangs-udskrivning. Og holder pærerene det producenterne lover, så er det jo begrænset hvad den mer-pris betyder på +25 år. Statistisk set burde dine dæmpere og/eller moduler, controlleren stå af/blive forældet før det (lidt stof til eftertanke, når du påtænker at skifte dem )

Hehe.. Fik det netop til at virke for få sekunder siden med bevægelse og temperatur. Men du får lov at overtage den alligevel, soon.

Så der er 8 PIR følere i alt? Tja, det er muligt det er sådan det menes. I øvrig en interessant opsætning, der forklarer hvorfor der er brug for tryk Det er jeg med på. Men jeg forstår ikke hvorfor. Det eliminere jo meningen med PIR følerne, der ligesom af sig burde kunne finde ud af, hvilken vej man går. Kræver selvfølgelig man har sat dem strategisk rigtigt op. 2 stk side og side på hvert hjørne er næppe optimalt medmindre de peger i hver sin retning. Men okay, det er nok en teoretisk opgave som du siger. Og så er alt jo "meningsfyldt". Den løsning jeg ser for hans opgave er nok, at lade PIR gøre det de er bedst til, nemlig at detektere bevægelse hele tiden 24/7. Og så sætte trykkene (kontakt) ind over selve tændingen af lyset (udgangen måske). Derudover skal der indsættes tidsblok/tidspunkter og lysniveau (Scene) ind foran. Men det er vel bare standard. Mit eget lille skuffe projekt, som faktisk er nærmest 100% identisk med hans grundlag med samme hus, samme 2 stier langs hus, og spot i udhængsider der har egen tilgang. Der er jeg ude i et større antal PIR følere, da jeg også har PIR følere undervejs på stierne, som afgøre, hvilken retning man bevæger sig i. Det eneste jeg vil bruge tryk det, det er at skifte mellem konstant og automatisk.

Jeg mener det er nødvendigt netop når de har været forbundet standalone.. eller også så var det et godt råd jeg har læst herinde. Uanset hvad, så tager det jo kun +5 sekunder

Den opgave synes jeg er lidt tvetydig beskrevet. Det første jeg falder over er, du skriver, der er 2 pir følere ved siden af hinanden. I opgaven står der, at udelyset styres af forskellige PIR følere placeret ved husets hjørner. I bullet fire, der virker det som om at der tales om endnu flere pir følere, "...de pir følere, som sidder på stien langs stien højre om huset". Noget (understreget) siger mig, at der må være flere end 2 pir følere, og de bestemt ikke sidder ved siden af hinanden, medmindre det er et ret atypisk hus med hjørner ved siden af hinanden Pir følerne skal tænde lyset hver sin vej rundt om huset. Men opgaven beskriver også nogle tryk som skal angive hvilken vej der skal tændes. Det virker ret forvirrende. Hvorfor bruge pir følere, hvis man alligevel tænder på tryk, eller omvendt? Jeg har ingen ide om hvordan man laver en Fb. Men selve opgaven, (udover de der tryk som de er beskrevet), den er meget lig det jeg selv har på tegnebordet i vores hus, hvor jeg netop selv har planer om at lave udelyset styret af indtil flere pir følere opsat strategiske steder, som netop angiver, i hvilken retning man bevæger sig, Men jeg kunne altså ikke drømme om at bruge en kombination af tryk og pir til samme formål. Det giver ikke ret meget mening, synes jeg. Jeg er med på en lytter her.

Okay vi ser hvad der sker, når du er klar med det næste version. Btw.. Ang den der motion sensor, den er på nippet til at ryge ud nu. Sad og rodede med den i går i OpenHab. Og selvom det burde være lige til, så er det bare ikke. Giver den sidste chance i de næste par dage, (skal bla opdatere OpenHab). Hvis det ikke virker, så skal jeg bare bruge din adresse i en PM, eller hvis du kommer i nærheden af Ørestad/Ejby (ved Køge)

Jeg mener de skal resettes først. Jf denne vejledning skal du holde A nede i mindst 5 sekunder indtil rød/grøn blinker. http://www1.lk.dk/katalog/vejledning/98530_03.pdf

En specifik ting springer mig i øjnene.. Det er som om der kommer noget andet lys ind og genere til venstre side over vinduet virker blålig, som kan være med til at give problemer. Specielt udpræget på billederne 1, 3, 4 og 5. En anden ting. Jeg vil foretrække at have billederne side og side, evt i mindre størrelser. Forumet her kan ikke gøre det, men jeg tænker om en mulighed var at du lagde dem ind i et billede i Paint eller lign program. Billederne: 1. Ser mystisk ud af en halogen at være. Mit gæt er at kameraet er kommet til kort. 2. Ser ud af helvedes til. 3. Et okay lys. 4. Lidt mere rød igen. 5 og 6. Meget ens. 5 er dog lidt mere rød. Personligt kan jeg nok bedst li billede 3.

Hvorfor jeg ville vide, om lyset er tændt eller slukket. Det er netop for at lade IHC controlleren vide det, præcis som lysindikering/tilbagemelding fra en dimmer i IHC. Men det som du beskriver, det er ikke det som jeg oplever. Mit resultat er: Når lyset er blevet tænd via automatik i Hue appen, så skal jeg trykke 2 gange på fysisk IHC tryk for at slukke lyset. Hvis lyset ikke er blevet tændt via automatik i Hue appen. Så skal jeg IKKE trykke 2 gange på fysisk IHC tryk for at slukke det. Se vedhæftede filer som viser opsætningen. Den fulde http kommandoen i IHC Captain til Hue er: http://10.4.28.39/api/min_user_key/groups/3/action At du mener IHC Captain skal stå for logikken, det er jeg ikke helt enig med dig i er den smarteste løsning.. Jo måske den dag hvor IHC Captain er så tilpas udviklet, så man bla kan lave automatisk styring. Men indtil da, så foretrækker jeg at lægge logikken i IHC controlleren. Jeg har det på samme måde med OpenHab2, men det skyldes nu mest af alt, at jeg synes OpenHab2 er møg besværlig at have med at gøre, og på trods af absolut ingen nedbrud i lidt over ½ år, så stoler jeg ikke helt på den endnu. Det er stadigvæk nemmere at lave/indsætte Fbére i IHC controlleren, fremfor at sidde og lave hjernedøde rules i hånden i OpenHab2.

Fordi du skrev du ville bruge Hue appen

Er ikke med på, hvordan det løser problemet den anden vej. Jeg er godt klar over, at det er en atypisk situation at styre en pære fra flere forskellige steder, som jeg har beskrevet. Det er endda direkte dumt af mig Normalvis vil man benytte et system, og så lade alle andre systemer "gå ind" i påvirkningen af dette system. Fx ved at lade al styringen foregå i IHC controlleren. Mit problem, (som selvfølgelig er fuldstændigt selvskabt, og kunne/burde være lavet rigtig ved at lægge styringen over i IHC controlleren) er, at jeg har defineret en schedule i Hue appen, som tænder min stue (en scene med 4 Hue lamper) på bestemte tidspunkter hver dag. Jeg har desuden i IHC Captain defineret et IHC tryk, som også tænder stuen, (scenen) manuelt. Problemet med det: Når Hue appen tænder stuen automatisk, så ved IHC controlleren ikke at det er tændt. Dvs hvis jeg så manuelt vil slukke for stuen via IHC trykket, så skal jeg trykke to gange, fordi FBén er OFF i IHC controlleren. Logik for burhøns! Den rigtige løsning er selvfølgelig, at jeg dropper schedule/automatik i Hue appen, og lægger den automatiske styring over i IHC controlleren. På den måde vil IHC controlleren altid vide, om lyset er tændt eller slukket, forudsat at der ikke går ged i det. Det er nok her du mener, at der allerede er kontrol med det. Men kontrollen/tilbagemeldingen skal/bør vel overføres i IHC controlleren, så FBén altid, uanset hvad der sker, kender status på Hue enhederne (hvad enten det er pære, scener, rum eller andet). Ellers går det hen og bliver noget rigtigt rod på et tidspunkt, hvis de kommer ud af "synkronisering".

Vil det sige, at hvis du via Hue appen/andet tænder for en Hue, så ved IHC det også? (fx sætter en tilbagemelding/lysindikering ON i funktionsblokken?).

Nej, men problemet er at du i Hue appn skal slukke noget først, førend du kan sende det videre til IHC controlleren. Du kan ikke definere en funktion, uden at du har en eller anden form for enhed med. Som sagt er det ikke noget jeg har prøvet, da jeg operere den anden vej.. Men Hubén kender status på en scene/rum/enhed eller hvad du nu end har defineret i Hue. Så egentlig burde IHC Captain kunne læse denne status. Når jeg tænker på det, så er manglende status faktisk et af de problemer jeg har med IHC Captain, som jeg ikke har fået kigget videre på, (fordi jeg roder med 117 andre ting som sædvanlig). I Hue appen har jeg defineret en scene/rum. Dette rum tændes automatisk hver dag på en bestemt tid, via Hue appen. Samme scene/rum har jeg lavet, så jeg manuelt kan tænde det via IHC tryk (en Fb). Problemet er, at hvis rummet tænder via Hue, så ved IHC ikke det er tændt. Det betyder, at når jeg så manuelt skal slukke det igen, så skal jeg trykke 2 gange på IHC trykket. Første tryk "tænder" Fbén, andet tryk slukker, og dermed slukke rummet, fordi den mangler tilbagemelding om rummets status. Måske jeg skulle tage mig sammen og rode lidt mere med det. Det bør være muligt, eller ihvertfald bør det være muligt for Mikkel at bygge det ind, da det blot er status/tilbagemeldingen på lys/enhederne der mangler fra Hubén. Hvis det er/bliver muligt i IHC Captain, så bør du også kunne lave en sluk alt via IHC Captain, når blot du slukker mindst een enhed/rum/scene i din hue app. Jeg betragter det dog ikke som være specielt bevendt, for den funktion vil jo altid resultere i "sluk alt" i IHC. Så det skal i givet fald kun være en enhed som skal styres til netop dette formål. Den del kan Mikkel næppe gøre noget ved, da det er grundlaget i Hue appen. Det er så absolut en forudsætning Forstår godt hvad du mener. Jeg ville dog blive ret hurtigt hysterisk over, at skulle starte mindst 2 apps op på min mobil. Så jeg tror det vil ske max ½ gang, så er jeg suset til garagen og hentet et trådløst IHC tryk, som jeg lyn hurtigt ville klistre på væggen ved siden af sengen, og indbygge i IHC systemet med en sluk alt funktion, sandsynligvis hurtigere end det tager mig at starte Hue appen for at slukke alt - Nu er jeg dog heldigvis så priviligeret, så jeg allerede har fortrådet tryk siddende ved sengen

Det er ikke Hue appen han udvikler på. Men derimod et alternativ til Hue appen, som hedder IHC Det bør dog være muligt via APIén , at du fx slukker en bestemt lampe/gruppe/eller rum med din Hue app, og så sender IHC Captain en on/off til den Fb i IHC controlleren, som du slukker resten med. Tror egentlig det er muligt allerede i dag. IHC Captain skal bare have en status fra den enhed (lampe, gruppe, rum) som du starter det hele på. Jeg har ikke selv prøvet det, da jeg ikke rigtig kan se nogen ide i at arbejde i den retning. Skal jeg bruge sluk alt, så bruger jeg det som er mest oplagt, et tryk som oftest er lige ved hånden, når jeg skal slukke alt

Men vel ikke via en ø80 dæmper?

Det bliver nok før end senere, Mikkel. OpenHab´s Hue binding kan slet ikke håndtere sensorerne, selvom det snart er 1½ år siden den kom på markedet. Så eneste måde er at bruge http, JSON til APién og noget javascript. Ikke fordi det er specielt svært. Det er bare unødigt og tåbligt, ligesom alle de items man skal sidde og definere manuelt

Du kan ikke benytte dæmpning. Og faktisk er jeg i tvivl om ø80 overhovedet kan tænde/slukke en Hue pære, (jeg kan teste det senere). Men dæmpning er sten sikkert ikke muligt, da Hue pærene dæmper på en helt anden måde. Hvis du skal bruge Hue pærerne, så skal du i stedet for ø80 dæmperen, tilslutte dem til et almindeligt udtag, og gerne et med konstant spænding, eller fx en stikkontakt, ellers skal du bruge et output 230, som du så tænder udtaget på via IHC trykket. Derefter skal du bruge Hue app og/eller Hue dimmer switch/Tap til at tænde og styre pærene med. Det er noget skrald og en skidt løsning, fordi Hue tænder på fuld skrald, når spændingen har været slukket. Der er desværre ingen andre løsningen end større/avanceret kodningsopgaver, når man vil kombinere flere forskellige systemer.

Og hvor meget kan vi lige spare, hvis vi ikke tegner nogle forsikringer overhovedet? Vil du også tale for det? Næppe! Praktisk til alt her i livet, det koster altså bare. Det giver ingen mening at begrænse sig.. Hvad skal han begrænse sig til, i det pågældende eksempel? Overvågning uden IP cams? Netværk uden switch? Internet uden router? Han kan også begrænse sin vejrtrækning, så lukker han mindre CO2 ud, (håber du forstår pointen). At tænke på miljøet er at kunne gøre det nødvendige med mindst mulige resourcer. Fx hvis valget står mellem 2 resultatmæssige ens IP cams der forbruger forskelligt. Så er det fx at vælge dem der forbruger mindst. Løsningen er ikke at droppe IP cams. At tænke på miljøet og undlade at gøre det nødvendige, det er fanatisme der reelt ingen grænser har. Det er useriøst, og har oftest den stik modsatte effekt.