Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Please Try Out the MQTT-SN Gateway
I should have checked my git diff -- another required change is

diff --git a/MQTTSNGateway/src/linux/xbee/SensorNetwork.h b/MQTTSNGateway/src/linux/xbee/SensorNetwork.h

index f4a18ee..264c57d 100644

--- a/MQTTSNGateway/src/linux/xbee/SensorNetwork.h

+++ b/MQTTSNGateway/src/linux/xbee/SensorNetwork.h

@@ -125,6 +125,7 @@ public:

        int read(uint8_t* buf, uint16_t bufLen);

        int initialize(void);

        const char* getType(void);

+       const char* getDescription(void) { return "XBEE"; }

 

        SensorNetAddress* getSenderAddress(void)

        {


to be able to compile the xbee version. The UDP one gives a variant description; you might for this one too, I'm not sure about its purpose, I was just "making it go".

Another change I would suggest is

diff --git a/Makefile b/Makefile

index 6f33f36..f25a044 100644

--- a/Makefile

+++ b/Makefile

@@ -11,7 +11,9 @@ SRCDIR := MQTTSNGateway/src

 SUBDIR := MQTTSNPacket/src

 

 OS := linux

-SENSORNET := udp

+ifndef SENSORNET

+  SENSORNET := udp

+endif

 

 CPPSRCS :=  \


to allow the sensor net to be changed from make without altering the makefile. Ultimately, if we wanted this kind of thing to be an distributed binary, I think we might want the sensor net to be software selectable instead compile time selected, as than only a single binary is needed, but at least this change allows two binaries to be built without altering the Makefile.

Lastly, I'd like to see the XBee device SerialDevice to be able to be overridden on the command line, as if you are stuck using a USB serial device you might need to detect the device name before calling the gateway and pass it in on the command line (there are ways to get a steady device name if one does get desperate...). I can run up a diff for that if you like (eventually... the command line handling/def file handling is a fairly layered here and I've not followed it through completely)

PK

On Sun, 25 Sep 2016 at 06:55 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:
Paul and Ian,

I made a pull request for configurable API mode, Termination of gateway and TLS connection.
It works except client certificate required TLS connection.

Tomy Technology

Tomoaki  YAMAGUCHI

2016-09-25 10:48 GMT+09:00 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx>:
Paul,

Thank you for testing and informations.

According to your link, Digi has implemented the technique of escaping characters in an API frame in order to improve reliability, especially in noisy environments.
therefore, it should be configurable as you mentioned.
I will update it.

> this might take a couple of weeks.
Thank you for your cooperation.

Tomy Technology
Tomoaki  YAMAGUCHI

2016-09-25 2:56 GMT+09:00 Paul Kierstead <paulkierstead@xxxxxxxxx>:
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.

On Sat, 24 Sep 2016 at 13:38 Paul Kierstead <paulkierstead@xxxxxxxxx> wrote:
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).

All XBees series 2, ZigBee firmware load, API mode 1. See http://knowledge.digi.com/articles/Knowledge_Base_Article/Escaped-Characters-and-API-Mode-2 for Digi recommendation on mode 1.

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.

PK

On Tue, 20 Sep 2016 at 19:57 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:
Hi Paul,

Thank you for your good suggestion.


> digi recommends API mode 1 for most uses.
I didn't know that.  

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.



Tomy Technology

Tomoaki  YAMAGUCHI

2016-09-20 23:09 GMT+09:00 Paul Kierstead <paulkierstead@xxxxxxxxx>:
One hitch in the XBee code is that (as far as I can tell) it assumes API mode 2 (escape mode), which is not the generally recommended mode for XBee; digi recommends API mode 1 for most uses. This should probably be configurable.

Hopefully I'll get some time soon to hack it back to API mode 1 and run a couple of little trials. I have a simple remote power switch I need and was going to do with an ESP8266/MQTT (it is what I have used in the past), but could try it out with an XBee/MQTTSN, as it would be nice if it could run off battery for a while. What I really need is MQTTSN over BLE ... someone needs to write that up!

On Tue, 20 Sep 2016 at 00:47 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:
Ian,

Sorry, I miss understood your intension.
Link is correct.

Tomy Technology

Tomoaki  YAMAGUCHI

2016-09-20 13:39 GMT+09:00 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx>:
otherwise,  Makefile is missing in github.

Tomy Technology
Tomoaki  YAMAGUCHI

2016-09-20 7:04 GMT+09:00 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
Hello all,

Tomoaki is kindly working on and contributed an MQTT-SN transparent gateway.  You can find it here:

https://github.com/eclipse/paho.mqtt-sn.embedded-c/tree/gateway/MQTTSNGateway

in the gateway branch.  I had been waiting for a few more updates to go in before asking for interested parties to try it out for themselves, but I've not found the time I was hoping for.

The instructions for building and using it are in the Readme. I've been using the MQTTSNPacket client to test it out.  I'm hoping a few more people can use it and open issues for bugs or suggestions.

Thanks!

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
 
_______________________________________________
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


_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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


_______________________________________________
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

Back to the top