I could not find the canonical way to do what I’m looking, maybe I have a nomenclature problem. My scenario is:
I have a lot of boiler plate for aqara light switches. My main idea was to put all the boiler-plate into a AppDaemon script and let the AppDaemon create the entity through the ZiGate platform, with all the boiler plate, then create the template light related to the previously created switch.
And my question: can I create an entity, through a platform, with AppDaemon? How?
This creates an entity, but not through a platform AFAIU.
My goal is to create the entity and set up all its internal stuff --configuration which typically is in the configuration. In my scenario, that would be: all the zigbee parameters for the “real” switch and the template string for the template one.
I understood that set_state doesn’t use any platform to create the entity, so it doesn’t allow me to configure it properly. Am I right?
set_state works perfectly for sensors.
you can create attributes and everything that is needed for a sensor.
i havent found a way to create anything else from outside HA properly. not with AD or any other way.
But… how do you define the platform then? I mean, in my scenario, the switches are under the zigate platform --although I could find another examples. And the platform is not an attribute. So using set_state doesn’t solve the scenario, does it? Or am I missing something?
platform is something that is used in the configuration files to set specific attributes for an entity.
after the start from HA platform doesnt do anything for a sensor, in my eyes.
but like i said, you cant create a switch from outside HA. a switch needs to be in the configuration from HA or it doesnt work correctly.
i love to find another way to create entities, without editing the config from HA and restarting HA, but i havent found a way. (except for sensors that work perfectly)
Well I just try to take stuffs from HA as much as I can. Like if I can get some via MQTT, I am so not using HA.
In the process of moving my zigbee devices to a zigbee to mqtt gateway using this; and it works so great, even more stable than the HA compoenent itself. I pick them up all in App daemon directly, and just by passing HA completely.
Still had to setup the binary_sensors in HA, so i can have a visual state of the doors and windows, but that will change soon.
This is my move forward now. HA simply a state machine for stuffs I can’t get over mqtt for now 
But with the new plugin architecture, I am so looking forward to doing different stuffs from AppDaemon directly. So rather than AD connect to HA, HA actually will connect to AD and AD is my main focal point for all my stuffs.
You can create entities using MQTT discovery, if that helps
What MQTT Discovery is doing, under the hood, is using async_load_platform. But I haven’t found any way to use async_load_platform-ish mechanisms from outside the home-assistant codebase. I thought that there would be a hook that allowed me to call async_load_platform from AppDaemon, and thus I would be able to dynamically create the entities. But so far, I haven’t found it.
i really need to start using mqtt 
just out of curiosity:
when i add a switch to mqtt it gets picked up without restarting HA, and it gets placed inside the configuration files?
in that case we can use AD to create a switch by using mqtt.
at the moment i let AD create parts from the config from HA (mostly input_booleans), but it needs a restart from HA to get activated.
Yeah MQTT rocks.
BUT, this discover is prepared to detect MQTT components (like MQTT switches, MQTT covers, etc.). It is not intended to be a tool to “automagically add entities on the fly”. And I think that MQTT discover should not discover non-MQTT entities, as that would be extremely confusing.
Having a different, let’s say service called homeassistant.load_platform which internally calls the method async_load_platform and allows to dynamically add an entity (given its platform and configuration) would be a nice thing for debugging purposes and would allow AppDaemon applications to dynamically add stuff.
Initially, I thought that maybe this feature already existed and I could not find it, but I have kept looking and I think that it indeeds does not exist… yet.
Let me answer that, going a little bit off topic here 
The entity gets picked up just as you say, but the configuration files are not touched. Typically, the MQTT message containing the configuration has the retain flag, so every time home assistant restart it picks the message and thus recreates the component with the most up-to-date configuration available in MQTT (i.e. the last one).
what is a non-MQTT entity?
if i create a switch in AD and add that to my MQTT broker, then i have a virtual MQTT switch.
i dont see the difference between:
a) an esp that creates a mqtt switch and switches some hardware or
b) AD that creates a mqtt switch and switches some software
i asked about the option to create things like input_booleans or switches through API a long time ago, but they dont like the idea. (dont know why, because sensors can be created that way)
i just added mqtt to my HA and i am going to try to play with it
Let me answer that, going a little bit off topic here
hmm in the docs it says:
The basic idea is that the device itself adds its configuration into your configuration.yaml automatically.
but ok, i will find it out.
and it isnt that off topic. you want an option to create switches with AD into HA.
if MQTT gives us that option then you can use that as workaround.
Since its ZiGate, i think you might need to look into the zigbee2mqtt option, and use that to dynamically create your entities using Appdaemon. it will be able to do most of what you want I believe. It even supports the ability to dynamically create it for you if you want. Haven’t tested that part though.
But I don’t really get what you mean by boiler plate and template light. And if you want to do all your automation within AppD, you may as well use the self.set_app_state, as I use that to “create entities” within AppD.
Regards
All entitites that are from a component whose docs are not in the form
https://www.home-assistant.io/components/<platform>.mqtt/
It something quite adhoc, but my point remains. Everything you are saying (the MQTT and the ESP and the AD doing a MQTT switch) is using MQTT, but in my scenario there is no MQTT (only ZigBee / ZiGate and I am not planning to use any MQTT for that).
You are right that the docs says so. I hadn’t realized until now. However, I am using the discover feature and AFAICT it is not modifying the configuration.yaml file; instead it is creating stuff “on-the-fly”. But, this is heavily off-topic here, and on top of that, I was wrong (either me or the docs, I am playing safe and saying it’s me).
Thanks for the suggestions but I am not going to use MQTT. My original question remains, rephrased: I am looking into a way to trigger load_platform calls with arbitrary data from “outside” (not hass codebase). I know there are workarounds like throwing all my environment to the bin and using MQTT instead. Or selling all the ZigBee components and buy Z-Wave
I thought that it was an AppDaemon use case but maybe is more architectural to the platform and entities management in home-assistant.
in that case i can give you the same answer i already gave you:
there is no possibility to create entities properly other then sensors through HA API.
and AD uses HA API to speak to HA.
i tested it with mqtt, and i can now create switches in AD on the fly with the help of mqtt.
to bad that the mqtt discovery has such a small range of entities. (but i hope that might change because of the popularity from mqtt)
@ReneTode, Cool.
Did you use the Mqtt Plugin I submitted as pull request? Seeking some feedback so I could improve on it if need be. (sorry a bit off topic 
)
i got the plugin installed and functional.
i didnt use it to create the switch, but i know it is possible.
i get all data from the plugin.
it is satisfying for the moment.
but i must say that i rather have that mqtt is an included part from AD like alexa and google are.
it would open more possibilities in my eyes.
think about functions like create_switch(…) which wouldnt make sense in the mqtt plugin but it would make sense in the hass plugin.