-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New mqtt version with mosquitto #257
Comments
Hi, take a look at #249 if you are using it over SSL. if you want to check it with older versions you have 2 options:
if you need more help regarding your issue please post some sample code of what are you doing so we can help. Best regards, |
Which example are you using that it is not working? There might be a race condition problem in the example in the README. It seemed fixed, but please try: var mqtt = require('mqtt');
var client = mqtt.connect('mqtt://test.mosquitto.org');
client.on('connect', function() {
client.subscribe('presence');
client.publish('presence', 'Hello mqtt');
});
client.on('message', function (topic, message) {
// message is Buffer
console.log(message.toString());
client.end();
}); |
Hi All thanks for helping! but i have mosquitto installed on a cubietruck (ubuntu) i have done the changes regarding connect var mqttbroker = { address: '10.0.0.47', port: '1883' }; client.on('connect', function() { client.on('message', function (topic, message) { but also this not working and this not (this just ends the programs and gives back cursor) var mqtt = require('mqtt') client.subscribe('presence'); |
hi, connect constructor use 2 parameters: look in lib/connect/index.js from line 53 to 58 for how to use those 2 parameters your last example is correct, but you call client.end() before you actualy receive the message. move the client.end() inside the function for receive message and it should work Best regards, |
Hi itavy sorry, i had tested that also, did so many testing this is not working also, but i have also this for monitoring, and nothing comes in there also? this is the code i use now, like i told before with old mqtt its running instantly with same setting var mqtt = require('mqtt')
, host = '10.0.0.47' // or localhost
, client = mqtt.connect();
console.log('starting');
client.subscribe('presence');
client.publish('presence', 'bin hier');
client.on('message', function (topic, message) {
console.log(message);
client.end();
}); |
hi, i can tell you what i have done when i switched first time:
Regards, |
Hi, I am usinge Ubuntu 14.04, mosquitto, and node mqtt on the same laptop. mosquitto_sub and mosquitto_pub on localhost work as expected but node mqtt does not. node v.0.10.25 Here is the test code with log messages for every event. var mqtt = require('mqtt');
var client = mqtt.connect('mqtt://127.0.0.1');
console.log('mqtt.connect');
client.on('connect', function () {
console.log('on connect');
client.subscribe('presence');
client.publish('presence', 'Hello mqtt');
});
client.on('error', function(err) {
console.log('on error', err);
});
client.on('close', function() {
console.log('on close');
});
client.on('disconnect', function() {
console.log('on disconnect');
});
client.on('reconnect', function() {
console.log('on reconnect');
});
client.on('offline', function() {
console.log('on offline');
});
client.on('message', function (topic, message) {
// message is Buffer
console.log(message.toString());
client.end();
}); The output looks like this:
If the URL is changed to mqtt://test.mosquitto.org, the test works fine. The output looks like this:
I suspect this is a race problem since connecting to localhost must be < 1ms while connecting to test.mosquitto.org is probably > 50 ms depending on location. I will try to work backwards from the offline event since it is emitted in a single place in the code. Thanks, |
Which version of Mosquitto are you running locally? Il giorno mer 18 mar 2015 alle ore 23:02 bbx10 [email protected]
|
Hi, mosquitto 3.1 is the default version for Ubuntu 14.04. I found the problem and has nothing to do with timing or race conditions. node mqtt requests protocolVersion 4 by default but mosquitto supports up to 3. And mosquitto does not like MQTT The following messages appear in syslog when mosquitto logging is turned on.
The following works but I am not sure what the protocol ID should be. I copied the value that mosquitto_sub sends. var client = mqtt.connect('mqtt://127.0.0.1', {
protocolId: 'MQIsdp',
protocolVersion: 3
}); I will take a look at mosquitto source code to see what the rules are for the protocol ID. Or just build from source code instead of using the version in the repo. bbx10node |
Hi, Installing mosquitto from the mosquitto dev PPA solves the problem as well. The version is 1.4-0mosquitto1. The example in the README works without changes except I changed the URL to 'mqtt://127.0.0.1'. bbx10node |
Thanks for reporting and helping triaging this one. I updated the README accordingly. |
Thanks @bbx10. I ran into exactly the same problem. Your post helped immensely. |
@bbx10 and @mcollina i've same issue in localhost doesn't work, if install default MQTT package on ubuntu 14.04, solved problem by installing using this method, work like a charm |
This problem is still around here a year later. According to my reading of the MQTT spec, the broker should return a CONNACK with return code 0x01 if the protocol level isn't specified. Is there any way the module can detect this and emit an 'error' event? |
@jimbojw I think it's fairly straightforward. Would you mind to send a PR? |
Update: I spent a couple of hours looking into this, about at the limit I'm willing to sink. :) I've noticed a couple of problems (by module):
Somewhere there should be a test that implements a minimal shim server that correctly connack's for version 3 but not 4, like old versions of Mosquitto do. It's not clear to me which package ought to contain this, my guess would be I stand by my assertion though if the server connack's with return code 0x01, this should be interpreted by the client as an error condition that will not be resolved by reconnecting and should emit an 'error' event. It's not clear to me however which module ought to be responsible for this and how to implement a test for it. Next steps:
|
So:
You want to place the fix here: https://github.com/mqttjs/MQTT.js/blob/master/lib/client.js#L681-L701. |
TL;DR This is a problem with the MQTT protocol, not the mqtt Node module. Thanks for the link to the code for From the spec on CONNECT: http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connect (emphasis mine)
I investigated the bytes passed on the TCP connection between mqtt and old Mosquitto. As far as I can tell, Mosquitto is simply closing the connection in response to the invalid protocol version number, which the specification allows it to do. From the client's perspective, the socket just closed unexpectedly. It has no way of knowing whether this was a network interruption or a wilful rejection of the CONNECT packet. Continuously attempting to reconnect may be the correct move here. However, from the perspective of the user of the mqtt npm module, there is no difference between attempting to connect to a TCP port that's not listening at all, and one that accepts the TCP connection but rejects the CONNECT packet. There is no 'connected' event that signals that the underlying TCP connection was at least successful. When connecting, there are two cases worth considering separately. One is the case where at some point in the past a successful CONNACK had been received. These cases will often be due to a connectivity issue that could be resolved in the future. For example if the broker restarts, or there's a hiccup in the client's network connectivity. The other case is where at no point in the past has the client ever received a CONNACK. These cases are often (but not always) going to be due to incorrect configuration like wrong host/port, wrong protocol version, etc. This is the case with old Mosquitto. Currently the mqtt module's strategy is optimized for the first case. In the case of a disconnect, we attempt reconnect ad infinitum. It might be nice to have an optional "maximum first connect threshold" that stops trying to connect after some reasonable number of attempts if a CONNACK has never been received. This would help users triage configuration issues, but should NOT be the default since this would change the behavior of production systems which may already rely on the infinite reconnect strategy. In any case, I do not have cycles to implement this functionality myself, and we may as well close this bug as working as intended. |
Thanks for investigating this, and providing a definite answer for this. |
Hi
Im using mqtt for a long time and is working very good
this weekend i installed a new raspberry with the new nodejs 0.12 and also your new Mqtt
I cant get it to work anymore?
If I use your new sample, mosquitto does not see any topics
The program runs without errors but no topics?
My mosquitto is running on another raspberry working good with other raspberrys with lower version of mqtt
Is there a possibility to install an older version of mqtt, so i can check?
any known issues for this?
Thanks
pieter
The text was updated successfully, but these errors were encountered: