I just took the time this afternoon and implemented a mqtt-gateway that works as mqtt-client:

https://github.com/ntruchsess/MySensors/tree/mqttclient/libraries/MySensors/examples/MQTTClientGateway

it is based on the work of @Damme (http://forum.mysensors.org/topic/260/mysensors-mqtt-gateway) and makes use of nick o'learys PubSubClient-library (http://knolleary.net/arduino-client-for-mqtt/)

The main difference to the existing MyMQTT-gateway is that it will connect to an existing mqtt-broker (e.g. mosquitto). This is beneficial if you want to integrate with other mqtt-client-devices sharing a single broker for your automation solution. It also ensures your mqtt-client that is going to pick up the messages from the gateway will talk to a 'real' broker understanding the whole mqtt protocolls semantics

It works both ways:
on startup or reconnect it subscribes to "MyMQTT/#" (configurable as MQTT_PREFIX). Any publish-messages payload that is delivered by the broker to a topic that complies with the sheme <prefix>/<nodeId>/<childId>/<variable_type> is forwarded as a C_SET-msg to the MySensors radio.
Any C_SET-message received from a node is published to the mqtt-broker using the same sheme.

• Norbert

I did improve stability of ethernet-gateway in respect to reconnect:

https://github.com/ntruchsess/MySensors/blob/ethernet_gw/libraries/MySensors/examples/EthernetGateway/EthernetGateway.ino#L125

Issue with relying on server.available() + server.write() is that it allows to connect with multiple clients. That might be fine with other protocols, but doesn't make a lot of sense as the gateway is by design connected to a single controller only. It also has issues when (re-)connecting more than 4 times in a row without doing a proper shutdown of previous connections as both WIZ5100 and UIPEthernet support only a limited (4) connections in parallel and TCP-timeouts are quite long so the gateway wouldn't notice not being connected to a valid remote-socket any more if you e.g. do a hard power down and reboot of your controller.

The change I made makes sure that whenever the controller reconnects any previous connection is properly removed by calling client.stop().

Works using Arduino-IDE 1.0.6/1.5.7 (or later) as it makes use of operator== in EthernetClient (a change I added this to EthernetClient some month ago for this very purpose...)

Cannot tell about the others, never tried them. But here is my experience with fhem:
in FHEM you find support for all the sketches that come with MySensors lib and may easily configure any combination and number of current defined sensor-, variable-types. Serial and Ethernet-gateway are supported. (MQTT is supported as well (using the mqtt-client-gateway), but the as the MQTT-gateway is not as configurable as FHEM itself the support for custom sensor-types is limitted). In terms of MySensors-protocol it supports the complete functionality of Serial- and Ethernet-gateway (including configurable Support for Acknowledge, so an actor would get a message resend multiple times until it's acknowledged).
FHEM requires very little resources (it even runs on a Fritz-box, so a RasPi is more than sufficient) and is written in perl. The buildin-web-interface is a bit old-fashioned, but there are mobile clients for Android and iOS as well. Values are persisted on restart, they may be logged and rendered as SVG-Plots. Value-changes may trigger arbitrary Events (as being written in perl you may even run your own perl-code as configurable events occour). And last but not least the fhem-codebase is very mature. I run an fhem-server 24/7 on an alix-board (that is also my router, owncloud and print-server) to control my heating-system since nearly a decade now with very, very little downtime. As I usually do very little changes to the setup availability has been better than 99% during those years including all maintenance. For sure availability has been proven better than for the arduino-based ethernet gateways
But as a last word: as administration is not all point and klick a bit of technical interest (e.g. willingness to use a web-based commandline-interface for configuration and maybe some knowledge of regular expressions and a bit of perl) is helpful to explore the full power of fhem.

• Norbert

so when you intent to use GNU GPL v2 or higher for all code why would you need the right to change to 'any other license' (even to licenses not compliant with GPL v2 of higher)?

I'd like to contribute but will not sign a CLA that allows this 'change to any other license'.

Feel free to pull any changes that I commit to my fork (as you have done with my UIPEthernet-lib):

https://github.com/ntruchsess/MySensors/tree/ethernet_gw
https://github.com/ntruchsess/MySensors/tree/mqttclient

all changes there are (and will remain) licensed GPL v2 or higher.

@Aloha
sure. You may use as many gateways in a single instance of fhem as the machine is capable to service in terms of cpu, ram and filehandles. What does not work is to use multiple gateways for the very same sensors to archive higher avaiability (or redundancy), so it would be beneficial to use different channels for each gateway to lessen cpu-load on the gateways ans save bandwith on the connection to fhem. If all sensors and gateways share the same channel you will have to assign each sensor to the gateway that suits best (e.g. is positioned with the least distance to the sensor) - fhem will just ignore messages for a gateway a sensor is not assigned to (if not in inclusion-mode).

• Norbert

@Aloha
fhem (or better 'perl') is unable to do a clean reload of a single module without restart of the perl-process. Hence the warnings. Just do a 'shutdown restart' on the web-console.

@Aloha
VAR_1 needs to be mapped for clientid 5:

attr Vatten mapReading_value15 5 value1

(you may choose to use any other identifier of your choice instead of 'value15' - this is just what the autocreate-mechanism is supposed to choose).

Edit: I just noticed that V_VAR1 was missing in S_WATER definitions for autocreate (that is fixed now: http://sourceforge.net/p/fhem/code/7112/)
With this fix it should be sufficient to just do a 'delete Vatten', enable inclusion-mode and restart the sensor. Autocreate should create all required attributes including the missing mapReading. As I didn't test with the Watersensor-sketch please let me know if it doesn't....

• Norbert

@hek said:

I can't seem to find any install instructions in english at the moment.

The commandref is in english:
http://fhem.de/commandref.html#MYSENSORS
http://fhem.de/commandref.html#MYSENSORS_DEVICE

@Aloha, I've just seen your post on fhem-forum. Seems you are not on the latest code, the kind of crash you experience has been fixed on Nov. 09 2014. Please upgrade:
http://fhem.de/commandref.html#update

• Norbert

@b0rmann
PubSubClient and ENC28J60 require more memory than an Uno provides. It should run on a Mega256 though.

For TCP you are right - the boolean return-value is not required as the library does free memory not before a packet is acknowledged or the connection is closed. I guess here I can remove some code from the lib. UDP does not retransmit and would loose packets just because of collisions. UDP should loose packets only when they time out or get dropped due to physical failure.

@Rachmat-Aditiya said:

fhem is more stable but you need to configure everything manually,

configure 'everything' is not entirely true, in respect to MySensors there's an autocreate-mode in FHEM. You will have to manually configure the gateway (e.g. 'define gw MYSENSOR /dev/ttyUSB0'), then activate autocreate (by pressing the include-button on the gateway, or setting the autocreate-attribute on the gateway device), then restart all MySensor-nodes and fhem will create a MYSENSORS_DEVICE-entry for every Sensor that sends presentation-messages while inclusion-mode is active.

Cannot tell about the others, never tried them. But here is my experience with fhem:
in FHEM you find support for all the sketches that come with MySensors lib and may easily configure any combination and number of current defined sensor-, variable-types. Serial and Ethernet-gateway are supported. (MQTT is supported as well (using the mqtt-client-gateway), but the as the MQTT-gateway is not as configurable as FHEM itself the support for custom sensor-types is limitted). In terms of MySensors-protocol it supports the complete functionality of Serial- and Ethernet-gateway (including configurable Support for Acknowledge, so an actor would get a message resend multiple times until it's acknowledged).
FHEM requires very little resources (it even runs on a Fritz-box, so a RasPi is more than sufficient) and is written in perl. The buildin-web-interface is a bit old-fashioned, but there are mobile clients for Android and iOS as well. Values are persisted on restart, they may be logged and rendered as SVG-Plots. Value-changes may trigger arbitrary Events (as being written in perl you may even run your own perl-code as configurable events occour). And last but not least the fhem-codebase is very mature. I run an fhem-server 24/7 on an alix-board (that is also my router, owncloud and print-server) to control my heating-system since nearly a decade now with very, very little downtime. As I usually do very little changes to the setup availability has been better than 99% during those years including all maintenance. For sure availability has been proven better than for the arduino-based ethernet gateways
But as a last word: as administration is not all point and klick a bit of technical interest (e.g. willingness to use a web-based commandline-interface for configuration and maybe some knowledge of regular expressions and a bit of perl) is helpful to explore the full power of fhem.

• Norbert

@frol Thank you for the data. Bad thing TXABRT is not set when timeout occours. I have to give this workaround a second thought. I hope I can somehow avoid the 1sec busy wait. It's not about the 1 sek of having unresponsive ethernet, but it stalls any other processing during that time as well

Did merge your pullrequest so others may test it easily.

• Norbert