Hop til indhold

Kandersen

Members
  • Antal indlæg

    3.308
  • Medlem siden

  • Senest besøgt

  • Days Won

    39

Alt der er opslået af Kandersen

  1. Kan det tænkes at strømforsyningen evt kan være presset pga varmeinstallationen? Jeg oplever selv flere genstarter med min 6.2 controller, (havde netop en for et par timer siden). Men der er ved at danne sig et billede af, at det sker oftere om vinteren end om sommeren. Så jeg tænker om det kan være fordi telestaterne sidder på samme forsyning, (det gør de hos mig), og de af gode grunde arbejder mere om vinteren end om sommeren. Min næste teori er, at fordi det meste af mit IHC anlæg sidder oppe på loftet, at det måske skyldes kulde. Men det er enormt svært at påvise.
  2. Helt principielt, så er alt trådløst signal hæmmet af mange udefra kommende omstændigheder i markant større grad end kabling er. Noget så banalt som en væg giver en massiv dæmpning i et trådløst signal. Her kommer problemet til sin ret, når man roder det ind i en bolig, der praktisk talt altid består af vægge. Oven i det har vi ofte med trådløs signalering, der ligger og roder i frekvensbånd med andet, eksempelvis Zigbee der bruger 2.4gHz, som også er det trådløst Wifi bruger. Og lige præcis på det frekvensbånd, der er kanalerne meget begrænset. 868mhz båndet er også voldsomt udbredt, også til meget andet udstyr, der bruges i hjemmet. Eksempelvis er der flere varmestyringsenheder, som netop benytter dette bånd. Men kan man isolere sit trådløse net, og løse barrieren med vægge der dæmper - Så ja, så kan et trådløst setup sagtens fungere. De er bare ikke altid nemme at løse.
  3. Vil skyde på pris. En 6.2 kan erhverves noget billigere end en V3. 6.2 har mere ram og potentielt mere stabil end 6.1. Men ellers er det ligegyldigt.
  4. Nu har jeg rodet med wireless i rigtig mange år. Min erfaring er, at det er et spørgsmål om tid, førend der opstår problemer af den ene eller anden art. Nogle gange kan billige løsninger også blive for billigt. Men det er klart, at det kommer meget an på, om man bare vil tænde/slukke en lampe fra en mobiltelefon, eller vi snakker langt mere avanceret funktioner. Der er folk der mener, at bare det at de kan tænde/slukke lys fra en app eller evt en tåbelig PIR (Philips Hue), så har de et smarthome system. Fred være med dem. Men det er langt fra virkeligheden. Bingo! Eller dvs det er der faktisk. Homey, Fibaro oa gør faktisk. Men fælles er, at de er rimelig begrænset udover de understøtter trådløse standarder. LK´s Wiser ser jeg bestemt ikke som en konkurrent til disse. Men hvis man bygget zigbee ind i fx IHC controlleren, så vil man se et system der uden at blinke med øjet vil feje alle andre af bordet. (selvfølgelig med visse tilpasninger til IHC Visual). Årsagen mener jeg, alene skal findes i "beskyttelse" af IHC til brug for elektrikerne. Mens Wiser bliver for hr og fru DK. Og så er vi ovre i de andre kommercielle mærker som nævnt herover, eller folk skal rode med openHAB/HA. Det sidste kommer ikke til at ske i vid udstrækning.
  5. Nope. Men hvis man har en ide om at det skal dække et helt hus, så skal der enten adskillige fastspænding enheder eller flere gateways, der kan repeate. Ellers bliver det op ad bakke at dække et hus med en trådløs teknologi. Det er designvalg, fordi det koster strøm. Batteri enheder går i "sleep" mode, og kan derfor ikke aggere repeater/mesh. Enig, det er den slags ting der skal til. Men oftest er der ikke rigtig nogen der snakker om det. IHC wireless har uden tvivl problemer. Og set ud fra det, så er Zigbee en god erstatning. Men IHC er jo meget andet end IHC wireless. Faktisk er en fortrådet IHC installation voldsomt meget mere stabil end alle andre systemer jeg kender. At sammenligne dem med hinanden, (IHC fortrådet med IHC wireless/Zigbee/andet trådløst), det er efter min mening ikke seriøst. Desværre går udviklingen i retningen af, at vi pine død skal have disse trådløse standarder i vores hjem, som oftest også følges af, at de er ekstremt begrænset når det kommer til logikstyring, (se bare på Philips Hue og dets tragiske logiske styringer, eller rettere, total mangel på samme). Det er derfor jeg mener, at hvis LK/Schneider havde haft bare lidt flere brikker mellem ørene, så havde de lavet en ny IHC controller med zigbee (evt z-wave og 433mhz). Så ville de med tiden kunne sluse IHC wireless helt ud af markedet. Og så de så have gjort det rigtigt godt, så havde de lavet IHC controlleren med et fuldblods ordenligt GUI klient/server system. Det kan umuligt have kostet mange bas-øre.. Men desværre har LK/Schneider endnu engang valgt en anden retning, og sandsynligvis satser på, at folk roder IHC, HA (openHAB og deslige) og Wiser sammen. Desværre er HA/openHAB bare ikke for gud og hver mand, tværtimod. Alt sammen i stedet for at bare gøre det rigtigt, første gang!
  6. Delvist korrekt. 65000 enheder er ikke pr gateway. Det er samlet set. Batterienheder kører IKKE mesh. En gateway indeholder ikke nødvendigvis logikstyring. Men i det pågældende tilfælde vil det være ubrugelig såfremt der ikke er logikstyring i. Zigbee er ikke 1000% bedre end IHC wireless. Man bliver slemt skuffet, hvis man tror Zigbee er den hellige gral. Lige så snart man roder batterienheder ind i det, så starter en ballade, der er markant værre end IHC wireless. Holder man sig til fast-strøm enheder, så er Zigbee godt/dårlig som alt muligt andet mesh system. Det havde givet mere mening, om man havde bygget en IHC controller med indbygget Zigbee gateway. Derved havde man allerede haft en massiv logikstyring, der ville være brugbar. Plus at man havde kunne smide den direkte ind i allerede eksisterende IHC installationer. Det som LK gør nu, det er "starte forfra" med et ikke kompatibelt med IHC system. Og jeg tvivler kraftigt på vi nogensinde kommer til at se en forbindelse i mellem dem.
  7. Der er flere ting man ikke kan sende direkte til en funktionsblok, selvom man umiddelbart skulle tro det, (jeg røg ind i problemet med alarm blokken forleden med skalsikring). Løsningen som jeg ser det, det er at oprette sensoren under produkter (venstre side) som en virtuel sensor. Og så sende værdien dertil fra HA/Nodered. Om det virker rent praktisk, det må komme an på en prøve. Men det er sådanne løsninger jeg selv har valgt, når jeg skal sende noget fra openHAB til IHC. Det har også den fordel, at du kan bibeholde den "normale" logik procedure i IHC controlleren, og ikke skal bekymre dig om, hvordan en funktionsblok er skruet sammen under "unormale" forhold. Håber det lykkes dig.
  8. Nu har jeg kun hørt rygter om det. Og det lader til det er deres Zigbee system. Men det er meget lidt info der ligger bag selve logikstyringen i det. Og det er i virkeligheden den som er alt afgørende. Husk endvidere, at Zigbee har et maks antal trådeløse enheder. (mener det er omkring 52). Over dette, så kræves der ekstra "hub". 52 enheder, det spår jeg at man lyn hurtigt render op i, hvis man skal gøre det lidt mere avanceret, end blot kip-tænding.
  9. Jeg har samme problem. Jeg har ikke fået boret så meget i det, men jeg tror det er Google som roder og fejler.
  10. Not exactly unfortunatly. It should be part of the Pin 7 (Signal in) from the output module. I have no idea how come it shouldnt work after you changed controller. Maybe @Henning Pedersen or someone else has a better/deeper knowlegde of the keypad and how it works. I wonder if there is some changes in the alarm function block.. If you look into Service View, your should be able to detamin if the keypar (alarm) is ready or not, when the alarm is armed. In my installation, when I arm the Alarm, the keypad turns into red light, and the output of "alarm status" is changed from ON to OFF. This is how it looks like in my openHAB setup, which basicly just read the status of the Alarm functionblock. Notice the first two at top. The Alarm is armed, and status goes OFF. To the right (still at top), you can see the total alarm is armed (ON).
  11. Helt enig med Henning. Gå ikke på kompromis med antallet af kabler. Fleksibilitet risikere at få for lidt fokus. Og så i øvrig lav samlingerne i loftdåserne. Der er væsentlig mere plads end i fuga vægdåser.
  12. Thats the original LK keypad. Make sure the wires are connected correct according to the scheme which is included when you bought the keypad. If they are connected corectly then I would assume the led is defect or maybe a output.
  13. OpenHAB 2/3 kan da læse phyton kode uden problemer direkte?? Og uden at vide noget som helst om phyton eller java, så ligner det da lidt, at det kun virker til gogogate apién ?
  14. Sandsynligvis ikke uden relæ eller et 8/10 IHC output modul, som koster en bondegård. Alternativ skal du omlægge ledningerne fra IHC trykket til direkte på portåbneren.
  15. Pjat, du har nu oceaner af tid. Du skal bare lære at multitaske, når du vælter rundt midt om natten med den lille ny på skulderen. Så sover du jo alligevel ikke Serious! Tillykke med den lille nu
  16. Kandersen

    Bedlamper

    Du kan også bare lade dine hue enheder styre af openhab og IHC. Men jeg tror mere dit problem er skumringmåleren. Jeg bruger en 180grader IHC pir i mit setup med skumring i. Den opfører sig også som du beskriver, men det skyldes lysniveauet kan svinge. Problemet er dog ikke værre, end at jeg lever med det. Det er mest de andre i huset, som synes det er underligt og lader sig irritere af, at lyset tænder i stuen, når det er "lyst nok" udenfor. Alternativ skal man have en rigtig lysmåler, eller starte en timer i fx 5 minutter.
  17. Ingen ide. Men jeg tror vi er ovre i stærkstrømsbekendtgørelsen (hedder den ikke mere). Og der er sikkert nogle regler deri der siger noget med 2 meter. Det er mere eller mindre generelt det sættes ind i forbindelse med disse drivere/strømforsyninger. Og jeg tvivler på specielt mange overholder det.
  18. Korrekt.. Jeg har dumpet utrolig mange LED (MR16) pærer på den konto. Jeg har flere LED strømforsyninger / Drivere, som jeg har dumpet. Det gælder simpelthen om at finde den rette kombination af driver og kilde. Og så i øvrig selve dæmperen. Men sidstnævnt er rimelig begrænset, når man har IHC. Generelt er min opfattelse dog, specielt når det kommer til dæmpbar, at billigt er lig med større problemer. Det gør det mindre sjovt at prøve sig frem. Håber du finder løsningen på dit problem.
  19. Ahh det er måske liiiige at stramme den. Hvis alle 8 korer er ført igennem korrekt, så må man formode, at der er basis for mindst 1000mbit/s, selv på et dårligt kategori 5e kabel. Bedre kabel gør det ikke værre, tværtimod
  20. Det er fuldstændig de samme, og i øvrig vanvittige gode, G4 jeg bruger i mit køkken. Men de er ikke helt uden problemer. Jeg har tre rækker (overskabe) med lys under. Den ene række har 6 stk af de G4 siddende på en 25watt dæmpbar LED driver. Den anden række har 3 stk af de G4 siddende på en 10 watt dæmpbar LED driver. Og den sidste række har 3 stk af de G4 siddende på en 10 watt dæmpbar LED driver. Begge type driver er denne, bare i forskellige watt: https://www.greenline.dk/led-paerer/led-driver/tridonic-led-driver-25w https://www.greenline.dk/led-paerer/led-driver/tridonic-10w-led-driver De sidder alle på den samme IHC wireless Uni 250 (1-modul) dæmper. Men af een eller anden årsag, så blinker den ene 3-rækker, når lyset er slukket. De to andre rækker funger klippe stabilt. Jeg mistænker det er driveren, fordi den "summer" lidt mere end de to andre, når lyset er tændt. Men jeg har ikke forsøgt at bytte rundt på dem, endnu, eller prøvet med en anden driver. LED er måske godt, men det er meget sjældent uden problemer
  21. Den burde ellers være god nok. Kan evt være LEDérne i kombination med dæmper og driver. Hvilke G4 er det?
  22. Måske hvis du nævner hvilken driver det er, ville det være nemmere. Men umiddelbart vil jeg mene RC eller AUTO.
  23. Hmm jeg kan godt se, at jeg skal vist se at få afsat lidt tid til det med min port. Det er lidt hæmmet af, at min port kun køre på puls. Dvs en puls til at starte, stop og returnere. Det er lettere akavet. Andre siger det er helt normalt. Men jeg synes jeg har svært ved at få Google/openHAB til at fattet det mere tydeligt, specielt fordi der er den "stop" som ikke rigtig giver mening. Jeg har så to magnet kontakter på, så jeg ved om porten er helt åben, helt lukket, og dermed også om den er et sted derimellem. Men det har ikke gjort logikken nemmere, synes jeg.
  24. Det kan mig bekendt kun lade sig gøre via funktionsblokken. Dvs du skal finde resourceID for status i funktionsblokke/højre side af Visual. Det er muligt den kun er der, hvis du bruger den avanceret fortrådet dæmper blok. (Kan ikke huske nummeret og er ikke hjemme lige nu). Det er sådan jeg selv gør det med openHAB2 og en UNI400 dimmer.
×
×
  • Tilføj...

Important Information

Privatlivspolitik og We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

1200x630bb.png

ok