@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

@frol Thank you for the data.
Well, it looks as if the workaround for errata12/13 doesn't work as described. TXERIF is never set in the 4 uip_debug-logs :-(, hence the timeout (BTW: it would make sense to return false in case timeout occurs so a packet might be retransmitted in that case. As TXERIF is not set sendPackage returns true in case of error). Strange thing is that even if a packet is not transmitted (and that is not detected) the next outgoing packet will reset transmitlogic anyway - but this doesn't seem to re-enable transmission, does it? (Any output truncated after the timeout?)
Maybe one should poll ESTAT for TXABRT instead of TXERIF (or both at the same time)?

• Norbert

intention is you may controll MySensor-actuators via mqtt-client-gateway by publishing messages to topic MyMQTT/<radioId>/<childId>/<variableType>

@frol thank you the feedback. If it still responds to ping it indicates enc28j60 transmit-logic does not stall and the changes in fix_errata12 branch seem to work. I think the freeze must have a reason that is unrelated to this low-level patch. What sketch are you using for testing?

that test was using Ethernet-gw on wiz5100 shield. Enc28j60 not tested (yet)

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.

Ok, I can reproduce this with Arduino IDE 1.0.6.
It did compile fine on IDE version 1.0.5 though.

EDIT:
go to PubSubClient.h and remove the 'PROGMEM' in line 72:

change:
boolean publish_P(char *, uint8_t PROGMEM *, unsigned int, boolean);
to:
boolean publish_P(char *, uint8_t *, unsigned int, boolean);

see issue on github and pullrequest with fix:
https://github.com/knolleary/pubsubclient/issues/46
https://github.com/knolleary/pubsubclient/issues/47

btw: I did improve reconnect of Ethernet-gw: http://forum.mysensors.org/topic/572/improved-ethernet-gateway

have noticed the same here. Upgrading the Gateway to 1.4.1 would receive from Relay-actuator 1.4 fine but The relay-actuator wouldn't receive messages sent by gw.
Upgrading the actor to 1.4.1 MySensors lib did solve the issue.

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...)

@MagKas I did investigate a bit - the implementation in UIPEthernet was based on an older Version of Silicon Errata. Rev B7 has clarified this issue in more detail, in fact Issue 13 contains pseudocode that also should solve your 'deadlock' on 'while (readOp(ENC28J60_READ_CTRL_REG, ECON1) & ECON1_TXRTS)'
The issue is that eventually TXRTS is not (never) cleared by the transmission-logic after package transmission so the while will never exit. As a workaround the code should wait for either TXIF or TXERIF to be set.

Here is my code that I just commited to UIPEthernet (https://github.com/ntruchsess/arduino_uip/blob/fix_errata12/utility/Enc28J60Network.cpp#L233):

// Reset the transmit logic problem. See Rev. B7 Silicon Errata issues 12 and 13
writeOp(ENC28J60_BIT_FIELD_SET, ECON1, ECON1_TXRST);
writeOp(ENC28J60_BIT_FIELD_CLR, ECON1, ECON1_TXRST);
writeOp(ENC28J60_BIT_FIELD_CLR, EIR, EIR_TXERIF | EIR_TXIF);
// send the contents of the transmit buffer onto the network
writeOp(ENC28J60_BIT_FIELD_SET, ECON1, ECON1_TXRTS);
// wait for transmission to complete or fail
while (((eir = readReg(EIR)) & (EIR_TXIF | EIR_TXERIF)) == 0);
writeOp(ENC28J60_BIT_FIELD_CLR, ECON1, ECON1_TXRTS);

The retransmission-logic that is described in Issue 13 is implemented outside of sendPacket-method. On transmission-error it returns false, the packet will not be freed in UIPEthernet::network_send() and transmission will be reattempted on next call to UIPEthernet.tick().

I also added a fix that allocated the 7 bytes of transmit-status-vector to prevent corruption of other outstanding packets. Code is in branch 'fix_errata12' (https://github.com/ntruchsess/arduino_uip/tree/fix_errata12). Maybe you'd like to test before I release?

• Norbert