Missing strong typed Entity in generated code

[rumbu13]

The problem

Services code generator generates extension service methods for non-existing entity domains.

• Services are generated by extracting domains from available services.
• Entity classes are generated by extracting domains from entity states. If no entity is available, no strong typed entity class is generated to be used by the corresponding service.

Example

SmartThinq integration is exposing several services related to humidifiers. Among them set_fan_mode:

//auto-generated code by nd-codegen:

public static void SetFanMode(this HumidifierEntity target, SmartthinqSensorsSetFanModeParameters data)
{
	target.CallService("set_fan_mode", data);
}

//... other services/overloads excluded for brevity

Since I don't have any device to expose a HumidifierEntity, no code is generated for:

• HumidifierEntity
• HumidifierAttributes

Workaround

I am maintaining manually written definitions for HumidifierEntity and HumidifierAttributes in a separate file with the same namespace as the generated code.

Environment

• NetDaemon release with the issue: 22.27.2
• Operating environment (Home assistant Add-on/Docker/Dev setup): Add-On

[helto4real]

@FrankBakkerNl what you think of this one?

[FrankBakkerNl]

Right now we only have strings and numerics, no DateTime. This does not use generics (because we already had a LOT of type arguments and generic complexity here). Adding DateTime might make it all even more complicated. I do understand why you would want it. So it would be nice to solve it somehow.

I would prefer to not to hard code this. Maybe make it configurable what basetype should be used per domain. We could use the same for the attributes classes to use which is now based on matching the type name. Let's discuss more on discord.

[skotl]

C#11 introduces generics and interfaces for numbers so this would likely be simpler when v11 arrives.

Regards, Scott

—-

Sent from a mobile device

—-

On 19 Jul 2022, at 16:20, Frank Bakker @.***> wrote:



Right now we only have strings and numerics, no DateTime. This does not use generics (because we already had a LOT of type arguments and generic complexity here). Adding DateTime might make it all even more complicated. I do understand why you would want it. So it would be nice to solve it somehow.

I would prefer to not to hard code this. Maybe make it configurable what basetype should be used per domain. We could use the same for the attributes classes to use which is now based on matching the type name. Let's discuss more on discord.

— Reply to this email directly, view it on GitHubhttps://github.com/net-daemon/netdaemon/issues/728#issuecomment-1189115201, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAA7KQEFNA6DZQDLEENBYTDVU22R3ANCNFSM53N6I6OA. You are receiving this because you are subscribed to this thread.Message ID: @.***>