Kandersen

Virker administrator heller ikke med USB ? Så er det stadigvæk Java.

Der findes ikke en IHC wireless PIR. Så ja, PIR skal altid forbindes med kabel til et input. Alternativ er 3.part løsninger, som fx Zigbee eller Zwave. Men det kræver du får en gateway imellem IHC controlleren og Zigbee coordinatoren/Zwave gateway. Det er omstændigt, men det fungere til gengæld. Jeg bruger selv en løsning med openhab som gateway.

Heller ikke min erfaring.

Hmm.. Jeg undre mig lidt over, hvorfor du overhovedet skulle genstarte controlleren efter strømafbrydelse, netop når du har batteri på. Controlleren burde jo ikke have "opdaget" strømafbrydelsen.. Anyway - Der kan være årsager til at skulle slukke/tænde sin controller engang imellem. Pt sidder jeg selv i en situation hvor en wireless dimmer ikke fungere, (andet end via app/openhab osv). Og som regel når det sker, så er der kun een vej, sluk/tænde controlleren. Vi har også batteri backup på, og vores controller er placeret på loftet.. Dvs det er en anelse mere besværligt at skulle bevæge sig derop, skrue en ledning af og på igen. Derfor har jeg fået den ide at installere en fjernbetjent "kontakt", der simpelthen kan afbryde forbindelsen imellem. Og som selvfølgelig skal være en NC (normally closed) kontakt, der ikke skal styres via IHC, (for så virker det ikke). Det er dog en kontakt der skal være visse krav til. Dels skal ingen andre kunne slukke for den, eller det skal være voldsomt besværligt, (ellers ryger hele sikkerheden i batteribackup og alarmen). Og dernæst skal den altid gå til den sikre side (NC) i tilfælde af strømafbrydelse. Det sidste er nemt nok. Men det første er lidt mere vanskeligt. Så hvis nogen har en ide, så hører jeg gerne.

Problemet er ikke kunderne, men at LK har valgt at elektrikeren skal sælge deres produkt - og den opgave har de svært ved at løfte. Men at produktet kan langt mere, skal vel ikke lægges producenten til last. Det er vel netop LK´s aller fornemmeste opgave at få vist, hvad produktet kan? Hvis ikke via el-installatørene, som LK har vedtaget skal distribuere deres produkt, så må de jo selv. (Eller få nogen til at, der kan det). Kunderne kan/bør aldrig blandes ind i et ansvar hvad det her angår. Hvis ikke kunderne bliver præsenteret for produktet, så vælger de det heller ikke. Og de vælger det heller ikke efter præsentation, hvis ikke produktet kan det som kunderne vil have. Det nytter simpelthen ikke at lave et produkt som ingen vil have. (Der tror jeg desværre at LK stadigvæk lever i "de gamle dage", hvor de nærmest havde monopol på alle installationer her i landet). Jeg mener et af LK´s helt store problemer er, at de ikke hvad de allerede har, og de ser ikke udviklingen inden for smarthome systemer. De lytter slet ikke til forbrugerne. Der findes ikke en synlig strategi (ej heller udvikling) for LK/Schneider i forbindelse med SmartHome, som der oprindelig gjorde med IHC konceptet. Det er det der (med rette) får folk til at fravælge IHC, efter min mening. Hvorfor betale et massivt stort beløb for et system som ikke udvikler sig, og producenten bag ikke rigtig formår at vise har en fremtid i? Vi skriver år 2019 (snart 2020), mere end to år efter den seneste controller blev lanceret, og der er fx stadigvæk ikke engang en ordentlig LED tavle dæmper.

Stop lige et øjeblik. Hvis du ikke har problemer med Java mere, så burde administrator virke (via USB). Derinde kan du skifte brugernavn/pw. Via USB kræves der ikke brugernavn/pw.

Kan godt forstå du ikke gider kode en app. Hvis IHC Captain også bruger java, så burde folk med java problemer have de samme problemer med IHC? USBén burde simpelthen ikke være afhængig af java delen i det OS man nu engang kører med. Det burde være en reel serial forbindelse, som burde kunne klares via et simpelt terminal program. På den måde vil man altid kunne komme ind i controlleren, nærmest uanset hvad maskine/OS/Java eller andet man bruger.

Ville det ikke være en bedre ide, at gøre det via USB? På den måde vil det også virke lokalt. Egentlig burde nogen udvikle et administrator program, som er et RIGTIG administrator program, hvor man fx også kan uploade ny firmware fra. Det skal selvfølgelig være via USB, og ikke via LAN. (Mener slet ikke man får lov til at uploade firmware via LAN). Det tvivler jeg også stærkt på kommer til at virke med krydset kabel, (kan ikke se hvad det skulle gøre godt for). Nu har jeg praktisk talt aldrig haft disse problemer her. Men min helt klare opfattelse er, når alt andet fejler, så skal USB virke. USB er den "sikkerhed" man har for, at man altid kan komme til controller delen og "resette/opdatere/whatever" uden store krumpspring. Problemet som jeg forstår, det er det rådne Java bras.. Der findes en tråd her på forum som beskriver flere mulige løsninger. Problemet med det er, man skal kende sin firmware i controlleren og man skal have den rigtige visual og java installeret (korrekt). En "rigtig" USB løsning ville slet ikke skabe disse problemer, da jeg mener den er ren seriel uden beskyttelse eller andet.

Hmm.. Ombytning af portene burde ikke have skabt nævnebærdige problemer. Men jeg må erkende, jeg har aldrig hørt nogen forsøge at bruge 443 til http på den måde. Er det USB du forsøger at få adgang med? Hvis ikke, så prøv det.

Du har ikke tilfældigvis en maskine kørende hjemme som du kan RTD til? Så ville du kunne bruge ServiceView (den absolut nemmeste (hurtigste) løsning efter min mening). Ellers er der IHCremote appén. Men det virker kun alt afhængig af hvor gammel din IHC controller er. (HW6.1, HW6.2 og Seneste controller kan bruges). Det kræver så lige at du laver en portforward i din router, og muligvis (kan blive en showstopper), du skal ind i admin på IHC controlleren og tillade adgang udefra. Sidste mulighed - Få nogen til fysisk at slukke lyset. (5 mdr ude, så burde man have nogen med en nøgle der kan træde til i nødstilfælde, efter min mening. Men det er selvfølgelig nemt at være bagklog).

Det virker fint.. Her er resultatet jeg får: 2019-10-21 19:28:04.760 [vent.ItemStateChangedEvent] - test_Ur changed from NULL to 2000-01-01T07:31:00.000+0100 2019-10-21 19:28:15.777 [vent.ItemStateChangedEvent] - test_Ur changed from 2000-01-01T07:31:00.000+0100 to 2000-01-01T08:31:00.000+0100 Jeg har indsat FBén og lagt resourceID in i min manuelle things til sådan her: Type datetime :testur "Test ur" [ resourceId=17534733 ] I items har jeg defineret den således: DateTime test_Ur "Test Ur [%1$tH:%1$tM:%1$tS] " <time> { channel="ihc:controller:elko:testur" } Og sådan her i sitemap: Text item=test_Ur Og ser således ud i sitemap: Jeg har ikke prøvet at skrive tilbage til controlleren. Men det burde være det samme. EDIT: Jeg har heller ikke prøvet i Habpanel. Men jeg formoder det virker fint derfra, når det virker i BasicUI (og ikke mindst at jeg får data i loggen).

Har start/slut overhovedet en resourceID i funktionsblokken? Hvis ikke, så kan jeg ikke se det er muligt overhovedet. Måske lidt info om funktionsblokken kunne være en ide.

Hmm, det er så ikke det jeg oplever med de alarm PIR jeg bruger. De reagere temmelig hurtig. Så derfor har jeg et par steder kombineret dem med lys.

Okay, det er ikke sådan jeg oplever det. Faktisk oplever jeg, at hvergang jeg uploader et nyt program, så er setpunkt og kalibrering ændret til det som er i programmet (også selvom jeg ikke har ændret disse ting i det program).. Hmm forklaret på en anden måde. Hvis jeg laver kalibrering og setpunkt på en termostat, og skriver resultat ind i Visual, uploader til controlleren. Så er alt som det skal være. Men hvis jeg efterfølgende ændre setpunkt, fx i serviceview, så næste gang jeg uploader mit program fra Visual, så er setpunkt ændret tilbage til det som er i Visual programmet.

Jeg tror ikke jeg forstå hvad langsom/hurtig er så. Fordelen må da altid være, at en PIR aktivere så hurtigt som muligt, uanset hvad den bruges til.

Er det rum og gulv føler samtidig, så kan jeg godt forstå at det kan være svært. Jeg bruger kun rum følere, og her kan kalibrering nærmest ikke gå galt, (forudsat man har mål reference korrekt). Dernæst skal man lige huske - Hvis man ændre kalibrering (og/eller setpoint) i ServiceViewer, så gemmes den ikke i programmet. Så hvis man genstarter sin controller, eller uploader et nyt program, så vil disse ændringer være overskrevet. For at lave det og gennem det rigtigt, så skal man ind i Visual og skrive det ind i programmet.

Hvorfor skulle en alarm PIR ikke være særlig hurtig? Det må være et problem med IHC Alarm PIR. Jeg har nogle Jabletron PIR siddende, og de er bogstaveligt talt vanvittige hurtige, hvilket jeg netop også opfatter, at alarm PIR burde være.

Hvis du ikke kan få det til at virke med Rest API, så har jeg ingen ide til, hvordan du tilføjer tags til dine items.. altså andet end at lave dine items filer manuelt Det er efter min mening også betydelig nemmere og mere overskueligt med items filer, når man først har fanget ideen og prøvet det et par gange. Du kan langt nemmere inddele dine items enten i flere filer eller lave "remarks" i dine items filer, og på den måde få overblikket over, hvad du har husket (eller måske glemt). Jeg synes PaperUI er noget bras til netop dette, specielt når man har rigtig mange things og adskillige hundrede items.

Vanen tro, trods adskillige forsøg på at undgå at kommunikere med dig, så besvarer du igen et af mine indlæg, fordi du ikke bryder dig om indholdet, samtidig med du anfægter mig personligt. Endnu mere vanen tro missede du, som sædvanlig, "bare" den kontekst som lå i det jeg citerede, eller så blev et ord "essentielt" simpelthen for svært for dig at forstå. (Måske du burde slå det op, og så lige minde dig selv om, at det faktisk var en anden der skrev det, og det jeg citerede. Men dit personlig angreb vendte du igen imod mig). LK lytter ikke til privatpersoner, hvad du selv flere gange har påpeget. Så hvad nytter det at jeg brokker mig til dem? (Lad være med at svare - Dit svar kan aldrig komme til at give mening). Netop fordi LK ikke kommunikere (og lytter) med private, så finder jeg det vigtigt at ytre mig om det, så andre uvidende har mulighed for at vide, hvordan det forholder sig. Heller en gang for meget end for lidt. I stedet for at "gemme" virkeligheden i et LK regi, hvor andre ikke ser det, som åbenbart er din foretrukne metode. Der findes moderatorer her, der nok skal fortælle, hvis visse ytringer ikke er i orden. Måske du skulle overlade vurderingen til dem, (igen). "Ingen" er et stort ord, udtalt af en enkelt person, som tilsyneladende har travlt med noget der mere minde om personlig forfølgelse! Du havde alle muligheder for at lade være med at kommentere mit indlæg. Du er sågar flere gange blevet opfordret til at lade være. Alligevel gør du det! Apropos at forpeste - Kan du få forklare mig forskellen på mine indlæg, og så dine evige tilbagevende omkring min holdning og ytringer ang LK, præcis som denne gang? (<--- et ordsprog der har ord som "sten" og "glashus" kan måske være en ledetråd for dig her).

Det er skam ikke mit største problem (igen tager du fejl). Men det er, på trods af omstændighederne, et stort unødige problem. Som du netop også ville have kunnet tydet, hvis du ikke havde været så fokuseret på få af de ord du har citeret, og dermed (igen) forsøgt at manipulere konteksten, i det jeg ytre mig om.

Har du en regel hvor du bruger et IHC tryk til trinløs regulering af et Velux vindue? Og kan du gøre det på samme IHC tryK? Det er nemlig en af de detaljer som jeg har brudt min knold med i et stykke tid.

Yep det er via rules i openhab. Nu siger du at dine velux-vinduer kører via en KLF200. Det gør min vinduer også. Men der er forskellige måder at styre dem på. MED KLF200 firmware 2.xx så kan du styre vinduerne i 1-100%. Ellers kan du bruge scener som er oprettet i KLF200. Velux bindingen til openhab skulle gerne have fundet både vinduer og scener. Derefter er det sådan set en forholdsvis smal sag at få noget til at gøre noget andet ved påvirkning. fx.. rule "simple princip regel" When item sensor changed then velux.sendCommand(ON) end Denne simple regel (rule) gør sådan set det som den siger: Når sensor ændre sig, så Send kommando ON til velux. Sensor er så en item fra et eller andet Velux er en item linket til et velux vindue eller en scene på din KLF200. Her er min gamle (en del mere omstændig/avanceret) rule til styring af mine velux vinduer, der bla tager forbehold for, om alarmen er slået til/fra, og om det er mørkt udenfor. Og så selvfølgelig temperaturen i form af en Netamo sensor. Det skal lige siges, at den er ændret lidt i dag. Men princippet er det samme. Den aktivere scener i KLF200. rule "Automatic control of all skylight windows" when Item NetamoUdendoersTemperature changed or Item Node13_SensorLuminance changed or Item alarm_totalalarm changed or Item dummy1 changed then // Exit the rule when there is nothing to do if(Override.state == ON) return; if(alarm_totalalarm.state instanceof Switch ) return; if(!(Node13_SensorLuminance.state instanceof Number)) return; if(!(NetamoUdendoersTemperature.state instanceof Number)) return; // Calculate which velux to send the ON command to val Number fTemp = NetamoUdendoersTemperature.state as Number val Number lux = Node13_SensorLuminance.state as Number val alarm = alarm_totalalarm.state var velux = VeluxAlleLuk // Third table if(alarm == ON) { logInfo("debug", "Third table clause") velux = if(fTemp >= 18|"°C") VeluxAlleVent else VeluxAlleLuk } // Second table, we already know alarm isn't ON so we don't have to test it for OFF here else if(lux < 10){ logInfo("debug", "Second table clause") velux = if(fTemp >= 18|"°C") VeluxAlleVent else VeluxAlleLuk } // First table, we know that alarm isn't ON and we know lux >= 20 so we don't have to test for it here else { logInfo("debug", "First table clause") switch fTemp { case fTemp >= 25|"°C": velux = VeluxAlleAaben100 case fTemp >= 24|"°C": velux = VeluxAlleAaben75 case fTemp >= 23|"°C": velux = VeluxAlleAaben50 case fTemp >= 18|"°C": velux = VeluxAlleVent default: velux = VeluxAlleLuk } logInfo("debug", "Choose " + velux.name) } // Send the command logInfo("skylight", "Sending ON command to " + velux.name + " because OutsideTemp = " + NetamoUdendoersTemperature.state + " Lux = " + Node13_SensorLuminance.state + " and Alarm = " + alarm_totalalarm.state) velux.sendCommand(ON) end

Jeg har ikke det problem på min iphone. Det er en iphone 8 med nyeste IOS.

I mit tilfælde er det lidt omvendt. Slangerne er jo lagt (og ikke rigtig til at ændre på). Jeg mistænker det aldrig har været indreguleret. Men selv hvis det er, så kunne jeg godt tænke mig at få det optimeret så meget som overhovedet muligt. Det forudsætter vel "bare", at man kan finde ud af at beregne det, og så i øvrig ved hvordan det er strikket sammen. Slangernes længde formoder jeg at jeg kan måle mig nogenlunde frem til, hvis man forudsætter at de ligger i nærmest fugleflugt linje og med 50cm mellem hver? Jeg kunne ikke lige downloade den exe fil.. Måske fordi jeg sidder på arbejdet nu. Prøver igen senere.

Kan du komme nærmere ind på, hvor jeg finder disse, og evt hvordan de bruges. Jeg har præcis nada forstand på det her. Er det "bare" forskellen i fremløb og retur for den enkelte kreds man finder varmetabet på? Dem kender jeg ikke.. Nogen links?