Best posts made by rickmontana83

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.