Hardware Contributor

@vecnar Nice job! I think that I too will mostly stick with my current smoke alarm setup until either prices on the Nest drop to parity levels or something better comes along. Kinda the "if it isn't broken, don't fix it" philosophy. If it turns out that de-dusting my smoke alarms on a regular basis provides 100% anti-false alarm protection, then I may never feel the need to upgrade at all. Meanwhile, I think I will replace my ionizing smoke alarms with photoelectric ones, since photoelectric smokes alarms are thought to have many fewer false alarms.

@vecnar If I'm understanding right, your device listens for a loud sound and then triggers on that and only that. So, then the tradeoffs are you want to set the threshold low enough that it triggers whenever the alarm siren sounds, but high enough that it doesn't trigger on false events, like a car honking in the distance or possibly someone dropping something on the floor or a baby crying. Well, I imagine that would work, though you might get occasional false positives. If your device could be dialed in to only trigger on sustained loud noise, rather than bursty noise, it might cut-out the false positive of someone dropping a vase on the floor, or the like. One thing to possibly be wary of is whether there's drift in the sound threshold over time or temperature of the components in your detection device.

Depending on how your alarm sounds, you could maybe improve on that. For instance, if it has some kind of repeating on-off-on-off pattern to the siren, then you could program an arduino to listen for that pattern specifically, instead of just purely level of loudness. I'd wager that would be quite accurate at triggering if and only if your smoke alarm sounds. Otherwise, there are projects out there where you can allegedly "teach" a sensor to identify your particular alarm's sounds.using classifiers. I happened to notice such a project was published just a few days ago: https://www.hackster.io/news/sandeep-mistry-walks-through-tinyml-audio-classification-using-tensorflow-lite-raspberry-pi-rp2040-f4065b654565

Worthy of note is that bCNC now supports camera alignment for two sided PCB boards. You just need a spindle mounted camera, and then you simply show bCNC a couple of points (by centering the camera cross-hairs on them) around which to do the alignment for the opposite side. This replaces the need to use physical alignment pins to align the two sides, as flatcam does. I haven't yet tried it, but it sounds like a very nice convenience. The "Ant PCB Maker" project has been leveraging this feature of bCNC for one or two years now. I don't believe the existence of bCNC's camera alignment capability is widely known, though, as I only just recently heard about it, and even then only by chance.

Thinking about it now, two known points are required when nothing is pinned because that's how many points are needed to re-establish the origin as well as correct for any rotation that may have occurred after the board is flipped over. So, presumably, first a new origin needs to be established, and then all of the g-code for the second side needs to be amended after-the-fact to account for any rotation that may have happened when the board was flipped.

@forexsieno Is the device accessible by the user that Openhab is running with?

@Diego-Serrano said in Pir AS 312 with 2 rechargeable AAA battery. Boost needed?:

@franz-unix Hi, this post is very old I hope I can get an answer
I have ME2188 here but the behaviour of CE pin in extrange.
If I apply high to CE pin I get my correct 5v but if I change CE pin to low I get 4v on the output and I hope to get 0v.

Hello, this is the normal behavior for this chip. CE will enable the step up, but with CE low it acts as a bridge so you get input voltage at output.
Pretty annoying

Anyone can share your experience?

My experience was to add an MT9700 power switch before the voltage input of the ME2188. The EN pin of the power switch is connected to the same signal than the CE pin of the MT2188, driven by the microcontroller.
It works fine like this driving a Plantower PM sensor not a PIR (don't pay too much attention at the caps at output I just wanted to have different footprints available).

I actually created a message queue for this. It will go on retry when it gets a didn't reach parent. So I know when the communication is gone. I'll add a communication up event to it. And I should be done. I won't know it it reaches the gateway. But I can add a visual indicator for when the repeater is out. That's sufficient for me.

While we're at this topic. Does any one know what the NRF24L01+ does with it's interrupt pin? I'd like to hook it up to the other pin - d4 in this case. Does it pull high when there's a new message or is it pulled up by default? Which I hope

It's something I'm looking for as well

Hi all,

Recently I started to experiment with the Wemos D1 mini as a MySensors node, with a NRF24L01+ radio. As most wouldn't go this route, since it has built in WiFi. I did, because for one WiFi was not available for the particular node I'm developing. And second I don't really like my HA to run on WiFi. There are many reasons I have for this. But my main concern is the amount of time it takes to reconfigure all your nodes when the ssid and or password on your router have changed. But let's not start a topic on this. In this topic I just wanted to share some tips and tricks I discovered which some were hard to find on the internet and others I came up with my own solution. I'll keep adding tips and tricks to this topic if I discover new ones.

The Mini D1 doesn't like it when you declare an interrupt handler like you'd normally do.

volatile bool interruptReceived= false;

void handleInterrupt() {
  interruptReceived = true;
}

If you're lucky it compiles. But it will not work. You'll receive a strange bootloader error and the Mini will not boot. The reason for this is that the Mini expects handlers to be stored in the IRAM space. Just add a compiler directive and your interrupt handler will work just fine.

volatile bool interruptReceived= false;

ICACHE_RAM_ATTR void handleInterrupt() {
  interruptReceived = true;
}

void setup() {
    pinMode( interruptPin, INPUT_PULLUP );
    attachInterrupt(digitalPinToInterrupt( interruptPin ), handleInterrupt, FALLING ); 

Be carefull with using interrupts on D3 and D4

So the ESP2866 does a lot of funky things during bootup. It will pull some pins HIGH and LOW to check if it should go into program mode or not. It probably uses it for more reasons, but I'm by no means an ESP expert. The D3 and D4 pins are pulled up high by the Esp, with a - I believe - 10K resistor. Whenever you connect anything to it, that will cause these pins to be high during booting, the Wemos will not finish the boot mode and your sketch is never loaded.

I wanted to attach an MCP23017 port extender to my Wemos and use the interrupt to refresh the values. So I didn't need to poll the MCP23017 all of the time and kept CPU time available for other tasks. The problem with this, is that the MCP23017 pulls it's interrupt pin HIGH when there's no interrupt - which is always the case when the chip power's up. So connecting the interrupt pin to D3 or D4 caused my Mini D1 to not exit boot mode.

I could have simply used D3 and D4 as SDA and SCL pins for the I2c communications and use D1 and D2 as interrupt pins. But not all libraries like that. So the easiest way to get around it was a simple and cheap hardware solution. I connected a diode (doesn't matter which one you take. Just take a low 1N400x one) and that did the following:
The HIGH value of the MCP's interrupt pin is blocked by the diode. When the MCP pulls the interrupt pin low current can flow between the interrupt pin (INPUT_PULLUP) on the Wemos Mini and the MCP's interrupt pin. This made sure the MCP is never able to pull the pin on the Mini high. And the problem was actually solved - easy peasy. I can use D3 and D4 as interrupt pins.

Here's the schematic. In my case I use the mirror mode on the MCP's interrupts. So I only need to connect one of the MCP23017's interrupt pins to the Wemos.

I also run the MCP23017 on 3.3V so it's the same as the Wemos mini.