Very impressed with your Instructable. Very well done. 

linw:

 

Very impressed with your Instructable. Very well done. 

 

Thanks! I find it frustrating that too many instructables projects assumes the person following it, already has knowledge in what they're following - which kind of defeats the purpose because if they did, then they would already be able to work it out themselves.  I like to write instructables so the person gets educated as they follow the steps in the project - its really a summary of what I learn't doing it myself.

Feel free to vote for it if you like :-)  I've entered into the instructables electronics competition - worth a shot...!

chimera:

 

Got the basic's of this going last night, works pretty well. Thanks so much for your help Aredwood, it makes sense, well - now that I've done it! 

 

EDIT: The only one downside, is the Wemos doesn't power up when the alarm powers up.  Suspect the alarm panel must draw a bit of power on startup, I'll try some capacitors for the Wemos see if that helps.  Other issue is powering off alarm panel all the time for testing, comes up with fault 12 hours later but luckily it is only because the date/time isn't set.

 

 

 

Breadboard to alarm...

 

 

iPhone view of OpenHAB

 

 

 

 

I want to revisit this... specifically my post above where I mention "The only one downside, is the Wemos doesn't power up when the alarm powers up."

As my alarm system has been powered on all this time, and the circuit was running off a breadboard I'd forgotten about this small issue.  While its powered, it runs fine (eg; power up alarm system, wait 5 seconds, and THEN plug power to the circuit)  I've now soldered this to a PCB and was going to enclose into the alarm panel, and noticed this small issue has come about again so need to remedy.

The issue is when everything is connected (circuit board to alarm and PIR zones etc) and I power up the alarm system (which also powers the Wemos) the Wemos doesn't work. The LED on it flashes once briefly, but it doesn't run.  I've worked out the issue is due to the GPIO's (that are connected to the comparator outputs) and I suspect its possibly something to do with the "alarm system power on test" (as I've tested it with comparator outputs unplugged, and it boots up fine)

The problem has something to do with the GPIO pins - I suspect the voltage that is hitting these is causing the issue, but I can't work out where or why. 

Any ideas?

Here is what it looks like (ignore the voltage reg on the right, that's been replaced with a buck convertor - although is irrelevant to the issue)

Have you tried seeing if its the ESP8266 crashing?

If you plug it into a computer and bring up a serial terminal if it does crash it will dump the crash log.

It may be something as simple as a number being out of bounds during the power on cycle.

If its the LM339 crashing the only suggestion would be to put a p channel MOSFET on the power rail to the LM339 and have the ESP8266 bring it high after a select amount of time.

You should check the rise time on your power supply to the wemos. Make sure the rail doesn't take too long to come up.

If it is this, you can get reset ics that hold your MCU in reset until the power rail is up.

It's not rise time, power is near immediate to Wemos (prior to buck convertor, 9V then jumps to about 12V - but seamless at 5V on buck output)

It's not ESP crashing, certainly not a coding issue.  As I say, works normally as per usual.

Delaying to power the LM339 makes sense, I'll work through this in my head and see how it goes.

Thanks for your replies!

Yes actually they do. I think 6.6V I measured. The pins are defined as pull-ups in code, but you’re saying there is a likelihood that the higher voltage is hitting the pins before the board is able to boot and define those pins as pull-ups?

Confirmed voltage on GPIO pin jumps high to about 6.7V for 1-2 seconds before dropping down to the ~4.7V or so range.  How do I avoid this?!

It could be the fact the pin voltage exceeds VCC - usually modern chips can handle an active input pin on boot.

Solve with a clamp diode - anode on GPIO, cathode (stripe) on VCC.

More info on illegal pin states is in the hardware manual for the MCU (sorry not familiar with that particular one you have, just speaking generally with my comments).

http://www.kevinmfodor.com/home/My-Blog/microcontrollerinputprotectiontechniques

Pic half way down the page shows this idea. 

Apologies, it was too late at night to be working on this... GPIO voltages are actually ok, I was measuring the comparator inputs rather than outputs 

I measured GPIO pin voltage and they are very low Vcc on power on.  GND connections from what I can see are good.  Buck convertor voltage output is dead on 5V on power up (plus as I say, if I plug power to the Wemos AFTER the alarm system has powered up it runs ok)  

However, I just did a test with the 12V VCC to the LM339 VCC unplugged, and the Wemos booted up fine.  So, if I control the LM339's power on by code instead, this should in theory work right?

If I'm powering on the LM339 via a MOSFET then I'd want an N channel wouldn't I?  Because the GPIO pin will be LOW on power up, and I'd need to provide HIGH to the gate to power it?  Or would it be better using a P channel MOSFET with pull up resistor then pull the gate LOW to power it?

I had an N channel FET (2N7000) floating around so hooked it up with a 1K ohm resistor pulling the GPIO pin to ground, gate to GPIO, source to GND, drain to GND pin of LM339 and altered the code in setup to set "LM339" GPIO pin low first, then delay a few seconds, then pull it high and it worked a treat. Thanks Geocom for the suggestion! Question though - would it make more sense to use a P channel FET still?  Eg: so I'm not wasting power by holding a dedicated GPIO pin HIGH all the time?  Is that the main difference between P and N from a usability point of view? 

The key difference between a p-channel and n-channel is that p only works on positive and n only works on negative.

The reason I suggested a p-channel is in some chips the GND can be tied to multiple pins even ones not marked GND(https://www.youtube.com/watch?v=2yFh7Vv0Paw) where as this should not really be the case with the positive rail.

But if it works fine with a n-channel mosfet then there would be no real reason to change it for a p-channel one.

That's right @aredwood.

i suggest you follow his earlier suggestion to check the state of the GPIO's internal pullup/down at boot.

You might find that all you have to do is invert the signal arriving at the GPIO (and the corresponding software) or, flip a config bit in the IO config register.

BTW, what pin numbers use the comparator input?