@digitalstone : TCP/UDP is at the transport layer of IP suite. HTTP is only one of the most widely used protocol at the application layer. There are still more than 100 other protocols and many not documented/non-standard protocols out there. By allowing Automagic to use other TCP/UDP protocol, we are not limited to only HTTP protocol.
HTTP is not suitable for IoT device, because of the overhead. It is too heavy, require constant good connection. While IoT device tends to be small device, low-power, small bandwidth, send small but frequent data, tends to go to sleep after finishing the connection. That's why a lot of IoT device don't use HTTP. HTTP is good, it is just not suitable for IoT.
The same command sent directly via TCP + yeelight protocol, maybe only takes 100-200 bytes in sent and response packet. But sent from HTTP, added up with its glorious header, can be up to 300-500 bytes in each sent and response packet. UDP discovery only takes about 130 bytes, it is definitely more in HTTP. This seems small, but very crucial for IoT with limited resources. Some IoT devices even don't use TCP at all. Orvibo S20 use purely UDP for all control. There is no way I can do that using HTTP request, it is completely different protocol on different transport layer. I have to use UDP sender plugin to do that. And discovering netcat is really a bless. I really don't know that tool, although I have been searching it since 2015.
@elektroinside : I have to find some alternative as some of my phone are not rooted.
Automation app is a very niche app, just like root users too. We are probably less than 1% from total android users out there. So most likely the one who will use Automagic already using some other automation app too. One of the biggest obstacle for most new users to Automation is the complexity of the concept. That's why I will try to introduce the automation concept whenever I can (when I post in other forum), specificly for Automagic, but not intrusively forcing them. Just to let them know the Automation possibility is there, if they are willing to learn the concept.
Most of our flows will be very specific to our own usage. Example, one of my WIP flow, relating to check internet quota for my carrier. This is specific to my carrier, and my internet package. Even shared, maybe doesn't serve much function to others. But with generic ones, it will be helpful to others. Example, the yeelight flow I am also working on right now, will be useful for other yeelight user out there. I have done until the half of the function testing, including the input dialog box for the parameter. The flow also can be called with parameter prepared, so it serve also as function flow. I will share it when it is finished.