Best posts made by ntruchsess

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.