Flame Sensor Not Triggering Setup
-
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.
-
I have found that when I do a send that a wait (not delay) must precede the next send.
-
I have found that when I do a send that a wait (not delay) must precede the next send.
@OldSurferDude Sounds like a power issue to me. What radio are you using. NRF or RFM?
Check your capacitor, maybe it's old?
-
@OldSurferDude Sounds like a power issue to me. What radio are you using. NRF or RFM?
Check your capacitor, maybe it's old?
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.)
-
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.
-
I have a 10µF capacitor soldered onto the board of the nRF24.
-
I have a 10µF capacitor soldered onto the board of the nRF24.
@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.
-
I will consider it for future designs. For now, "if it ain't broke, don't fix it."
(I, too, hate delays)
-
I will consider it for future designs. For now, "if it ain't broke, don't fix it."
(I, too, hate delays)
@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
-
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!
-
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 -
ok grazie
-
@skywatch If I may, how do you introduce a delay between one broadcast and another?
@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.
-
@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.
-
@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
@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. :)
-
@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.
@skywatch @sindrome73 This is what I do, too.
Note that it is wait(), which is a MySensors function and not delay(), an Arduino function. wait() checks for MySensors messages, delay() halts all process, thus a message might be missed.
