Hop til indhold

tgr

Members
  • Antal indlæg

    11
  • Medlem siden

  • Senest besøgt

tgr's Achievements

  1. Efter jeg smed en glødepære ind i kredsen har jeg ikke set et eneste udfald, så nu har jeg bestilt nogle støjkondensatorer og vil prøve at sætte sådan en ind lige efter relæet for at se om det kan have en positiv effekt. Er der nogen der har erfaring med støjkondensatorer og om de reelt set kunne have den ønskede effekt?
  2. Så er der skiftet ud og den virker pt mere stabil end jeg har set før (det kan selvfølgelig nå at ændre sig). Hvis det viser sig at være problemer med LED/sparepærer, der forårsager balladen, er der så nogen måde hvorpå jeg kan forhindre det? Kan man sætte en formodstand ind for at stabilisere eller er der andre måder at modarbejde pærernes ustabilitet på?
  3. Jeg fandt ud af hvordan man logger i serviceview og kunne hurtigt se at det også var et problem her (jeg har desuden koblet OpenHab fra, så der ikke er andet der påvirker det rene IHC setup) - Jeg opdagede forøvrigt også det med dvalen I loggen kunne jeg se at de utilregnelige statusskifte varierede fra 4-5 sekunder til halve og hele timer.
  4. Jeg prøver lige at skifte ud med en alm glødepære og ser om det ændrer på noget. Tak for tippet!
  5. Det forklarer ihvertfald delayet, men så er spørgsmålet om mine lyskilder kan være årsagen til dens utilregnelige opførsel? Jeg kan ikke helt forstå hvordan det skulle være muligt, men det kunne jo være der var en naturlig forklaring
  6. Der sidder 2 6W sparepærer og et 20W LED panel på. Er der ikke nok belastning? Relæet slår jo til og fra som forventet, det er bare selve statusdelen der er utilregnelig... Den er faktisk også lidt sløv til at registrere at der er slukket hvis jeg trykker på knappen på relæet.
  7. Ja det er noget mærkeligt - Desværre er det mere end to år gammelt, så reklamationsretten er smuttet Jeg har et par stykker mere, som ikke er koblet til endnu - det må jeg få gjort så jeg kan teste om de gør det samme.
  8. Nu har jeg prøvet at frakoble OpenHab for at sikre mig at det ikke er den, der skaber ballade og problemet vedbliver. Når du siger at du har besat relæet, var det så bare ved at holde A inde i 5 sekunder og linke det til controlleren igen? Det har jeg nemlig lige prøvet og det ser ud til anden stadig sender ON/OFF tilfældigt - Den slutter altid på OFF, men relæet tænder aldrig ved disse status-skifter...
  9. Relæet er et wireless universalrelæ (https://www.billigvvs.dk/El-artikler-LK-IHC-IHC-Wireless-Lysdaempere-relaeer--LK-IHC-Wireless-Fuga-Universal-relae-6A-1-modul-Hvid-215251.html), så datalinien er wireless Så fandt jeg ServiceView Jeg kan se at det samme mønster gør sig gældende derinde med at den skifter fra OFF til ON tilfældigt, men jeg har ikke prøvet hvor jeg tager OpenHab ud af ligningen - det kunne være at bindingen fremprovokerer dette. Jeg undrer mig bare over at tilstanden ikke slår relæet til eller fra - Jeg kan tænde og slukke lyset fra OpenHab og fra kontakten på relæet, men når tilstanden skifter af sig selv, slår relæet ikke til eller fra. Det sker også kun når relæet reelt set står til OFF. Er der et sted hvor jeg kan trække logfiler eller kan man få IHC Control til at spytte logfiler ud til en logserver? Jeg prøver lige at finde hvad jeg har af channels og items samt regler og vender tilbage med det - Tak for hjælpen
  10. Jeg har desværre (så vidt jeg ved) ikke mulighed for at se om det sker uden OpenHab, da det pt er det eneste sted jeg kan monitorere status. Jeg er ret ny udi IHC, så det kan sagtens være du kan fortælle mig noget andet? Har ikke lige haft en Raspberry på hånden at installere IHC Captain på endnu... Jeg har bare brugt simpel Kip da det bare er et relæ der er sat istedet for den gamle kontakt til mit værksted. Jeg har derfor ikke behov for at sætte timer på, men vil gerne på sigt koble det sammen med noget pir, der kan holde øje med om jeg er i værkstedet eller ej.
  11. Hej Jeg har et setup med en Visual Controller ver. 6.2 og kører OpenHab med IHC binding 2.5. Jeg oplever at mit universalrelæ umotiveret registreres som ON/OFF i OpenHab uden der trykkes på noget. Det er heller ikke fordi relæet rent faktisk aktiveres, men det virker til at værdien for dens tilstand står og floater i controlleren og dette meldes videre. Jeg har en regel der baserer sig på hvorvidt relæet er sluttet eller ej, så det er en kende upraktisk at det registrerer aktivitet med alt mellem 8 sekunder til adskillige minutter imellem. Relæet er sat op med simpelt kip i controlleren - ved ikke om dette er forkert eller om der er en mere stabil måde at sætte det op - Jeg kører udelukkende wireless moduler med det formål at kunne fange og sende kommandoer via OpenHab samt styre lys fra batteritryk. Trace-log ser sådan her ud for et falsk event (forøvrigt skræmmende ens med et reelt event): 2019-09-23 15:03:46.080 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - 1 new notifications received from controller 2019-09-23 15:03:46.083 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - resourceValueUpdateReceived: [resourceId=302430, value=true] 2019-09-23 15:03:46.089 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Update channel 'ihc:controller:e46eedca:output302430' state, channel params: [ channelTypeId=switch, resourceId=302430, direction=null, commandToReact=null, pulseWidth=null, inverted=false, serialNumber=null, longPressTime=null, onLevel=null ] 2019-09-23 15:03:46.097 [TRACE] [ab.binding.ihc.internal.ws.IhcClient] - Wait new resource value notifications from controller 2019-09-23 15:03:46.101 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://192.168.8.230/ws/ResourceInteractionService, connectionPool=25499528, clientId=27675242 requestId=57, timeout=15000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:utcs="utcs"> <soapenv:Body> <utcs:waitForResourceValueChanges1>5</utcs:waitForResourceValueChanges1> </soapenv:Body> </soapenv:Envelope> Med venlig hilsen Thomas
×
×
  • 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