Posts made by TD22057

Look here under Valve: https://github.com/TD22057/TD-Arduino-Core

You don't really have to buy anything - lots of things will work to keep the temperature down. A wet paper towel wrapped around the fuse or submerge it in a small cup of water (easy for through hole components when the board is upside down) or wrap with 2 wet sponges and some rubber bands, etc etc.

@mars000 said in Water Leak Detection:

@TD22057
I can't seem to work out how the water sensor functions - i notice you wired it to 5V on red and black to D4, but is there a trick in terms of how it works ?
I assume you are reading the D4 pin in your code ? Could you pls help out/share your code ?
How you finding the reliability of the sensor and value ?

Honestly - I don't remember. Re-reading the thread, I believe they worked fine but that 5V was required. Try hooking them up to an analog pin and reading the value there. They might be not be passing enough voltage to trigger a digital reading. I actually never deployed the design above - I switched to a more modular design and used the rope sensors shown above. I haven't had any problems with the valves - of course they don't cycle at all since I don't have any leaks, but they work when I test them.

Very interesting designs @enterprised and @dbemowsk. I've also been working on my own version of decora switch and relay system. It's designed to use empty keystone switch plates with 1, 2, or 3 switches and uses keystone jack fillers as the switch covers so they look almost commercial. It's a 3 PCB system. The front PCB has the switches, LED's, reset button, CPU, and an RFM69 or NRF radio. The middle PCB has a MeanWell IRM-02 or HLK AC->DC converter (with fuse, thermal fuse, and varistor), a replaceable fused 10A AC relay with opto-coupler isolation, 5V and 3.3V rails and a 2 wire temperature probe to measure the temp of the PSU module. The back PCB is just a cover to insure no sharp solder points are in an electrical box. I decided that since this will be in my walls, I would only use name brand parts (from digikey and mouser) on the high voltage side which increases costs but should reduce the risk of fire (or at least make me feel better).

I've designed the PCB and checked them over but we're in the middle of buying a house and moving so I haven't ordered any yet. Here's the 3D rendering of the PSU and CPU boards together and a one of the PSU board.

I have short and long press status reports on my switch class here. There are example sketches one directory up in the tests area. Double click gets more complicated because you have to decide are you going to delay reporting the press/release from the first click until enough time has passed for it not to be a double click? Or do you report the press/release from the first click, and then report a double click? I'd be surprised if there aren't a lot of arduino double-click switch examples around...

@nagelc said:

I have tried this antenna with the RFM69:

YAGEO ANT1204F005R0915A
http://www.newark.com/yageo/ant1204f005r0915a/antenna-chip-915mhz-50-ohm-1204/dp/38X6113?ost=ANT1204F005R0915A&selectedCategoryId=&categoryNameResp=All%2BCategories&searchView=table&iscrfnonsku=false

That looks very promising. But I have no idea how to design or tune the matching circuit called for in the data sheet. Any thoughts?

I've used these type of small helical antennas with good results.

Very cool. What kind of connector are you using to connect to the programming pads?

Very cool. Would you mind adding a pdf of the schematic?

@TD22057 said:

I have a question... referring to the first post, why is the varistor after of the fuses? I thought it was there to protect against surges in the AC lines which would makes me think that the varistor should be before the fuses. Thoughts?

I answered (some what) my own question via Google. Here's a quote from an electronics site:

Fuse upstream of the MOV, but don't expect it to save the MOV. It will prevent your house from burning down after the MOV partly shorts and sits there glowing red hot.

So it seems like the original post is correct on the order.

I have a question... referring to the first post, why is the varistor after of the fuses? I thought it was there to protect against surges in the AC lines which would makes me think that the varistor should be before the fuses. Thoughts?

If getting the laser cut blank doesn't work out, another option you could consider is using pre-cut keystone plates. It's probably possible to modify a blank keystone jack by cutting the mounting tabs off and have it sit flush or a little proud of the plate and use that to press a switch on the pcb behind it.

That looks fantastic! I looked at the capacitive solutions and while they're neat, I don't like them from a user interface perspective. I want tactile feedback in a switch - a rocker would be even better but this is a close second. It would be nice if you could take those of us who use RFM69's into account if that isn't too difficult.

You might want to look at the SwitchMote for packaging and board ideas. Another thought: Just my opinion but I think it would look nicer if it was symmetrical. Could the LED's be moved into the center between the switches?

Check http://pcbshopper.com/ for prices and reviews. I got very good results from Electrow for my last order.

There are standards for PCB hole sizes. You can find Eagle parts for M2, M2.5, M3 drill holes with tight and loose clearance in my Eagle parts library. I created the parts from this blog page.

Here's the data sheet I have for those: G3MB solid state relay.pdf

@Dwalt said:

How are you converting the Acurite sensors to MQTT?

The Acurite Bridge is a 433MHz receiver that reads any Acurite sensors and posts them to the Acurite web site using a simple HTTP call. I have it connected through a USB ethernet dongle to a Raspberry Pi with the dongle bridged to the main network. I have a script which runs tcpflow to intercept that traffic and send it to some simple Python scripts I wrote which convert the data to MQTT. There are instructions here - they're out of date but give you the basic idea. So it's basically a man-in-the-middle attach against the bridge traffic. Let me know if you want more information - I have the code in git but haven't pushed it up to github lately.

The biggest thing MQTT adds for me is abstraction. The RF messages MS uses get converted to MQTT which the controller (and other things) understands. This means the controller only needs to understand MQTT, not MS. And I can merge lots of different sensor sources into a single system by converting them all to MQTT.

As a trivial example, I have three sources for temperature data in my house. 1) MySensors nodes, 2) two WIFI thermostats, 3) several Acurite wireless weather sensors. All of those get converted to a single, standard format MQTT temperature messages. So it doesn't matter what the hardware is, if I want to graph/see/store temperature data, I just need to know the MQTT message format.

@scalz said:

@m26872 oki! same bad luck things happens to me sometimes
Finally I have looked at my cheap wallplugs and it seems smaller than yours...so more difficult to fit something in mine.
I have few of these box that I bought for this purpose too (and still empty!) : http://www.tme.eu/fr/details/cp-z-27_j/boitiers-pour-alimentations/combiplast/
Bigger..and maybe less interesting/looking nice than buying a kit of 3 wallplug. but maybe easier to make something "standard" as it can be bought from tme.

Those look very nice. I wish I could find a US version of that box somewhere.

Another write up on resistors dividers and opto-couplers: http://electronics.stackexchange.com/questions/43498/how-can-i-use-a-12-v-input-on-a-digital-arduino-pin

I've used optocouplers in the past without any problem. They can be purchased for practically nothing on aliexpress. In either case it's important to check the voltage on the signal line ahead of time to really see what the sensor is putting out.

@neech said:

TD22057, I love this idea. However, how are you going to power the ESP? I'd like to do the same thing but don't want to take the thing out to replace a battery. I also don't want to try and fit a 5v or 3.3v power supply in there...just curious if you thought of that yet.

Search for HLK-PM01 - there are a bunch of threads on how to power from 120/240V mains.

Another reason: number of inputs. The arduino has a lot more pins so for more complicated sensors, the ESP just doesn't cut it. Pairing them together isn't a bad idea though. Can the ESP do over the air boot loading? That's a nice feature in the radios.

I think both are good ideas. In my "future plans", I want to replace my Insteon remote switches and outlets with home made ones and I think using an ESP is perfect for that. They aren't battery powered, the ESP is much smaller than an arduino+radio, cheaper, and it only needs to control a single relay.

@msev said:

This sketch doesn't support MQTT right? Has anyone maybe a version of this sketch which outputs MQTT? Or could you guys maybe guide me on how I would do it?

MySensors uses radios to communicate with a gateway over RF. The gateway can be set up to convert those messages to/from MQTT (or use software to convert the serial messages to/from MQTT). So there aren't going to be any sensor sketches with MQTT in them. If you use an ESP, then you could send MQTT directly but then you're on WIFI and don't need MySensors.

Here's one I designed which you can get from OSHPark for $5 for 3. I've used it w/ 3.3V signals but it was based on this break out board which the designer reported worked fine using the resistor dividers for 5V signals. Works great for bread-board tests of the RFM69.

@sundberg84 I think that looks like an excellent idea. I was looking at the tear down of the HLK in the test that was run and it doesn't look like there was any reason for them to do this - at least as far as I could see, there was plenty of room to put those connectors at the corners like the DC side.

One more tip: If you want to order a full 10x10 cm board, you can panelize them yourself and use https://github.com/p12tic/eagle-brd-merge to get around the 10x8 limit in the free version of Eagle. Worked great for my mother/daughter board order.

The RFM69 library from lowpowerlab (which MS has cloned) has a setFrequency() method which is almost the same as the one @lafleur posted above. It should be available in MS via accessing the RFM69 object. My understanding was it was used for tuning the network to avoid interference or in freq hopping applications.

You can find Eagle parts for M2, M2.5, M3 drill holes with tight and loose clearance in my Eagle parts library. I created the parts from this blog page.

Looks very cool.

The immediate thing I noticed is that there should be bypass capacitors on all the IC's. So a 0.1uF cap on the crypto and flash memory chips. And if you have caps in the schematic, they should really be wired with the chip they go with. I noticed there are a few caps in the schematic that are by themselves (just vcc/cap/gnd) - if those are bypass caps, it helps a lot to have them shown in the schematic with the IC they go with. That makes it clear that they need to be on the board next to the IC and not at an arbitrary location.

Mounting holes for screws might also be a good idea.

@lafleur said:

It would be nice to have a .PDF of schematic, make it allot easier to view than to load a CAD program...

Done. Added to the repository and the openhardware page.

I've added all the files manually so things should be there now (though I'd recommend grabbing things from github to preserve directory structure and get all the files).

@Anticimex Well that's kind of annoying. I supposed I'll go back and fix that. Do you happen to know if the github extraction for https://www.openhardware.io/ is working? I tried to use it but seems to just create a blank project.

FYI: Boards, schematics, BOM's, and software are now available here: https://github.com/TD22057/MySensors-Mother

@hek - I tried using the github extraction system and I'm not sure it's working. I didn't fill any files/images/etc manually, I just gave it the repository. Is the system supposed to extract everything automatically or is there something else I need to do?

Surprisingly, all of my circuits are working perfectly. I found one relay label that was swapped (NO/NC) and one jumper pad that wasn't very useful but other than that, all of the functionality is working. I have to admit I'm quite surprised there wasn't some serious problem somewhere given that this is my first non-trivial board design.

When I started this design, I purchased a stereo microscope and it was fantastic. I'm no soldering expert by any measure but having the microscope (using the 5x lenses) made soldering all of the components very easy. After building 8 main boards and a bunch of daughter boards, I can now see why people invest in making a reflow oven for soldering.

I'll be uploading the design files and schematics as soon as I clean up the BOM. Next up is cleaning up the software to drive everything and start on the case construction.

Look at the filters - there is one for "case code-in" and one for "case code-mm". So if you pick 0603 in "case-code-in", you get a normal 0603 part (metric 1608). If you pick 0603 in "case-code-mm", you'll get the metric 0603 (imperial 0201).

FYI I have ordered a lot 0805 cap's and resistors from this seller on aliexpress ($2-3 per 100) and haven't had any problems with them yet.

In Eagle 0603 is going to be the imperial 0603 part.

@Anticimex
I used the signing sketch on the dev branch - I'm in the process of shifting my stuff over to the dev branch from 1.5 now.

@Anticimex - thanks for this. I finally got around to enabling signing on everything while I was testing out my new board design. I followed your schematic from your board design when I built mine and I just went through the instructions to configure the crypto chip and everything went smoothly. Thanks for the work and the good instructions!

I wanted to share some of the classes I've been using for my MySensor modules. I've been making some fairly complicated sensors (boards with a lot of things going on - see my mother/daugter board system) and I have found that these classes to be very useful. They're all fully commented and include test sketches. They're designed around two main principals:

• Asynchronous operations. There are no delay calls anywhere. Each class maintains it's own state and behaves accordingly. This allows me to combine many different items and use them all without worrying about how they interact with anything else.

• Hardware abstraction. Each class has a very similar API in which the hardware specific information is set in the init() function called in the the setup. After that, all the interaction is via state change ("turn on", "blink 5 times", "sensor triggered", etc). In my board system, I connection these things via direct Arduino pins (some digital, some analog, some analog only A6/A7) and shift registers. This abstraction allows be to use the same logic code regardless of how the hardware is actually connected.

The basic idea is that:

• setup(): initializes the hardware (pins, etc) and state
• loop(): poll each object with a callback function to look for changes
• callback(): handle the state change

I've found that I really like this type of API. All of the hardware configuration is in setup() and all of the state changes (what happens) is in the callback. I've found that this makes the code easier for me to debug and much easier for me to understand (when I come back and look at it 6 months later) since the role of each function is clearly defined. On the output side, the DigitalOutput class allows me to turn things on for different amounts of time (turn a relay on for 5 seconds) while various LED's are blinking at different rates with very simple code. It's not the most size efficient code - but I've never found that to be a problem for my builds and the ease of use and clarity of intent is more important to me.

• DigitalInput: On/Off inputs (switches) with either HIGH or LOW
  active, optional debouncing, and support for digital pins, analog only
  pins (A6/A7) and shift registers.
• DigitalOutput: On/Off ouputs (LED's, relays) including blinking.
• MedianFilter: N sample running median filter.
• Sonar: Ultrasonic snsor.
• Timer: Repeating (num or infinite) periodic triggers.
• Valve: 5 wire articulated valve control

The repository is here: https://github.com/TD22057/TD-Arduino-Core
A good, long'ish example using several different classes is: https://github.com/TD22057/TD-Arduino-Core/blob/master/Valve/tests/leak_sensor/leak_sensor.ino

Feel free to use these if you find them helpful and any comments or suggestions are welcome.

@mfalkvidd said:

Edit: I only have one available pin on the Arduino and i2c requires 2 pins so I2c isn't going to work in my project. Back to the drawing board

I assume you looked at using shift registers already? I've experimented with a few and some of them work well on the SPI bus (and are very fast). They do require extra pins for the various latches - I use 3 pins (+spi) to run an 8 pin input and 8 pin output register and more could be added. If you want more info, let me know...

I just got my first large (for me) PCB order in and so I've spent a lot of time using the Eagle PCB design software over the last few months. I realize that many/most people are using KiCad since it's open source but I found Eagle first and did a lot of work in it before I saw KiCad so that's what I've stuck with. I thought it might be a nice idea to capture what I've learned about using Eagle effectively and see if anyone else had any tips to share.

Project names

Put a version number in the project name. I usually start with v1...vN as I'm iterating designs. Any time you start reworking something (routing, layouts, etc), save it to a new iteration. When you submit an order, move all the extra versions to a backup folder and rename the version you submitted to v1.0 and never change it again. If you need to edit something, create a v1.1 and edit that.

Hot keys

To get the maximum efficiency, use hot keys for everything. It's much faster selecting tools and toggling layers if you have keys set up instead of using the mouse. The most important set to me are the display keys (see F9-F12). They allow me to quickly toggle top and bottom layers and toggle polygon filling. It's annoying to set them up because you have to do it in the schematic editor and the board editor but it's worth it.

The most useful ones are:

• F9 shows both layers
• alt-F9 shows just unrouted air wires
• F10 shows just the top layer
• F11 shows just the bottom layer
• F12 fills polygons (ground planes)
• alt-F12 unfills polygons

Here are my keys:

Key	Action
alt-b	move
alt-c	copy
alt-d	delete
alt-e	net
alt-f	move
alt-g	group
alt-i	info
alt-j	junction
alt-l	label
alt-m	move
alt-n	name
alt-q	ripup
alt-r	rotate
alt-s	smash
alt-t	text
alt-v	via (board), value (schematic)
alt-w	route (board), wire (schematic)
alt-z	ratsnest
F9	display 1 tname torigin tplace 16 bname borigin bplace pads via unrouted dimension tkeepout bkeepout trestrict brestrict drills holes milling; display 1 16 125
alt-F9	display none unrouted
F10	display top tname torigin tplace -bottom -bname -borigin -bplace -bkeepout
F11	display bottom bname borigin bplace -top -tname -torigin -tplace -tkeepout
F12	ratsnest
alt-F12	ripup @;

Libraries

Build your own part library with the parts you'll use. That way you can find things faster and you know whether they work or not. Copy parts from eagle, sparkfun, and other online sources. You can find the library I've created for MySensors components at https://github.com/TD22057/Eagle-MySensors

Grid

For the schematic view, stick with 0.1 inch spacing since most of the library parts use that for the schematic symbol layouts (and NEVER use the alternate spacing). This insures wires will snap to the correct location and the connections get made. For the board view, metric or Imperial works. Since most of the parts I use have pins on 0.01 inch spacing, I use a grid with the major size 0.025" and the alternate size 0.00625 which seems to work well.

Ground planes

Use 0.012 isolation, 0.010 line width. The smaller line width allows the ground plane to flow between pads better. If you ever see a ground plane not going between a pad you think it should - it's probably the line width.

Silk screen

0.032, 15% is the smallest text size I would use on a board. That's readable (in good light) - but I usually prefer things to be larger than that. Once your board is done, smash all the parts to separate the text and parts, then position the labels in good locations. Add your own labels with the text command - make sure they're in the tPlace layer - that way the panelize ulp will duplicate them correctly.

Scripting

Eagle has a scripting language which I don't really understand. But - if you have any task that seems tedious (changing lots of items, spacing many components on a grid, etc), someone has probably already written a script to do it so search the web for Eagle scripts.

Design Rule Checking (DRC)

Obviously you need to run DRC often to make sure you haven't violated any rules. Download the DRC file from your manufacturer and use that. I normally copy and edit that file and make it more conservative and use that for my DRC run. The more conservative you can be, the less likely there are to be errors in the board when it's made.

Viewing your board

Use http://3dbrdviewer.cytec.bg/ to upload the board file for 3-d viewing. This can help visuallize how close things are together. In addition, you can download EagleUp and use it to export your board to SketchUp for 3-d viewing. Each part in your board will require a SketchUp object with the same name but they're pretty easy to find. This can really help visuallize how components will fit together.

Ordering your board

Before placing an order, run the renumber ULP - that will insure that parts are numbered in a reasonable order (so R12 isn't next to R1). Then adjust all the labels until you're satisfied.

If you need to "panelize" a board (make duplicates of a single board in a larger board), you can do that. Close the schematic view and save the board to a new file. Run the eagle panelize.ulp - that will copy all the names from the tNames and tPlace names to a new layer. Then do a group, copy on everything and position the copy. Repeat as necessary. The problem with the copy is that each part gets a unique name which makes the labels wrong. But, the copied names in the new layer are correct so when you export the board for manufacture, select that layer instead of tPlace and tNames and the labels will be correct. See this panelize tutorial for more details.

Be sure to download the CAM job from whatever board house you use (so far I've had great results from Elecrow) and run that to generate the gerber files for them.

Boards larger than 10cm x 8cm

The free version of Eagle limits boards to 10cm x 8cm. If you can split your order into smaller pieces (say two 10cm x 5cm or four 5cm x 5cm boards), you can use eagle-brd-merge to merge multiple board files. It takes in an offset and rotation for each board and writes out a new board file with the merged result. You won't be able to edit anything outside the 10x8 cm area but it works great for combining multiple boards into a single panel.

@petewill said:

I don't remember where I read this but it was advised not to use resettable fuses with the HLK. Basically it was said that if the fuse were to blow the HLK would have already been stressed to the point where it may be unsafe and it's best to replace the whole device. I wish I could remember where I read that but I'm not sure...

I'm 90% certain that was from the guy who did the power tests of the HLK. I believe he was saying that these small PSU's don't handle heat or spikes well and if the fuse goes, you should assume the PSU is unsafe as well and replace it. I think it was in a thread that he was replying to on a different forum but I could be wrong.

I've finished soldering the first batch of boards and things look pretty good so far. I had one diode footprint that was wrong but it was easy to fix and a couple of soldering errors that were also fixable. In hind sight, I think putting the power supply and other IC's under the arduino is a mistake - I should have moved them to the back of the board. If there is anything is wrong with a joint, it's impossible to get to for diagnosis and reworking. Here's a glamour shot of the mother and daughter boards:

Yeah! Boards have arrived. I used elecrow.com and ordered 10 boards for $25. They shipped 14 and they arrived (California) in 16 days. Everything looks good so far. I probably should switch to a larger silk screen font for some of the labels but so far all the footprints seem to be correct. Next up is to start cutting the boards apart and start soldering...

One more note: There is also an HLK PM03 which outputs 3.3V.

FYI: Here's an emissions test of the HLK-PM01. I don't have any experience with this sort of thing so I'm not sure what to make of the results:
https://skippy.org.uk/quick-look-at-the-hlk-pm01/

Another thing you can do is use the MockSensor sketch - it makes it pretty easy to make fake sensors so you can test out radio range or controller behavior for different sensor types.

I would phrase it a little differently. You're trying to use MS in a way for which it wasn't constructed. MS docs are good, provided you follow the path the system was designed for. It shouldn't surprise you that you'll have to start going through the code since you're trying to build something new. I'm sure no one will mind if you write a lot of good documentation in the areas you find deficient and put in a pull request

ps: As someone who works on a multi-decade software project, I completely agree with you on the state of the arduino code and that includes the libraries and most user code. It appalls me every time I have to look through the arduino standard libraries to see the lack of a standard style, documentation requirements, test cases, etc.

Does that affect the AES encryption in the RFM69 radio as well?

I'm curious why you're against having a gateway. One of the good reasons to use one is that the RPI is not a real time OS and has a non-trivial chance of losing radio messages since the process to read from the radio may or may not be running while the messages come in. The more applications you start on the pi, the more likely you'll be too lose messages which will be frustrating and hard to debug, especially since it will be intermittent. A gateway is a cheap, easy way to avoid this.

If you read the docs http://www.mysensors.org/download/sensor_api_15, the library API is the MyMessage class. The class is the protocol. For an example (using v1.5), look at MySensor::sendWrite() and you'll see it calls radio.send( &message, ... ) so it's sending the message class as the data over the radio link.

I agree completely. The cloud makes all of these options unusable to me. I understand that data == money these days so I think these companies are trying to figure out how they're going to make enough money to survive and that's part of it - but it's not something I want to participate in.

FYI @zeph if anyone wants to see some cool, ultra small form factor boards, I found these over at LowPowerLabs the other day and they're pretty cool. They are for the RFM69 but that could be changed w/o too much work.
https://lowpowerlab.com/forum/index.php/topic,1254.0.html
https://lowpowerlab.com/forum/index.php?topic=1269.0

Update: I settled on an SPI based shift register system and received and tested those parts (they will require an update to the RFM69 library to use SPI transactions but we should do that anyway). I finished testing all of my schematics on a breadboard, fixed several errors, and submitted my PCB order this morning with Elecrow for 10 board of 10 cm x 10 cm. I was able to fit 2 main boards and 10 child boards on a single panel so that's 120 different boards for $25. I ended up creating the following 7 different child boards to use in the system:

• valve board (see first post)
• protected input board (see first post)
• sensor board (see first post)
• parking board (see first post)
• AC relay board (higher amperage/power relay for large loads)
• DC relay board (5V DC relay for small loads)
• I2C sensor board

Once I get the boards in and test them, I'll post the raw boards and schematics (or ping me if you want to see them now) in case anyone is interested. Just because it's cool, attached is an image of the final board submission.

Here's another great leak "sensor": rope leak detector. The nice part about this is that it can cover a large area and it's basically white so it looks nice. I'm planning on cutting the 8 foot length up in to 15-20cm lengths to use in multiple locations.

There are four wires in the sensor in the rope, 2 black, 1 white, 1 red. The only ones that matter are the black ones. Feed 5V to one of the black wires and attach the other to an analog pin. When dry, the pin reads about 20-30 (out of 0-1023 analog range). When wet, it will read anywhere from 60-150. That's not high enough to trip the digital HIGH value using digitalRead() so it needs to be hooked up to an analog pin to work properly.

What kind of relay is it and how do you have it wired (a schematic is always helpful)? As people have said, it's most likely a power drop which can be fixed with bypass capacitor. I always use at least one cap on the radio and I use caps on the relay power lines as well. Relays (depending on the type) can also put a lot of noise on the line and do other weird things so if you have the space, it's not a bad idea to use an optocoupler (or buy a break out board with one) to isolate the relay coil (assuming it's not a solid state relay) from the arduino. You can read more here: https://arduino-info.wikispaces.com/RelayIsolation. I use a circuit similar to that one and also added 2 caps (0.01 and 10uf) on the relay power line as well and haven't had any problems so far.

The regular RFM69 has much better range than the NRF so you might not need the high power version at all. It does require you buy/build your own antenna though. I'm using the 915 MHz version and can cover my whole house, yard, and garage with a small helical antenna I bought on ebay (the NRF couldn't do that even with an external antenna). Just search for "XXX hz helical antenna) on ebay to see a lot of options.

Thanks - that makes sense. It's probably short lived - micro processors are coming with more and more memory all the time so in a few years it won't matter at all for most things.

Regarding the LED's - so does that mean the "approved" way to handle that is to just go in and edit the MyLeds.cpp file? I was hoping to avoid editing anything in the MS library because it becomes very hard to track source code configurations between different builds.

@hek I'm designing a main board and am going to have a single LED which may end up on an output shift register. I've been looking through the dev branch and I can't figure out how I would override the existing LED blinking behavior with a custom function of my own. It seems like I can have it either enabled or not but I can't figure out how I would write a custom blink routine other than removing the existing ones and re-coding them to be my own. Is that the best way to handle this case or am I missing some other way?

Thanks,
TD
ps: General question on the dev branch: It seems like the new system is hiding a lot of the code (which is good for new people, maybe not so good for people who like to access that stuff) and different implementations are provided via global variables in the library (rather than the sketch), free functions and #define's control which get used. Providing different implementations with a common API is pretty much what object oriented design was built for so I'm curious if you considered using a system of interfaces and derived classes for different implementations for this? (I'm not trying to criticize - just trying to understand).

Try searching for "remote outlet" on aliexpress or ebay. You can get ones with a remote for anywhere from $6-$10 delivered/outlet depending on the model and number. Take them apart and replace the guts with your hardware. Something like this.

Yes - but you have to protect the arduino from that high voltage. Best way is with a small optocoupler chip (I use EL817 chips which you can get for practically nothing). There is an excellent explanation in the first answer on this post on stackExchange. You may have to adjust the resistors because of the higher voltage. I've included the schematic below (it's a good idea to read the answer though).

I've seen that on the serial line when I have the baud rate incorrect set in the serial window. I think 115200 is usually correct but you might want to check your sketch to see what it's using.

Try the MockSensors sketch one of the minis. It sends fake sensor data at whatever rate you want (you'll have to edit the sketch to pick a couple of dummy values). Leave the serial gateway on one of them and plug that into the computer. You should see sensor data arrive at expected rate if things are working.

It wasn't so much the design, it's the fixed pin requirements (which I totally understand). I'm exposing 3 input and 3 output pins from shift registers on 2 of the expansion slots and a different set of Arduino pins on the 3rd expansion slots and none of those match up w/ the MYSX pin specifications.

@Anticimex said:

Have you considerd the MYSX connector?

Thanks - I did look at it and I think it's a great idea. But I decided it didn't match my needs for small modular boards that use the same pin outs for each board. I'm also trying to keep the design as flat as possible because of constraints on mounting it in the case along with lots of connectors.

So it turns out the "standard" input shift register that everyone uses in Arduino examples (SN74HC165) doesn't work on the SPI bus because it never puts MISO into high impedance. It can be fixed with another chip (single gate, 3 state chip). Instead, I found an input shift register that is designed to work on SPI (74HC589). I've got those on order now and will try it out on the breadboard before ordering any real boards.

I've been having fun w/ EagleUp and SketchUp - here is a view of my main board with three daughter cards installed in it. The bare pins are the inputs and output jacks which will go to the external connectors (power, sensor jacks, valve controls, etc), LED's, and switches mounted in the case. I have to admin, seeing the resulting board in 3D is just extremely cool

Nice - I forgot that you upgraded and weren't using a 328 processor.

@tbowmo said:

Got it working as a serial GW.. Receiving the first messages from one of my sensebenders..

Also got the ethernet going, this is not integrated with the mysensors parts though, as I have to refactor nrf / ethernet libraries a bit, in order to support multiple (HW) SPI interfaces..

Sounds great. I'm definitely interested in using this as a gateway as well. Any chance you're going to add SPI transaction support to those libraries (more info in my post here)? I know there are RFM library versions that have that as well (see here).

I'm looking at using an input and output shift register (one of each) on the SPI bus so I started reading more about how it works and how to use it. I seen several SPI related conflicts in the forum (needing soft SPI) and don't want to go down the SPI path if it's going to be a problem when I try to add the radio or ethernet in to my build. I was reading these pages

http://dorkbotpdx.org/blog/paul/spi_transactions_in_arduino
https://www.arduino.cc/en/Tutorial/SPITransaction

which discusses the transaction support system in the SPI library (it's dated 2014). This seems to get around several SPI issues including individual libraries initializing the SPI bus to whatever values they want which causes problems in other libraries. I don't see any calls in the current dev branch like that and I do seem some code where the bus is set for an individual sensor (lighting sensor example) which might cause problems when adding other SPI hardware.

So I'm curious: does the current MySensors libraries have these problems (I don't seen any transaction code anywhere) - i.e. is this something I should be worried about? If yes, how do people feel about using this new system to solve those problems?

Well... the good news is my 3D board looks fantastic. The bad news is that I should have tested my schematic first. My wiring for using the input and output shift registers together is totally wrong. I'm going to have to move some things around and rewire it. There is a lesson here somewhere - I spent the last few days iterating on the board layout getting everything just the way I wanted because checking the schematic isn't as fun but it turns out I wasted a lot of time because it was wrong in the first place.

I need to decide if I'm going to switch my shift registers to using the SPI bus or stick with the a system that shares a clock and data pin and uses separate latch pins for each. It probably makes sense to move them to using the SPI bus - I wasn't sure this was a good idea because I didn't really understand it or how the radio and memory are using it. Now that I've read more about it, it seems like changing the registers to have their own select pins and using the SPI bus is probably the best way to go. Any thoughts on that?

I'd like to share my latest design. It's a mother/daughter board design using an RFM69 radio (though it would be easy to change it to an NRF). I have about 10 sensors I need to make and they're all similar, but not quite the same. This system allows be to mix and match what I need for each application. It's designed to be AC powered (which isn't a problem for my needs) and uses the following case for all of them (~$3/apiece for 10). I'm not trying to get the smallest form factor - I want something that's easy to build and looks nice. I needed a decent size case because I use a lot of detachable connectors and have at least one switch and 1-4 LED's on the front all of which intrude into the interior volume.

The main board has the basic components and supports two daughter boards (roughly 25mm x 35mm) which plug into the side so the whole assembly is basically flat (leaving more room in the case for the switches, connectors, and LED's). An additional third daughter board can be used for small boards mounted perpendicular to the main boards (the sensor board below does that) or mounting over the top of the arduino.

The main board contains:

• 3.3V Arduino Pro Mini
• RFM69 radio
  • side mount for external dipole antenna
  • interior mount with enough space for a helical antenna mounted parallel or perpendicular to the board
• 5V->3.3V power supply
• digital signing chip
• flash memory chip
• input and output shift registers
• headers for a switch, LED, and piezo buzzer
• header for SPI (MISO, MOSI, SCK) pins
• 2 side mounted daughter board headers with inputs and outputs from the shift registers
• 1 top mounted daughter board header with pins from the mini including D3 (IRQ), D5 and D6 (PWM), A3, A4 (SDA), and A5 (SCL)
• 5cm x 5cm footprint for cheap production
• all components are top mounted for easier soldering and a bigger ground plane for better antenna performance

Here's a 3D view of the main board with the Arduino removed:

Each daughter board header has 5V, 3.3V, ground, 3 input pins, and 3 output pins. I've designed five different daughter boards so far. The first four fit in a single 5cm x 5cm package so I can get 10 copies of each for about $15. Other daughter boards are generally small enough that OSHPark is a viable source if I only need a few boards made (like for the car parking board).

• Relay board. I'm using this to control simple switching (like the garage door opener) and AC loads (hot water recirculating pump).
  • 1 solid state opto-isolated relay with screw header with LED for AC loads
  • 2 switched transistors for simple connections
  • 3 sensor inputs with pull up resistors
• Protected input board. I'm using this to trigger when external security cameras and motion sensors trip (they both operate on 12V signals).
  • 3 opto-isolator circuits for triggering on 12V lines
• Valve/motor control board. I'm using this for articulated water valves for controlling leaks at the water heater, washing machine, etc.
  • L9110 motor controller with LED and valve open/closed sensors.
• Generic LED/sensor board. This board adds pull up resistors on the inputs and LED resistors on the outputs so it can be used with the shift registers.
  • 3 sensor inputs with pull up resistors
  • 3 LED's with resistors
• Car parking board
  • 3.3V<->5V level shifters for the distance sensor
  • Ultrasonic distance sensor
  • LED ring

To give you an example of how this works, here are some of the builds I'm going to use:

• Garage sensor
  • relay board for monitoring and controlling the garage door
  • parking board for LED parking sensor
  • could add a 3rd sensor board for temp, humidity, or air quality later
• Water heater sensor
  • sensor board for monitoring water leaks
  • valve board for shutting off hot water intake
  • relay board for a hot water recirculating pump
• Refrigerator and bathroom sensor
  • sensor board for monitoring water leaks
  • valve board for shutting off water to the ice machine or toilet
• Washing machine sensor
  • sensor board for monitoring water leaks
  • valve board for shutting off the hot water
  • valve board for shutting off the cold water

I've finished all of the board designs and am now bread-boarding the schematics to make sure everything works properly before I put in my order. Once I get everything tested and confirm the boards work, I'll post the schematics and board files for anyone else that's interested. If you have any suggestions or comments, I'd love to hear them.

I don't think "from China" means it's bad. But for a power supply, I would be concerned about quality control. I wouldn't be surprised if items that fail a quality check for a big name company get dumped on the open market as parts anyway. Another option to consider is the Samsung cube charger for ~$9, it's tiny, works on 120/240, is well designed (see online tear downs and tests), and is nicely isolated for safety. As long as buy from an actual Samsung version and not a fake, I think it's a really good solution. In the US, I buy them sold by Amazon - not a 3rd party seller on Amazon.

I think the DIY version is really cool - but it does scare me a little because I'm not trained enough to evaluate it's safety.

You could combine the two ideas and create a PCB board with level shifters and the 4x2 connector.

I definitely fall in the "don't need it/don't want it" category. But - if I was going to try and design something like that, I'd think about building a "standard" set of component classes (Switch, Led, Relay, etc) and use a state machine style interface. The user then doesn't need to worry about how an item works, just which items they need to construct. The documentation for each class would explain how to wire it up and the user would create an instance of each class with the pins it's attached to and supply a callback function which would get called when the state of that item gets changed. So the user is just responsible for filling in the "what happens when things change" portion of the code. The main loop function would be a series of poll commands to each item. I've used that kind of design in my own sensors and it's a nice way to separate the hardware code (pins, polling) from the sensor code (what happens when the state changes). I think something like that could help with basic needs - obviously it wouldn't help much with complicated sensor behavior. It does still require coding - but not coding that cares about low level arduino stuff.

I haven't put anything up on github yet but I could do that if anyone is interested in them. I have fully documented classes with wiring guides for a Switch (low or high, digital or analog pin), Timer (simple polling trigger), DigitalOutput (used for LED's and relays including blinking), and articulated water valve.

Here's an example of a callback in my leak detector test case (no MS messages in this one) to give you an example of what this kind of code looks like. What I like about this kind of design is that the real work in the state change code has nothing do with hardware, pins, bit flags, etc. In 5 years when I've forgotten all of that stuff, I can still look at this and see exactly what's going on. The g_xxx variables are the globals for the Switch, Led, etc.

void
statusChange( Status status )
{
   if ( status == g_status )
   {
      return;
   }

#ifdef DEBUG_LEAK
   Serial.print( "Status  -> " ); Serial.println( status );
#endif   
   
   switch( status )
   {
   case NORMAL:
      // Going back to normal operations.  Turn off the LED and open
      // the valve.
      g_led.off();
      g_valve.open();

      // TODO: send message, leak cleared.
      break;
      
   case LEAK:
      // Leak in secondary sensor - don't close the valves.
      g_led.blinkSlow();

      // TODO: send message, leak, valves opened
      break;

   case LEAK_SHUTOFF:
      // Leak in primary sensor - close the valves.
      g_valve.close();
      g_led.blinkFast();

      // TODO: send message, leak, valves closing
      break;
   }

   g_status = status;
}

You might want to look at this one which is much simpler (IMO): https://github.com/uChip/RFM69W_BOB - it has space for a 3.3V power regulator and level shifting resistors if you need them.

I made a modified (even simpler) version of that which you can find here: https://oshpark.com/shared_projects/OhoMAYdA which I've used successfully. It requires a 3.3V input but it will do level shifting via resistors or you can solder the jumper pads if you already have 3.3V signals (that's what I did).

See this thread: http://forum.mysensors.org/topic/1810/no-softspi-support-for-rfm69/2

There is a post in there w/ a github repository to a SoftSPI version of the RFM69 code posted by @gieemek. There is also some links I posted there to (especially this one: https://lowpowerlab.com/forum/index.php/topic,838.0) where the LowPowerLab folks have implemented SoftSPI support. It might be worth trying to integrate their updated code into the MySensors.

This has been a great thread with a lot of good information. I'm still a little worried about putting something like this in my wall though. What are peoples thoughts on benefits of this approach versus using something like a Samsung cube charger which is about a 28 mm cube (without the prongs), handles 120/240 V, and is probably very safe?

I think what @hek is suggesting is something like this: clone the repository and branches (dev, main, etc) to your local machine. Point the IDE at that location. Then when you want to do a build with a different version, use git to switch the repository to the other branch. And better yet, tag the software you use for a specific sensor deployment when you build it, then when you need to go back to it, checkout the tag.

If that doesn't sound good, you may want to look at other IDE/build choices. Any of the Arduino make/cmake systems will let you explicitly point a compile step at different directories to pick up specific versions of the software. So you can have all the branches checked out and sitting there on a disk and just point at different ones as part of the build process. You should still use tags to track exactly what you deployed, but it lets you keep all the versions of the library you're using visible and it may be less confusing than trying to remember to switch the code using git. It's just more expensive (in time) to set up the initial build system to use this vs the Arduino IDE.

FYI - I used these 915MHz coil antenna and ran a mock sensors test around my house. I had several areas where the NRF radios had terrible coverage (even with the various antenna mod ideas floating around). The RFM69 with this little antenna worked perfectly in all of those areas. The only area I couldn't get anything was out at the street by the water meter - but that's under 18 inches of ground and concrete so I'm not too surprised by that. No idea on power usage - I'm using/planning on hard wired nodes everywhere so range and encryption are the major selling points for me. I haven't tested the encryption yet but it's on my list to do.

@MikeF said:

I'm not sure I understand - I was talking about mounting these on a stripboard, where all the connections are different:

All of those came from different places so it's pretty unlikely anyone here can help...

Ki-Cad or Eagle are both free PCB design software packages that will work. Eagle is commercial and limits free designs to 8cm x 10cm. Google for "Eagle vs kicad" and you'll see lots of discussions. Both have YouTube videos which are the best way (IMO) to learn them (search for "eagle/kicad tutorial" on youtube) and both have tons of parts libraries that are easy to use. I came across Eagle first so I started using that. If you can handle a basic schematic, you can be designing your first PCB in a week or so.

You have to position your components on a board first, then both programs have an "auto-router" which will lay out the traces for you but it won't be good. At least for me, the fun in PCB design is doing the traces yourself.

Floating pins can read as anything so I think you need a pull up or pull down resistor for every input. I usually feed GND to the switches and then use the internal pull up resistors which works well (though I've never tried it w/ an OR gate). You could also try removing the OR gate and get that working reliably then add it back in.

Did you try resetting the board after power on? I guess there are some boards that have issues and need a reset after power on before anything works. See the links in this post: http://forum.mysensors.org/topic/1021/security-introducing-signing-support-to-mysensors/157. The links in that post have a relatively easy fix to implement if it turns out that is the problem.

@GertSanders Check out http://pcbshopper.com/, there are places slightly cheaper than DirtyPCB and places that will do runs of 5 boards instead of 10 for the same price per board. http://www.elecrow.com/ looks really good (5 boards for $15 delivered) but I haven't ordered from them yet so I can't comment on quality (other reviews of them say it's fine though).

Well - the good news is that mine is working now. The ??? news is that I'm not sure why. I was using an Uno as my gateway (w/ a dipole antenna) and a 5V mini (small helical antenna) as the sensor and couldn't get anything to go between them. To simply things, I changed the Uno to a 3V mini w/ a monopole antenna and got some traffic, but not very consistent. So I shut everything down, ate some dinner, watched some TV and came back to it. Turned both nodes on and everything was working fine. I rigged up a battery and booster to the 5V mini and started moving it around the house and it's working perfectly. Basically there doesn't seem to be anywhere on my property that I can't get a signal.

The 5V mini is using a level shifter on all the lines (including IRQ) except MISO so I'll try removing the IRQ shifting next to make sure it works without that. And I need to see if I can get the Uno working as the gateway.

My best guess is that I had a loose connection in the breadboard (i.e. maybe I should stop buying cheap breadboards). Or maybe start using wire wrap for my prototypes.

@jkandasa said:

@TD22057 The current MQTT gateway supports only limited features and a big drawback is we cannot use it directly on internet as it does not have any security option and limited to number of connections

For this reason I'm implementing MQTT broker support in MyController server. Here we can connect our mysensors gateway (serial/Ethernet) to MyController. Connect all our MQTT client to MyController with authentication

https://github.com/mycontroller-org/mycontroller/issues/7

I'm sure I'm not understanding something, but isn't that a lot more complicated than it needs to be? Why isn't MyController just an MQTT client that connects to an existing broker? So Arduinos <-> MQTTClientGateway <-> Mosquitto <-> MyController. If MyController subscribes to the MS messages from the broker and publishes command messages to the broker, everything works fine. Security and everything else is already handled by the existing broker software (Mosquitto).

Well I'm having problems too... I'm running basically the same serial gateway code you are and, like you, it starts up fine. For my sensor, I'm using the MockSensor sketch modified to send a counter. That starts up fine as well but can't communicate with the gateway. I tried level shifting IRQ and not level shifting IRQ - no change. Basically the gateway never gets the transmitted message. I'm using a small helical antenna that came w/ the radio on the sensor and a home made dipole on the gateway. I'm going to try and replace my home made antenna with a helical model on the gateway and see what happens.

Here's what I see on the sensor:

find parent
send: 254-254-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:

I'm using this level shifter. If my antenna mod doesn't work (I'm not expecting it to), I'll try changing this to a resistor network to do the shifting and see if that helps.

@bpair said:

This is fantastic. Thank you!

I am very grateful but I do have a feature request. I am collecting data in a greenhouse (and in the gardens) with mysensors. The more automation, the better. However, there are some instruments we still use manually, record data in a notebook, maybe copy to excel and manually create charts. It is very tedious and isolated form the automated sensor data.

It seems with your controller I can add a custom sensor (or use any of the other sensors) and with the Action board send data to the sensor. The feature I want is to enter data and have it appear as if the sensor sent the data. This data would then be logged along with all the automated data.

For example, we manually measure Nitrites. If I could add a custom sensor (a Manual Entry Sensor) and the action board allowed receiving data from the sensor it would provide a huge benefit. (No send data for this type of sensor is needed, only receive).

I am not sure how much work would be needed but it could also be used to test rules and other configurations.

Thanks for your work.

IMO, That's one of the good reasons to use MQTT as the communication system. MySensors gets translated to MQTT messages by the gateway and that's all the controller sees. Then adding more "readings" from manual sources or any other source is just a matter of sending a message into the system from that source. There are any number of GUI and command line tools (mosquitto_pub) you can use to post a message that would make entering manual readings very easy.

There isn't anything wrong w/ the #define - it's where it's being used. The #define is just a text replacer - you'll have to check the bcm2835.h line 350 to see what's going on. I'm not sure why it would think the constant ends at the x but maybe seeing where it's being compiled in might help.

I think the issue is that you shouldn't be calling delay() basically anywhere. The main loop() needs to run at a reasonable rate (i.e. be called at least every millisecond). One option: make rainbow() just show one time (remove the outer loop and delay calls) and pass in the current j variable as an argument. Then in loop(), use a timer to test if enough time has passed to re-call rainbow(). Any arduino ellapsed time/timer libraries will work fine. Here is an example: http://playground.arduino.cc/Code/ElapsedMillis. In that example, change the ledState/digitalWrite lines to call the new rainbow() function.

@hek said:

Shouldn't D2-> DI00 have level shifting as well?

That's IRQ so it should be an output from the radio to the arduino just like MISO right? I was under the impression that radio->arduino links didn't need to be shifted since they're digital connections and the arduino will read 3.3V as HIGH. I could be mistaken of course...

@Cliff-Karlsson I'm going to start my RFM69 radio testing this weekend (finally) using ProMini 5V <-> level shifter <-> RFM69W so hopefully I can report back with something that works.

Anytime you have trouble, you should start w/ the simplest case and build up to a real case. So:

1. use a serial gateway. start it up w/ debug output and make sure that the radio initializes properly.
2. use the MockMySensors sketch or take a simple sketch and modify it to send an increasing counter value (1,2,3...) every second. start that w/ debug print as well (run 2 arduino ide's so you can use 2 serial monitor windows). That will tell you if the radios are receiving each other properly. You can use this to test range as well my moving one of the radios to another location.
3. create a simple arduino sketch that reads the sensor. it shouldn't have any mysensors code in it. just report the sensor values to the serial connection. make sure that works. This validates the sensor reading and wiring code.
4. combine 2+3 so you're sending real data to the gateway == success!

@DrJeff Very cool. I have 2 HikVision cameras covering the front of my house so I think I'm going to try the DIY version of Ring.com. Both of the cameras have "alarm" input and output wires (12V signal) that you can use to start recording video using an external PIR or do something when the camera detects motion. One camera has an external Bosch PIR sensor that works really well. It's a 12 V NC signal wire connected to the camera and it has eliminated virtually all of the false motion alarms. The other camera is above the door and has a built in PIR sensor.

Reading this thread made me realize that I should tap into the door bell signal and the alarm output wire on the camera above to the door and send that out as a MySensor message which will send an MQTT message to a script which can grab the camera feed and email me still images (or send me a link to a web page w/ the images) of who is coming up to the house.

FYI for anyone who wants to make a more complicated version of this, take a look at LowPowerLabs door bell controller. There is some good docs there (and in the follow up articles) if you want to try and tap the door bell power source to power the arduino. There is also a nice explanation of how to detect when another circuit activates which might be handy for another application.

I think it's a great idea. Who cares whether it's the perfect security or not - it's a useful and fun project to build.

I'm planning on something like this in the long term (tons of other projects first and I already have an Ademco alarm w/ hardwired sensors everywhere). There are lots of ways you could build an alarm system. You could have an Arduino serial gateway passing sensor messages to a Raspberry Pi and then code up the alarm logic in any language you like on the pi (Python is much easier than C). Since the pi has internet access, it can send emails and run a web server to show alarm status. Or for hardwired alarms without MySensors, a pro-mini and a few input shift registers is probably enough to run a complete alarm system. Or for a MySensors (wireless sensors) build, you could buy an Arduino Mega and put the alarm code in that.

Remote keypads could either be wireless w/ MySensors messages (ok) or wired with serial or I2C communication (better). I'd love to have a Mega with one of the Itead Nextion touch screens for my alarm keypads. Maybe with a motion sensor that only turns on the display when you're near it. Then the keypad could double as a weather display, general my sensors controller (lights, etc) as well as an alarm keypad.

Thanks! The connection diagrams are a nice touch. I'll take a look and try it out (probably w/ the MQTTClientGateway) as soon as I can.

How hard would it be to make a version of RFM69 that would support soft and hard spi? I haven't run diff's yet to see what your modifications were but it would be nice if this was a fork of the LowPowerLap library so Felix could fold back in to his version code. Having two versions of the same file that I have to switch between might get confusing in the future.

I'm looking forward to the results of the refactoring. So far it looks really nice. I thought it might be nice to capture any ideas people had for improvements to the system.

A big problem is the arduino IDE and it's re-writing of the code. That makes it difficult to have things like #defines before include files which is one good way to have local definitions of things. I use this technique http://gammon.com.au/forum/?id=12625 to get around that. It looks like maybe this is being addressed in the branch but I wasn't sure.

Right now, I'm in the hack/prototyping phase but I'm starting to think about my real build/deployments and how I want to manage the software for my various nodes. I think there are three levels of software that may need different types of management.

1. MySensors libraries. This will be the version of MS that I have on my nodes. It should be the core libraries, RF code, etc.

2. Site specific configuration. This contains the information that is common to all of my nodes. Things like network channel, encryption keys, etc.

3. Node specific configuration. This contains the information that is specific to the hardware/software of a single node. Pin identifiers, LED control, radio information, SOFT_SPI, etc.

Right now, a lot of these items are mixed together in a single file (MyConfig.h) which makes it more difficult to CM the site specific information and the sensor specific information in a nice way. I'm planning on running these nodes for several years (hopefully with no updates) once I deploy them and I need to insure my CM system has a record of exactly what was sent to each one in a way that I can understand when I'm not in the middle of working on them.

For example, I'm never going to remember to edit SOFT_SPI for my gateway in the common area when building it. I know to do that now, but, 3 years from now I won't remember any of this. So whatever we can do to make node specific configuration data in the node code would be an improvement.

Here's an example of what I'm thinking I'd like the code for a single node to look like:

// Define the hardware configuration for this node
#define MY_PIN_OTA_FLASH_SS 7
#define MY_PIN_RX_LED 4
#define MY_PIN_TX_LED 5
#define MY_PIN_ATSHA204 16
#define MY_PIN_SPI_MISO 15
#define MY_PIN_SPI_MOSI 16
#define MY_PIN_SPI_SLK 14

// Include site specific data (encryption keys, etc)
#include "MySiteConfig.h"

// Include the MySensors classes
#include "MySensor.h"

// setup(), loop() go here

Some of the examples in the refactoring branch look like they're doing something like this but I wasn't sure so I thought I'd post this for discussion.

Thoughts? Any other ideas for improvements to the infrastructure?

Did you search for MQTT in the forum? I think this thread answers your questions.
http://forum.mysensors.org/topic/1997/use-of-mqtt-gateway-from-other-sensors

Sorry - there are 2 gateway implementations that use MQTT. The first one is MQTTGateway and implements a very limited broker interface. Only a limited number of clients can connect and they can't limit what they subscribe to. It's only designed to interface with controllers using MQTT and isn't a general purpose broker.

The second one is on the development branch (go to MySensors github, click the branch menu, and select Development) and is named MQTTClientGateway. It's a gateway that is an MQTT client so it publishes to and subscribes from a regular MQTT broker like mosquitto.

The first one is useful for people who want to use a controller that uses MQTT but aren't using MQTT for anything else. The second one is better for everything else (in my opinion). In the MQTTClientGateway, you give the IP and port number of your MQTT broker and it publishes sensor values and subscribes to actuator commands. So I would recommend that you download the development branch and use that one instead.

The issue is probably that that the MQTT broker gateway is an extremely limited implementation because of space/cpu issues on the Arduino. I'd recommend that you run a regular mosquitto instance as your primary message broker and connect everything through that. So the MySensors gateway is a client of the mosquitto broker and openhab and everything else is connected through mosquitto. If you want to use the MQTT broker gateway, then look up "mosquitto bridge" which will let you connect the mosquitto broker to the MySensors broker. if you want to use the MQTT client gateway (which I would recommend), then you can point it at the mosquitto broker like any normal client.

FYI for anyone looking to get PCB's made, here is a price comparison site that shows you various manufacturers and what they'll charge you for different sized boards. Prices are crazy cheap these days...

http://pcbshopper.com/

You can also look at real security cameras. I have a couple Hikvision cameras that support an "alarm input" which is used with external motion sensors to trigger the camera to record to a NAS. I use this with a nice PIR motion detector to avoid image analysis false positives. If you have a camera with an alarm input, you can use a relay to start recording, use MySensors to send a message out, and have an external process go to the NAS and grab the snapshots and/or video and do something with them. In my case, the Hikvision camera can also email me if I wanted that as well.

@ahhk said:

Would you share your python script? Does the script send received messages from the MQTT to the sensors, too?

Sorry - I don't have anything up and working yet. I'm still flipping back and forth between ideas so I haven't gotten around to finishing my script. I'm basing it on these repositories though which might be usable by you:
https://github.com/thehawkes/pymygw
https://github.com/wbcode/ham

@John-Connolly You may want to the try the client gateway from this thread: http://forum.mysensors.org/topic/524/mqtt-client-gateway
It's a real MQTT client (point it at your Mosquitto broker) which I find easier to understand than the pseudo-broker that the MQTT gateway uses.