Stop RGB.mirrorTo(); once connected to Particle Cloud -- SOLVED

Hi -

Apologies for the trivial question, but I have not been able to resolve this seemingly simple issue. I have read numerous threads on RGB.mirrorto(); subject but have not found the answer.

My scenario is that I want to either:

  1. Mirror onboard RGB to external RGB LED but only until connected to Particle Cloud and then “hand over” external LED control to code. I managed to disable RGB.mirrorto(); once connected, but I am unable to engage RGB.mirrorto(); again once device has been put in Listen Mode via interrupt pin.

  2. Light up the external RGB LED while in Listen Mode after device has been put in Listen Mode via interrupt pin and without the use of RGB.mirrorto();

I would prefer to steer clear of SYSTEM_THREAD(ENABLED); if possible which I supposed disqualifies option 2 :slight_smile:

Would appreciate some help.

Thanks

I can’t quote follow your intent.
If you want your code to take over control of the RGB LED (onboard and external) you’d use RGB.control(true).
On the other hand if you want your code to only act on the external LED and have the onboard LED behave as alsways you’d need to stop the mirroring via RGB.mirrorDisable() - but then you need to reenable mirroring once you detect a loss of connection (or engage an alternative mode of operation) - best via a System.on() handler.

1 Like

HI @ScruffR -

Thank you for the reply and my apologies for not being clear. Let me they again.

The onboard LED does not really serve a purpose as it is not visible to the client, hence the need for the external RGB LED. Currently the External LED serve three statuses;

  1. Solid green when load controlled by device is running in energy saving mode
  2. Solid Blue when load controlled by device is running in normal mode
  3. Solid Red when load controlled by device is not running at all.

I also use Interrupt pin (exposed A2 pin; pulled to GND) to re-enter Listen mode, incase client WiFi details change for example. I implemented SoftAP in order for the client then to easily reconnect the new WiFi after putting there device in Listen Mode.

I would like the device to also indicate it is in Listen Mode via the External RGB LED so that the client can be sure it is indeed in Listen mode. I have this so far, initial RGB.mirrorto(); is in void Setup(); as I already have SOFTAP in the Startup. (I can post entire code, but it is quite long):


void Listen_mode() {
     if(connectToCloud) {
        if(Particle.connected() == false) {
             Particle.connect();
             connectToCloud = false;
             RGB.mirrorDisable();

        }
    }
}

void loop() {
    
    Blynk.run();
    CS();
    temperature();
    Listen_mode();
}

 void connect() {
     connectToCloud = true; //true
//     RGB.mirrorto(D1,D2,D3).   // If I Enable this, I get hard fault (red LED flash) until device restarts en reconnects to existing WiFi
     WiFi.listen();
    }
    

Initial RGB.mirror(); seems to work as desired when device starts up and stops as soon as device is connected to Particle Cloud, but when Listen Mode is entered via the interrupt pin, the device goes into Listen Mode, the OB LED is blue but External LED only starts indicating status once connected to Wifi. Then RGB.mirror(); then stops again once connected to Particle Cloud. From there normal External LED functionality resumes.

Hope this clarifies.
Regards, Friedl.

In this case I would stick with having mirroring active and persisted in the bootloader (lack of that is possibly the reason why you don’t see LM indicated on your external LED) and only take over RGB.control(true) when your know you are not interested in the system’s own RGB codes and once you want to hand back control to the system call RGB.control(false) (i.e. before entering Listening Mode) - don’t use RGB.mirrorDisable().

This is how you’d setup persistent mirroring
https://docs.particle.io/reference/device-os/firmware/photon/#mirrorto-


(you want the last parameter to be true for that - the last but one merely switches between common “anode” (true) and common “cathode” (false) mode)

1 Like

Thanks a million @ScruffR Let me try to implement, I will let you know of I have any further questions :slight_smile:

Regards, F.

1 Like

HI @ScruffR -

Great, got it working, all be it slightly different with the Photon controlling the LED mostly any only handing over control to the code during the following scenarios.

Here is an example of how it is implemented, hopefully it can help someone else as well.

void setup() {
    
    Serial.begin(115200);
    RGB.mirrorTo(D3, D1, D2);

// ** and a whole bunch of other SETUP stuff **//
BLYNK_WRITE(V1)                        // Holiday Mode Timer Widget 
{                                     
      powersaving = param.asInt();

if (powersaving == 1 && widgetTimerEnable == 1) {
        // Do Power Saving On stuff 
        RGB.control(true);
        digitalWrite(greenPin, HIGH);
        digitalWrite(led, HIGH);
        Blynk.virtualWrite(V7,HIGH);

 }else if (powersaving == 0 && widgetTimerEnable == 1) {  
        // Turn switch off
        RGB.control(false);
        Blynk.virtualWrite(V7,LOW);
    }
}

It also allowed me to get rid of a whole bunch of digitalWrite(greenPin, LOW); commands as I am simply handing control over the the Photon in these cases.

Thanks Again!
Friedl.

1 Like

Once you have assumed RGB.control() and you also have mirroring active, you can just write RGB.color(0, 255, 0); to have your LED (aswell as the onboard LED) light up green.

1 Like

@ScruffR -

It keeps getting better :slight_smile:

Ran into a small glitch. Code worked fine on breadboard version, but on the actual PCB it kept entering Listen mode. I then realised as these pins (A2 and A3) were initially meant for Sensor inputs, I had to solder some 3K3 resistors in place. I assume these are pulling the pin down causing it to enter listen mode all the time.

Is the fix as simple as changing from:

  • attachInterrupt(A2, connect, FALLING); to

  • attachInterrupt(A2, connect, RISING); and use 3V3 pin instead of GND?

Regards,
Friedl.

@friedl_1977, why don’t you give it a try!

Hi @peekay123 -

Haha… I did, but I don’t like ‘losing’ Photons… I very much have a SpaceX approach when it comes to these matters and sometimes regret it later. Somehow flashing red LEDs or some magic smoke just don’t pack the much a Rocket blowing up does :rofl: :rofl: Thought I check this time.

Regardles, my finding was that it did not work, neither did attachInterrupt(A2, connect, CHANGE);. I then resolve the matter by chaining it to:

   pinMode(A2, INPUT_PULLUP);
   attachInterrupt(A2, connect, FALLING);

Seems to be working now.

Regards,
F.

1 Like