[SOLVED!] TCP commands not working - not getting response

Hi,
I have Smart LED Bulb (v2 = 800lm).
I have android phone with yeelight official app and have enabled the LAN CONTROL.

when I send TCP commands to port 55443 to the IP of my bulb - NOTHING HAPPEN - the bulb simply does NOT response to TCP commands on LAN.

commands I tried to send ( each line different TCP command )
{“id”:1,“method”:“get_prop”,“params”:[“power”, “not_exist”, “bright”]}
{“id”:1,“method”:“set_power”,“params”:[“on”, “smooth”, 500]}
{“id”:1,“method”:“set_power”,“params”:[“off”, “smooth”, 500]}
{“id”:1,“method”:“toggle”,“params”:[]}

source:

I used free portable app on windows to send the TCP commands named “packetsender”.

I made sure my firewall is DISABLED during the check I made through my windows.
also - I tried to perform the same check on my android, using a trial of tasker plugin named “send/expect” downloaded from the dev site:
https://sites.google.com/site/sendexpect/home/trial-version

My bulb’s firmware is 1.4.2_0026 - and it’s “up to date”.

PLEASE FIX THE FIRMWARE SO THAT TCP COMMANDS CAN WORK ON LAN.

Try telnet to the IP of the bulb… on port 55443, that way you will be sure if it connects or not.

thanks for the reply.
I used “Putty” portable, telnet @port 55443 to the bulb’s IP -it opens black screen W/O any output.
I try to enter
{“id”:1,“method”:“toggle”,“params”:[]} -> enter -> then I get reponse:
{“id”:(null), “error”:{“code”:-1, “message”:“invalid command”}}

why is that ?
I thought that TCP commands are based on the info written in the official Yeelight “operation spec”:

so connection is possible - but commands are different then what officially is publish…
YEELIGHT / XIOMI: can you please publish UPDATED & RELEVANT “operation spec” manual for the LED BULB V2 ( 800LM) ?

UPDATE:
I think I found the reason:
when I send:
{“id”:0,“method”:“toggle”,“params”:[]} -> it does work !
the “id” should be “0” and not “1” !!!
IMHO, the “operation spec” is badly written since no mention of possible value range for “ID” is mentioned and ALL the examples of commands being sent is with “ID”:“1” and NOT “0”…

Yes, you should get black screen! If you get black screen, it means you are connected. And it also replies… So your communication is OK.

try sending i.e.

{“id”: 1, “method”: “set_power”, “params”: [“on”, “smooth”, 200]}

Hi dalanik - thanks for the fast reply…

I think I found the reason:
when I send:
{“id”:0,“method”:“toggle”,“params”:[]} -> it does work !
the “id” should be “0” and not “1” !!!
IMHO, the “operation spec” is badly written, since possible value range for “ID” is NOT mentioned at all, and the examples of commands being sent throughout the manual are all with “ID”:“1” no other value… ( there’s a ID of 1/2/3 of replies… not of command to the bulb )

UPDATE:
I’ve just disconnected and reconnected the bulb…
ID 0 isn’t working any more… now it’s ID 1 !!!
what the hell - why is the ID dynemic if I only have 1 Yeelight on my home LAN ?
what can the ID range be, if I only got 1 bulb in my LAN ?

that’s seriously really BAD firmware coding/algorithm there…

OK - i’ve played a bit more with the bulb…
apparently, each few seconds - the bulb changes its ID:
one time I need to run the TCP commands when ID is 0, on the other when it’s 1, and sometimes even 2 !

I know only of a limit that’s written in the “operation spec” manual of:

NOTE: Currently WiFi smart device support up to 4 simultaneous TCP connections, any further connect attempt will be rejected.
For each connection, there is a command message quota, that is 60 commands per minute.
There is also a total quota for all the LAN commands: 144 commands per minute

BUT THERE IS NO MENTION OF ID SWITCH/CHANGE EACH TIME THE BULB GET A COMMAND !

IMHO - THIS IS A BUG.

@dalanik - you wrote in other thread about this one that:

As I said in the other thread, ideal solution is Send/Expect plugin for Tasker - shell might work but you can’t get the RESULTS of your command. No problems with ID as well.

@dalanik
A. can you please tell me how to reply &quote directly others in this forum ?
when I press “reply” it does not do that and there isn’t any other button for it like in many vBulletin forums.

B. “Send/Expect plugin” for Tasker - IS NOT FREE & only offers free trial for 7 days.
if a user already purchased Tasker - they can use internal “run shell” command which works great ( minus the ID issue )

C. the ID issue I complained about exist no matter the source I send command ( tasker “run shell” or “Send/Expect plugin”) no matter the HW I send it from ( PC windows using Putty or any other telnet software, android phone etc… )

the ID issue is a firmware BUG or DELIBERATE coding behavior done by Yeelight/Yeelink
it might be limited only to my RGB bulb v2 (800lm) - so you might not be effected by this BUG, if you got other Yeelight products ( or even other firmware version of same product ).
(so this is why I cataloged this thread under “LED Bulb v2” tag)

Well yes, it is not free - but it is not expensive either - if you need it. And is more convenient than issuing shell commands, but most important part is being able to parse the result.

I don’t know about v2 RGB since I don’t have it but all other products work fine.

I only write this because I have been using this combo for over a year and is totaly reliable.

@dalanik - when you use “run shell” and send command - you can put the answer into a variable you decide ( just add a variable under “store output in” and “store errors in” ).
then it is only a matter of splitting the replied text into each component.

for example if I run “run shell” and output the reply into “%reply”, then I run “variable split” on that %reply variable with splitter “[”, then another “variable split” on “%reply2” with splitter “"” then I can get the different values returned from the answer by using “%reply22”, “%reply24”, “%reply26” etc…

so parsing isn’t an issue…its is the ID that’s being change each time I send a TCP command - so I need to create a loop in tasker to send the same command to different ID each time ( and that’s eating CPU, wasting time & battery ! ).

as you reported - the ID stays the same the whole time ( as long as the bulb isn’t being disconnected/connected again from electricity, I guess ) - SO THAT IS WHAT I EXPECT FROM MY BULB - BUT THAT DOES NOT HAPPEN !

So i’ll change the thread topic - if I can to emphasize that.

@dalanik - you said that using send/expect plugin:

most important part is being able to parse the result.

how exactly using regex is simpler then using two “split variable” tasks & tasker variable system ?( i.e %reply22, %reply24)
https://groups.google.com/forum/#!topic/android-send-expect/GSyxYEeYxlw

gee… why you try to break the head with send/expect ?

Just use whatever you wish, my point is not “my daddy is stronger than yours”, you must be like 15 or what?

I don’t understand why you protect yeelight instead of letting the official employees to answer by themself.

I’m not protecting anyone, I was just giving you a solution how to get the state of the bulb…

1529976672388.jpg1180x506 96.3 KB

I tried the bulb (v2) with TCP command and post the result. Actually, ID is a label for a response result to know which command it belong. So if you use ID 1000 to send the command, response will also has iD 1000.

Please have a try again.

@dingyichen - thanks for the reply.

here’s my trial using Lubuntu ( a linux/ubuntu fork ) shell

2018-06-26_5-40-13.jpg948x487 180 KB

from ~13 commands sent - only one got reply from the bulb.
this happens as well when I run such command on my phone when I use tasker’s shell ( then in turn uses Android’s shell ).

Hi, I didn’t get response with command you post, but it’s ok from the second pic.

1529982428489.jpg2500x328 161 KB

1529982435999.jpg1330x446 112 KB

OK - I solved the issue…

It’s not Yeelight’s bulb fault and NEVER WAS - its simply how shell/bash and other basic apps ( from busybox ) works.
also, YES - using telnet directly ( w/o calling it from any shell script ) it works w/o any issue ( like in your photoes ).

when using:
echo -ne ‘{“id”:0,“method”:“toggle”,“params”:[]}\r\n’ | nc -w1 <bulb_IP> 55443
I found an explanation for that behavior:

“This is exactly how netcat is supposed to operate: once it has reached EOF on stdin, it (one-way) closes the connection /to/ the server and then waits for data coming from the server. When the latter closes the connection (the other way: server->client), then netcat stops”
Source

That source also recommend to use “cat<(echo command) | nc ip port” which I tested and indeed output response from the bulb - but you need to manually do CTRL+C to “finish” the command.
( that’s not so good for scripts / tasker )

As also stated as well in that source, there’s another option: adding a “-q1” instead that “cat<()”,and it solves that issue of mandatory manually CTRL+C - BUT, it will output the response as we wish - BUT WITH MIN OF 1 SECOND DELAY !
so that’s NOT perfect as well…

SO - very simply I found out that adding a small SLEEP AFTER the echo command - solves it.
it is best to keep that sleep/delay as low as possible (~1/4sec) but it could vary ( network/bulb connection is busy?)
anywho… the shell command for linux, that work out-of-the-box for android as well is:

( echo -ne ‘{“id”:0,“method”:“toggle”,“params”:[]}\r\n’; sleep 0.1 ) | nc -w1 IP 55443

• please note the () encapsulation and added sleep after the echo.
• if you get no response when issuing a command, raise the sleep delay (0.25/0.3/0.4/0.5 etc…)
• IP is of course an IP address.
• the sent command can be changed according to Yeelight Spec manual

NOW - anyone can enjoy scripting on any device
thanks for all the help.

P.S - proof of concept:

Good to know, thanks for sharing