[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] Please Try Out the MQTT-SN Gateway
|
Oh, missing details: Everything was QOS0 (I'm still contemplating how to buffer, but still have flexible code, on a platform as constrained as an arduino, you need to buffer just the payload I think). The MQTTSN code fits in an Arduino, but not with a lot to spare. That platform seems to be the lower limit for a moderately flexible implementation of MQTTSN, though I haven't tried that hard to slim it down. A BLE client really would be interesting; BLE is cheaper then XBee, much less power required, mostly awake small battery operation becomes realistic.
So, I've given it a basic trial using an XBee and I'm happy to say it works. My set up was:
- MQTTSNGateway in Ubuntu 16 Server VM using FTDI Serial adapter directly to XBee (coordinator). Only changes were for API mode 1, and Makefile change for XBee sensor network.
- Mosquitto broker in same VM
- Arduino UNO using slightly modded Paho MQTTSN packet lib with an XBee (router) shield, running my own state machine (lightly tested against my own MQTTSN gateway).
The Arduino uses SEARCHGW to find the gateway. It then connects, publishes status topic (with retain), and subscribes to two topics. It also publishes a rolling counter on a topic. It flips a couple of pins on the subscriptions. It also uses a Will topic/message on the status topic.
Everything seemed to work well from an MQTT perspective; I used mosquito_sub/pub to monitor change, plus observed the pins on the XBee. There were some hitches, but not all are reproducible; for example, ^C did not seem to exit the gateway in all states, I observed the CPU pegged at one point, etc., but these are all fairly minor bugs. The makefile could use better dependency setup. It would be nice if a cross platform (at least Linux and OS X and maybe other BSD variants) lib was used for the threading; some recommend an apache lib, but I do not have direct experience with it.
I hope to deploy it on a pi or in a docker instance soonish and let it soak against my 'house' mosquito broker, which has some activity (though certainly not 'busy'), and maybe have it fire up things on a display or something. Alas, I have family and job so this might take a couple of weeks.
Hi Paul,
Thank you for your good suggestion.
> digi recommends API mode 1 for most uses.
MQTT & MQTT-SN should transport a binary payload.
therefore, I thought simply escape mode is only way out to get the real start byte, not 0x7e in a payload, for a stable communication.
so, I have never tested API mode 1 from the beginning.
I'm expecting your XBee testing of API mode 1.
> This should probably be configurable.
It's easy to change the code for TEST.
Just comment out as follows:
=========================================
void XBee::send(uint8_t c)
{
// if(c == START_BYTE || c == ESCAPE || c == XON || c == XOFF){
// _serialPort->send(ESCAPE);
// _serialPort->send(c ^ 0x20);
// }else{
_serialPort->send(c);
//}
}
int XBee::recv(uint8_t* buf)
{
if (_serialPort->recv(buf) )
{
// if ( *buf == ESCAPE)
// {
// _serialPort->recv(buf);
// *buf = 0x20 ^ *buf;
// }
return 0;
}
return -1;
}
==========================================
XBee programs as far as I know are just sending with out Frame ID. It's unstable same as QoS0.
In my experience, A point of stable communication of XBee API mode is
that using a Frame ID in Transmit Request and get Transmit Status.
I will change it configurable after my struggling with client certificate required TLS connections.
Thank you for your cooperation.
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev