Kandersen

Medmindre han har trådløs strøm, så er han pine død nødt til at have en eller anden form for kabeltræk Det var derfor jeg forventede, at han kunne opsætte 4 stk ø80 relæ/dæmp, og så styre dem via et 4-tast tryk. Til gengæld var jeg ikke klar over, at wireless stand alone ikke kan bruge kip.. Så ja, så skal han have gang i 2 x 4-tast tryk. Faktisk lidt underligt at de ikke kan kippe. Sgu da godt man ikke bruger wireless stand alone. Hele huset ville jo være klistre til med tryk..

Kan 1 stk wireless 4-tast tryk ikke styre 2 lampeudtag? (relæ, der nævnes intet om dæmp) ?

Og det er egentlig den "fornemmelse" som jeg søger lidt mere konkret dokumentation på. For min "fornemmelse" er slet ikke i nærheden af at være den samme som din. I bedste fald, så er min HW6.2 lige så 'langsom' som min HW6.1. Men til tider synes jeg den virker langsommere, specielt ved up/download. Det er min fornemmelse. Overordnet set synes jeg bare, der er for mange individuelle fornemmelser og ikke mindst folk der helt klart formoder, at bare fordi noget er nyere, så er det også bedre (hurtigere). Sågar folk der udtaler sig, uden overhovedet at have stiftet bekendtskab med enheden. Det er lidt skidt på den måde. Specifikt med IHC controlleren, så tror jeg også der er enorm forskel på, hvor meget ens program egentlig indeholder, specielt omkring timere, sensorer osv. Jo flere af disse, desto tungere er "tiden". Dvs man kan sandsynligvis godt have en gammel controller som suser afsted, som om den lever af den. Mens en nyere i nogle helt specifikke situationer kan virke enorm træg. Jeg kunne helt klart mærke forskel på min HW6.1 før jeg lavede varmestyring, og så efter. Men da jeg skiftede til HW6.2 controlleren, der synes jeg bare ikke jeg fik det samme "tab" retur. Jeg gad godt prøve en HW7, men jeg må erkende, jeg frygter det er det samme igen, at oplevelsen simpelthen bare ikke er det værd, fordi der enten ikke er forskel, eller så er den så minimal, så det kan være ligegyldigt. Ang 3. part tilslutning, så køre jeg IHC captain og OpenHab op imod HW6.2 controlleren (det gjorde jeg også med min HW6.1 controller). Og her er det helt klart, at Visual og ServiceView til tider kan være enddog ret lang tid som om at forbinde til HW6.2 controlleren, sikkert fordi de skal slås om at komme til sammen med IHC Captain og OpenHab. Men jeg har bemærket, at hvis jeg kan nå at loade et projekt ind i Visual så går tiden noget hurtigere for at den tilslutter til controlleren.. Det er lidt underligt. ServiceView tager bare den tid ServiceView tager.

Ahh okay så er jeg med

Hmm jeg kan ikke lige se det for mig.. hvis vindmåleren ikke kan sende signalet ud, hvordan skulle konvertere og omformere så kunne klare det?

Har jeg ret i, at den der regn/vind sensor, der sætter man vind niveauet fast for, hvornår den skal trigge kontakten? Selvom det er brugbart til at åbne/lukke vinduerne/andet ved en bestemt vind hastighed, så havde det være bedre (læs - sjovere) om man kunne få vind målingerne direkte ind i controlleren, så man fx kunne bruge det i flere henseende, med forskellige hastigheder, inkl en vindretning. På den måde kan man kombinere det med flere faktorer, fx temperatur. Jo lavere temperatur, jo mere vind, desto mere skal der lukkes i for vinduerne, og omvendt.. Men det kaldes vist for en vejrstation

Hvilken PIR er det?

Det var præcis samme program jeg skiftede med fra HW6.1 til HW6.2. HW6.1éren var kort forinden opdateret til firmware 2.8.4. Og dermed samme firmware på begge. Antal år imellem er bestemt ingen garanti for, at den er hurtigere. Så jeg forstår ikke argumentet, udover at det kan være din formodning, at bare fordi der er flere år imellem, så må den være hurtigere. Som du selv er inde på, når man "vurdere" disse controllere imod hinanden, så skal man gøre det på samme installation. Og det var netop her min opfattelse kom som en skuffelse. Jeg havde hørt fra andre at HW6.2 skulle være hurtigere. Men jeg kan bestemt ikke selv konstatere det. Tværtimod synes jeg faktisk at den HW6.2 jeg har, den kan være frygtelig længe om fx at sende/modtage programmet i Visual. Nu hører jeg det samme igen med HW7, men igen er det enormt ukonkret og "svævende". "Jeg synes den er hurtigere.. og blablabla". Bemærk, jeg siger ikke det ikke kan være en korrekt opfattelse. Men jeg tror også der er noget placebo effekt i det, specielt hvis man har en opfattelse, at bare fordi der er år imellem, så må den dermed også være hurtigere.

Er der nogen der har specifik dokumentation på dette? Jeg har det lidt underligt med sådan en udtalelse, som ikke kun er set fra dig Lars men også andre. Mange sagde det samme om V1 vs V2, and V2 var hurtigere. Min erfaring siger mig derimod, at det bestemt ikke er tilfældet. Eller så er forskellen så lille, så den stort set ikke er mærkbar. Når jeg så ser det samme om V2 vs V3, så begynder jeg at få en fornemmelse af, at det her bare er noget nogen tror. Og jeg kan ikke rigtig finde noget der understøtter, at den skulle være hurtigere, samt hurtigere på hvad måde? Derfor søger jeg lidt konkret viden om det.

Hvis du kun har to ledninger fra motoren. Så skal du vel bare vende polvendingen for at skifte retning? Dvs den ene omskifter har den ene polvending. Og modsat på den anden omskifter.

Hmm, hvis jeg forstår det her korrekt, så virker det ikke efter hensigten. (kommer jeg til om lidt). I øvrigt er det da totalt gakket at "resette" ventilmotionering, bare fordi telestaten har været ON. Den kan jo have været ON i et ganske kort øjeblik, fx pga et vindue der blev åbnet. Så hvis en telestat åbner hver dag i 20 sekunder, så vil den aldrig udføre en ventilmotionering. Det lyder ikke rigtigt. Den bør udføre ventilmotionering, uanset hvor mange eller få gange en telestat har været ON/OFF i forvejen. Det virker ikke helt efter hensigten.. (forklaring). Jeg bruger 5.2.05.c i alle rum. Her flyttede jeg ventilmotionering op på en udgang (efter Hennings anvisning), med det formål at jeg kunne logge på, hvor tit og hvornår FBén køre ventilmotionering. Det er det billede du kan se, 3 indlæg længere oppe. Dvs. når udgangen for ventilmotionering går ON, så logger jeg det i OpenHab med tid/dato. Som det ses af billede, så lader det til at alle rum, undtagen 3 rum, alle har sendt ventilmotionering ON inde for de sidste 7 dage. Men de 3 rum har ikke gjort det. Dvs der er ventilmotionering ikke på noget tidspunkt gået ON. Jeg logger også temperaturene, (i grafer). For fx Bryggers, som ikke har kørt ventil motionering endnu, så kan jeg ud fra grafen se, at temperaturen IKKE har været lang nok nede endnu, til at telestaten skulle have åbnet. Billedet her er fra de sidste 7 dage i Bryggerset. Mindste temperatur er 23.2. Setpunkt (kan du ikke se) er 22.5 grader. Desværre har jeg ikke logget selve telestaterne, men det kan jeg da lyn hurtigt lave, så jeg ved, hvornår tid/dato de sidst har åbnet (gået ON). Mht til opsætning i Visual, så har jeg lavet det sådan, at alle rum, undtage 3 børneværelser, er styret fra 5.2.01.h (bejteningspanelet), hvor jeg via et tryk stiller disse tre rum til beboet/ubeboet. Det skyldes at disse tre rum kun er beboet hver 14. dag. Resten af rummene kører bare konstant beboet og er derfor ikke med i driftform i FB 5.2.01.h. Det ser således ud: I rummene (hvis vi tager et af dem der ikke har kørt ventilmotionering, ser det således ud: (Bemærk den røde ring, det er her jeg aftaster/logger ventilmotionering i OpenHab, og det er i alle rummene) Så min påstand er lidt, at noget må være galt i varmestyringsblokken, medmindre det selvfølgelig hænger så idiotisk sammen som du siger LK har lavet det, for så er den ventilmotionering da ikke en pind værd. Hvilket i den grad giver min grund til bekymring nu. Det forklare bare ikke, hvorfor det kun er de 3 rum, som ikke har kørt ventilmotionering

Nu er jeg lidt bekymret. Alle varmeblokke er sat til at køre ventilmotion i 10 minutter, hver 7. dag. Jeg startede ventil motioneringen manuelt i går. Den gik også i gang, og straks åbnede den tre telestater. Efter 20 minutter, så stod de samme tre telestater stadigvæk åbne, og IHC controlleren havde ikke åbnet til flere. Efter 25 minutter stoppede jeg ventilmotioneringen Kan nogen forklare mig, hvordan IHC controlleren styre det her ventil motionering show?

Nogle vil kalde det for en ond cirkel

Hmm okay, jeg må give det et forsøg og se hvad der sker. Hvordan ved controlleren forresten, hvornår og hvad tid den skal køre ventil motionering ? Som de ses ud af nedestående screendump (fra OpenHab), så mangler der 3 tre endnu, og nu er vi på 8. dag. Jeg logger dato/tid for, hvornår ventil motionering starter i det pågældende rum. Men det er heldigvis forskellige tidspunkter. Så er spørgsmålet, hvor gemmer IHC controlleren oplysningerne om, hvornår den næste gang skal køre ventil motionering i et rum?

@Henning Pedersen Lige et hurtigt ? til " Indgang for start af ventilmotion" i Fb 5.2.01.h. Er det bare en puls den skal have, eller skal den have en konstant? Det er lidt svært at tyde, fordi i beskrivelsen står, at den skal tilsluttes en udgang på pumpestyringen. Jeg har 3 rum hvor der i 7 dage ikke er kørt ventil motionering, selvom de alle står til 7 dage. 9 rum har kørt. Så jeg vil prøve at starte den manuelt.

Som jeg forstår vejledningen, så er det bare en potentiale fri kontakt. Dvs den skal bare direkte i et indput, ligesom almindelige pir. I øvrigt kan den køre med 12volt, som er det man nok bedst får fra batteri backup modulet. Ellers skal du have en konverter på eller en anden 12 volt trafo.

Det er en ret fed PIR 1873BOBBY-AM må jeg sige. Deres 1779BABY-AM er jeg også lidt vild med. Det fede ved denne er, at man kan justere udbredelsen, hvilket gør den ret ideel til mine tanker om at lave automatisk tænd/sluk/rute lys i vores 34 stk spot i udhænget rundt om huset. Den fandt jeg på en engelsk hjemmeside til ca £21. Det er dæleme billigt! Og så selvfølgelig lige deres 1630DT/JOLLY, som erstatning for en almindelig PIR.

Ahh, nu tænkte jeg rent elektrisk. Kunne ikke rigtig finde så meget info om den. Er den 24volt med potentiale fri kontakt?

Det er muligt udefra kommende trafik kan være problemet. Det afhænger meget af hvilken type forbindelse han har. En mobil internet forbindelse et absolut NoGo. Er det en "almindelig" internet forbindelse, så vil det oftest virke uden problemer. Ud fra billederne herover ligner det et almindelig kabelmodem (netgear c6250) Her er Yousee´s vejledning til at lave portforward: https://kundeservice.yousee.dk/bredbaand/opsaetning/port-forward/c6250 En ikke-statisk IP adresse er normalt ikke et problem hos Yousee. Eneste forskel på det, og så en statisk er, at med en statisk (som man ofte betaler ekstra for), der er man garanteret sin egen IP adresse altid, (som i øvrigt vil være DHCP tildelt alligevel). Med en ikke-statisk, så kan man risikere at den skifter. En god ide at finde sin IP adresse på, det er ved at gå ind på siden: https://www.myip.dk Denne fortæller dog ikke, om den er statisk!! Men så kan man se IP adressen man kommer fra. Er en portforward til en intern enhed (server, IHC controller eller lign), noget man skal bruge fast og i længere tid, så anbefaler jeg klart, at man får en statisk IP adresse. Han skal ikke bestille fast IP endnu, førend han har opsat det hele korrekt, og konstateret det måske ikke virker. Før det kan han købe katten i sækken. Michael. Kan du fortælle lidt om, hvordan du konstatere, at det ikke virker? Hvad gør du præcist? En måde at teste på, om du kan få LOKAL adgang til IHC controlleren, det er ved at bruge Administrator, ServiceView eller Visual, og selvfølgelig indskrive IP adressen som du har sat op i IHC controlleren. Dvs flå USB kablet ud, og forsøg skab forbindelse fra din computer til IHC controlleren via lokal nettet. Dette BØR virke med de seneste screenshots du har vist her. Så tager vi portforward derefter.

Det er sgu lidt smart det der. Der kunne LK godt lære noget, i stedet for man kun har 3 muligheder, (beboet, ubeboet og frostsikring).

Efter din seneste ændring bør det virke. Men for en god ordens skyld, så prøv at gå på controlleren lokalt. Virker det? Hvis ja, så er det din port forward som ikke virker. tag evt screen shot af det, så vi kan se hvordan du har lavet det. Hvis lokalt ikke virker, så er der stadigvæk noget galt i opsætning, som ikke er umiddelbart er vist i ovenstående screenshots.

Hvordan har du monteret den PIR?

Jeg kan ikke svare dig på spørgsmålet. Til gengæld, mens du venter på svar, så kunne jeg godt tænke mig at vide, hvordan du vil måle, altså hvilken sensor?

Lige en update til denne. Jeg har skiftet pæren som gav problemer. Og nu er problemet væk.. Pæren må altså være blevet defekt på een eller anden måde, så Hue bridge ind imellem ikke kunne få forbindelse til den, (selvom den sidder 2 meter fra en Bloom lampe og Mesh derfor burde virke).

Hmm, umiddelbart vil jeg sige nej. Men det er underligt den taber forbindelsen så voldsomt som du giver udtryk for. Jeg oplever det ind imellem, men kun i den ene retning. Dvs OpenHab modtager fint fra controlleren, men hvis der ikke har været aktivitet i den anden retning (fra openhab til controller) i et stykke tid, så kan jeg få en timeout lige så snart noget forsøger at manipulere med controlleren. Jeg har en z-wave PIR stående her på mit kontor til test, og hvergang den opfanger bevægelse så starter den en timer i IHC controlleren, (ligesom hvis det var en almindelige IHC PIR). Den får jeg som regel timeout på, når jeg ikke har været på kontoret i nogle timer. Oftest går det i sig selv med 2-3 timeouts forsøg, og ellers kan jeg "vække" den ved at sende en kommando afsted, (fx tænde et lys i IHC via OpenHab). Det er et problem som har været omtalt tidligere, og nogle har lavet en rule i openhab, hvor de med jævne mellemrum (fx hvert kvarter) sende en commando afsted. Det holder som regel forbindelsen oppe. Jeg har ikke selv afprøvet dette, simpelthen fordi problemet ikke har været stort nok, endnu Hvad står timeout til i IHC bindingen i Openhab? Det kan hjælpe at sætte den op til fx 8000. Jeg mener den default står til 5000.