[solved] PlaySMS+SMStools+unicode SMS not showing in Inbox

PlaySMS ver. 1.4.3
Debian 10 up-to-date ( smstools )
Modem Huawei 3131
Everything ( almost ) works perfect.

  • I can send SMS from web composer and from WebAPI. Both ASCI and Unicode.
  • Smstools serves received SMS to proper directory /var/spool/sms/incoming
  • PlaySMS operates properly with @user redirections to user Inbox
    But… When incoming SMS contains even one non-ascii character it does not drop into proper Inbox. It desapears. It’s moved to backup/incoming directory ( probably by a recvsmsd process ) but not appearing in inbox.
    Of course - as said at the begining - pure ascii sms goes to proper inbox.
    I tried with decode_unicode_text=yes and without it. I also put manually file with SMS with unicode into received directory - it is moved to backup/incoming with no result in inbox ( always with @user string inside ).
    My SMS’es with unicode ( Europe / Poland ) looks like _@u_s_e_r X… where _ is a unicode extension character ( one or more ).
    Test incoming SMS ( Simulate incoming SMS ) works fine and puts SMS in proper @user inbox.

Can You help me to enable unicode SMS to go to proper Inbox ?


set log level to 3 in config.php, restart playsmsd, and then do the test, share here the log (please redact numbers, hostnames, IPs etc…)


I set core_config[‘logstate’]=3
Here are two log examples: with unicode ( only 2 lines of log ), and without unicode ( many lines more ). Log were empty before SMS receivig.
There is NO decode_unicode_text in smsd.conf of smstools.
When SMS wihout unicode arriver - user @xxx got a proper e-mail.
Nothing happened with message with unicode beside moving it to backup/incoming

This above is without unicode

Sorry - one uplink in one post for new users…


Can you test using shorter unicode words, without “|”.

For example send this:

ą ć ę ł ń


The test text was: ‘@xxx test test żółty kolor.’ Only one word was with unicode, but it means all the letters were considered as unicode.

What text do You want me to send to PLAYsms. Please write it and I will send it. Eg. ‘@xxx żółty’ ?

can you check in your database, table playsms_tblRecvSMS, seems like when you’re using unicode it was not saved in that table. If it was, then check whats the different in db table between the unicode and non-unicode.


One more observation with text:
@xxx ą ć ę ł ń [ @xxx with 5 letters with unicode separated with space ] works. Sends e-mail but with rubish inside [ @x x x B D ]

@xxx żółty [ @xxx with a word zolty with unicode ] does not put in a Inbox and not sending [ exactly 2 lines in log - like I put above ]

… going to look into tables.

(1)Simulate incoming SMS -> contains unicode characters and is seen in field message with unicode chracters and is seen in my Inbox.
(2)The rest -> present are only sms that were sent to email. They are stripped from unicode to rubish text but @xxx string is properly translated. The rest is not similiar to sent letters [ ą ć ę ł ń -> B D ].
(3)If sms was sent without unicode it is there properly.
(4)There are no SMS that are not present in Inbox ( with two lines only in log file ).

Forget about forwarding to email, its another issue, we can solve it later.

But right now, what is the situation ?

What happend when testing with simulate incoming SMS:

  1. With unicodes, 1 word, 2 words, with/without spaces, combined with non unicodes, they are all considered unicode message when detected at least 1 char unicode

  2. Without any unicodes in the message

And then, what happen if you test with smstools (receiving from smstools) for 2 conditions above. Please share here the answer to 4 questions above (2 in simulate incoming sms, 2 with smstools).

Expected results would be:

  • both unicodes or not should be logged the same
  • both should be received in Inbox (or sandbox if you dont add @userinbox in test message)


(1)Simulate incoming message.
Works fine with unicode
Works fine without unicode
Both SMS’s are in tblRecvSMS.
All in log looks OK. It’s the longer log type ( shown at the begining ).
(2)SMS that are passed by smstools.
SMS without unicode - works fine.
It’s in tblRecvSMS and in log in long type.
SMS with unicode - disapear from incoming directory, it’s moved to backup/incoming directory. It’s not in table tblRecvSMS and log file is very short - 2 lines above.
(3) I tested manual file with unicode but not original - that comes from Huawei 3131 terminal but manually written in Linux shell. It works in proper way - goes to a table tblRecvSMS and is present in Inbox.
My conclusion ( it’s also visible in incoming file from smstools ) - unicoded message from the mobile operator differs from unicode in Linux terminal.
Hope that helpes…

Can you provide the sampel of incoming file ? Send it to email info@playsms.org


Example files were sent.


I can’t find the solution. I’ve tested by converting to UTF8 and other stuffs didn’t solve this. By changing DB table collate to ucs2_polish_ci at some point I can see as expected for message test 1 but not the 2nd.

Perhaps something like this can be used:


Tanks. I will test this solution and let You know.

That is the proper spell !!

Works perfect!

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.