Jump to content
IHC-User.dk

Troels Larsen1354922265

Members
  • Content Count

    26
  • Joined

  • Last visited

About Troels Larsen1354922265

  • Rank
    Tekniknørd :-D

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Jeg fandt ud af at jeg ikke var den eneste med oplevelsen. Det lader til, at der er gået et eller andet galt da jeg slettede et Lampeudtag for at lave det til en dimmer. Jeg fik lært at projektfilen bare er en XML fil, og at døde links gør, at IHC Visual ikke kan indlæse den. Det kunne være en rar feature, hvis den validerede filen inden den sendte den afsted til controlleren
  2. Jeg ved ikke helt hvad der er sket, men på en eller anden måde er det lykkedes LK IHC Visual at uploade et projekt til min controller, den ikke selv kan læse. Alt fungerer fint, men jeg kan ikke lave ændringer. Er der nogen, der har oplevet lignende og fået rettet op på det? Jeg har hverken opdateret program eller firmware i mellemtiden. Jeg har gemt filen flere gange på min disk, da jeg havde besvær med at få genereret en rapport - disse kan jeg heller ikke læse op med Visual. Gudskelov har jeg en backup, men jeg har lavet en del ændringer i dag, som jeg helst ikke vil lave igen, hvis det kan undgås. Jeg ved ikke om det er relevant, men jeg havde netop lavet min egen funktionsblok til styring af UNI 400 IHC/SA dimmere. Der er også u-mappede outputs, hvis det har noget at sige.
  3. Glem dette spørgsmål. Er lettere målløs over at IHC controlleren accepterer HTTP trafik uden speciel opsætning.
  4. Er der nogen der ved om en af følgende er muligt: - Få controlleren til at køre TLS - Slå HTTPS fra på controller og bruge HTTP istedet - Få LK til at opdaterere controlleren til en sikker kryptering (rigtige løsning) Mit problem er, at i nyeste version af .NET samt .NET Core fjernes understøttelsen af SSL. SSL er usikkert og TLS bør benyttes istedet. Derfor vil jeg enten gerne skifte til TLS eller køre helt ukrypteret.
  5. Web Reference kom først, så kom WCF med Service Reference. Og her for nyligt er dette erstattet af 'Connected Service' i WCF til .NET Core. Jeg har et fungerende eksempel skrevet i C# til .NET Core, hvis i er interesserede. Det skal dog siges, at det pt. ikke fungerer på Linux pga. at servicen bruger SSL og ikke TLS. Jeg har raised et issue ved WCF Core teamet på Github, så må vi se hvad de svarer. Mit mål er at få min service til at køre i docker.
  6. Det virker af lang tid. Jeg prøvede lige med min egen løsning: ---------------------------------------------------- Resource changed: Spisebord: True Time taken: 1451 ---------------------------------------------------- Resource changed: Spisebord: False Time taken: 238 ---------------------------------------------------- Resource changed: Spisebord: True Time taken: 197 ---------------------------------------------------- Resource changed: Spisebord: False Time taken: 959 ---------------------------------------------------- Resource changed: Spisebord: True Time taken: 204 ---------------------------------------------------- Resource changed: Spisebord: False Time taken: 198 ---------------------------------------------------- Resource changed: Spisebord: True Time taken: 195 ---------------------------------------------------- Resource changed: Spisebord: False Time taken: 209 Her toggler jeg et input og venter på svar på at det er skiftet. Altså en helt roundtrip. Første kald tage 1451ms (altså 1½ sekund). Derefter går det langt stærkere. Det er selvfølgelig klart, at hvis der kommer databasekald mv. ind i billedet, bliver det kun langsommere. Selv sender jeg blot signalet videre via SignalR til alle forbundne browser, men det har jeg ikke timings på.
  7. Jep, jeg fik det implementeret i går med både input og outputs, uden de store problemer. Men tak for tipsene.
  8. Tak for tippet. OpenHab var så venlige at dokumentere hvad parametrene til kaldene var. Det står ikke velbeskrevet i LK's WSDL, så det var en stor hjælp.
  9. Nå, indtil videre fandt jeg den, jeg stødte ind i sidste gang, i ResourceInteractionService: - enableRuntimeValueNotifications(ArrayOfInt) //Liste af resurser, der skal notificeres - waitForResourceValueChanges(Int) //timeout i sekunder Så, ganske rigtigt: 1. Slå notifikationer til med enableRuntimeValueNotifications 2. Kald waitForResourceValueChanges, som giver værdier med det samme 3. Kald waitForResourceValueChanges, som ikke svarer før en værdi skifter eller timeouten udløber Kan det passe, at jeg skal sende hele listen af både inputs og outputs med hvis jeg vil notificeres om det hele? Tusinde tak for hjælpen allesammen, men især Mikkel. Dette er en lang bedre løsning ift. polling. Nu skal jeg lige overveje hvad der skal hvis nogen trykker på en knap før jeg kan hooke en ny 'event handler' på.
  10. Hmm.. Jeg har set den funktionalitet, men tænkte at siden der ikke var mulighed for bare at lytte på alt, ville det nok ikke virke så godt. Det vil jeg da lige prøve igen, da jeg ikke er vild med polling hvis det kan undgåes. Jeg fik tid til det i aften alligevel, så nu kan jeg godt se at inputs også har en value i getRuntimeValue(id), der kortvarigt bliver sat til true når jeg trykker. Så nu kan jeg reagere på dem, men vil da fluks se om jeg ikke kan få interrupts til at virke istedet. Det er det, jeg mener med controller. At det er dit program, der bestemmer hvad der skal ske - det er ikke blot et passivt interface. Det er præcist det samme, jeg laver - bortset fra at det er lavet i individuelle klumper (API'er der kan deployes til Docker) så at man kan bruge IHC delen uden de andre og vice versa. Ved ikke helt hvordan vi kom ind på dette. Der er ikke noget galt med at være controller. Problemet med mange (ikke din) løsninger er, at de alle gerne vil være 'master controller' og ikke lade andre styre dem udefra. Hvis bare alt havde et API, var jeg glad
  11. Det 'smukke' ved IFTTT er jo netop at de samler alle de mange løsninger i én pakke, som man selv 'programmerer'. Dvs. at der kun er én person, der skal skrive et interface til f.eks. Hue. Ulempen er, at det foregår online. Dvs. intet virker uden internet og svartiderne er længere. Hvis IFTTT var et bibliotek af programblokke man kunne downloade, ville det være genialt. Så ville Mikkel og undertegnede være fri for at selv at skulle kode hele interaktionen med diverse tjenester. Det er netop det, du efterspørger. Problemet er at alle gerne vil være controlleren og kun få gider lave åbne interfaces. Derfor har vi IFTTT, Openhab, Smarthome, SmartThings, etc. Jeg prøver lige at kigge svaret fra IHC controlleren igennem en ekstra gang i morgen og ser om jeg kan finde Inputs også.
  12. Kandersen: Det er sikkert let med IHC Captain, men jeg tror ikke jeg kommer til at erstatte min løsning med dette, da det lader til at have et lidt andet scope end mit projekt. Captain lyder til at være en controller, hvorimod jeg udelukkende beskæftiger mig med IHC. Derfor gik mit spørgsmål mere på hvordan IHC Captain havde gjort ift. LK Controlleren. Helt enig med skræddersyning. Men LK er langt bedre end f.eks. Danfoss. Jeg ville så inderligt ønske at jeg kunne styre min gulvvarme (master regulator). LK har trods alt et semi-åbent API, selvom REST havde været at foretrække. Men forståeligt nok med SOAP, alderen taget i betragtning. I mine løsninger har jeg pt. integration med Netatmo, Kodi (tidl. XBMC), Wake-on-LAN til PC'er og mPower fra Ubiquiti. Men en IHC Captain, der kunne interface med IFTTT ville da sikkert være et hit for mange. Så fik man jo styring af Hue, Sonos og halvdelen af verden 'gratis'.
  13. Min løsning står og poller API'et så hurtigt den kan - typisk 2-3 gange i sekundet. Her kan jeg læse hele projekt status. Men jeg tænker, at indgangene ikke har nogen 'status' - altså enten at det ikke kan lade sig gøre at aflæse om der er trykket eller ej - eller at jeg i givet fald skal ramme API'et i lige præcis den period, hvor knappen bliver trykket ind. Det er derfor jeg tænkte det, som du også beskriver - at lave en funktionsblok/kip, der tænder et output, der ikke er forbundet til andet end et 24V output. En 3. løsning kunne være at erstatte et 24V Output med en raspberry, hvis det ellers er klart hvordan IHC controlleren kommunikerer med modulerne (I2C?) Det tænker jeg dog er lidt mere risikabelt. Jeg ved ikke helt hvad IHC Captain er, men det undersøger jeg da lige. Tilføjet efter at have hørt om eksistensen af IHC Captain: Ja ok, jeg kan se, at der nok er en del overlap i IHC Captain og det, jeg laver. Kan du i IHC Captain få en notifikation når en indgang skifter? Og vil du i så fald af med hemmeligheden? Det kan sagtens være en forkert antagelse fra min side, og at inputs skifter hver gang man trykker. Hvis det er tilfældet, kan jeg uden de store armbevægelser også få inputs med, hvilket vil være en langt bedre løsning end microcontroller + 24V output.
  14. Jeg har fået skrevet et .NET Core program, der kan opfange når et output skifter, men jeg ville gerne kunne fange når nogen trykker på en knap, hvad enten er der wireless eller kablet. Det lader ikke til at være muligt at fange disse notifikationer i deres soap API i controlleren, så jeg tænkte det ville være muligt, hvis jeg: - Købte et 24V Output modul - Smed en Raspberry Pi, ESP8266 eller Arduino på dette modul. (der skal nok lige reguleres 24V -> 3.3V for RPi på en eller anden måde) - Programmerede de ting, jeg gerne ville i IHC Visual, så den 'tænder' for microcontrolleren, der så sender et signal til hvad så end, det er jeg skal gøre. Er der nogen, der kan komme på en bedre løsning?
×
×
  • Create New...

Important Information

Privacy Policy 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.