This project contains an unofficial dotnet IHC client API for IHC (Intelligent House Concept). The project is NOT affiliated with- or supported by LK / Schneider Electric.
Since dotnet core (and later dot net v5.0) did not officially support SOAP webservices, the SDK API is based on a combination of code generated by dotnet-svcutil from downloaded WSDL files in combination with custom serialization and a higher-level wrapper for easier usage.
The Ihc namespace contains API service classes for all IHC controller web services such as AuthenticationService, ConfigurationService, ControllerService, MessagecontrollogService, ModuleService, NotificationManagerService, ResourceInteractionService, TimeManagerService, UserManagerService and OpenAPIService (*). The API service classes have a 1-1 relationship
with backing soap services and soap artifacts but are on a higher level to make the API easy to use and to better isolate developers against IHC SOAP contract changes. SOAP details are thus not exposed. Instead, methods in these service API classes use their own high-level data models declared in the same Ihc namespace.
*) The new OpenAPIService is for v3.0+ controllers only. I am unsure of the quality of it. Usage is not recommend it at the time of writing (2021).
Each service API class must be instantiated with new. Provide a logger and a IHC controller IP address in the constructor. Unless you are using the OpenAPIService, you generally need
to login using AuthenticationService before using the other services.
You can use a Microsoft.Extensions.Logging.Abstractions.NullLogger<YourClass>.Instance as a dummy logger if you want.
The provided API is by design free of SOAP inhertiage and completly async. For long pooling the API use async enumerables are used instead of traditional events/callbacks (see ResourceInteractionService.GetResourceValueChanges).
Each service class is internally wrapping a SoapImpl class based on a specific Ihc.Soap.*.* interface generated from the WSDL. These and
the related low level SOAP data structures in Ihc.Soap.. namespaces are for internal use (should not be exposed).
The AuthenticationService and ResourceInteractionService services are essentially feature complete. The remaining servies are currently only partically implemented.
All low-level wiring within SoapImpl ought to work though, so in most cases it should be relatively easy to add a missing high-level function (possibly needing a new high-level data structure as well).
Unless you are using the new OpenAPIService (not recommended, see above comment), Your code needs to Authenticate before calling IHC API's and Disconnect when finished as shown below. Setting the IHC application name is important for controllrs before v3.0 as the default is unlikely to work.
var endpoint = "http://<YOUR CONTROLLER IP ADDRESS>";
var noLog = NullLogger<Program>.Instance;
var authService = new AuthenticationService(noLog, endpoint);
var login = await authService.Authenticate("<MY IHC USERNAME>", "<MY IHC PASSWORD>", "administrator");
// Instantiate additional IHC Services and invoke them here.
var logoff = authService.Disconnect(); While it is possible to use the client in both simple console apps
and in AspNetCore apps, it is generally recommended to use
Microsoft host services in order to ensure orderly shutdown, such
as Disconnect being called when aborting with CTRL-C etc. AspNetCore apps all use hosting. For command line apps you can use .NET Generic Host.
In the rare event that WSDL must be changed and new generated code is needed, one can use the download_wsdl.sh and generate.sh files for this on MacOS (no scripts currently avilable for Windows/Linux). The output is placed in the generatedsrc folder. These files should not be changed manually. Note that wget and the dotnet-svcutil tool must be installed for the above scripts to work.