Input pullup or down - I'm missing something

[variable]

Disclaimer - its past my bedtime, apologies if this is asked and answered and my fritzing/mspain mashup makes no sense.

Short of it is that I’ve got this touch panel that is fed 3v via 3v & gnd from my photon, but the touch panel is always at 3v - normally closed I guess. I started confident I knew what I was doing but I think I’m missing something. I can catch the drop in voltage on the multimeter just enough to more or less confirm that it probably doing what I think - which is normally closed, so 3v to the D4 pin, and then open when pressed momentarily.

I don’t have control over the design of the switch - exceeds my motivation anyway, but its bugging me that its just out of reach.

First the code:

#define buttonpin D4

volatile int buttonPressed = 0;
void buttonPressed();

void setup()
{
  pinMode(buttonpin,INPUT_PULLDOWN);
  attachInterrupt(buttonpin,buttonPressed,FALLING);
}

void loop(){}

void buttonPressed()
{
  Particle.publish("I'm im-Pressed","go to bed already",PRIVATE);
}

I’ve tried pullup, pulldown, nothing, rising, falling, change… if I do anything other than Falling, it just continuously thinks somethings happening and spams the console - almost like its floating, which I’d have thought pull-up or down would have taken care of (maybe I need a bigger resistor?)

Keep in mind, I haven’t actually tested this chopped version - but I’ve tried some variations using a volatile int to try and grab a value and have been considering doing this analog and seeing if its actually going to zero or if its just going on holiday.

(again, sorry - I’m fading here) - here’s my sad attempt at Fritzing (couldn’t for the sleep deprived life of me find a normally closed 3 pin ‘lit’ button).

In case you’re curious, this is the touch panel off of an aeon labs touch panel for their micro dimmer - I had a good reason for wanting to do this (that is at the edge of my memory - though now its more that I have the pieces and they’re gathering dust…)

Here’s the back and front side of the switch:

I believe the model is AL001-W-US (swap W with B for black). I’ve not checked out what the 'K2, K3, K4’s do yet - one thing at a time.

The end goal is essentially to pipe this via MQTT and through something hopefully not too annoying, end up on my Hubitat controller. Right now I’d settle for it not freezing up, rebooting unpredictably, taking half a flash and just rebooting again, and just generally being a pain in the ass. And now its time to dream of electric sheep…

Any thoughts (or RTFM’s with useful tidbits) would be very welcomed.

[ScruffR]

First you mustnot call Particle.publish() from an ISR.
rather use a volatile flag and act upon it in loop()

Also this doesn't sound reassuring

@variable

I can catch the drop in voltage on the multimeter just enough to more or less confirm that it probably doing what I think

To actually tell what's happening (or better what not) you'd better look with a oscilloscope.

Without a datasheet to that touch panel it's difficult to advise, but I'd expect it to provide two descrete levels for touch and no-touch, hence pull resistors shouldn't be required - but I may be wrong.

---

Update:
Following "advice" will only represent my personal understanding of the situation and dealing with mains power is potentially dangerous, so you should only handle mains installation when you know what you do and allowed to do so according to your local regulations.

After some googling it seems that touch panel will just act as a fancy switch that closes K1 to COM when engaged. Hence INPUT_PULLUP and detecting a FALLING edge should work. However, without knowing the quality of the "contact" the internal 40k pull-up may be too weak. You could try a stronger (e.g. 4k7 or 2k2) external pullup on K1.

[variable]

Hey @ScruffR, thanks for taking the time to respond - I'm glad you were able to extract something from my sleepy posting

So, the idea isn't for the switch to actually do anything other than act as a button - the dimmer that usually accompanies this won't be present, just a 120vac to 5vdc (probably USB since they're easy) adapter. 99% of the wiring in this place is 2 wire toggle switches - I say 99%, because the 1% caught me by surprise, reinforcing the 'danger' part of the mains power... (someone needs to be hit on the head with a rolled up newspaper for not labeling anything).

@ScruffR

First you mustnot call Particle.publish() from an ISR.

rather use a volatile flag and act upon it in loop()

I suspected this to be problematic - ironically, it was only in there to help me debug as I designed myself into a corner by not leaving room for either a USB port or a serial connection... suffice to say, this will be changed (its been "finished" for over a year.. in a tub in the corner..) My guess is I was trying to address to many things at once without knowing what the underlying issue was - I got quite a bit ahead of myself.

The logic issue I ran into initially was that I was having a similar problem (I think?) with the ISR using an MQTT publish instead of the particle publish. I need to think about the volatile flag a bit more so that I don't end up using delays and don't bog myself down with a bunch of timers (usage understood - makes for a lot of code though. I still consider myself to be somewhat n00bish so efficient is still a work in process).

Speaking of timers, trying to debug, I was attempting to use the built in software timer (which was probably an exercise in futility) but I wasn't entirely clear whether or not it would interfere with the ISR attached to my button pin or not - and if it was causing problems. Not sure how to word this bit - I know there's syntax for 'startFromISR' (etc.) but does it have some level of priority that might/would conflict with the priority of an attached interrupt? I know you can set priorities on individual interrupts, though I assumed this was so that if you had a number them, you could prioritize them, but I've never been quite clear as to what else gets interrupted if you set the priority too high. I still can't account for the reboots that seemed to happen every so many seconds from 1 or 2 to 10-15 (with it occasionally just freezing completely).

@ScruffR

To actually tell what’s happening (or better what not) you’d better look with a oscilloscope.

Without a datasheet to that touch panel it’s difficult to advise, but I’d expect it to provide two descrete levels for touch and no-touch, hence pull resistors shouldn’t be required - but I may be wrong.

Aeon labs has a lot of nifty stuff, but a distinct lack of information in the datasheet department - possibly to keep people like me from 'fiddling' Which I guess I can understand...

As for an oscilloscope, the best I've got is one of these guys: Sainsmart DSO DS211 Mini Oscilloscope that I barely know how to use.

In any case, I think I've got enough to go on (I still have a hard time wrapping my head around the idea that a 40k resistor is weak by comparison to a 4k resistor - in my head, bigger=stronger.. )

Off to re-read the user manual on my "oscilloscope" (thanks again btw!)

UPDATE:
That wasn't as hard as I was thinking - drops to ~0 (was actually -120mv which I'm going to assume is not especially interesting(?))

[ScruffR]

Wow, that's a lot of points to touch
So I'm going for this one

@variable

In any case, I think I’ve got enough to go on (I still have a hard time wrapping my head around the idea that a 40k resistor is weak by comparison to a 4k resistor - in my head, bigger=stronger… )

A pull resistor pulls the level of the pin in one direction (HIGH or LOW) and the smaller the resistor value the more powerful the pull is.
The extremes would be a 0Ohm resistor which would make it virtually impossible to overcome and force that pin to get any other level than the one the pull resistor forces. On the other end you'd have a ∞Ohm resistor which would be so weak that it wouldn't pull the pin at all and the mere fluctuation in atmospheric charge can pull the pin wherever it wants.

OK, one more

@variable

(usage understood - makes for a lot of code though. I still consider myself to be somewhat n00bish so efficient is still a work in process).

I'd not say a lot of code but only slightly more

const int buttonPin = D4;
volatile boolean buttonPressed = false;
void buttonPressedISR();

void setup()
{
  pinMode(buttonpin, INPUT_PULLUP);
  attachInterrupt(buttonPin, buttonPressedISR, FALLING);
}

void loop()
{
  if (buttonPressed) 
  {
    Particle.publish("I'm im-Pressed","go to bed already",PRIVATE);
    buttonPressed = false;
  }
}

void buttonPressedISR()
{
  buttonPressed = true;
}

However, debouncing might still be required. But a poor-man's debounce would be a delay(100) after the publish call.

[variable]

@ScruffR

Wow, that’s a lot of points to touch

Yeah.. I do tend to go on a bit

Thanks for the explanations though!

[variable]

Had to make buttonPressed not be both a boolean and a function but otherwise worked like a charm!