Releases: net-daemon/netdaemon
Testbuild ignore
0.4.1 Try fix the custom build
0.4.0-alpha Release
By setting the HASS_DISABLE_LOCAL_ASM=true environment variable you now can disable loading of locally built apps. This is needed to build custom docker containers depending on other packages than core ones. This prohibit NetDaemon to load the assemblies and use the .cs files provided in the app folder.
Upgraded HassClient dependency to newest version.
From now on using following version scheme:
0.x.y, where x is a new feature and y is fix releases
0.3.7-alpha Release
Exclude auto generated code from Execute/ExecuteAsync warnings
0.3.6-alpha Release
Big release this time, we are getting closer and closer to beta stage.
NetDaemonApp is abstract
The NetDaemonApp should be an abstract class. The design intent is not to use it directly. Each app in NetDaemon should inherit from it.
Warn users not closing with Execute and ExecuteAsync
Added error message to users if forgetting to close command chains with .Exectute() or .ExecuteAsync(). This feature will not do that automatically cause it is important the programmer has full control.
In some cases there is a problem with warning users missing Execute and ExecuteAsync. In those cases the users need to have a way to disable those warnings since it is the intent of the code.
The code below shows example of how to supress missing Execute warnings on a function.
public class SupressLogs : NetDaemonApp
{
[DisableLog(SupressLogType.MissingExecute)]
public override async Task InitializeAsync()
{
// All warnings in this is supressed
Entity("Test");
await DoStuff();
}
public async Task DoStuff()
{
// This is not supressed
Entity("Test");
}
}PDB information
Also PDB symbols been added to compilation to show more accurate information when something breaks in user
code
Global thread safe shared in-memory storage
Add a global shared in-memory state for safely share objects between apps or within app. In any app you can now use Global[key] = value;. It is shared statically and uses the ConcurrentDicitionary<string,object> internally.
Redesign of the reconnect logic
Before: Internally tried to reconnect
Now: Reconnection logic is pushed to the service. This means that with a disconnect from Home assistant the NetDaemon will be reloaded entirenly and everything is in start-up state. Beware that saved memory state is gone when app is reloaded. Use Store object to persist state that will be reloaded att startup.
0.3.5-alpha Release
Hi folks, this is a nice but potentially breaking release so pay attension.
Entitystate unavailable are treated as null
The changes the behavior for entity states that are unavailable. Any state that is unavailable is set to null value. You now do not have to check for unavailable in the scenarios you expect state to be a number as an example.
It can be breaking if you rely on:
if (entity.State == "unavailable") ...after:
if (entity.State is null) ...The code below breaks before this release but will be fine this release since State is null if unavailable.
public async override Task InitializeAsync() => Entity("sensor.hacs")
.WhenStateChange((n, o) =>
o?.State != n?.State && n?.State > 0)
.Call(async (entityId, newState, oldState) =>
{
var serviceDataTitle = "Updates pending in HACS";
var serviceDataMessage = "There are updates pending in [HACS](/hacs)\n\n";
List<object> repositories = newState?.Attribute?.repositories || new List<object>();
foreach (IDictionary<string, object?> item in repositories)
{
serviceDataMessage += $"- {item?["display_name"].ToString()}\n";
}
await CallService("persistent_notification", "create", new
{
title = serviceDataTitle,
message = serviceDataMessage
}, true);
}).Execute();Home Assistant switches for app-switches
This PR is breaking. Before the app id was netdaemon.[appid] after change switch.netdaemon_[appid]
Makes a real switch of app companion switches. You can now use real Home Assistant switches to turn on/off/toggle apps. As before you need to call netdaemon.reload_apps to make your changes.
0.3.4-alpha Release
- More improvements in logging
- S6 support and new smaller base for docker images
0.3.3-alpha Release
A path to the add-on was updated to reflect the docker change
0.3.2-alpha Release
This release is alot of logging and some stability fixes for NetDaemon.
- New logging using Serilog, sadly Serilog does not support coloring on add-on but when providing the -t to docker run colors will be shown for docker users. see docker install instructions
- New version of HassClient that makes it possible to add logging of messages for debugging
- Loglevel can now be set on docker containers using environment var.
- Application name are shown i logging from user apps when using the Log command.
- Specific LogWarning, LogError etc. is now provided for more readable code. All Log use aspnet logging style
Log("Hello {name}", namevar);do not use"Log($"Hello {namevar}")since you miss out on strucured logging provided by ILogger interface and Serilog.
0.3.1-alpha Release
Bugfix for dependent apps not working properly
Get application instance and application dependencies
This releas makes the NetDaemon support to get singleton references to other running instances of an app.
var lightManagerApp = GetApp("light_manager");this also requires support to do dependencies in yaml config
app:
class: MyApp
dependencies:
- light_managerCamera fluent API support
In the effort to get more specific support for enitity domains in the fluent api, the camera is now added. Also it is first of many refactorings of the fluent API to make it simpler and easier to maintain.
The autogenerated camera entities will now use this interface instead.
Sample below:
await Camera("camera.camera1")
.Snapshot("/config/www/snapshots/cam1.jpg")
.ExecuteAsync();0.3.0-alpha Release
Get application instance and application dependencies
This releas makes the NetDaemon support to get singleton references to other running instances of an app.
var lightManagerApp = GetApp("light_manager");this also requires support to do dependencies in yaml config
app:
class: MyApp
dependencies:
- light_managerCamera fluent API support
In the effort to get more specific support for enitity domains in the fluent api, the camera is now added. Also it is first of many refactorings of the fluent API to make it simpler and easier to maintain.
The autogenerated camera entities will now use this interface instead.
Sample below:
await Camera("camera.camera1")
.Snapshot("/config/www/snapshots/cam1.jpg")
.ExecuteAsync();