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_rX… 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 ?
Hi,
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
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 ]
OK.
(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:
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
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…
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.
