Sparkcore operating without an instruction


#1

Hi

I have set up my core to operate 2 240V sockets via relays. In parallel, the core also lights 2 LEDs to show whether the sockets are live or not. For various reasons, I am driving the relays (via transistors) from pins D0 and D1 and the LEDs from pins D4 and D5. All works well and the appropriate command driving a spark function turns the sockets/LEDs on and off.

My problem is that they also turn off randomly by themselves. When this happens, there is no change to the “breathing” cyan LED on the core. I would have suspected my assembly but the socket/LED pair always change state together. This means that the spark function must be executing even though no command has been sent.

Any ideas?


#2

To rule out any problems with your code, I would try running your hardware setup with Tinker, the default Spark app. That way you will know if the problem is in your code or your hardware.


#3

Hi @bko

I can try tinker but the problem is the random switching of two pins together (i.e., the relay pin and the LED pin). My code is very simple:

int turnOn1(String args){
    if (digitalRead(0) == LOW){
        digitalWrite(5,HIGH);
        digitalWrite(0,HIGH);
        temp = 1;
    }
    else {
        digitalWrite(0, LOW);
        digitalWrite(5,LOW);
        temp = 0;
    }
    return temp;
}

void setup() {
    pinMode(0,OUTPUT);
    pinMode(5,OUTPUT);
     Spark.function("switchOn1", turnOn1);
 }

(This is half the code. It is replicated for the other relay/LED.)

So if I try tinker I will lose the relationship between the pin pairs…


#4

@mrh1,

Can you do a proper code formatting by reading the Forum tips and tricks ? :wink:


#5

I will try to make my point in a slightly clearer way: I don’t think the Spark cloud is sending you spurious function calls so that leaves your code (firmware and web) or your hardware as the likely suspects. Removing one variable is likely to show where the problem is.

If you have a firmware issue and the core is spontaneously rebooting (but you aren’t watching the LED) that could explain your symptoms. Alternatively if your hardware has say insufficient drive to hold the relays in under some circumstance, that could explain your symptoms too.

I am happy to help you debug either scenario but first we have to figure out which is the most likely one to be causing the problem.


#6

As a thought - does the core support reading an output pin? (I know that arduino doesn’t fully support it.) Wouldn’t it be better to store the status in a variable instead?


#7

It was fixed months ago. Simply use digitalRead(PIN)


#8

Hi Bko

OK, I reflashed tinker. Everything works as it should when I send commands. Having left things alone for some hours, I have seen no random switching events.


#9

Hi Kenneth

Happy to post code correctly formatted - but where do I find the tips and tricks?


#10

So that seems to say that it is not your hardware but your code (firmware or web) that is causing the fault.

I think you should post your firmware code, but you have not said what you are using to control the core on the web side yet–how does that part work?

Tips and Tricks is a forum entry here:


#11

The firmware code is as posted yesterday (yes, I know it is not properly formatted - I’ll learn for next time…).

To control the core I am using an app on my IPhone using Smartthings. Now you have raised the matter, of course, the issue may be that this is generating spurious commands, even though the phone itself is switched off.

OK, problem solved! Bko’s comment about how I was controlling the core got me thinking. The Smartthings code that I am using is adapted from K. Varma’s project about combing Smartthings and Spark Core. Unfortunately, my lack of understanding about how this works meant that I had not spotted that there is a “polling” element that runs on a regular basis. If I remove this, the problem is solved.

That’s the trouble with being a mechanical engineer - we don’t read instructions.

Thanks to bko for your help and apologies for wasting your time on something that is down to my own failings.


#12

OK, got it!


#13

Glad you got it fixed @mrh1, good luck with the rest of your project!