I'm looking for a controller that hits as many of these points as possible. I know this is likely covered ad nauseam in this forum, but looking to see if anyone who has already gone before has any sage pointers.

My key requirements are:

• Free (as in beer) open source solution
• Works with MySensors gateway "out of the box" (i.e. minimal fiddling or coding to wire the MySensors network to the controller)
• Dynamic (picks up new nodes automatically)
• Ideally written in Python.
• Stable (I want to run more or less indefinitely without having to reboot all the time)
• Runs on Raspberry Pi B+

I don't have any other HA devices that I need to interface with yet, but I will likely be extending the the future, so connection with other popular HA devices is a plus.

Thanks!

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...

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.

This is awesome!

Any plans to provide source or a back-end API that could be used to connect this up to an HA controller? That way you could control everything downstream in the MySensors cloud from this app, and everything upstream (the HA controller and the cloud) could interface with a much richer (and presumably more robust) infrastructure rather than yet again figuring out how to parse the bits coming off of the serial port...

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.

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.

@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...