Microsoft .NET API/SDK

[TGF Rules]

Hej AlleJeg er ny bruger her, og har søgt på forum men kan ikke helt finde svar på mit spørgmål.Er det muligt at styre sit IHC med et .NET API eller på anden måde fra kode?

[Thomas H. Kristensen]

Nej, Desværre findes der ikke ikke API til controlleren. Controlleren m. Visual kan dog fjernbetjenes vha de medfølgende java applikationer og via email.Om man så derigennem kan sniffe sig til et API ... ?Der var nogen som på et tidspunkt eksperimenterede med at droppe controlleren og styre input og output modulerne direkte fra en linux ting, men det er vist længe siden. Og det understøtter jo så heller ikke wireless.

[McenterFreak]

THK skrev:

Nej, Desværre findes der ikke ikke API til controlleren. Controlleren m. Visual kan dog fjernbetjenes vha de medfølgende java applikationer og via email.Om man så derigennem kan sniffe sig til et API ... ?Der var nogen som på et tidspunkt eksperimenterede med at droppe controlleren og styre input og output modulerne direkte fra en linux ting, men det er vist længe siden. Og det understøtter jo så heller ikke wireless.

Og jo mere jeg tænker over det, synes jeg det er en god beslutning LK har taget der. Det er jo trods alt 230/400 volt vi ligger og leger med. Hvis LK skulle stå inde for et API der håndterede disse spændinger, ville det være totalt uoverskueligt hvem der har ansvaret for en evt. fejlprogrammering. Jeg er sikker på at hvis der sker skader i forbindelse med IHC, som det er nu, så vil LK være ansvarlig hvis det er en konstruktions eller software fejl. Det ville de ikke være hvis man selv fik lov til at programmere hardwaren uden om LKs software.Men, indrømmet, det kunne være fedt at man selv kunne kode til et IHC API

[hhg]

At droppe controlleren vil jeg give dig ret i ingen mening giver.Men at stille det API som f.eks ServiceView bruger til almen rådighed kan jeg ikke se noget problem i. Du vil ikke kunne provokere "farlige situationer" på den måde.ServiceView m.m. benytter sandsynligvis SOAP/Webservices, men det sker over https, så det er ikke sådan at "sniffe"....En anden mulighed er at opbygge et WebView med de funktioner du ønsker at tilgå fra din .Net applikation, og så lade denne benytte dette - Tænk cURL etc.Til de tidligere udgaver fandtes der vist et IHCService program, der kunne bruges til at sætte og aflæse controlleren "udefra" - Kender det ikke i detaljer, har kun haft V2 controller.MvhhhgPS: Prøv

https://controllerip/wsdl/authentication.wsdl

som en start... Men det er nok rimeligt umuligt at komme videre uden hjælp/dokumentation fra LK

[TGF Rules]

Tak for alt jeres feedback!Jeg tror som sådan godt man kan "sniffe" koden fra Java, og portere det til C#. Spørgsmålet er bare om man har lyst til det.Hvis der var LK's side ikke er lagt op til en god/sikker måde at styre systemet på, skal man passe på med at kaste for meget tid efter det.Når man samtidigt kigger på prisen, begynder jeg dog at finde IHC mindre gunstig i forhold til mine behov.Jeg tror jeg kaster mig over Z-Wave der lader til at være billigere, men også have et andet fokus en IHC.

[hhg]

Ingen tvivl om at Z-wave er mere "åbent" end IHC. Og jeg kiggede en del på det, inden jeg fik installeret IHC i mit eksisterende hus. Følgende lå til grund:[ul][li]Meget lidt Z-wave materiel i "fuga" størrelsen[/li][li]Få elektrikkere kender til det - svært/dyrt at få installeret[/li][li]Ikke alt Z-wave kan snakke sammen (Der er en årsag til sider som http://zwaves.dk/wiki/index.php?title=Produkter)[/li][li]Prisen på Wireless IHC og Z-Wave er ca. den samme, måske IHC lidt billigere, men en 1:1 sammenligning er svær, da der ikke er produktmatch[/li][/ul]Men omvendt er der jo også Z-Wave komponenter, som jeg savner hos IHC, specielt trådløse PIRs etc.Nu kører det meste af huset IHC på "lyset", men på sigt håber jeg da på integrationsmuligheder, så de øvrige ting kan komme med.

[Kvade]

Fandt lige denne webservice også:http://controllerip/wsdl/controller.wsdlHar ikke kigget på de funktioner der er, men måske man kan bruge det til noget.

[Kvade]

Faldt lige over lidt flere i forbindelse med decompilen: , "/ws/ModuleService" = "/wsdl/module.wsdl");"/ws/ResourceInteractionService" = "/wsdl/resourceinteraction.wsdl");"/ws/ControllerService" = "/wsdl/controller.wsdl");"/ws/UserManagerService" = "/wsdl/usermanager.wsdl");"/ws/ConfigurationService" = "/wsdl/configuration.wsdl");"/ws/TimeManagerService" = "/wsdl/timemanager.wsdl");"/ws/NotificationManagerService" = "/wsdl/notificationmanager.wsdl");"/ws/EmailControlLogService" = "/wsdl/emailcontrollog.wsdl");

[Kvade]

Så lykkedes det at lave en funktion (i .NET) som logger ind i controlleren, nu mangler jeg så bare at finde ud af sessionshåndteringen i API'et, da den ikke vil tillade at køre kommando'er til f.eks. tænd/sluk.

[McenterFreak]

Nu ikke for at være en kedeligPer, men til dem der har tænkt sig at udforske det her, pas nu på hvis i ikke er 100% sikre på hvad i gør, det er altså 230/400 volt der leges med. Jeg har nada forstand på hvad der foregår i den controller, og vil derfor ikke begynde at rode med det.

[Per Aspelini]

Go Kvade, go kvade … :cheer: Keep up the good work, dette lyder interresant./Per

[hhg]

Sejt gået, Kvade, ser frem til at høre mere....ResourceInteractionService ser ud til klart at være det mest interessante til at sætte og læse udgange (setResourceValue)MCenterFreak: Der "leges" ikke mere med 220 Volt, end der gør når man sætter udgange i ServiceView - I en "almindelig" IHC installation er der jo ingen udgange, der er "farlige" at aktivere.Alt hvad controlleren gør er jo at aktivere et relæ i et outputmodule eller i et trådløst modul, om det sker på baggrund af et Visual IHC-program, ServiceView, SceneView eller at man kalder en webservice (som jo er det ServiceView/SceneView benytter) gør jo ingen forskel.... Mvhhhg

[McenterFreak]

hhg skrev:

Sejt gået, Kvade, ser frem til at høre mere....ResourceInteractionService ser ud til klart at være det mest interessante til at sætte og læse udgange (setResourceValue)MCenterFreak: Der "leges" ikke mere med 220 Volt, end der gør når man sætter udgange i ServiceView - I en "almindelig" IHC installation er der jo ingen udgange, der er "farlige" at aktivere.Alt hvad controlleren gør er jo at aktivere et relæ i et outputmodule eller i et trådløst modul, om det sker på baggrund af et Visual IHC-program, ServiceView, SceneView eller at man kalder en webservice (som jo er det ServiceView/SceneView benytter) gør jo ingen forskel.... Mvhhhg

Jeg siger jo ikke man ikke skal gøre det man nu har lyst til, men er der noget der "brænder af" så kan LK jo ikke gøres ansvarlige for det, hvis man selv har kodet, uden om LK's snitflade.Grunden til jeg siger det, er at jeg selv havde 3-4 dimmere der begyndte at ryge, og udsendte flammer. Jeg opdagede det heldigvis. De blev skiftet uden problem, og LK indrømmede at de havde et problem med de gamle dimmere. Lad os nu tænke situationen, hvor jeg i samme setup havde programmeret, i Visual C++, hvordan disse dimmere skulle fungere, med et API som en eller anden havde strikket sammen, og der var gået ild i huset. Hvem har så ansvaret her?Tænk over det!At man kan gøre en masse i ServiceView, SceneView osv, er jo stadig styret af LK og dermed deres ansvarDet korte af det lange: Gør nu som i har lyst til, ville bare lige påpege at der kunne være aspekter der skulle tænkes over

[hhg]

McenterFreak skrev:

Grunden til jeg siger det, er at jeg selv havde 3-4 dimmere der begyndte at ryge, og udsendte flammer.

Interessant (og skræmmende) historie. Er det en du vil uddybe? (Eller det har du måske allerede gjort i en anden tråd?)Hvilken type dimmere? Og hvordan var de koblet til controlleren?Var det en defekt i dimmerne eller i funktionsblokken, der styrede dem?Uden at vide det kunne jeg forestille mig at almindelige touch dimmere ikke er beregnet/dimensioneret til at man "holder knappen inde i timevis" men det er jo netop noget en softwarefejl kan gøre.... Jeg forstår din pointe!Den måde jeg forestiller mig at bruge et API på er til at kanalisere events fra eksterne systemer ind til IHC controlleren som inputs på funktionsblokke, og så lade disse gøre det ønskede på vanlig vis.

[Chris Frost]

Synes det er super sejt det i har gang i!!!Kan ikke lige se hvad alle de advarsler og dårlige undskyldninger skal ind i denne tråd! Er nice der findes nogen der er noget klogere end gennemsnittet, og kan lave de ting LK ikke kan finde ud af at komme frem med!Keep up the good work boys

[Thomas H. Kristensen]

Jeg er meget enig. Et API som kan tænde og slukke for funktioner står øverst på min ønskeseddel.Glæder mig til at høre mere fra Kvade :cheer: Husk at alt non-Open Source software vil blive "åbnet" på et eller andet tidspunkt - enten af leverandøren eller af folket. Især når man basere sig på Linux! Fy fy LK - Det kan Linus Torvalds ikke lide!Karma til Kvade.

[Kristian Poulsen]

Kvade skrev:

Fandt lige denne webservice også:http://controllerip/wsdl/controller.wsdlHar ikke kigget på de funktioner der er, men måske man kan bruge det til noget.

Hvilken controller virker det med, og skal der være en viewer til controlleren?Jeg har selv en 1.2 controller med viewer og eksperimenterer lidt med at benytte e-mail interfacet til at overvåge og styre den eksternt, dels pga min port 80 er lukket i min adsl-router, dels pga den manglende mulighed for opsamling af data.

[McenterFreak]

hhg skrev:

McenterFreak skrev:

Grunden til jeg siger det, er at jeg selv havde 3-4 dimmere der begyndte at ryge, og udsendte flammer.

Interessant (og skræmmende) historie. Er det en du vil uddybe? (Eller det har du måske allerede gjort i en anden tråd?)Hvilken type dimmere? Og hvordan var de koblet til controlleren?Var det en defekt i dimmerne eller i funktionsblokken, der styrede dem?Uden at vide det kunne jeg forestille mig at almindelige touch dimmere ikke er beregnet/dimensioneret til at man "holder knappen inde i timevis" men det er jo netop noget en softwarefejl kan gøre.... Jeg forstår din pointe!Den måde jeg forestiller mig at bruge et API på er til at kanalisere events fra eksterne systemer ind til IHC controlleren som inputs på funktionsblokke, og så lade disse gøre det ønskede på vanlig vis.

Der er ingen der rigtigt har "vedkendt" sig hvad der gjorde at de dimmere stod af. Det er/var 400 UNI dimmere. De er koblet til af en trikker, på helt autoriseret vis. Funktionsblokken er uændret. Efter udskiftningen fungerede alt et stykke tid. Men nu er der problemer igen, så jeg har for en sikkerheds skyld taget fasen fra. Men det betyder jo ingen lys i de rum de dækkerJeg er overbevist om at der et eller andet sted er en "der holder knappen inde" rent programmeringsmæsigt, og derfor brænder de af. Nu er der jo kommet nyt firmware og nyt Visual, så jeg satser på en opgradering. Men som sagt, så er der ikke "alternativt" SW ind over, så LK kommer under alle omstændigheder til at finde en løsning på det her

[Kvade]

Opdatering:Javakoden som jeg fik decompileret var ikke videre detaljeret mht. dokumentation, så jeg har i stedet dekrypteret HTTPS kommunikationen mellem JNLP applikationerne for at finde frem til headeren på kaldene. Det ser ud til at man efter authenticate i Authentication WS'en får returneret en set-cookie = JSESSIONID= som efterfølgende skal returneres for hver kommando der skal eksekveres. Det medfører desværre også at .NET's standard måde at lave webservice clienter på ikke dur (da man ikke har direkte adgang til selve HTTPRequestet). Derfor skal man sikkert bygge sit HTTPRequst op fra bunden, hvilket kræver lidt mere arbejde.Forhåbentligt har jeg snart en lille app som kan bekræfte/afkræfte om ovennævnte sessionsbegreb er korrekt.

[Kenneth Marsner]

Jeg vil da godt høre mere om jeres software udvikling. Man må kunne en del via web servics. Det viser LK jo selv, efter de har anoceret deres IPhone applikation.http://www.lk.dk/sites/Lauritz%20Knudsen/privat/det-intelligente-hjem/ihc-control-tilbehor.page

[Chris Frost]

199,- Kan godt forstå de gør alt for at lukke deres system...

[Jan Jung-Jensen]

Kvade...

Keep up the good work

:woohoo: :woohoo: :woohoo: :woohoo:

[Tais]

Kvade har helt ret :)Her er en lille .NET webservice der laver lidt basal kom. med IHC.Koden er ikke super pæn men den burde virke...kald getRuntimeValues for at se status på alle outputskald getAllDatalineOutputs for at få IDer på alle outputskald setRuntimeValue for at sætte et bestemt ID til true eller falsehusk at den bruger som anvendes skal være administratorLidt hjælp til det videre arbejde WSDLerh_t_t_p_s://ip/wsdl/authentication.wsdl h_t_t_p_s://ip/wsdl/module.wsdl h_t_t_p_s://ip/wsdl/resourceinteraction.wsdl h_t_t_p_s://ip/wsdl/controller.wsdl h_t_t_p_s://ip/wsdl/usermanager.wsdl h_t_t_p_s://ip/wsdl/configuration.wsdl h_t_t_p_s://ip/wsdl/timemanager.wsdl h_t_t_p_s://ip/wsdl/notificationmanager.wsdl h_t_t_p_s://ip/wsdl/emailcontrollog.wsdl webservicesh_t_t_p_s://ip/ws/ModuleServiceh_t_t_p_s://ip/ws/ResourceInteractionServiceh_t_t_p_s://ip/ws/ControllerServiceh_t_t_p_s://ip/ws/UserManagerServiceh_t_t_p_s://ip/ws/ConfigurationServiceh_t_t_p_s://ip/ws/TimeManagerServiceh_t_t_p_s://ip/ws/NotificationManagerServiceh_t_t_p_s://ip/ws/EmailControlLogServicetoolsFiddler - undersøg https kom.soapUI - test kom. med IHC [file name=IHCService.txt size=10512]http://ihc-user.dk/media/kunena/attachments/legacy/files/IHCService.txt[/file]

IHCService.txt

[Lars Jacobsen]

Er helt grøn på .NET ASP og lignende så derfor lige et par basale spørgsmål:Hvad skal der til for at anvende jeres kode ?Hvad kan man se/styre ?Der er/har været andre tiltag igang for at kunne kommunikere direkte med controleren med andet end LK´applikationer, men hvilken løsning man skal gå efter kræver jo lidt indsigt.

[Kristian Poulsen]

Hej LarsJeg vil gerne forsøge at svare på dine spørgsmål: 1 - Hvad skal der til for at anvende jeres kode ?2 - Hvad kan man se/styre ?Hvad skal der til for at anvende jeres kode ?Hvis du skal have noget ud af koden, så kommer du længst hvis du har en udgave af Visual Studio til at køre det fra. Koden fra tais og kvade vil jeg betragte som en slags proof of concept - altså forstået på den måde at det er eftervist at man kan kommunikere med controlleren. Du skal derfor ikke forvente at koden har status af et færdigt API på nuværende tidspunkt.Hvad kan man se/styre ?Dette spørgsmål er meget interessant. Pga ferie og børn, har jeg kun overfladisk kigget på koden, men umiddelbart vil jeg tro at det kun er fantasien der sætter grænser.De Web Service interfaces der er fundet frem til, lader til at understøtte stort set alle de metoder der er behov for til at kommunikere med controlleren, men det er jo svært at vide endeligt uden dokumentation fra LK.Derfor vil det være lidt af et detektivarbejde at finde frem til hvilke metoder der benyttes til hvilke formål, og til det kan man benytte Fiddler og SoapUI til reverse engineering.Personligt synes jeg at potentialiet er meget stort og Web Services vil absolut være den snitflade som jeg vil foretrække at arbejde med.