Lars1

Øvelse gør mester. Med den sidste ændring du lavede ser din FB rigtig ud. Du kan godt sætte "sløver" FB'en mellem din AND blok hvor du samler dine PIR og din lys FB. Så vil den virke på alle PIR samtidig, medmindre du er så uheldig at vinden tricker PIR'ne så de overlapper og dit samlede PIR signal dermed bliver mere end dine 3 sek. F.eks. PIR 1 trikkes 15:15:15 og er on i 2 sek. PIR 2 trikkes 15:15:16 og er on i 2 sek. PIR 3 trikkes 15:15:17 og er on i 2 sek. Sker dette så vil det samlede PIR signal være on i 4 sek. hvilket er over hvad din "sløver" FB ser som en valid aktivering. For at undgå dette problem skal du sende signalet fra hver enkelt PIR gennem en "sløver" FB før end du samler det.

Ingen af mine ca. 7 PIR (5 af den "nye" LK model) er vind følsomme, udover de 2 som bliver påvirket af mine brombær eller blommetræer. Den som bliver påvirket af mit blommetræ er plan forsænket i hjørnet af mit hus, mens den som bliver påvirket af brombærbusken sidder i et underlag uden på min udestue. De resterende er alle en blanding af planforsænkede og monteret på underlag. De fleste sidder på hjørner af bygninger hvor de burde være ekstra udsat for vind. En "sløver" FB er relativ nem at lave. Problemet er mere at få den til at virke, for hvor langtid har du stående signal fra PIR'en når du går forbi den? Det skal jo gerne være længere end de 2-5 sek. som vinden tricker. En "sløver" FB kan f.eks. laves via følgende program trin. Når indgangen går ON starter nedtælling på en timer med initial værdi Når timeren går i 0 går udgangen ON Når indgangen går OFF stopper timeren og udgangen går OFF

Jeg har ikke oplevet at mine er følsomme overfor blæst, men der er forskellige ting som kan påvirke dem. Jjeg har en brombær lige under en af dem, og når den vokser så meget at en af grene komme ind i PIR feltet, så bliver den MEGET følsom overfor blæst. En anden PIR sidder ca. 5M fra mit blommetræ. På en varm nat (+20 grader) med let vind kan den også blive MEGET følsom. I dagstimerne når solen skinner ind på en PIR kan den også være MEGET følsom. Følsomhed er hos mig sat til middel og bevægelses udgang er sat til B.

Bjarne's setup er ikke normalt. Han har MANGE el måler i forhold til en normal husstand. Hvis du bare har en enkelt el-måler kan en LK IHC controller sagtens følge med. Der hvor problemerne opstår er hvis den puls din IHC controller modtager fra el-måleren er for kort eller pausen mellem 2 pulser er for kort. Så kan el-måleren misse en puls fra tid til anden. Derudover skal man være opmærksom på at nogle, specielt ældre el-måler sender 100 pulser pr. KWh mens andre sender 1000 pulser pr. KWh. Såvidt ejg husker er 4.2.03 sat til 100 pulser pr. KWh som default, men det kan ændres uden at man låser FB'en op. Omkring at bruge en indgang til puls opsamling, så skal du sikre dig at indgangen elektrisk passer til din el-måler puls. S0 og en indgang er ikke elektrisk ens, så man kan risiker at skulle have et overdragelses relæ eller andet i mellem. Bortset fra det er det de færreste moderne el-måler som overhovedet har S0 udgang.

Det virker umiddelbart unødvendigt kompliseret med 2 forskellige lampe styringer af 2 lamper som sidder så tæt at de styres af samme PIR. Det samme med forskellig ur styring, men hvis det er det du gerne vil have, så gælder mit forrige indlæg fortsat, med den ændring at du erstatter PIR A og PIR B med PIR. Man kan nemt komme til at gøre ting unødvendigt kompliceret med LK IHC. Langt de fleste af de avancerede funktioner jeg lavede da jeg installerede IHC for snart 15 år siden har jeg slet ikke brugt de sidste 12-13 år. Jeg har i alt 10 lamper samt 7 PIR placeret hele vejen rundt om mit hus. Jeg startede også ud med udendørs lys styring med tidsstyring, skumring, PIR, manuel overstyring m.m. Manuel overstyring findes fortsat i mit program, men er kun forbundet til 1 lampe, og har ikke været brugt i flere år. Tidsstyring er helt fjernet, således at samtlige lamper idag tænder på 25% når skumring indtræder (1 lux måler mod nord) og skruer op til 100% i 2 min. når en PIR i lampens område bliver aktiveret. Efter at jeg har skiftet til LED pære, kan jeg måske spare omkring 50-100W om dage ved at slukke lyset i 5 timer om natten, men det er kun ca. 75-150 kr. om året ved en el pris på 5kr. pr. KWh. Så vil jeg heller have den ekstra tryghed det giver at der er lys på huset hele natten, især når jeg ikke er hjemme (indbruds sikring)

Såvidt jeg husker opstår en cirkulær reference når du linker FB'er således at de kalder hinanden og dermed kan danne et event loop. Jeg mener der bliver checket for dette inden du oploader et program i de nyer versioner af Visual, men er ikke 100% sikker. De eneste tidpunkter jeg har haft en controller, som er gået i fejltilstand var under firmware update af en HW 6.2 controller, samt vist en enkelt gang hvor det genstartede uprovokeret. Men det var med firmware 2.7.199 eller noget i den stil.

Hvis jeg forstår dig ret, så har du følgende ønske. Lampe A styres af tidspunkt A, skumring og PIR A Lampe B styres af tidspunkt B, skumring og PIR B Hvis ovenstående er korrekt forstået skal du bruge 2 dimmer FB's, 2 ur FB's 1 skumrings FB og 2 PIR. Dimmer FB A forbindes til lampe A og får input fra ur FB A, skumrings FB og PIR A. Dimmer FB B forbindes til lampe B og får input fra ur FB B, skumrings FB og PIR B. Med mindre du har mere end 2 PIR's, eller 1 eller begge PIR skal styre mere end 1 lampe, skal du ikke bruge en OR FB. Du skal kun bruge en OR FB hvis du vil samle 2 eller flere input signaler.

Med en visual 3 controller burde du kunne bruge rebuild funktionen, så du slipper for at genlinke wireless enheder efter en reset. Cirkulære reference fejlen kan jeg ikke forklare, men hvis den kun dukker op i forbindelse med en reset vil jeg ikke bekymre mig for meget over den. Datoen kan evt. skyldes at controlleren ikke har fået opdateret tiden på det tidspunkt hvor fejlen opstår og dermed er default tidspunktet i controlleren. Hvis du vil teste det, så prøv at slette NTP opsætningen i din IHC controller og efterfølgende reset den. Så skulle du gerne se default tiden.

Jeg er ikke sikker på at jeg forstå hvad du vil opnå, og jeg vil nødig blande mig i Henning's hjælp, men grundlæggende. Hvis lampe A og B ikke skal følges ad, skal de have hver deres funktions blok. Her kan du så vælge at bruge den samme ur FB til dem begge hvis tænd/sluk tidspunktet skal være det samme. Skal det være forskelligt skal du bruge 2 ur FB's.

Prøv lige at checke datoen på din cirkulære reference fejl. Medmindre tiden på din controller er helt hen i skoven, så er det en MEGET gammel fejl. Fejl bliver liggene i serviceview indtil du clear loggen. Højre klik på log entriet og vælg slet loggen.

Hvis du har haft FB'en låst op for at rette i den forsvinder linket. Prøv evt. at tilføje FB'en til dit program igen.

Funktions blokkene bliver installeret samme med Visual. Når du installer en ny Visual version kommer der ofte opdaterede funktions blokke med. Desværre har de sommetider en væsentlig ændret funktion. Jeg ved ikke om dette er tilfældet med 1.2.01, men 1.2.01g er seneste version af 1.2.01 funktions blokken og normalt vil anbefalingen være at hvis du har 1.2.01a eller 1.2.01c i dit program bør du erstatte dem med 1.2.01g. Hvis du ønsker fortsat at bruge 1.2.01a eller 1.2.01c kan du bare højre klikke på FB'en i dit program og vælge kopier og efterfølgende indsæt. Noget helt andet. En HW 6.1 controler kan godt køre med software til HW 6.2 controlleren. I starten da HW 6.2 kom på marked delte de 2 controller faktisk software. Det var først da LK stoppede med supporten af HW 6.1 controller at de ikke længere skrev at Visual 2.8 med tilhørende firmware kunne bruges på HW 6.1 controller. Mange (incl. mig selv) har med held installeret seneste HW 6.2 software på en HW 6.1 controller. Der er en risiko for at en HW 6.1 controller ikke kan køre med HW 6.2 software, men jeg har ikke kendskab til at det er gået galt for nogen. Faktisk gør seneste HW 6.2 firmware ofte en HW 6.1 controller mere stabil end med seneste firmware til en HW 6.1 controller.

Hvis det er et wireless lampeudtag ses den fejl ofte med version 1 lampe udtag. Hvis det er et alm. lampeudtag forbundet til en udgang i et 230V output modul, kan der være selvinduktion i kablet mellem lampeudtaget og output modulet. Selvinduktion opstår typisk når flere kabler løber parallet over en længere strækning, eller hvis der f.eks. er brug 5 leder og den ene leder er forbundet til noget hvor der er et konstant højt forbrug.

Jeg har også kigget lidt på smart me, men det bliver næppe den vej jeg går. De stedder hvor jeg har kunnet finde smart me er det så dyrt at det er billigere at købe en elmåler med modbus interface fra f.eks. Carlo Gavazzi og en modbus gateway. Den integration Ejvind har lavet understøttes tilsyneladen ikke længere af smart me. Smart me forhandles tilsyneladen ikke længere i DK

Jeg tillod mig at sende dit program gennem Mikkel's dokumentations værktøj. Du kan finde linket til det i hans indlæg højer oppe i denne tråd. Jeg kan ikke umiddelbart se noget i dit program som skulle give den forsinkelse du oplever, og programmet er meget lille og temmeligt simpelt sammenlignet med mit som køre uden problemer i samme controller med samme firmware. Det eneste du bør overveje at lave anderledes er din sluk alt funktion. Det virker på den måde som du har lavet det, men man anbefaler ikke at have flere FB'er til at styre samme udgang da man risiker at FB'erne komme ud af sync med udgangen. Du kan relativt simpelt rette "fejlen" ved at linke 4.1.15 til sluk på de enkelte kip FB'er fremfor at bruge en kip FB specifikt til sluk alt. Ændringen giver lidt mere load på controlleren når du aktiver sluk alt, da der er flere FB'er i spil, men med dit program bør det ikke være noget du mærker overhovedet. Ændringen vil imidlertid sikre dig mod den situation hvor du efter at have aktiveret sluk alt skal trykke 2 gange på et tryk for at tænde lyset da den fysisk udgang og din kip FB er kommet ud af sync.

LK's temp. og lux sensor sender en bit strøm til controlleren, hvilket svare til 8 tryk på MEGET kort tid. Hvis du monter en temp. eller lux sensor men endnu ikke har tilføjet produket på indgangen i dit program, vil controlleren derfor tro at der kommer 8 seperate tryk som den skal generer event's på, fremfor en temperatur, som kun skal generer et event.

Hvis du fysisk har forbundet 4 tryk til samme indgang, skal du ikke oprette 4 tryk i dit program, men kun 1. Hvis du opretter 4 tryk og forbinder dem til samme indgang på en FB kan det trigge 4 events, som meget vel kan være årsagen til at dit program er langsomt. Prøv evt. at lægge dig program op i denne tråd, så er der sikkert en af kode haj'erne som kan tage et kig på det.

IHC captain er installeret på "standard" Linux, så log på med dit fortrukkende terminal program og skriv den kommando jeg gav i forrige indlæg. Hvis du har skærm og tastatur på din Raspberry, kan du også åbne en command prompt der og skrive kommandoen.

Jeg er på ingen måde Linux expert, så @Mikkel Skovgaard griner sikkert sin røv i laser over dette. Men jeg bruger "cat /opt/ihccaptain/data/log.txt" til at vise indholdet af en tekst fil.

Jeg vil ikke bekymre mig om det. Min controller lavede også det nummer en enkelt gang for nogle år siden, men den har ikke gjort det siden. Hvilken firmware har du i controlleren?

For en der kender HA er jo netop det springende punkt. En der kender OpenHab kan også gøre det på 5-10 min. der. Men det tog mig et par uger før det lykkes mig at lave den første data opsamling der. Uden at kende HA vil jeg sige at det nok er nogenlunde det samme der. IHC Captain tog det mig 1 dag at sætte op og forbinde til min IHC controller. Det meste af tiden gik med at få min nyindkøbte Raspberry PI til at virke eftersom det var første gang jeg rodede med Raspberry PI. Efterfølgende tog det mig 1/2 time at får den første data logging til at køre.

HA, OpenHab m.m. er intet værd før end du har sat så meget op at du i dette tilfælde kan se dine måle data i et dashboard eller tilsvarende. Jeg tvivler STÆRKT på at du kan køre det på kop kaffe's tid. Bjarne har allerede IHC Captain. At sætte data logging op her, tager en kop kaffe's tid første gang, og derefter kan du klare resten på 1/2 kop kaffe.

Det er samme sted som du sætter handlinger op. I steddet vælger du bare tab'en med gem til disk og angiver hvor du vil gemme data og i hvilket format. Min IHC captain er version 0.996, så det er muligt at Mikkel har ændret i hvordan man gemmer til disk. Men da jeg satte det op, var der en god guideline på hans website.

Jeg kender ikke HA, men hvis det ligner OpenHab bare en lille smule, er det ikke noget man sætter op på en eftermiddag.

Når jeg ændre i mit program, uploader jeg ofte undervejs, da jeg ofte skal lave flere ændringer. Det vigtige er at man ikke mister forbindelsen til controlleren undervejs. I IHC captain kan du opsætte datalogging til disk. Det er relativt simpelt at sætte op og fylder ikke ret meget. Det vil dog fortsat tage tid at gå gennem tekst filerne og genskabe dine data, men du vil have de aktuelle data fra få sek. før de blev nulstillet.