Flame Sensor Not Triggering Setup

[Jordan22xx]

Hey everyone,

I’m trying to integrate this [Flame Sensor] into my MySensors network, but it’s just not behaving as expected:

Setup Details:
I'm using an Arduino Pro Mini (3.3V) as the gateway node. Sensor powered from 5V. Relay output connected to digital input pin with INPUT_PULLUP, expecting LOW when flame is detected

MySensors sketch includes S_DOOR type for simplicity, just to read ON/OFF state

When the sensor detects flame, the onboard LED lights up and clicking is heard, so the relay is clearly switching. But in my node logs, I only see the relay output toggling occasionally,mostly it stays HIGH (OFF), even when flame is present continuously.

Swapping GPIO pins, wires, and sensors doesn't change the symptom. No change with or without external pull-down.

I've tried testing the relay output manually via Serial Monitor, works fine, reading LOW when flame is near. Using a hardware pull-down resistor on the signal line, still inconsistent. Enabling debug mode in MySensors, doesn’t show any obvious issues with message transmission or state change. Confirmed the node resets after state change (so it isn’t a freeze).

My Questions:
Could the MySensors library be filtering out rapid changes from the sensor relay? Should I use S_BINARY or a custom sensor type instead of S_DOOR? Is there a timing or debounce issue I’m missing with relay switching vs. reading pin state?

Has anyone used a relay-type flame sensor successfully in MySensors? If so, what input handling (pull-up/down, sensor type) have you used?

Would appreciate any pointers or examples to help me get reliable flame detection working!

Thanks in advance,
Jordan

[fsgraz]

@Jordan22xx do you mean via Serial Monitor from the pro mini ? if it works that would exclude hardware issues. do you poll the pin in the loop ? do you use an interrupt pin ?
I would exclude problems with the mysensors library. is the gateway recognized by the controller ? Check if the node is registered and the sensor presentation works.

[OldSurferDude]

You write "...clicking is heard..." Is that a single click or a click click click ...?

After getting the LOW signal, wait a period of time and if it's still low, send the message that there is a flame. Likewise for a HIGH signal.

Perhaps instead of a relay, an opto-isolator?

[skywatch]

Post your code and a photo or diagram of your wiring.

[TheoL]

Like skywatach says. It's hard to tell what's going on without those. Also put the node in debug mode so we can see the communication log.

From reading your post, I think it can be two things: a power problem or a communication problem. But we need more info to be able to help out.

[OldSurferDude]

I have found that when I do a send that a wait (not delay) must precede the next send.

[TheoL]

@OldSurferDude Sounds like a power issue to me. What radio are you using. NRF or RFM?

Check your capacitor, maybe it's old?

[OldSurferDude]

@TheoL

I'm using the nRF24L01. It's sounds like you're implying that the radio is doing a lot of retries. I don't think that's the case.

The sensor sends to the gateway. The gateway sends to the MQTT broker. Home Assistant (HA) has subscribed to the broker, but HA takes a while (I've seen as much as 3 seconds) before it acts on the data. If I'm not mistaken, an ACK follows the route back. Presentation data takes a lot longer than regular data.

When I have a serial gateway, I set the time to wait to a half second and 1 second for presentation.

To confound even more, I have HA running in a virtual box.

Different controllers may react faster (or slower?)

Yes, the delay is annoy, but I find it reliable.

That said, I will give serious consideration to providing the radio with good quality power. My RPi zero 2w gateway uses a rock solid 12V 20A power supply followed by a 5A buck converter. My sensors, though, use a really cheap 700mA wall wart or a really cheap 80-277VAC to 5VDC 700mA buck converter.

Perhaps I should add a bypass capacitor to the existing electrolytic capacitor that is already on the radio.

My understanding is that if the rating of an electrolytic capacitor is double or more the expected voltage, it will last a very long time. (eg. my computer is at least 15 years old and is still running well...if Microsoft would stop giving it updates it would be working great.)

[TheoL]

You mean you have no 100uf capacitor between the ground and vcc of the nrf radio? Because you really need it.

I still wanna experiment with replacing the 100uf with 0.1 uf 1 uf and 10 uf in parallel. They use that in analog synth PSU's to guarentee a smooth power.

[OldSurferDude]

I have a 10µF capacitor soldered onto the board of the nRF24.

[TheoL]

@OldSurferDude Swap them with 100uf. That improves communication a lot. You might even be able to get rid of the delays

I just hate delays in code.

[OldSurferDude]

I will consider it for future designs. For now, "if it ain't broke, don't fix it."

(I, too, hate delays)

[TheoL]

@OldSurferDude I believe we started with 4.7 Uf, then it was 10Uf and eventually it become 100uf.

Although I still wanna try if0.1 1 and 10 uf in parallel will work better. I believe EEVLOG gave an explanation why that is the best. But I forgot

[skywatch]

FWIW I am using 47uF * ceramic smd caps but always use delay to allow the data and power line to stablilse between sends.

*I like being different!

[sindrome73]

@skywatch If I may, how do you introduce a delay between one broadcast and another?

[TheoL]

I use a message queue, I implemented a long time ago. But all of this shouldn't be needed, as there's a retry built into the MySensors Core.
I do it to give other Nodes the time to send as well. Because sometimes the traffic is really bursty

[sindrome73]

ok grazie

[skywatch]

@sindrome73 From a recent upgraded node I do it like this....

if (dustAverage > 20.0 && dustAverage < 500.0) {
send(msgDust.set(dustAverage, 2));
wait(200);
}
send(msgQuality.set(dustStrings[x]));
wait(200);
send(msgTemp.set(temperature, 2));
lasttemperature = temperature;
wait(200);
send(msgHum.set(humidity, 2));
wait(200);
send(msgVOC.set(VOC, 2));
wait(200);
send(msgNOX.set(NOX, 2));
}

Hope this is clear!

Ciao.

[TheoL]

@skywatch When I have time I will give you a library. I like code the best when there's no wait or delay in it.

Giving a library means I have to take it out of my code and make it decent xd

[skywatch]

@TheoL That is kind of you, but no rush. I have not been building for a while now due to circumstances outside my control.

Maybe you could think of putting it on this site to help others too? Just a thought.

I will be interested to see what you have done and how it is working. :)