Kandersen

Jeg er egentlig ikke helt sikker på at jeg forstår, hvorfor du skelner imellem det. Når jeg bruger min kalender (Google), så sætter jeg en notifikation op en vis tid før selve event/aftalen. Det er vel i bund og grund denne notifikation som er den relevante, hvis vi fx skal bruge det til at styre noget. Og her kan jeg ikke se, hvorfor det skulle komme an på, hvilken kalender man bruger. Så længe notifkationen kommer igennem og kan bruges til noget, så må det være det primære. Eller??

God fornøjelse.. Der findes mig bekendt ikke en løsning på dette. Det eneste du kan, det er at tænde og slukke dimmeren, og så ellers hente dimmer status til Openhab, så du kan se om lyset er tændt/tændt. Det er IKKE lykkedes mig at finde en måde at skrue op/ned for lyset, for det kræver du kan lave langt tryk i Openhab. Og det kan man mig bekendt ikke. Anyway. Min datters værelse har halogenspot på en Uni400 dæmper. Her er items.. (Bemærk, jeg bruger tænd/sluk fra IHC trykket). Du skal ikke hænge dig så meget t tags osv.. Det er noget af det første jeg lavede, og er pt ved at migrere det hele over i Google Assistant, og når jeg når til denne, så vil den blive ændret og optimeret, inkl grupperet ordentligt. Switch amanda_OEH "Tryk øverste højre" <WallSwitch> ["lighting"] {ihc=">[ON:60250:100]", autoupdate="false"} Switch amanda_halogenlys "Dimmer status" <light> ["lighting"] {ihc="12361490", autoupdate="false"} Her er sitemap: sitemap amanda label="Amanda" { Frame label="Lys" { Switch item=amanda_OEH label="Halogenlys" mappings=[ON=Kip] Text item=amanda_halogenlys label="Halogenlys" Switch item=amanda_OEV label="80mm lampeudtag" mappings=[ON=Kip] Text item=amanda_lampeudtag label="80mm lampeudtag" } Frame label="varme" { Text item=amanda_Temperature label="Temperaturen" Setpoint item=amanda_Tempsetpunkt minValue=18 maxValue=25 step=0.1 label="Juster varmen [%.1f °C]" Text item=telestat8_amanda label="Telestat [%s]" } Frame label="Online" { Text item=amandasPhone } }

Yep, den var ON, når lampeudtaget var tændt (altså ikke det fysiske lys). Jeg aftaster lysindikering i Openhab på dette også, da det er min "sikkerhed" for at lyset tænder/slukker. Alt virkede som det skulle ved at påvirke lampeudtaget direkte, (bortset fra der ikke kom fysisk lys i LEDérne). IHC trykket og dermed Fbén virkede ikke. Det fik ikke lampeudtaget til at reagere. Men lysindikeringen i Fbén var ON, når lampeudtaget ON (lysniveau). Det er derfor jeg mener, at Fbén virkede delvist, og produktet (selve lampeudtaget) virkede delvist. I realiteten burde jeg kunne styre lampeudtaget helt uden brug af en Fb forbundet. Men det fik ikke det fysiske lys til at tænde. Derfor mener jeg der er tale om to ting der går galt. 1. Fbén er gået i baglås, eller forbindelsen mellem IHC trykket, Fbén og lampeudtaget. 2. Lampeudtaget er gået i baglås - Ellers burde det jo netop reagere vha OpenHab. Korrekt, Openhab har fat i begge IDér på lampeudtage (venstreside i Visual). Men Lysindikering er den samme på højre side i Visual, altså samme ID, i Fbén. Men det forklarer ikke, hvorfor det fysiske lys ikke tænder. Det kan derfor ikke kun være Fbén. Her er et billede af, hvor OpenHab har fat. Lysindikering i venstre og højre side har samme ID, så derfor har jeg markeret dem begge.

Så sætter man bare sin event til før den tid

2.7.220 virker ikke med SSL. Det er IOS 10 (Apple) problematikken, som du kan finde mere om her på forumet. Der findes IKKE en officiel løsning til en HW 6.1 controller. LK anbefaler du udskifter din controller til en HW 6.2 eller bedre, end HW7, (pris omkring 5.000 kroner plus evt montering). Uofficiel løsning er at lægge firmware 2.8.4 på din HW 6.1 controller. Dette kan du gøre ved at hente firmwareloaderen version 1.3.3 (mener jeg den hedder) her på forumet, og hente firmware 2.8.4 på LK´s hjemmeside under HW 6.2 controlleren. Firmwareloaderen bruger du til at opdatere din controller med den firmware 2.8.4 du henter fra LK. Skal ske via USB. Derefter virker SSL på din HW 6.1, og du kan nu bruge apps som LK´s IOS apps (på iphone/Ipad). Eller, som min mistanke er, din Android 8.0. Bemærk dog - Det er en uofficiel løsning!!! De fleste, inkl min tidligere HW 6.1 controller virkede fint med den firmware. Min egen controller kørte i 4 dage, så udskiftede jeg den med en HW 6.2, fordi jeg troede den ville være bedre/hurtigere (er den ikke, skal jeg hilse og sige). Men nogle (2 stk) på facebook påstår, at de har oplevet controllere er gået i baglås, og ikke kunnet få forbindelse til den bagefter. Jeg skal ikke kunne sige, hvad der er rigtigt, eller om det har betydning, hvor stort og komplekst et program din controller kører med. Men som jeg ser det, så er du lost, uanset hvad du gør. Enten leve uden apps, betale prisen for en nyere controller, eller tage chancen med firmware 2.8.4. En rigtig lorte situation som LK har skabt. Mht de andre apps du nævner, så har jeg ikke haft succes med nogle andre apps end Lk´s overhovedet. Dem jeg har prøvet har været så elendige, inkl ikke kunne få forbindelse, så de er røget ud få minutter efter de blev installeret. I dag bruger jeg praktisk talt ikke LK´s apps mere, men i stedet OpenHab2 og dens Android App. Men det er en noget større operation man skal igennem for at opnå det resultat.

Så gik det galt igen. Endnu engang et ø80 lampeudtag ver. 2 med dæmp, som vælger at leve sit eget liv. Denne gang er det lyset over spisebordet. Der er monteret 2 lamper med 8watt Osram dæmpbar LED kilder. (Dette handler IKKE om LED/Vs ikke LED, og dimbob og blablabla). Denne gang er det en virkelig mystisk oplevelse: I forgårs (aften): Jeg tændte lyset over spisebordet helt normalt på IHC trykket. Lod det stå tændt i et par timer. Da jeg ville slukke, kunne jeg ikke slukke det. Det reagerede ikke længere på IHC trykket. (dette er samme symptom som jeg oplevede tidligere i vores soveværelse med 2x35watt halogen på jernkerne trafo og som står beskrevet længere oppe i denne tråd). Ny form for fejlsøgning/afhjælpning: Denne gang tog jeg min mobil, startede OpenHab appén. Ikonet og skyderen viste at lyset var tændt på 30%. Altså helt normalt. Jeg tog fat i skyderen (slideren i appén). Og herfra kunne jeg sagtens skrue op/ned for lyset, uden problemer. <Værd at bemærke dette> Og lyset reagerede på det. Jeg skruede helt ned for skyderen, hvilket betyder Openhab sender en OFF til IHC controlleren og lyset slukkede. Dette skete ganske som det skulle. Klokken var mange, og jeg var på vej i seng, så jeg gjorde ikke mere ved det, andet end at jeg ville rode mere med det dagen efter, uden at have pillet yderligere i det. I går aftes, (dagen efter): Da jeg kom hjem fra arbejde prøvede jeg først at trykke på IHC trykket for at tænde lyset. Dette virkede stadigvæk ikke. Tog derefter fat i Openhab appén. Nu virkede den heller ikke. Startede derpå serviceview op for at se, om der overhovedet skete noget. Serviceview: Jeg kontrollerede først, at serviceview kunne reagere IHC trykket. Det virkede helt som dette. Ved første tryk på IHC trykket, så skiftede dæmperen til 30% og lysindikering, (dette er normal scene). Fysisk Lys tændte ikke. Ved fornyet tryk på IHC trykket, skete intet. Dæmperen burde slukke (gå på OFF (0%). Men dæmperen reagerede ikke i serviceview. Holde IHC trykket inde, (skrue op/ned for dæmperen). Dæmperen reagerede ikke i serviceview Ved påvirkning af skyderen i OpenHab app´en, der reagerede dæmperen i serviceview. Dvs jeg kunne se lysniveau ændre sig på dæmperen, sågar også til Off. Det fysiske lys reagerede stadigvæk ikke. Herfra gik jeg i tænke boks inden jeg gik videre med fejlsøgning.. Spørgsmål: 1. Hvorfor kunne jeg påvirke det fysiske lys fra OpenHab appén aftenen før, når IHC trykket ikke gav nogen påvirkning? 2. Hvorfor virkede Openhab appén ikke længere, dagen efter? 3. Hvorfor kan jeg ikke se påvirkning af dæmperen i Serviceview, ved tryk på IHC trykket? 4. Hvorfor kan jeg se påvirkning af dæmperen i Serviceview ved brug af OpenHab appén? (5). Hvorfor reagere det fysiske lys ikke overhovedet. Jeg havde ikke rigtig nogle gode svar til ovenstående, andet end, noget siger mig at der sker et eller andet i funktionsblokken mellem det fysisk IHC tryk og dæmperen. Som om forbindelse imellem helt forsvinder. Det er en væsentlig detajle. Måden jeg bruger OpenHab på, det er ved at påvirke dæmperen direkte i selve funktionsblokken. Dvs lysniveau, det er det som skyderen i Openhab styre. At dæmperen reagere på dette, det fortælle mig at dele af funktionsblokken faktisk virker som den skal. Men det forklare så ikke, hvorfor det fysiske lys så ikke reagere. Så selvom dæmperen reagere, så er der altså stadigvæk noget et eller andet sted, som forhindre at det fysiske lys også reagere. Mit næste skridt var at gå på lofte og demontere lampeudtaget (det er fysisk placeret ved siden af IHC tavlen). Jeg fjernede 230volt til lampeudtaget og efter kort stykke tid monteret jeg det igen. Derefter startede jeg forfra med fejlsøgningen. 1. Jeg trykkede på IHC trykkket - Lyset tændte som som normalt. Så troede jeg faktisk at problemet var løst, lige indtil... 2. Jeg trykkede igen på IHC trykket - Lyset reagerede ikke. Nu var jeg tilbage til det udgangspunkt som startede det hele aftenen før. 3. Tog OpenHab appén. Den viste at lyset var tændt på 30%. Bevægede skyderen i appén - Kunne skrue op ned. Skruet helt ned til Off. Lyset slukkede. 4. Prøvede IHC trykket igen. Det virkede stadigvæk ikke. Men appén viste at lyset tændte på 30%. Fysisk lys tændte ikke. 5. Tog fat i appén og bevægede skyderen - intet skete, andet end det som skete tidligere. Kunne se dæmperen reagerede i serviceview, men fysisk lys reagerede ikke. Nu var jeg altså tilbage til det punkt lige inden jeg fjernede 230volt til lampeudtaget. Herfra var der kun den sidste løsning tilbage, som også havde løst tidligere problem i med et ø80 lampeudtag i soveværelset. Fjerne spændingen til IHC controlleren. Men inden jeg gjorde det, så ville jeg lige prøve noget som jeg tidligere havde tænkt på jeg ville have af/bekræftet. Jeg startede IHC Administrator op. Her valgte jeg at genstarte controlleren. Efter den havde genstartet, så forsøgte jeg igen med IHC trykket. Intet skete, problemet var stadigvæk eksisterende. Med Openhab appén, så var det stadigvæk det samme. Dæmperen reagere i serviceview, men fysisk lys reagere ikke. Herefter gik jeg igen på loftet, fjernede spændingen til IHC controlleren i ca 30 sekunder. Monteret den igen, lod IHC controlleren starte op på ny. Resultat: Alting virker som det skal, inkl. IHC trykket. Lyset reagere som det skal. Problemet er simpelthen væk nu. Og jeg kan ikke fremprovokere fejlen Lidt har jeg dog fået ud af det. 1. Genstart af IHC controlleren fra Administrator, det løser ikke dette problem. Jeg vil tro den genstart fra administrator er en slags "soft"-genstart, og efter min mening ikke en pind værd, som jeg netop fik bekræftet. Så anbefaling til andre fremover - Fjern spændingen til IHC controlleren. 2. Når dette problem opstår, så må problemet ligge et sted i funktionsblokken, som virker delvist. Forbindelsen mellem funktionsblok <-> dæmper lader til at virke, mens selve styringen i dæmperen (fysisk i dæmperen/produktet) må også være gået i baglås, når dæmperen kan reagere i serviceview, men fysisk lys ikke reagere. Forbindelsen mellem IHC tryk, funktionsblok<->dæmperen virker ikke. 3. Problemet KAN (også) være relateret til det trådløse signal. Min fejlsøgning kan ikke afvise, at dele af problematikken kan ligge i kommunikationen mellem dæmper og controller. Det begrunder jeg med, at jeg kan styre dæmperen fra serviceview, (bare ikke med et IHC tryk). Og fordi jeg i servicview kan se, at dæmperen (produktet) ikke reagere på IHC trykket, men det reagere på Openhab appén, så må der være tale om flere problemer, som også er relateret til funktionsblokken. Og det har intet med det trådløse signal at gøre. Men at det fysiske lys ikke reagere, når dæmper gør, det kan netop være relateret til det trådløse signal. Jeg tror dog personligt på, at problemet ligger et andet sted. For at kunne fejlsøge på dette, så kræver det at jeg kan monitorere det trådløse signal, når det sker. Det har jeg pt ikke udstyr til. Men igen, jeg tvivler på det er problemet. Det er nok mere den del med sending af signalet fra controlleren, som fejler. Nu venter jeg bare på det hele sker igen. Når det sker, så prøver jeg at gribe det an på en ny måde igen, evt ved at starte Visual op, fjerne/genindsætte funktionsblokken, uden at fjerne spændningen til controlleren. Og så se hvad der sker ved det. Det er bare irriterende lang tid at gå og vente på det.

Hvilken firmware bruger du i din HW 6.1? Jeg tænker om Android 8.0 nu har lavet samme trick som Apple, at den kræver SSL forbindelse. Din HW 6.1 understøtter ikke umiddelbart denne forbindelse, medmindre det er firmware 2.8.4 (som i øvrig slet ikke er bygget til HW 6.1, men med lidt trylleri kan man godt få den til at køre med den).

Tror nu nok man kunne finde årsager til at styre huset med en kalender, fx som Martin siger ved ferier, eller gæstebesøg. Løsningen for dig er vel at have en form for kalender derhjemme, (simpel tablet) som er den der styre dine events. Den behøver nok slet ikke gå på nettet (uden dog jeg er sikker på det).

Jamen jeg er skam ikke uenig. Omvendt er der nogle ting som jeg godt kan leve med kommer udefra. Du kan jo passende have din kalender på din mobil, og når du kommer hjem på lokal nettet, så syncér den 1, 2 eller 3 måneder frem. Problemet er hvis du udefra laver events, som du af een eller anden årsag skal bruge hjemme. Det vil dog nok ske relativ sjældent.

Hvad mener du?

Lars, jeg havde heller ikke forventet at Nilan anlægget ville køle, ihvertfald ikke noget der har nogen nævneværdig betydning. Løsningen med de mange vinduer er helt klart at lave afdækning. Det er bare ikke lige altid nemt, når man er typen der vil have det automatisk, og forholdene ikke lige er til det. Og slet ikke i ovenlys vinduerne, (selvom Velux praler af det skulle være så nemt). Jeg har 12 Zigza sensore. Jeg er faktisk ikke helt klar over, hvilken sensor der sidder i dem. Derudover har jeg en Netamo vejrstation, Philips motionsensor, 2 stk z-wave sensorer, (Everspring og en Aeotec multisensor 6) samt en Xiaomi Zigbee sensor. Og så selvfølgelig Nilan´s. De 12 Zigza sensore er kalibreret ved brug af to andre sensorer (et analogt væg termometer og et billigt inde/ude digitalt termometer). Jeg tog simpelthen middel temperaturen mellem de to og kalibrerede zigza sensorene ud fra det. En skod måde, men det var det jeg lige havde ved hånden. Aeotec z-wave sensoren er kalibreret. De andre kan ikke kalibreres. Men jeg gad godt at have en rigtig reference, og så kalibrere dem alle på ny, af de der kan.

Lyder som en særpræget løsning du har dig der. Mja kommer vel mest af alt an på, hvor og hvordan man bruger sin kalender. Jeg bruger Google kalender, og jeg vil da foretrække den ligger i "skyen" frem for lokalt. Så er den tilgængelig over alt.

Den synkronisere vel lige så snart den har internet forbindelse?? Det skal du da ikke genstarte routeren for?

Der er ingen konsistens, synes jeg. Der er til gengæld utrolig mange faktore som spiller ind i de her anlæg, synes jeg. Hvilket bare gør det hele endnu mere vanskeligt. En mistro til temperaturfølerne gør ikke sagen bedre. Jeg ville gerne have haft et tilnærmelsesvis forhold mellem rum temperatur og den temperatur som anlægget siger der er på suge-siden. Men der er en verden til forskel. Pt har vi en gennemsnits temperatur på 25,4 (17 forskellige temperatur følere fordelt i huset). Nilan anlægget indsugning sigerd 29.0 grader lige nu. Jeg vil ikke afvise at Nilan kan være korrekt, for nogle af temperaturfølerne er ikke kalibreret. Og de som er, dem har kalibreret imod 2 andre forskellige temperaturfølere, som jeg ingen ide har om er korrekte kalibreret.. Det er faktisk ret svært at finde en korrekt reference til sådan noget. Pointen er dog, at omkring 4-5 graders forskel det virker af ret meget, synes jeg. Isoleringen på rørene har indflydelse på forholdet mellem udsug og indblæs. Men flowet har også betydning. Jo højere flow, (trin) desto mindre forskel mellem indsug og udblæs, specielt hvis der er mange lange rør og 90grader bøjninger. I et stort hus som vores har vi pr automatik også mange meter rør. Jeg synes dog de alle virker korrekt isoleret. Vores anlæg står på loftet, som er uisoleret. I dage som disse, så er der ekstremt varmt deroppe (nok omkring 50 grader). Hvis rør og anlæg ikke er virkelig godt isoleret, så vil det i den grad også have indflydelse på temperaturerne.

Din tekniker´s udsagn om lille spjæld triggede lige et forsøg i mig. Jeg sidder remote (på mobilen) og kan se/styre Nilan anlægget. Kl 13:52 havde det kørt på trin 4 i nogle timer. Temperaturene er: Udsugning: 29.2, Indblæs: 28.1, Udendørs: 25.0 kl 13:53 Satte anlægget på trin 1 og fulgte anlæggets ændringer: Udsugning: 29.4, Indblæs: 27.7, udendørs: 25.5 kl 13:56 Udsugning: 30.0, Indblæs: 28.2, Udendørs: 26,1 kl 14:00 satte jeg anlægget tilbage på trin 4. Udsugning: 29.6, Indblæs: 28.4, udendørs: 25.1 kl 14:18 Udsugning: 29.2, Indblæs: 28.0, udendørs: 24.7 I følge min Mobil, så kan jeg ikke se om spjældet er åbent eller lukket, (den viser closed), men anlægget står på "Cooling", så det burde være åbent. Dette er muligvis pga den mystiske måde jeg synes spjældet og Modbus er lavet på. Det interessante er, at trinet som sådan intet ændre, udover alting bliver varmere ved lavt trin, inkl udendørs temperaturen.. vildt underligt medmindre konstruktionen i Nilan anlægget er helt galt skruet sammen.

Det er egentlig også det jeg prøver, samtidig med jeg forsøger finde ud af, hvad der virker med OpenHab bindingen og mit anlæg.. Det er bare en møg besværlig måde, men desværre den eneste måde, da personen som har lavet bindingen ikke helt har gidet dokumentere det på en ordentlig måde. Når jeg læser det du skriver her, så er det faktisk meget lig det som jeg også ser. Din tekniker kan meget vel have ret i, at det ser underligt ud fordi spjældet ikke er specielt stort.. Et fænomen jeg egentlig ikke har tænkt på som årsag. Ved forår/sommer (som nu), så vil det bevirke, at det ingen som helst betydning har ved høj ventilation. Og det forklarer hvorfor jeg fx ikke kan køle vores hus nu ned, selvom anlægget lige nu står og knokler for fuld drøn, 100%. Huset er ca 30 grader indvendigt og 24 grader uden for. Men det er svært at specifikt pege på Nilan anlægget, for vores hus er samtidig smæk fyldt med vinduer, inkl ovenlys, så vi har en massiv drivhus-effekt i disse dage, når vi ikke er hjemme. Jeg sad netop og overvejede om jeg skulle prøve at slukke helt for anlægget og se, hvad der så sker med temperaturen. Om vinteren tror jeg derimod det er meget godt, hvis spjældet ikke er særligt stort. Men den eneste måde jeg kan måle det på, når nu jeg ikke stoler på Nilan anlægget. Det er ved at tage en temperaturmåling fra den udblæsning der sidder tættest på Nilan anlægget og holde den op imod udendørs temperaturen (Nilans egen udendørssensor i anlægget). Den burde være meget tæt på ens, hvis anlægget skal give mening.

Hvis jeg sammenligner dit stik med mit, så må din rækkefølge være: +12v, A1, B2, A2, B2, GND. Eller +12v = f A1 = e B1 = d A2 = c B2 = b GND = a Jeg har bare brugt almindeligt telekabel her, 3x2par. Jeg bruger Putty og WinScp til min Openhab Rpi.

Jeg forstår godt ideen med det, men jeg synes ikke det giver mening, netop fordi vinteren som regel IKKE har en høj relativ luftfugtighed. Derfor kommer luftfugtigheden i anlægget sjældent over niveauet, sjældnere end når man fx går i bad, hvor der netop er brug for at den "booster" ventilationen. Det er meget typisk at se i den tid vi lige er gået ind i. Praktisk talt hele vinteren har anlægget ikke kørt op i trin 4, når nogen er gået i bad. Men nu har vi varmere dage (og en gennemsnitlig højere relativ luftfugtighed) og så starter den kort tid efter en er gået i bad. Det er også tiden nu, hvor anlægget kan finde på at køre op i trin 4 midt om natten, selv uden nogen har været i bad. Alt sammen skyldes selvfølgelig af luftfugtigheden er højere når det er varmere, samt at grænsen for, hvornår det er sommer eller vinter, bliver mindre betydningsfuld. Og det giver mening om sommeren. Men jeg synes det giver meget lidt mening, at den praktisk talt ikke reagere om vinteren, når nogen har været i bad. Selv dage hvor begge badeværelser har været i gang på samme tid (vi har to store badeværelser). Tja, jeg har læst dem en milliard gange, og synes godt jeg kan forstå ideen. Jeg synes bare ikke det giver specielt meget mening på den måde. Ideen med de 24 timer kræver jo også, at man ligesom IKKE har en fast rythme. Men er der noget vi mennesker er, så er det sgu vane dyr Anyway, godt du fandt årsagen. Altså, jeg vil sige, jeg oplever det samme som dig, og jeg er ikke imponeret over resultatet. Det er svært at "køle" huset ned via Nilan anlægget, ligesom jeg også synes det er svært at få Co2 niveauet ned. Jeg har nogle gange tænkt, at problemet måske skyldes, at anlægget slet ikke er stort nok. Det er kun et Comfort 300LR anlæg vi har. Men vi har også 296kvm hus (dog små 50kvm i garagen). Men Comfort 300LR anlægget anbefales op til 250kvm. Så måske det er lige i underkanten. Selv på fuld drøn en hel dag, kan det ikke holde temperaturen nede. Vi har også mange vinduer, indk 8 loft vinduer. Heldigvis vender 2 stk mod Nord og 2 andre mod vest. De fire resterende vender mod Øst. Men en dag som i dag, der har vi gerne 25-27 grader indendørs med anlægget kørende på fuld skrald. Jeg tror man skal se det som, at hvis Nilan anlægget ikke åbner spjældet, så vil det være endnu værre indendøre, i hvert fald i vores hus.

Som nævnt, så er det en meget underlig måde Nilan anlægget reagere ud fra med fugtstyringen. Alene det at læse og fortstå det de skriver i vejledningen, det er så tåget, så man skal virkelig holde tungen lige i munden: --- 1. HAST LAV "1" Mulighed for at vælge lavere ventilationstrin ved lav luftfugtighed. Værdien kan indstilles til: OFF samt 1, 2, 3. 2. LAV "30"% Justerbar område mellem 15 ...45%. Standard er 30% 3. HAST HØJ "4" Mulighed for at vælge højere ventilationstrin ved høj luftfugtighed. Værdien kan indstilles til: OFF samt 2, 3, 4. 4. TID "60" MIN Maximal varighed for højt ventilationstrin som følge af høj luftfugtighed. Tiden kan indstilles fra 1-180 min. I menuen FUGT er der mulighed for at køre med højere og / eller lavere ventilationstrin ved høj / lav luftfugtighed. Lavt ventilationstrin aktiveres kun i vinterdrift og ved luftfugtigheder under 30%. Højt trin aktiveres med en ændring fra 10-5%, i forhold til gennemsnit relativ RH fra 40-80% over de sidste 24 timer. Når den aktuelle luftfugtighed kommer ned på gennemsnit relativ luftfugtighed + 3% stopper høj hastighed. Hvis tiden udløber inden luftfugtigheden når ned, stopper høj hastighed. Højt ventilationstrin deaktiveres igen, når luftfugtigheden falder til 3% eller mindre i forhold til døgngennemsnittet. Når tiden er udløbet sættes et nyt, forhøjet døgngennemsnit, så funktionen ikke umiddelbart genaktiveres. Der kan gå op til 3 minutter før højt / lavt ventilationstrin er stabiliseret. --- Selvom ideen virker rimelig effektiv, så er det simpelten en mystisk måde. Hvorfor skal den overhovedet måle fugtniveauet over 24 timer? Oven i det, så roder den sommer og vinterdrift ind i det. Det kan virke naturligt nok, i og med fugtniveauet oftest er lavt om vinteren, og man samtidig ikke risikere at drøne ventilationen op på sit højeste, når der er frostgrader uden for. Men på den anden side, så er der jo sjældent så fugtigt alligevel, så det sker nok ikke. Og hvis det sker, så er det sgu nok fordi fugtigheden netop er for høj indendøre, (af andre årsager, fx badværelser). Det havde være mere simpelt, om man blot havde sat fugtigheden, og så kørt løs ud fra det aktuelle niveau, altid. Sommer/vinter afgøres ud fra udetemperaturen. Jeg mener det er 12 grader. Under 12 grader = vinter. Over 12 grader = sommer, eller noget i den stil. Den kan justeres til andet, men jeg husker ikke hvor meget. Men hvad så de dage hvor dagstimer er over 12, og aften/nat er under, og fugt procenten er høj.. Altså faktisk som de dage vi har i øjeblikket. Der kommer systemet til kort. Og igen kan man se ud af måde de gør det på, at de gerne vil undgå at man køre for kold luft ind (uden varmeflade). Selvfølgelig giver de 24 timers måling her mening, men alligevel synes jeg det er et stort kompromis de roder rundt i. Og virkeligheden er måske, at anlægget som det er skruet sammen, slet ikke giver mening uden en varmeflade monteret. (jeg har overvejet en varmeflade). Jeg har overvejet servicemnenuen. Men indtil jeg har fået helt styr på det her modbus show, så holder jeg mig lige fra den.. Den kan få adgang via Modbus, når du når dertil Jeg har endnu ikke fundet ud af, hvad Panelet reelt gør. Derfor har jeg bare konstateret at den lever sit eget liv med 4-5 grader forkert, og ladet den være ved det. Men det er klart, at jeg skal have "korrigeret" den på et tidspunkt, når/hvis jeg skal bruge det til noget. Det kan jeg heldigvis gøre i Openhab, da det virker som om den konstant er 4-5 grader forkert på den.

Jeg ser det som to (idiotiske) onder der møder hinanden, i en tidsalder ingen af delene hører til. IHC Net Basic hører efter min mening slet ikke nutiden til. Det er langt mere effektivt at lave et ordentligt net, evt ved at trække 2 kabler (og opsætte 2 stik). På den anden side møder man en boks, som ikke er bygget til det, som var mere eller mindre standard for et par årtier siden, men som burde være bagudkompatibel. Yousee underskylder jeg delvist, fordi 2 par kabel (eller 10/100mbit) ikke har været normen i rigtig mange år, og det er sandsynligvis ganske få som vil opleve netop dette problem, (sker kun for dem med splitterkabler). Mht til at bruge WiFi. Så er det også lidt noget sludder jeg siger Du har jo alligevel kun max 100mbit til rådighed. Med et godt Wifi net, så burde du få det samme ud af det eller mere. Men principielt, så er jeg langt mere tilhænger af kablet forbindelser specielt når/hvis det kommer til 4K streaming, som boksen jo sagtens kan.

Nå, Yousee har åbenbart meget tid for tiden, (måske fordi deres systemer igen har været nede ). Jeg har netop modtaget et svar: Hej Kim Jeg har faktisk et svar til dig allerede nu. Vi har selv observeret/genskabt det du beskriver, men der er desværre ikke nogen desideret løsning til det udover, at køre på traditionelvis eller via WiFi. Det negative er, at det er korrekt det ikke virker, og der er ikke en løsning. (Jeg tvivler seriøst på der nogensinde kommer en løsning, fordi problemet er/må være stærkt begrænset). Det positive er, som Lars1 tidligere har været inde på, at du burde kunne klare det ved at sætte en lille switch op, som du så trækker et almindeligt netværkskabel fra til din yousee boks. WiFi vil jeg ikke umiddelbart anbefale, medmindre det er som nødløsning.

Præcis!

@Mikkel Skovgaard kan du ikke lave en log der fortæller, hvorfor den er stoppet?

Yousee (dele af) er informeret nu. Hvornår eller om de nogensinde finder ud af det, det må tiden vise. Desværre kan sådanne her ting godt trække helt derud, hvor vi til sidst hverken har boks eller internet mere, og problemet derfor er forsvundet Jeg sidder dog lidt med en tanke om at se lave et kabel og teste det. Jeg har midlerne til det. Jeg skal bare lige have tiden til det.

HW 6.2 med 2.8.4