Tcp/udp Sending and receiving

[elektroinside]

Yep, I've been testing this in Termux, unfortunately the only way for me, as I did not root this phone. I'm using it in corporate/mission critical environments (as a helping tool, for monitoring) and i can't risk anything. Integration of something similar in Automagic would be fantastic, as i also need to keep that plugin alive in order for it to work properly (otherwise it times out).

Thanks for the answer!

[Desmanto]

Ah, forget netcat if you already get the fix IP for the yeelight and don't care about the feedback. I can't use the SSDP discovery, because need tcpdump (root). I can run the tcpdump in parallel by using execute flow, but still can't get the proper packet data.

Since I have fixed static IP already, I just sent the request directly to the yeelight. And it turns out I can use action HTTP request to toggle it
Put script before the HTTP request,

Code: Select all

command = '{"id":0,"method":"toggle","params":[]}\r\n';

Then use HTTP Request
URL : http://192.168.1.100:55443
uncheck verify https
Request Method : POST
Content Type : General Text
Data : {command}
But you won't get the proper response for this, so you can't get the current status.

AFAIK, you can still use the busybox unroot. You just have to specify the full path to the busybox binary. So example

Code: Select all

( echo -ne '{toggle}'; sleep 0.5 ) | /data/data/burrows.apps.busybox/app_busybox/busybox nc -w1 192.168.1.100 55443

[elektroinside]

Yes, you're right, http requests do work!
This was the first thing I tried, but I made the mistake to select json data and my commands failed all the time.
Many thanks for showing me the right way to do it! I got rid of the plugin as I do not need it anymore and rewrote all my light automation flows, and everything works perfectly. Declared everything as global variables and that's it.

Again, I cannot express my gratitude enough for this project. I would have paid a lot more for it. Very well done!

I have attached a screenshot with the number of flows I already created, and they all work perfectly!

[elektroinside]

However, with a TCP/UDP sender/listener, one could send a "getprop" query to the lights and parse the results, or even send a multicast udp (for the discovery) and totally automate everything.

So, I could not be more happy if this could be implemented. It could also be used for some lan chatting Wouldn't that be great? Mirror notifications to a PC, send different commands to a PC etc. Yes i know, some of these can be made with the http requests, but there's a need for a server, etc. With these new features, everything could be lighter (and more independent) to use. Or even command Automagic from other places some other way (might be reliably possible already, haven't researched yet about the http request trigger, its safety features etc.).

[Desmanto]

"Poison" others to use Automagic too (read: encourage). That way, when more users are using Automagic, there will be more flow sharing for useful things. I tried to translate the tasker project from the yeelight forum. It was so difficult to read the project in tasker, too many if branching and parameter passing scattered in so many tasks, that I better recreate my own flow directly from the yeelight documentation. If more users are using Automagic, we might see more flow sharing for Automagic than current condition.

Fortunately, the yeelight dev is very perfectionist in documenting the protocol. I might purchase another bulbs for the Automation purpose only. I have stored all the function into a nested map/list (very tidy, compared to the tasker version), and will create the branching input dialog for it in the next few days.

BTW, I just tried the nc from busybox no root at my non rooted phone. The flow runs properly and can turn on/off the yeelight just like my primary rooted phone. I installed the binary using method 1 and use this script for the nc part.

Code: Select all

( echo -ne '{toggle}'; sleep 0.5 ) | /data/data/exa.free.bbin/files/busybox nc -w1 192.168.1.100 55443

basically, I just add the busybox binary location path to the script and use Execute Command, instead of execute root command. So nc can be alternative solution until Automagic implement this action built-in.


For two way communication from phone to PC and vice versa, just use Eventghost as the server. Automagic HTTP request trigger also very lightweight, that I can't find any battery drain issue even with the flow enabled. The general concept of the eventghost usage is here : viewtopic.php?f=3&t=7866#p23548 I wish I can explain it in simpler wording

I also can't imagine my life right now without Automagic. Today, 67 active flows from 209, keep growing.

67-209.png (112.57 KiB) Viewed 24001 times

[digitalstone]

I'm missing the point i'm sure, but aren't TCP/UDP just protocols that sending a http just makes use of?

[elektroinside]

I'm missing the point i'm sure, but aren't TCP/UDP just protocols that sending a http just makes use of?

This link here describes perfectly the differences: https://stackoverflow.com/questions/231 ... web-server
Particularly one comment. But basically, they are not the same

@Desmanto
Wow, now that's a big list Very nice!
Thank you for your detailed response, very good to know there are alternatives! Not just that, but basically you could theoretically extend the possibilities to a another level, and all without being rooted. Nice!
Yeah, I've been showing Automagic to friends, some of them already use Tasker and built their automations there. I also bought Tasker a long time ago, but for some reason, I find Automagic to be far more handy and easy to use. And to read your automations a week later - and see it, not just read it.
The attention to details is extraordinary and I'm yet to find bugs, none so far. Truly, is one of my all time favorite apps, and I too could say that after a proper virtual keyboard, this will be the second app I'll install on any new phone. Simply wonderful!
I'm yet to discover the sharing of flows, I saw the feature but never used it. Yet This will certainly help attract people, because free stuff are always the best (ready-made, available flows to download and import)

Edit: Just shared a little flow i made this evening. I was just playing around but it turned out ok
viewtopic.php?f=3&t=7905

[digitalstone]

@elektroinside The answer on that forum already describes what my question was implying. I know it's just a protocol where a format like "http" rides upon.
I just want to know what you would like to be sending a message with (using UDP or TCP)?

[Desmanto]

@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.

[elektroinside]

Yes, very much agreed, a TCP/UDP sender/listener would be awesome.
Exactly, this thread is also full of useful info, in case somebody needs help with controlling IoT devices, especially the netcat part, as there's no one place (or i did not found one) where usable workarounds, even for routed phones,are listed all in the same place.
I'm still to hack my vacuum robot, also Xiaomi, which is not an open protocol, and the easiest way would be to sniff the communication between the app and the robot. But that will be in hex, unless you decrypt the packages, which can be done. And hex sending through http requests.. i don't think will work.
Home Assistant has some plugin, i have to take a look, they are not using hex, maybe http requests can be used after all. Anyway, just another example where tcp sending would help.
I just finished a very complicated flow group that acts like an automatic DDNS client for duckdns, and i'm very happy that http requests work flawlessly. So i'll be super happy to have both in the future