Skip to main content

Instance applications

Instancing applications can be done in several ways. Here are the ones supported by NetDaemon.

Instancing an application using an attribute

Instance any class with the [NetDaemonApp] attribute:

public class MyApp


If you need async initialization to be called after the app is instanced you can use the interface IAsyncInitializable.

public class MyAsyncInitializableApp : IAsyncInitializable
// async
public Task InitializeAsync()
// do some async initialization here

Instancing an application configuration using yaml

You can use a YAML configuration file to provide configuration details that are injected into the constructor using the IAppConfig<> interface.

This is a sample YAML config file, C# config class, and app class with config injected into the constructor:

LightConfig: # This is  the fully qualified name of the config class
TheLight: light.kitchenlightwindow # this is example of custom configuration
public class LightConfig
// This property will be automapped with ´the_light´ config
// Using autogenerated entity classes in HassModel
public LightEntity? TheLight { get; set; }

public class LightManager
/// <summary>
/// Initialize, is automatically run by the daemon
/// </summary>
public LightManager(IAppConfig<LightConfig> config)
// Turn on the light when loading


NetDaemon can inject a logger into your application instance when you specify a scoped ILogger parameter in your application's constructor.

For example, if your application is called FrontDoorLocker then specifying a parameter of type ILogger<FrontDoorLocker> into the app's constructor will ensure that an appropriate logger is injected. In this example the FrontDoorLocker constructor stores the logger into a class field so that it can be used by subsequent methods:

private readonly ILogger<FrontDoorLocker> _logger;

public FrontDoorLocker(IHaContext ha, ILogger<FrontDoorLocker> logger)
_ha = ha;
_logger = logger;

_logger.LogInformation($"{nameof(FrontDoorLocker)} started");
// ... //

Log levels in brief

The logging subsystem (Serilog) defines several levels of log events. From low to high these are Verbose, Debug, Information, Warning, Error and Fatal. You can set the minimum level that you wish to log which means that only events at that level or higher will be logged.

NetDaemon defaults to the Debug level, but you can override this in your appsettings.json file:

"Logging": {
"MinimumLevel": "Debug"

Within your application you will use one of the _logger methods to write a message at the desired level.


ILogger is a Microsoft-defined interface and there is (oddly!) not an exact match of ILogger methods to Serilog levels.

  // See code sample above for setting up the logger in your constructor

_logger.LogTrace("This is at Verbose level");
_logger.LogDebug("This is at Debug level");
_logger.LogInformation("This is at Information level");
_logger.LogWarning("This is at Warning level");
_logger.LogError("This is at Error level");
_logger.LogCritical("This is at Fatal level");

Viewing log messages

Within the development environment you can view log messages inside the console view (or the container console view if you're debugging in containers).

When your application is deployed to your Home Assistant production environment then you can view the logs in Home Assistant by clicking on: Settings -> Add-ons -> NetDaemon VX.X (.NET X) -> Log


Logs are cleared each time you restart the NetDaemon add-on (or the Home Assistant server).

More advanced logging

One of the goals of the NetDaemon template app is that it should work out of the box with minimal configuration. For that reason, the template ships with a "Default NetDaemon Logging Configurator", which supports all of the functionality described on this page, but nothing more.

If you are familiar with Serilog or other .NET loggers and want to use more advanced techniques such as writing to log files or to remote log servers then please read the Custom logging page, which shows how to create and configure a custom logger.