Troubleshooting

@hek I've rebooted several times over the past few days while working on other sensors. However, your idea sounds valid. So you're saying that I should be able to have multiple sensors running the example relay sketch on my network without issue, correct? This should be fine because each individual node/arduino gets it's own ID so the relays on each Arduino should not conflict with its neighbors.

I have a similar problem. I upgraded from 1.3 to 1.4 and my Wiznet gateway does not work. I can ping version 1.3 from my PC and it see the gateway. When I ping 1.4 from my PC it says that the destination address can not be found. I have downloaded the latest Ethernet gateway sketch, but it did not help. Has any other file change that could effect this. Thanks John

@Yveaux @hek in fact it has to be debounced for it vibrates on rising and falling so it is important to see. maybe the bling delay would do it simply but someoone may remove the led... Also through trial and error here is the way to manage it: // Setup the reed pinMode(DIGITAL_INPUT_SENSOR,INPUT); // Activate internal pull-up digitalWrite(DIGITAL_INPUT_SENSOR,HIGH); attachInterrupt(INTERRUPT, onPulse, FALLING); you have to power the pin to get the signal when both sides are connected.

I think it's both. you can have a relay node (say a light switch) act as a repeater (passing other nodes msg's on)

Well, all the sensors as still running YEAH YEAH YEAH... I think this problem is finally behind me. We have not locked up since moving to the latest versions of the DallasTemperature and OneWire libraries. Not sure what the differences are between the MySensor download versions and the latest, but it appears that was indeed the cause. Is there any way the MySensor project download can be updated to include the latest version of these libraries? Thanks to all who gave suggestions and time in helping me sort this out. I was very close to throwing in the towel..

I have the same setup, and it works okay, voltage sits around 3.2ish volts in operation when powered via USB. If your power supply is adequate, perhaps it's just a bad Nano?

Thanks Guys

@Hoffan - wiznet

@epierre said: Both need protection (internal or external) from excessive discharge (or excessive charge, and short circuits etc) That is where our new library to check battery level goes in, we could dream to have an internal mysensor security check of a LiPo battery ! they do so in 'copters I may pass on that. I'm not used to software glitches having quite so much potential impact, and I don't need to save every gram. But to each their own!

@goose I've fixed this bug, I will do some tests tomorrow before I upload the changes. http://forum.mysensors.org/topic/303/mqtt-broker-gateway/

Eb.. no. 360917673897 vendor "liuddndd2009"

@ServiceXp you said in this post: That was it!!!!! I tried 22uF, was still doggie, so I thought why not move up to 47uF wink and what do you know, that seems to be the winning value. I have some more testing, but looking pretty good so far. This sounds to me that the issue is solved... I can imagine that 1.4 requires a bigger cap while 1.3 doesn't. 1.4 uses auto acknowledge which can send burst packets. This could put a bigger load on your power supply.

@Nuubi said: Hope someone learns from this Yeah! Like.... you? :-)

take care to have the good number of pin, some sketch use digital others analogic... I've ordered light sensors and sound sensors without analogic, I couldn't use them for my target use...

@lininger No. it is only 5 misses now.

@bjornhallberg That was it!!!!! I tried 22uF, was still doggie, so I thought why not move up to 47uF ;-) and what do you know, that seems to be the winning value. I have some more testing, but looking pretty good so far. Thanks everybody for all the suggestions.

@mikeones Yes you got it, some devices are active low. (Just to confuse things, some relays have double throw outputs, meaning that one pair of conductors is shorted when the relay is powered - "Normally Open/NO" - and one when it's not powered - "Normally Closed/NC" (with one of those contact being common to both). So sometimes you might power a device with the NC connection of the relay output, meaning the device loses power when the relay is powered. One reason do so this would be if you want the device to be powered even if the microcontroller was disabled. Anyway, take that into account too, and return 1 if after all the possible inversions, the hardware device is powered on. For code, you could just return !digitalRead(...), where the NOT operator ! will convert 0 into 1, and 1 into 0 more simply than the ?: syntax (actually it will change any non-zero value to zero, not just 1).

I'm aware of the superiority of 1.4. Because I just started with building my custom controller I will go with the development branch for now. I really like the new protocol so far. I'm using very basic arduino sketches at the moment. The only thing I'm worried about is my custom controller that I'm building in Node-Red. Hopefully the feature changes will not have to much impact on that part.