Connecting to AMQP broker (Rabbitmq)


#1

Hello!
Could someone explain a bit thoroughly how to connect to RabbitMQ broker? For now I have code, but it gives me ERROR: Transport error:
amqp:connection:framing-error: AMQP header mismatch: Unknown protocol [‘AMQP\x00\x00\x09\x01’]
Code:

const rabbitmq = “78.84.XXX.XXX:5672”;

conn <- null;
session <- null;

function amqpConnectionManager(event, errorDetail) {
// Received an event from the AMQP connection
if (errorDetail) {
server.error(errorDetail);
} else {
switch(event) {
case “CONNECTION_OPEN”:
session = conn.opensession(amqpConnectionManager);
}
}
}

conn = amqp.openconnection(rabbitmq, amqpConnectionManager);

It was ment just to connect to broker. By the way, Node-RED connects to it and works as expected.

Kind regards,
Pavel


#2

Ok, I’ve got it :smiley: You should enable AMQP 1.0 plugin in RabbitMQ.


#3

Unfortunately, it does not work as I thought it should. Are there any instructions (or examples) available from ElectricIMP to understand how does AMQP work?

BR,
Pavel


#4

Yep it’s AMQP 1.0; what are you looking for that isn’t in the documentation?

MQTT is going to be available very shortly, which may be easier (it’s more fully featured as a client)


#5

Thank you, Hugo!
I was looking for how to use exchanges, how to specify routing key etc.
Great news about MQTT, are there any terms in which MQTT will be released for developing?

BR,
Pavel


#6

The routing key is, I believe, the path that you pass into amqp.openreceiver (or opensender).

Docs on MQTT are here: https://developer.electricimp.com/api/mqtt - we are in final production testing for this, to ensure it’s robust. Most of the testing has been done against Azure IoThub but as people use it for other things we’ll ensure that it is usable with them. Are you planning to use it with your own broker or something else?


#7

The routing key is, I believe, the path that you pass into amqp.openreceiver (or opensender).

For my testing i use RabbitMQ with amqp1.0 plugin, and the path that I pass into creates a new queue. But if MQTT functionality will be released shortly, then I will give up AMQP. For mqtt mosquitto is planned to be used.

BR,
Pavel


#8

We’re keen to get more people using the MQTT implementation, and we’re hoping to release it as a “beta” feature, on an opt-in basis. Details of how to opt in are still under discussion, and the exact timeline depends on the results of the final few rounds of testing.

We’ve tested it with Azure IoTHub and, less thoroughly, against Google Cloud IoT Core.

As a beta feature:

  • We don’t expect the API to change, but we reserve the right to change it if absolutely necessary.
  • There might be edge cases that expose stability bugs. Particularly if used with brokers that we’ve not tested against.
  • Don’t use it for large-scale production.

In particular, we don’t expect to support client certificate authentication in the initial beta release.

Support/testing for other MQTT brokers will be added based on customer demand.


#9

Thank you for information!

Are there any alternatives to mqtt and AMQP in order to send large amount of small messages from agent? Maybe I have missed an better implementation?


#10

HTTP works pretty well. Due to HTTP/1.1 connection reuse, generally there’s no TCP or TLS overhead to send many small requests. Have you tried it?


#11

I am constantly getting too many requests error with http.post() :thinking: With sending one message/second


#12

That’s strange; the rate limit allows you to burst up to 40 requests per second, but sustained you can only do two posts per second per agent (at least on the public cloud).

Is the error you’re seeing from the imp side, or from the remote end? It’s quite possible the remote server is rate limiting you. When you see a 429 return, check the returned headers - if it contains x-agent-rate-limited then you were rate limited locally, vs remotely.

See https://developer.electricimp.com/api/httprequest/sendasync