User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
Hi Paul,
On 10/26/2015 03:50 PM, Paul Kierstead
wrote:
I'm already using your MQTTSNPacket on the client
side (atmega based platforms in the arduino vein currently, with
some other clients planned), and it works lovely (thanks for
writing it!), though there are some oddball things in there
still which looks (to me) like it might be from an earlier
version of the spec, but they don't get in the way. I've not
gotten around to figuring out MQTTSNClient classes (in
particular what the requirements for the Timer class are), but
will probably adopt it when I start having my clients subscribe.
Maybe you could open a bug, if you haven't already, describing the
oddball things?
The problem is the gateway side when you want to pick up
from something not IP, it gets kinda ugly. If the MQTT-SN
broker supported the forwarding method (FE I think it is?), it
would make writing a "get it off x, send on" super easy as it
is essentially stateless. Or, as a second approach, if brokers
like Mosquitto were more flexible about how you stuff frames
into them, you could write something. But right now, with the
tools I've been able to find, you seem to end up writing your
own gateway, though at least the protocol parsing/serializing
libs are getting pretty good.
I've already written
two embedded client packages MQTTSNPacket and MQTTSNClient,
in the aame portable style as the MQTT embedded client. I
wanted to write a gateway which would be similarly portable,
across network stacks and OSs. Maybe an gIt would be a
nice family :-)
The first one would be transparent, for sure (passing on
client requests as if they came from an MQTT client with the
same client id). Then maybe an aggregating version
afterwards.
Ian
On 10/26/2015 02:01 PM, Paul Kierstead wrote:
"MQTT-SN to MQTT embedded gateway"
I've been mucking about with MQTT-SN for a largely
personal project (home automation, no surprise, to
revise and expand a small network of sensors) and I'd
love to see some work in the MQTT-SN part. In
particular, support for forwarded messages (as per the
MQTT-SN spec) and, in the broker, more flexible in put
of packets (basically quit assuming UDP).
I've ended up in the short term working on a
gateway myself from ZigBee/MQTT-SN -> MQTT (in
python, because it is short term to get my network
going), but would be very happy to put my time
developing something more widely useful.
I'm planning to put together a release roadmap
for Paho for the next year to 18 months.
Items on the list include:
- contributing to M2Mqtt: regression tests,
disk persistence, maybe some other items
- offline buffering (ability to send while not
connected) and automatic reconnect for C, Java
and _javascript_ clients
- ongoing embedded client improvements: proper
FreeRTOS support, asynchronous clients, build
improvements, documentation: porting guides,
tutorials, formal MQTTClient-C release
- Android service stability - it's possible
James has achieved much of this already, but
we'll have to
- WebSockets support for C, Python clients
(any others?)
- MQTT-SN to MQTT embedded gateway
- MQTT conformance test material
- possibly an MQTT forwarder for DMZ (it's
been mooted, but I'm not exactly sure what it
means)
- device management in the form of a LwM2M
mapping over MQTT. However,
before we can commit to an
implementation plan, the Eclipse
Foundation is working to clarify a few
legal matters with the OMA.
Are there any other items that anyone would
like to see? All comments welcome.
Thanks
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto