Troubleshooting

I found the ESP8266 rock stable - been running for around 2 weeks so far. No issues. The issue above also seems to be fixed - been about 24 hours now, no crashes, no odd values. Update: Just done a update to Domoticz and now the value is incorrect and seems to be stuck there. Sensor debug: 0 LPG:0ppm CO:0ppm SMOKE:0ppm send: 1-1-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:0 Controller log: subtype = Voltcraft CO-20 CO2 = 536870912 ppm Quality = Bad 2015-11-08 21:29:09.177 (ESP8266 Gateway) Air Quality (Air Quality1) This is the 2nd time its happened right after a domoticz update (I'm running the dev build) Could this be a issue with domoticz? Its weird how it only does it now after a update. To fix it however I need to reset the sensor.

When radio drivers setup was created in 1.5 the channel radio constructor argument was simply forgotten. I think there was a pull request fixing this but I will probably not do any more patches of 1.5.

Domoticz treats all 'binary' devices the same and shows them as "lighting 2" which is an internal Domoticz type. In the Web interface you can set it to any specific type. So all the functionally (and more) for a door type is there

@DrJeff http://playground.arduino.cc/Code/Interrupts should help you out..

DI you have a similar serial log for the gateway? Think you should try to upgrade to be aligned with 1.5. Don't remember what problems you had earlier...

Hi, I still haven't found the cause of the problem. But I have found a workaround :) The problem is captured in the serial output of my previous post. As you can see the payload ? of the incomming message is for some reason messed up. I still suspect the mqtt-cllient-gateway to be responsible for this, but i can not prove this. So the workaround is to filter out only the good info from the messedup payload. The good info seems to be found in the first bytes of the payload, while the last part acts up randomly. I filtered using substring as follows :+1: String hexstring = message.getString(); String String3 = hexstring.substring(0,1); // Filter out unwanted additional characters = workaround bug

Do you have the radio connected during upload? What does the self-test say? To start self test connect A0->GND during startup. And have a look at the serial monitor.

I added the capacitor, but there's always the same problem :(

Maybe you can use the parking sensor example :-) http://www.mysensors.org/build/parking

@mvader Glad to hear you got it resolved. Cheers Al

@Dirk_H Hi, Thanks for all your help. I got it to work using an external pull-up resistor. I did a check on all my wiring just to make sure all was ok, and it was. The one thing I did get was a resistance on my front doorbell on what I thought was an open circuit; then I realized there was a lamp in the button. This video helped explain why it works, in a way that I understand at least. https://youtu.be/wxjerCHCEMg Thanks again @Dirk_H

The output looks fine to me. Is there anything wrong? Values for all sensors are presented and the values look good.

@Dwalt That was what i needed. It works now :-)

THanks! it worked for me too! :) @hek Maybe we should put a small hint about this (first delete old MySensors 1.4) on the Downloadpage?

My Uno with the enc28j60 shield is more stable, but still not THAT stable. Will go a week, sometimes two without crashing. Now it just locks up for no apparent reason. Haven't had a chance to troubleshoot it. interestingly, it always locks up now at a time when the 'receive' (green) LED is lit, so something about receiving a message over the radio is locking it up... I tried using the wiznet shield, but so far I've gotten two bad ones (even the built-in Arduino samples don't work), so I don't put much stock in them any more. I have been planning to swap out my enc28j60 shield for just the little detached module and see if that helps. Just amazes me as much as folks have banged on this stuff for all this time, that it's still unstable, but I guess each one is different, knock-offs, etc.

@insomnia Have you seen the basic MySensors example BinarySwitchSleepSensor ? (Personally I use a longer button settle delay though.)

@Splinteer said: And on the RPI which tty should I connect to ? Login to the RPi, plugin your USB serial device and type in a console: dmesg | grep tty which will return something like [145.376756] usb 5-1: pl2303 converter now attached to ttyUSB0 The serial device is now available at /dev/ttyUSB0

After looking at the flood of packets more closely, it turns out it was a combination of factors: a faulty IR sensor in the lock caused rapid flipping of the sensor's state, and the flood control timeout was set to 0...

RelayActuator__.ino

@Cliff-Karlsson Skip the Arduino and just go with red LEDs taped to coincell batteries. Should last thru Halloween. See this...