I have looked into this a bit more and the cause for the Assertion Failure (SOS+14) seems to come from the fact that the library hooks up a timer interrupt which calls digitalRead() before setting the pinMode() to INPUT.
Obviously one of the recent releases enforces the need to explicity set pinMode() before using digitalRead() (at least in an ISR) although INPUT is the default GPIO state.
Have you tried if it works. If so, where in the code do you set the pinMode()? Just asking because getting my photon working after the sos+14 was a pain.
I have not tried whether the IR part works but the SOS panic crash went away and that was enough for my part. Unfortunately @matej_konecny never reported back whether this actually solved his issue.
However, the obvious place without having to change the library would be in setup() before using any of the IRRemote functions.
Unfortunately @mdoan7 has not reacted yet to the issue filed here
Thanks for the quick reply, works like a charm now! For future generations, here’s what I did.
BINGO!
edit: I’m using OS 2.0.1 on my photon.
I’d suggest you rather use A1 instead of 11 in the pinMode() call.
While it might be common practice in Arduino code to use the anonymous pin numbers, in the Particle ecosystem we encourage people to use the pin labels for clarity.
There are always macro definitions that do the label/pin-number mapping for you.
While it’s unlikely that pin numbers change using the labels would still keep you safe.
Particularly between device generations the pin numbers might not always match, but that extra level of abstraction (hardware agnosticism) helps writing more portable code.
Thats good information. Here’s the latest version which I also tested and it works. I will be trying trasmission next.
Since you already define RECV_PIN = A1 and use it in the constructor call why not also use the same in the pinMode() call?
True. Changed that as well. Not sure if I should start a new topic but i have another question. I have been tinkering with my ledstrip remote and tv remote successfully so that i pass a string (on, off, vol+, vol- etc) to a cloudfunction via particle app on my phone. The function uses an if else statement to check the string and act accordingly (transmit ir signal to my device). Works beautifully.
Would it be better/simpler to use a switch-case statement instead? Is it possible and what would that look like?
Right now I have:
pinMode(SEND_PIN, OUTPUT);
Particle.function("remote",button);
}
void loop() {
}
int button(String command) {
if (command=="off") {
irsend.sendNEC(0x20DF10EF, 32); // off
return 1;
}
else if (command=="1") {
irsend.sendNEC(0x20DF8877, 32); // 1
return 1;
}
else if (command=="2") {
irsend.sendNEC(0x20DF48B7, 32); // 2
return 1;
}
else if (command=="-") {
irsend.sendNEC(0x20DFC03F, 32); // Vol -
return 1;
}
else if (command=="+") {
irsend.sendNEC(0x20DF40BF, 32); // Vol -
return 1;
}
else {
return 0;
}
}
But I was thinking more like:
int button(String command) {
switch (command) {
// default:
case "off": irsend.sendNEC(0x20DF10EF, 32); return 1; break ; // off
case "1": irsend.sendNEC(0x20DF8877, 32); return 1; break ; // 1
}
…but it doesn’t work because “off” is not an integer. However I found this piece of code which gives me hope that it might work:
void encoding (decode_results *results)
{
switch (results->decode_type) {
default:
case UNKNOWN: Serial.print("UNKNOWN"); break ;
case NEC: Serial.print("NEC"); break ;
case SONY: Serial.print("SONY"); break ;
I just can’t get my head around it.
With a switch() statement you cannot cover strings but only ordinal types (i.e. numeric types).
However, I have often proposed an entirely different approach with the focus of maintainability and extensibility
struct IrCmd_t {
char command[8];
uint32_t code;
};
const IrCmd_t commands[] =
{ { "off" , 0x20DF10EF }
, { "1" , 0x20DF8877 }
, { "2" , 0x20DF48B7 }
, { "-" , 0x20DFC03F }
, { "+" , 0x20DF40BF }
};
const int cmdCount = sizeof(commands) / sizeof(commands[0]); // derive command count from "dynamic" array
int button(const char* cmd) {
for(int i = 0; i < cmdCount; i++) { // traverse commands list
if (!strcmp(commands[i].command, cmd)) { // do we have a match?
irsend.sendNEC(commands[i].code, 32); // emit the respective command code
return i; // return the index of the found command
}
}
return -1; // no match found
}
To add a new command just add another line to the array declaration and the rest is taken care of already.
Even when you stick with your if() ... else if() ... else scheme a useful habit to adopt is that you should not return just any arbitrary value but rather think of some useful value to return to get some feedback about the inner state of the called function.
That is great. Looks neat and the extensibility is a big plus. However I get many error messages. Even if I understand the basics of both the code and the error messages, it is still above my knowledge.
Yup that’s it. The only error left after verifying had to do with cmdCount which was resolved with adding int here:
const int cmdCount = sizeof(commands) / sizeof(commands[0]);
Flashed and voila! Hugely appreciated the help. The code is actually really applicable in other projects as well.
Thanks @peekay123, now I have made that mistake I previously pointed out to others 
(corrected above).