@gohan I seem to remember trying that, and gave up when 470uF wasn't enough. :-) That being said, it's an easy enough thing to try.

@burningstone I'd search around the MySensors library code for the implementation of the sleep() routines. They'll need to call the radio shutdown somehow. Doing a quick drill-down, I see:

MySensorsCore.cpp defines the internal _sleep() routine, which ends up calling transportPowerDown() (to do the power-down of the radio in a hardware-independent way). This ends up calling into transportPowerDown() in MyTransportNRF24.cpp (for your radio type), which calls the RF24_powerDown() routine.

I would think that's probably the one you want to call.

I had what I suspect to be the same issue a while back, and it took me ages to debug.

I haven't looked at your code or reviewed the circuit diagrams in detail, but the symptoms sound spot-on, so I'm reasonably confident that this is what is going on.

For backround, the HC-SR501 is a very sensitive trigger that sets up a delicate balance between the two sides of the IR receiver, and then waits for that to get out of balance (i.e. from one side getting more or less light). Once things are out of balance, the sensor trips and you get an interrupt. Woohoo!

Now, the problem here is that even though we like to think of power and ground as "constant", in actuality any load that is not constant is going to raise or lower the power rail voltage a bit. And if you have a relatively "heavy" load (like an active radio and Arduino processor) that suddenly goes "off", the power rail is going to spike high for a brief time, since the batteries and regulators are all whirring along trying to supply that higher load. That voltage spike then rips through the HC-SR501 (which, as you recall is already spring-loaded looking for minute imbalances), and tips the scales, causing a trigger and what ends up looking like a motion event. The interrupt pin on the Arduino goes high (or low) and wakey-wakey!

(Keep in mind that I don't have access to an o-scope, so a lot of this is from thought experiment, conjecture and fiddling with various elements, but I'm reasonably certain that's at least close to what's happening.)

I also suspect that this is exacerbated by using a lower voltage (3.3V vs 5V), tying directly to the 3.3V pin on the HC-SR501 (bypassing extra voltage regulation), and using batteries as a power source (they've got their own inefficiencies as a voltage source).

So anyway, all that being said, the way I worked around this on my devices was to "stagger" the sleep. First I would power down the radio, then wait "a bit" (100ms or so?) for power to stabilize, then do the actual sleep() call to put the Arduino to sleep.

This was with MySensors 1.4, which I think made it a little easier to get at the internal radio to do a powerDown() call. But I think it's still possible to get at the raw radio. I just don't recall off the top of my head how to do with with MyS 2.x.

Anyway... hopefully that saves you a lot of head scratching. Digital components are awesome as building blocks, but darn it if analog issues creep in sometimes...

@Moshe-Livne Touché. I still think it'd be more trouble than it was worth, but your constraints make it a much more reasonable possibility.

For what it's worth, I have a couple of the power supply boards from the OP that I'm using with a bridge rectifier to convert from a 24VAC sprinkler system to DC voltages appropriate for Arduino. Much cheaper to get the rectifier and DC-DC board separately than a dedicated AC-DC board that is effectively the same thing. If memory serves, I think my doorbell is also on a 24VAC transformer, so that would be appropriate here, too.

@Moshe-Livne
Teaching a computer to see is one of he hardest problems computer science has yet tried to solve. I'd suggest giving this a miss if you value your sanity. ;-)

Not to be too snarky, but a Mechanical Turk might be the most elegant solution here. There are some things for which computers aren't really that well suited. (I know, I know... I'll turn in my nerd card and see myself out...)

I would think RFID pads on each shelf surface is your best bet; but that's likely to be cost prohibitive (you'll either need expensive high-range scanners or lots of not-so-cheap low range scanners).

Honestly I don't really see the point of going to all that bother. Is there any way to modify the design to something a little less automated? Perhaps one scanner per shelf that you have to wave each item by on checkout / checkin? My local library does something like that for self checkout.

@tbowmo
The Arduino ide hides some things (like main()), and some features of the language are disabled throughout to keep code size down, but it's all fed through the C++ compiler in the end. So all the normal C++ OO concepts work both in libraries and in sketches.

I think a lot of times sketches don't use classes because it's overkill and it's really easy to accidentally blow through all your memory if you don't really understand what the compiler generates, but it's definitely possible.

Oof... Looked at the code. It's probably possible, but not with a trivial mod. The logic is handled across several functions. Best bet would prob be to factor digitalWrite() calls in ledTimersInterrupt to a replaceable function pointer. You'll have more global data lying around, but that's already being done in the library, so it doesn't really compromise design integrity much.

Haven't looked at the code for the gateway, but in c++ if the functionality is implemented in a public or protected class member that is declared virtual then subclasses can redefine the behavior by overriding that method. Might be a workable avenue...

The "trick" here is that I wanted to keep things as tidy as possible on a breadboard, and didn't want "dangling" components or use up extra pins (I'm trying to mount everything on a mini breadboard, and have no space to waste). So the problem becomes finding a set of three side by side pins on the mini that won't hurt anything when I plug in the adapter.

It would all work out fine if RAW-GND-VCC sat next to one another, but they don't. So I used two analog pins that won't be hurt by Vin or GND from the adapter, and Vout from the adapter falls on the VCC pin. Jumper from A3 to GND to connect that up and voila: adapter sits right alongside the arduino, and I can monitor the raw battery voltage on A2. Only A3 gets wasted, and I typically don't use that many analog pins anyway.

Next round I think I'll optimize breadboard space by only soldering a subset of the male pin headers on the arduino, and providing upward facing female headers. Hat gives me move free space on the breadboard, while still allowing access to the arduino pins.

Of course, all of this is a little crazy, since I should just prototype on a big breadboard and then finalize on a proper circuit for the battery pack, but it's really fun to have reconfigurable battery pack units...

Agree about smaller. Everything looks classier with less wasted space.

Probably too late now, but if the board had mounting holes that lined up with the enclosure that would be sweet. I'm always at a loss for how to keep my boards stable inside their plastic homes. Would love to hear peoples' solutions for mounting when the holes don't line up.

Erm... scratch what I said about making sure A2 and A3 are inputs; I'm pretty sure that analog pins on Arduino pro-minis can ONLY be inputs. There's no DAC hardware on the chip. (analogWrite() uses PWM on digital pins.)

I have the 3.3v version of that step-up, and it works pretty well with a pro-mini 8MHz / 3.3v board. That's probably what you want if you are looking to run off of batteries, though 5v shouldn't be that much more of a mA hog if you're only looking to run for a couple of months at a time. For years you definitely will need the lower voltage (plus mods... search other threads for details).

Some anecdotal observations from the step-ups I have:

1. I think that these will run your batteries into the ground if you aren't careful. As far as I can tell there is no cutoff circuitry. So not sure if that will kill expensive rechargeable batteries....

2. On the pro-mini form factor, as long as you make sure A2 and A3 are INPUT (the default) you can plug this adapter in directly to (A2, A3, VCC) <-> (Vin, GND, Vout), then jumper from A3<->GND. This means less wiring on a breadboard / soldering on the board, and as an added bonus you can monitor the battery level with a simple analogRead(2). (Just be aware that NiMH batteries have a non-linear voltage curve, so as soon as they drop below 1.2V per cell you're nearly out of gas...)

I'll second (third? fourth? whatever...) the suggestion to design this to fit a cheap and readily available enclosure. Something like:

http://www.aliexpress.com/item/Free-Shipping-Plastic-Waterproof-Clear-Cover-Electronic-Project-Box-Enclosure-Case-85-58-33MM/2025247551.html

(Not saying that's ideal; just an example.)

Just my $0.02...

Be careful with any while loops that could go on forever under "perfect storm" conditions. It's usually a safe bet that eventually your device will get into a state where comms will fail forever. If you're stuck in a while loop waiting for a successful send then you have no chance to detect or correct the error, and given how tricky it is to debug Arduinos you'll probably never figure out what went wrong. The device will just go silent, and a little while later the batteries will run out (because it's sitting there trying to send over and over). Do yourself a favor and put a fail-safe && retries++ < MAX_RETRIES clause on your while loop.

This doesn't speak directly to your case, but in a broad sense my assumption going in to any wireless design is that packets will be dropped, so I always design with that constraint in mind, rather than trying to design a system where no drops occur. For example, you might consider adding a "resync" timer that sends the current state regardless of changes every so often. So even if something is dropped you have a bounded amount of time where things are in the wrong state. I do this with my presentations: Every 5 minutes my sensors retransmit all presentation messages just in case the controller missed the first set, or the controller reset, or whatever...

Handling lossy comms is not usually too hard if you aren't trying to back-engineer that into a system that was designed with the assumption that messages would always succeed.

Incidentally, this is more or less the same as "UDP" vs "TCP" networking, if you've ever worked in that realm. So strategies would overlap pretty nicely.

Wow... you weren't kidding about the turnaround time. Fix will be going into next beta release. +1 for Domoticz...

did you try to open a bug tracker ticket?

And miss an opportunity to whine about it on an unrelated forum? Never!

Okay, point taken. I should probably tell them about it. :-)

After playing with it for a week or so, I can add my recomendationg for domoticz. It plays very well with mysensors. (On the RPi I run the latest binary beta on a stock-ish raspbian image. Seems pretty stable so far.) I suspect that the fact that the mysensors backend in domoticz is written in C++ makes it far easier to create a "deep" integration. Plus reading the mysensors plugin code is super simple if you are already delving into any of the mysensors innards, since they're just mirror images of one another.

Which by the way reminds me: there's currently a bug in the domoticz plugin code whereby presentations from S_DIMMER sensors are ignored. So to get domoticz to see/add the sensor you have to send a value. Not a huge deal, but I had to dig into the code to find this, so thought I'd pass along the info. For anyone intereste, note that there is no S_DIMMER around http://sourceforge.net/p/domoticz/code/HEAD/tree/trunk/hardware/MySensorsBase.cpp#l1230

I'm also a bit bummed no Wink support with domoticz. I'd love to be able to use some of the stuff that ecosystem opens up.

At the risk of stating the obvious, you either have a hardware issue or a software issue. Given that things work with the other software faulty wiring seems unlikely. That leaves software.

If the same sketch works with an UNO node you can probably rule out resource constraints -- both boards have the same processor and memory. I'd still keep an eye toward any dynamically allocated resources. Dynamic memory management on a system this constrained (and hard to debug) is always hit or miss. I try to avoid it if at all possible.

That leaves the probable cause as something that you're misusing that for some reason happens to work on the uno because the hardware is more forgiving, or randomly works for some reason beyond your control (compiler, linker, avrdude baud, etc.). I'd go back and double check each API call to make sure you are certain that you're passing the correct values.

You might want to post your sketch code so others can browse, too. We might see something you've overlooked.

Thanks for the replies! I think Domoticz might be my next stop. I'll also check out monit, sounds great.

I tried OpenHab, but found it too ponderous to set up (and I detest Java). Seems like a general solution to map MySensors serial comms to/from OpenHab APIs is necessary. Right now it seems like you have to manually set up everything yourself, which is a major bummer if you just want to hack together a new sensor, turn it on and start collecting data. I see that as the main draw of the MySensors platform -- I can put together a sensor node from parts lying around on my desk, turn it on, and boom... new node!

I had very high hopes for Home Assistant (I agree it looks awesome, and Python is great). But it didn't fit the bill. Here's my mini-review:

Pros:

• Dirt simple setup (worked first time on my Ubuntu 14.04 machine)
• Easy to understand configuration
• MySensors plugin does auto-detect and add sensors as they come online
• End-to-end stack seems well architected without becoming overly ponderous and obfuscated. Perfect for learning and hacking.

Cons:

• Not stable yet (although take that with a grain of salt; the MySensors plugin was only added to GitHub a few days ago)
  • I saw lots of Python exceptions, losing connection, etc.
  • For some reason that I cannot fathom, the controller wouldn't see any messages from my sensor nodes unless the sensor had a serial terminal attached (even though the messages were sent to the gateway over the rf24 radio link!) I'm seriously at a loss for what was going on there...
• No way to rename sensors after they are added
• If a sensor hasn't reported data since it logged in, then it won't show up in the GUI (no looking at history when nodes are down)
• Router discovery services are neat, but require you to add your admin password in plain-text (so much for security...)
• I couldn't figure out how to get a light switch actuator working (sensor doesn't show up in the GUI)

So for now at least it looks like that is a non-starter for me. I see lots of potential for growth here, and I'll be looking into it again in a few months to see where things have gone, but for now it looks like more of an interesting toy than a production-ready solution.