How to count unread SMS or revived SMS using AT command?
void UnreadMEssage() {
fonaSS.println("AT+CMGF=0");
delay(1000);
fonaSS.println("AT+CMGL=\"REC UNREAD\",1");
}
Using this code, I can show the all received text messages, but I want to count the unread SMS.
Answering in reference to this blog :
There is no direct command to count the number of unread messages . We can use AT+CMGL command in a modified way to count unread messages .
Use the command AT+CPMS? to find out how many messages are stored in your SIM in total.
Use AT+GMGL=<stat> for each status other than 0 "REC UNREAD" and count the number of messages for each of these.
Add each of these counts together and subtract that from the total memory used as reported by +CPMS and you've got the number of unread messages.
P.B : If you don't mind "reading" the messages just do the +CMGL for status 0 "REC UNREAD" and count, i.e those messages will be marked as read.
The AT command +CPMS (Preferred Message Storage) is used to figure out,
Select the message storage area that will be used when sending, receiving, reading, writing or deleting SMS messages.
Find the number of messages that are currently stored in the message storage area.
Find the maximum number of messages that can be stored in the message storage area.
try AT+CPMS? to list the available spaces. and issue a command like this,
AT+CPMS="SM","SM","SM"
the response should show used space,available space repeatedly like this,
+CPMS: "SM",19,20,"SM",19,20,"SM",19,20
here is SM signifies SIM card space and a list of available options is below. A typical response shows,
+CPMS: used1,max1,used2,max2,used3,max3
Based on the count, read each response using AT+CMGR=x (x is the index of the message) and parse the response for "REC UNREAD" and subtract to get read messages.
PS:
here, SM is storage area in SIM card. others are,
SM. msg storage area on the SIM card.
ME. msg storage area on the GSM/GPRS modem or device. A larger storage
space than SIM card(SM).
MT. all msg storage areas associated with the your modem or device.
BM. broadcast message storage area.
(In some devices, ME & MT -> Flash message storage.)
SR. It refers to the status report message storage area. It is used to
store status reports.
TA. Terminal Adaptor msg storage area.
Related
I want to create a telegram bot to send updates to the groups/channel in which it is added. I used BotFather to create a bot. However, in https://api.telegram.org/bot<BOTAPI>/getUpdates, I'm getting all the messages sent in a channel like this: "channel_post":{"message_id":59,"chat":{"id":-1001192794322,"title":"Nseindia","username":"nseindia_updates","type":"channel"},"date":1588581996,"text":"AMBUJACEM : Bear\nAPOLLOHOSP : Bullish Reversal\nKOTAKBANK : Bullish\nMOTHERSUMI : Bear"}}
This is not a problem now, but as time goes, the json file could get very large and could pose a problem.
Is there any way such that I don't get all the messages in the json present in https://api.telegram.org/bot<BOTAPI>/getUpdates
you should specify the update_id of the latest update you've processed as an offset parameter to getUpdates to make them(updates with less update_id) marked processed and that way they wont come up the next time you call getUpdates.
In telegram's Bot API Docs it says:
By default, updates starting with the earliest unconfirmed update are
returned. An update is considered confirmed as soon as getUpdates is
called with an offset higher than its update_id.
I am able to successfully retrieve messages from a channel via channels.getMessages request, once I know their message IDs. I find channel id by contacts.search, by the way.
At the moment, mesage IDs are consequtive integers, so getting max_id would solve the issue.
I am sure it possible, since official clients do this (view a channel without joining it). I will try to find out how official desktop app does this by reading its sources, but any help will be much appreciated.
I need this because am writing a simple public telegram channel -> rss/web interface.
Please do not confuse Telegram Client API with Telegram Bot API. Bot API allows to receive 'push' messages on new messages, but no 'reading historical logs'.
Here are the steps you have to do in order to get messages from a channel you're not joined:
Resolve the username into ID and access_hash with contacts.resolveUsername
Invoke messages.getHistory to get your desired messages
Here is a short description of messages.getHistory parameters:
peer: The channel from whom to retrieve the message history
limit: Number of messages to be retrieved
offset_date: Offset date (messages *previous* to this date will be retrieved)
offset_id: Offset message ID (only messages *previous* to the given ID will be retrieved)
max_id: All the messages with a higher (newer) ID or equal to this will be excluded
min_id: All the messages with a lower (older) ID or equal to this will be excluded
add_offset: Additional message offset (all of the specified offsets + this offset = older messages)
It turns out messages.getHistory is just okay, gives you last N messages + total count.
Currently I implement code bluetooth low engine (BLE) for STM32L476 + X-NUCLEO-IDB04A1 base on example "sensor demo".
In "Sensor Demo" example, it only code to send data to smart phone. And don't have receive data.
I think can use function below to read data:
tBleStatus aci_gatt_read_charac_val(uint16_t conn_handle, uint16_t attr_handle)
And can read data from HCI_Event_CB(hciReadPacket->dataBuff);
However I don't know how to get parameter "uint16_t attr_handle" for function
tBleStatus aci_gatt_read_charac_val(uint16_t conn_handle, uint16_t attr_handle)
Could you explain for me about this problem?
That would be the value of the handle for this connection.
When IDB04A1 successfully connects to the smart phone, it shall send a HCI_LE_META_EVENT with information for this connection. Connection_Handle can be found in the event, to be specific, a 16-byte value:
(offset 6 | offset 5)
I am using a raspberry Pi and arduino CAN schield which is using a MCP2515 and SPI to request a single OBD II PID.
I am able to request and receive a single PID from my OBD emulator (Freematics). I know that is possible to request multiple PIDs (up to 6 PIDs) in a single query.
Whenever I use other kind of messages, I receive only the first request. Can anybody maybe help?
Here is the message for single PID which is working (C++):
msg.id = 0x7DF; //ID_QUERY
msg.header.rtr = 0;
msg.header.length = 0x08;
msg.data[0] = 0x02;
msg.data[1] = 0x01;
msg.data[2] = PID; //Whatever PID I want!
Message for multiple request that is not working:
msg.id = 0x7DF; //ID_QUERY
msg.header.rtr = 0;
msg.header.length = 0x08;
msg.data[0] = 0x07; //! Also it is not working with 0x08
msg.data[1] = 0x01;
msg.data[2] = PID0;
msg.data[3] = PID1;
msg.data[4] = PID2;
msg.data[5] = PID3;
msg.data[6] = PID4;
msg.data[7] = PID5;
Our Freematics OBD II emulator does not support sending multiple responses. One of our test vehicles, a 2010 Toyota corolla does. In our experience it is best to send a test command at startup to see if the device we're communicating with supports multiple responses or not. For our application we send the command 00 twice,
010000
If the response its greater than 25 characters, we know the device supports multiple commands as it responded to both 00 commands. If the response is less than 25 characters, we know the device responded to just the first 00 command and consequently only supports one command at a time. checking how many responses were received could be done multiple ways, but length has worked well for us so far.
Based on your use case, it may be enough to only send single commands. But if you really need the increased speed of multiple commands, add a check at start up to see if the device responds to multiple commands and then construct your messages based on the results. Dont forget to end your messages with the expected number of response lines to further increase speed. See the attached taken from: http://elmelectronics.com/DSheets/ELM327DS.pdf
Sending canbus messages through mcp2515 is a litle bit tricky.
First of all Freematics OBD Emulator support no multiple PID requests. Secondly, the multiple PID request should be sent with ISO 15765 format. when you send a multiple request, he ECU would response only with one "First Frame" message and will wait for the "Flow Control" message from the sender. After receiving the flow control, ECU will continue to sending the responses based on your flow control setting.
For more information about the CAN-Bus messages and how "First Frame" and "Single Frame" works, read the below links:
googleBooks, ISO_15765-2, hackaday (dot) com
I am dealing with Message Passing IPCS method. I do have few question regarding this:
KEY field in ipcs -q shows me 0x00000000 what does this means ?
Can i see what messsage is passes using msqid ?
If two entries are present (for a particular user) after executing command ipcs -q. Does this means that two messages were passed by this particular user ?
If used-bytes and message fields are set as 0 what does this mean?
Is there away to see if message queue is full or not?
How many queues can we have for one particular user?
I tried goggling, but was not able to find answer to these questions.
Please help
1. The "key" field of the Shared memory segments is usually 0x00000000. This indicates the IPC_PRIVATE key specified during creation of the shared memory segment. The manual of shmget() contains more details.
2. AFAIK, this cannot be done. If any msg is "de-queued" from the msgQ, then the intended receiver will not see it.
3. The 2 entries in the list of message queues indicates that there are currently 2 active message queues on the system identified by their corresponding unique keys.
Creating additional msgQ : ipcmk -Q
Deleting an existing msgQ : ipcrm -Q <unique-key>
4. The used-bytes and messages fields set to 0 indicate that currently no transfers have occurred using that particular msgQ.
5. Currently one way to do this to obtain the number of msgs currently queued-up in the msgQ programmatically as shown in the following C snippet. Next this can be compared with the size of the msgQ as demonstrated in this answer.
int ret = msgctl(msqid, IPC_STAT, &buf);
uint msg = (uint)(buf.msg_qnum);
printf("msgs in Q = %u\n", msg);
6. There exists a limit on the total memory used by all the msgQs on the system combined together. This can be obtained by ulimit -q. The amount of bytes used in a msgQ is listed under the used-bytes column in the output of ipcs -Q. The total number of msgQs is limited only by the amount of memory available to create a new msgQ from the msgQ memory pool limit seen above.
Also checkout the latter part of this answer for a few sample operations on POSIX message queues.