Page 3 of 4

Re: Tcp/udp Sending and receiving

Posted: 21 Feb 2019 19:30
by elektroinside
Another "hack" which i just tried and works, is to use an asus wifi router (with asuswrt), install entware, install netcat and use a shell command from automagic :-)
Or any router with a wrt-like build installed (and entware also installed).

Re: Tcp/udp Sending and receiving

Posted: 24 Feb 2019 16:55
by Desmanto
I have Tplink archer C7 with openwrt installed. I might try to play with it also later after I finish my yeelight flow.

Re: Tcp/udp Sending and receiving

Posted: 24 Feb 2019 22:06
by ariloc
Desmanto wrote:"Poison" others to use Automagic too :lol: (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
Wow, it seems I know nothing about the capabilities of Automagic :lol: . I also have a Yeelight Bulb, but I just use the Yeelight Plugin that the app offers (which it isn't that reliable), or for more reliability, I use Automagic+AutoRemote+IFTTT+Yeelight Service. So, just to know, what's the exact advantage of using direct communication (TCP/UDP communication, if I'm not wrong) than using the provided plugin (excluding the fact you don't require Internet connection in your WiFi, as far as I understand)?

Also, I'm a bit curious about those GCam flows, because I also installed GCam for better images, but I see no way Automagic would be helping more in my experience with the app :?:

Re: Tcp/udp Sending and receiving

Posted: 25 Feb 2019 05:18
by Desmanto
@ariloc : When yeelight got killed because of android default battery optimization, I still can run the flow to control the bulb. I don't want to let the yeelight running background all the time just because I want to control it from automagic. Using LAN control also have much more variable you can tweak/adjust rather than the default built-in one. The most powerful function is the color flowing and this is the part which I am working on right now. I am trying to make the flow to be able to build a working color flowing pattern that I can copy-paste as preset (just like the preset in the app). I have tried to copy the pattern from the app (candle, party, sunrise), but still can't find where it stored it. Querying the pattern while it is running also doesn't give anything. So I have to try and see which pattern that I will use.

Building that flow, have extended my knowledge and my scripting best practice again, about how to maintain big nested map/list inside the script, how to loop over the element and skip the input dialog if there is only one choice. So it is still a good exercise.


GCam flows is for comparison, as seen here : https://www.kaskus.co.id/show_post/5bdd ... ight-sight (I am sorry that I don't have the post in english, but you can take a look at the flow and the result)
At the time I discover the Night Sight, I was so excited that I want to show the difference compared to normal and HDR shot. In order to have fair comparison, the shooting angle must be exactly the same. If I press the button and switch manually, tap the camera button manually, there is a risk I will have slightly different capturing angle, making the comparison not fair enough. By using Control UI to do all the job, I can simply put it to tripod or any stand holder, run the flow, and it will capture in 4 modes : Normal, HDR, HDR enchanced and night sight. The whole flow finish in about 50 seconds, so you know it is impossible to hold it that long to maintain the same capturing angle. There is helper flow to help detect the capturing has finished (the processing HDR progress). Then another flow to collage the picture, retrieve the metadata and overlay it to the result.

I still have another unfinished GCam flow to compare the picture close, in terms of zoom result. But never finish it until now. As current flows already successfully convince others, to let them know the difference and why I am willing to have the trouble to enable Camera2 API (to use GCam). I also try with different GCam version, as you might already know, there is no single GCam that is fully compatible for non-pixel phone (I am using RN5, RR 7.0.0 Pie 9.0). I use different control UI for different Gcam version, as the UI slightly change depends on modder. Some Gcam also hate accessibility, that control UI will exit when trying to use INFO button. That's why I build several variant of the flow too.

Re: Tcp/udp Sending and receiving

Posted: 25 Feb 2019 12:00
by elektroinside
Here's how I did it:

1. Set the desired light flow mode in the Yeelight app, for all your lights, especially if they don't start with the same color

2. With https://packetsender.com/, send this command to each light @ TCP port 55443 :

Code: Select all

{"id":1,"method":"get_prop","params":["power", "bright", "ct", "rgb", "hue", "sat", "color_mode", "flowing", "delayoff", "flow_params", "music_on", "name"]}\r\n
3. Save the response in a txt file, as they will contain the currently applied settings, and extract the data, and replace below

4. For light flows, the final command to turn on/change something, for one IP, should look something like this:
{"id":3,"method":"set_scene","params":["cf",0,1,"7000,1,16755456,90,7000,1,10813184,90,7000,1,65514,90,7000,1,16711903,90"]}\r\n

5. For a white color, something like this:
{"id":11,"method":"set_scene","params":["ct",3200,90]}\r\n

6. I think you can extend the light flow values, I remember playing with more than 4 colors for one flow/light, just copy more flow values in the command, in the right format

You have to pay attention, it's not just a copy paste, you have to replace the right values in the right place, but with a little exercise, you'll find the correct formula :)

Re: Tcp/udp Sending and receiving

Posted: 25 Feb 2019 16:54
by Desmanto
@elektroinside : you don't need to query the whole params for single operation. I use one of the set_power function to make sure the LED is on before sending any other function which need the LED to be in ON state first. There are much more explained in the yeelight documentation : https://www.yeelight.com/download/Yeeli ... n_Spec.pdf

Re: Tcp/udp Sending and receiving

Posted: 25 Feb 2019 17:39
by ariloc
Desmanto wrote:@ariloc : When yeelight got killed because of android default battery optimization, I still can run the flow to control the bulb. I don't want to let the yeelight running background all the time just because I want to control it from automagic. Using LAN control also have much more variable you can tweak/adjust rather than the default built-in one. The most powerful function is the color flowing and this is the part which I am working on right now. I am trying to make the flow to be able to build a working color flowing pattern that I can copy-paste as preset (just like the preset in the app). I have tried to copy the pattern from the app (candle, party, sunrise), but still can't find where it stored it. Querying the pattern while it is running also doesn't give anything. So I have to try and see which pattern that I will use.
That makes quite a lot of sense. After some experimenting and reading through here and the documentation, I could get some things done that otherwise would need much more work. In my case, I used to run every 5s the Flash Notify scene with the plugin in an Automagic flow until something changed and turned the light back to white. But with the start_cf method I could replicate something similar and in an infinite loop, so now I don't have to send multiple commands :D .

Code: Select all

{"id":1,"method":"start_cf","params":[ 0,1 ,"500,2,4000,100,500,2,4000,1"]}\r\n
I may get a little bit more into tcp/udp packet sending and receiving, as I may be able to control some other smart devices in my house without IFTTT (but I'm not sure if they are as well documented as Yeelight bulbs are).

Thanks a lot for the help here!

Re: Tcp/udp Sending and receiving

Posted: 25 Feb 2019 19:16
by elektroinside
I used that command right after buying the lights, as a quick copy paste string in packet sender to get everything i needed for later, one by one for all the lights, and matching stuff with the documentation provided by Yeelight. Then i saved what i needed in variables which i use to command the lights from the lan. I'm using "set_scene" because it will turn on the lights if they are off, or change to whatever if they are already on. I'm using my lights for different alerts as well (important calls, sms, mails etc), so i need a speedy reaction/response. I'm not querying the lights, i just tell them what to do and when. I'm getting my "don't change the lights no matter what" info from elsewhere, like wifi states, connected clients, sms received from the alarm etc.

@ariloc: i'm not sure if i understood correctly, do you need help setting up/controlling the lights from the lan?

Re: Tcp/udp Sending and receiving

Posted: 26 Feb 2019 03:56
by ariloc
elektroinside wrote:I used that command right after buying the lights, as a quick copy paste string in packet sender to get everything i needed for later, one by one for all the lights, and matching stuff with the documentation provided by Yeelight. Then i saved what i needed in variables which i use to command the lights from the lan. I'm using "set_scene" because it will turn on the lights if they are off, or change to whatever if they are already on. I'm using my lights for different alerts as well (important calls, sms, mails etc), so i need a speedy reaction/response. I'm not querying the lights, i just tell them what to do and when. I'm getting my "don't change the lights no matter what" info from elsewhere, like wifi states, connected clients, sms received from the alarm etc.

@ariloc: i'm not sure if i understood correctly, do you need help setting up/controlling the lights from the lan?
That's useful information, I was actually using two http requests: one to turn on the light and then start color flow. I just didn't use set_scene by the fact I couldn't figure out how to use it, and noticed that start_cf was better described. Now I understand that it's almost the same, but it also turns on the light.

I guess I got it now. Also sorry if I wasn't clear, I just was thanking you and Desmanto for the great idea, as I didn't know about it, and also the previous posts that helped me understand the syntax of the requests :)

Re: Tcp/udp Sending and receiving

Posted: 26 Feb 2019 06:32
by elektroinside
Ah, sure thing, my pleasure. I'm happy i helped :-)