I have an expected last-minute failure regarding the interaction of our code with a Telegram bot API. I have been using a Nordic Sem. gently provided Telegram related code running over its nRF9160 chip.
Everything has worked properly and continuously for several days, with the mentioned code managing both outcoming and incoming Telegram messages successfully and without interruption until last week, when the code suddenly become unable to deal with the Telegram API and started delivering the errno22 each time it executed the send function below stated.
int num_bytes = send(client_fd, send_buf, send_data_len, 0)
Error:
ERROR!!! -> num_bytes = -1
As far as I know, this error means Invalid Argument, but I do obviously pass to the function the same arguments used from the beginning of the successful tests (nothing has been changed between successful and failed operation), so I cannot understand this unpredictable program break.
On the other hand, I have been aware that last week Telegram deprecated the use of TLS versions 1.0 and 1.1 and strongly recommended developers to upgrade to 1.2v to avoid service interruption. Theoretically, this update should not suppose a problem since the code provided by the chip support staff states within its arguments the TLS 1.2 version (see below) and, thus, I must assume that this is the version currently use by the chip manufacturer.
int client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TLS_1_2)
Nevertheless, information about this subject or any detected issues concerning the new TLS Telegram requirements would be very much appreciated as well as any other suggestion of how I can work around this issue.
Related
We have a Multitrack web conference implementation using AMS 2.4.1 version. Its working great for our use case, except in one scenario. When there are N (< 3) number of users and they on there camera simultaneously, then few remote users are not rendered as we don't receive the video tracks for those users in newStreamAvailable. We only receive the audio track for those users. We are able to reproduce this quite frequently.
As a backup, I am trying to poll AMS using getTrackList with the main track Id to get all available streams, but I am not getting any message trackList
var jsCmd =
{
command : "getTrackList",
streamId : streamId, // this is roomId or main track id
token : token
}
Any insight would be helpful.
Thanks,
We were able to resolve the issue, posting here to help anyone who might be facing a similar issue.
With push notifications from the server, we might encounter issues when for some reason push operation doesn't succeed. In that case, it's better to have a backup plan to pull from the server and sync.
The Ant Media Server suggests pulling the server periodically for the room info. The server will respond with active streams and the application should synchronize.
For reference, please refer to following link https://resources.antmedia.io/docs/webrtc-websocket-messaging-reference
I need to get the number of messages that are ready. A queue has three types of messages: 1. Total 2. Unack'd 3. Ready
Ready is the ones' that are in the queue but haven't been consumed yet.
Currently I use requests
url = "http://<RABBITHOST>:15672/api/queues/%2f/{}".format(q)
res = requests.get(url, auth=("<user>","<password>")).json()
messages_in_queue = res.get("messages_ready")
The problem here is that I have to pass in the username and password. Using Pika I believe you can get the "total" messages. Is there any way to get the other two types (unack'd and ready) using Pika?
No, the AMQP protocol doesn't support getting unacknowledged messages. You will still have to use the HTTP API for that. If you do a passive queue declaration, the message count returned is the number of ready messages.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I'm try to publish my data to ThingsBoard server i use this types of AT commands
AT+QIACT=1
OK
AT+QMTOPEN=1,"demo.thingsboard.io",1883
OK
AT+QMTCONN=1,"demo.thingsboard.io","MY_ACCESS_TOKEN",""
OK
AT+QMTPUB=1,0,0,0,"v1/devices/me/telemetry"
>{"temperature":35.00,"humidity":80.00} // MY_POST_DATA This line hanging my module
All AT commands response is ok But i finally enter MY_POST_DATA the module doesn't provide no response hanging the previous command.. and i check my ThinksBoard data never post telemetry..
Please help any one how can i fix this problem and publish MQTT server.
Step 1: Get hold of the official AT command documentation for the modem (Quectel BG96 I assume?). It should document how the AT+QMTPUB command behaves and what it expects. Everything else is just guessing. The manufacturer should provide this, and if not you should demand to get one.
...
Step 873, when you have exhausted absolutely all possible ways of getting hold of the official AT command documentation for the modem: You can try my guess that the command behaves similar to other commands that read arbitrary length user data, most notably AT+CMGS which sends SMS messages, which expect a Ctrl-Z (ascii value 26) as an end of data indicator.
+QMTPUB: 1,0,0 simply mean that BG96 has successfully published and your broker (thingsboard) have also acknowledged publication of message.
If you can't see data on broker, then please check if the topic you are publishing is correct or not.
It may happen you are publishing to another topic (or to a different PATH).
Ask 'thingsboard' for help regarding proper topic.
I'm trying to send a message from an Android companion app to a Pebble watchface app, but this fails with an APP_MSG_BUSY error. Reading the logs, I can reconstruct the following sequence of events, which is happening repeatedly:
Pebble app calls app_message_outbox_send.
Android companion app receives PebbleDataReceiver.receiveData call.
Android companion app calls PebbleDataReceiver.sendAckToPebble(context, id).
Pebble app receives outbox_sent call.
Android companion app does some work which takes less about 70ms.
Android companion app calls PebbleKit.sendDataToPebble.
Pebble app receives inbox_dropped call with APP_MSG_BUSY.
adb logcat shows the following warnings:
Pbl : [AppMessage] there is not UUID for transactionId : -1
Pbl : [JsInAppMessageHandler] sendAckNackToJs: run: can not send ack message to javascript code because uuid is null
APP_MSG_BUSY suggests there is an incoming or outgoing message in progress. However, you can see from the events above that there is no outgoing message. Also, this is happening for every incoming message, even the first that the Pebble app receives after restarting.
Can anyone offer some insight into what's going on here?
I found my mistake: when I called app_message_open, I passed a value for size_inbound that was too small to receive any of the messages that were being sent. Unfortunately, the AppMessageResult given to my inbox_dropped function wasn't APP_MSG_BUFFER_OVERFLOW as one might expect, but APP_MSG_BUSY.
Now for sheer speculation: what might have exacerbated this was that size_outbound was large enough. In fact, my mistake was swapping the size_inbound and size_outbound arguments. Maybe, by some logic, it didn't make sense to send APP_MSG_BUFFER_OVERFLOW because at least one of the buffers was large enough?
As you know, Cosm just turned into Xively on Tuesday.
They've added APIs for Products and Devices, and I'm trying to connect to them.
I'm running into problems getting the "Update a Device" API to work. The specific API is documented here:
https://xively.com/dev/docs/api/product_management/devices/update_device/
Anyone else have problems getting this call to return anything other than a 500 error message: '{"title":"Oops, something's broken","errors":"We've been unable to complete your request due to a problem with our server"}' ?
it's probably best mailing support#xively.com with this question I think. I just tried making the serial number update request on one of my devices via the API, and it seemed to work ok; so if you mail them then they'll be able to investigate your specific device.