@mfalkvidd

Thanks! I should check Github moe often I guess. 😁

@scalz

I agree with the comments about the varistor, it can certainly help with spikes. But only around 10 times. After that, the varistor will fail. Violently. In Europe, Australia and North America that will not be a big problem, but in countries with a little less reliable grid that could be within a year.
When the MOV fails, it will become a short across the live and neutral, so ALWAYS put your varistor/MOV behind the primary fuse so that that will blow and stop the current across. Otherwise you'll have a nice fire inside the switchbox...

little story: a friend of mine lives in the Carribean and they have a sketchy power grid there. One day the fridge was "tingly", so we start searching. Few minutes later: POOF!: magic smokes escapes from the power conditioner for the TV. OK. Something's really wrong here.
So we suspected the wiring because of the corrosive nature of the air there (warm, humid sea breeze). Switch off the power, and start opening switchboxes and outlets (all US 120V system), we start finding all sorts of weird stuff like a circuit that is spliced off, goes into the floor and exits in another box, that is also fed directly from the panel.....
So a few hours later we have checked everything, ripped out some unused wires and checked all connections and switch all back on. Still auchie on the fridge. So after a few minutes unplugging all appliances and socketstrips it was gone!

It was a socket strip with net filter. The MOVS had blown and created a short to earth. And since the US system does not use RCDs on all circuits that could go on for a while.

Moral of the story: MOVs can do good. And bad. Use them wisely!

I have an idea that it still might be a low voltage situation. You say your ultrasonic sensor consumes about 60mA. When your battery voltage is at 3.8V those currents combined with the spikes caused by your radio can pull your battery down to below 3.3V.
I have an outdoor sensor with a Moteino as board and that uses a MCP1703 as voltage regulator. Same family as the MCP1700-33 of your board. When my supply voltage drops in the direction of the regulated voltage, the MCP faults into some sort of short circuit mode which draws an insane amount of power but does not output any usable voltage. And that will drain your battery quick, fast, in a hurry... (©️ AvE )

My sensor is being topped up by a solar panel so theoretically, it should never run out. But theory and real world are NOT the same. Your board is also capable of charging a LiIon battery with both the Vin and 5V connections. The BQ24074 will charge your batt.

Hope this helps you towards your solution.

@GertSanders I can't know where you stand pricepoint wise, but this sounds like a 2 MCU project. One to handle the clock functions, and one to communicate with MySensors. Messages between the 2 MCU's over I2C.
If the link is down, that will only clog the comms MCU.

@parachutesj I can see why you chose to move away. RF will always be in the "black magic" realm. Unable to see, hear or feel it's presence. Of course with the proper tools, and knowledge of the correct use of aforementioned tools a lot can be unveiled, but those are out of reach for the average hobbyist.

I have stopped working on actuators as a safety precaution. Most lights I want to operate are fixed lights, and the in-wall-boxes where I'd have to put the actuators are just too small to be able to fit both my own design MySensors actuator and a momentary switch. One must in my system is the ability to switch the light locally for whenever the controller or network fails.
The final push for me to walk away was a fire at a family members house caused by a cheap china power supply. No one was hurt, but it took 4 weeks before the family could move back in. I just felt I was not capable of designing a safe power supply to power the node, that would fit inside the wall box.
So Z-wave it is. With a lot of compatibility issues. But I use it just for communications, not the think-work.

So I will also stay here for the input part. Sensors galore.... And there will be an actuator later. A low voltage dimmer. Max 30V DC input. Let other people worry about the mains side of things. I just cant bear the thought of putting my family in jeopardy because I wanted a hobby so hard.

Awsome!

I'd like to compare your impressive array of measurement devices against my Agilent U1273A. Actually to decide if I need a µCurrent.... Maybe in an upcoming meetup in NL or BE this summer?

The main question should (in my humble opinion) be: how often do you plan to update your sensor while it's in use? USB is very convenient, no doubt. But FTDI is almost just as easy when you prepare an adapter with a single connector that you slide on and program away....
Even if you plan to make more than one sensor the debugging will be longest with the first. (Hopefully!!!)

Either way, good luck on the build!

I am working on such a node, but am still in the programming and testing stage. I will come back here when I have positive results!

@tekka

Found it! I added a #ifndef so I do not have to change it every time I program a node (and forget at what setting it is the next time....).

It might be the board you're using. I had similar issues when I was building my weather node with the same proto-board. After I switched to single sided board it worked immediately. The copper might reflect RF-energy back to the radio and your Arduino that interfere with the transmission.

Can I make a suggestion? Reverse the placement of the nuts to the top part, and the little machine screws to the bottom part of the housing. That way it will be easier to keep the water out as it will not creep in to the gap between the ABS and the screw. That capillary action will also work upside down, but good old gravity counters that to a great degree.

Actually, I use the FTDI connector on my outdoor weather sensor to power it from the solar/Li-Ion charger board. Used angled headers to keep the height down. I'll try to post a picture asap.

@popunonkok

Well here's the first example of some code that works for me. It's a house controller mounted on a pulse switch (for a standard NL/BE/FR/DE switch box). Own developed PCB that can handle 4 switches, so needed to find a way to be able to sens all our inputs.
I used the "Button" library to de-clutter the code a bit, and I followed the MySensors way of setting up the program (with defines). That's because I want to deploy a whole bunch of these, so I can adjust some settings quick and then shoot the sketch in the MCU.
At first I included a sensor function as well but as the standard sketch grew too big I axed that.
I'll only give the relevant parts of my code now, as I'm not finished yet. Still working on the part where the connection with the GW is lost and reinstated. As this project can also be used as a light switch, it should ALWAYS work. So after the communication is restored the node has to send all the states to the GW again.

#define PULLUP true        
#define INVERT true        
#define bounceTime 20             // A debounce time of 20 milliseconds usually works well for tactile button switches.

#include <Button.h>
#include <PinChangeInt.h>

#define buttApin  14              // Arduino Digital I/O pin numbers for connected buttons 
#define buttBpin  15              // when connected to '`official' PCB.
#define buttCpin  8
#define buttDpin  9

bool battPower = true;
int inputPin[5] = {0, 0, 0, 0, 0};          // State machine registers
int actuatorPin[2] = {0, 0};
int function[4] = {0, 0, 0, 0};
bool safetyBttn[4] = {0, 0, 0, 0};
bool reqAck[4] = {0, 0, 0, 0};
bool inState[5] = {0, 0, 0, 0, 0};
bool longPr[5] = {0, 0, 0, 0, 0};
bool outState[4] = {0, 0, 0, 0};

Button BtnA(buttApin, PULLUP, INVERT, bounceTime);    
Button BtnB(buttBpin, PULLUP, INVERT, bounceTime);
Button BtnC(buttCpin, PULLUP, INVERT, bounceTime);
Button BtnD(buttDpin, PULLUP, INVERT, bounceTime);

attachPinChangeInterrupt(inputPin[ChanA], ChanA_ISR, CHANGE);
attachPinChangeInterrupt(inputPin[ChanB], ChanB_ISR, CHANGE);
attachPinChangeInterrupt(inputPin[ChanC], ChanC_ISR, CHANGE);
attachPinChangeInterrupt(inputPin[ChanD], ChanD_ISR, CHANGE);

void ChanA_ISR()
{
   pinChanged = ChanA;
   inState[ChanA] = BtnA.read();
}


void ChanB_ISR()
{
   pinChanged = ChanB;
   inState[ChanB] = BtnB.read();
}


void ChanC_ISR()
{
  pinChanged = ChanC;
  inState[ChanC] = BtnC.read();
}


void ChanD_ISR()
{
  pinChanged = ChanD;
  inState[ChanD] = BtnC.read();
}

So when the node wakes up from sleep the variable pinChanged carries the number of the pin that has made it enter the ISR. That can be used to take action. After everything is handled pinChangedis set to the resting value (255 in this case).

Depending on whether the circuit is powered by a battery or a 5V supply the node enters sleep state or simply loops without doing anything. When sleeping I use sleep(0xff,0x00, 0xff, 0x00, 0); When using any other call to sleep, it will not work (the node never wakes up). So I got a hint from one of the developers how to solve it, and I have yet to try that. But I'll keep you updated here (and the other thread).

I hope this helps you a bit further.

I've been following that development. And I think it's good that MySensors follows the rules as set by Atmel.

To be able to use more interrupt pins at the same time I have been looking into pin change interrupts. Those are triggered as the designated pin changes state, either LOW->HIGH or the other way round.

I think by changing MyHWAVR.cpp (and the comparable files for other hardware) a little, my sensors is capable of using PCI's to wake the node. There is always a negative, and in this case I think its the amount of code needed to see what pin caused the interrupt. The work done by GreyGnome with the EnableInterrupt library shows that very well. The lib is also huge because of the way they use enabling and disabling of the pins with software to emulate the other modes(RISING, FALLING, HIGH and LOW).

This is not THE solution. It's only one of the ways to be able to use the other modes with a pin.

Welcome to the club!

Regarding radio's: The RFM69's with a C in the type have a smaller form factor (which is pin compatible with the predecessor RFM12B). The the 'W' and "HW' versions are larger in size and have more programmable pins (which MySensors does not use) but have exactly the same functionality within MyS.

All the footprints on the boards available in OpenHardware.io are for the 'W' and 'HW' versions so I'd go with one of these.
The 'W' uses way less power than the 'HW' which would be good the for the battery life of your nodes. Sensors powered by the grid can be 'HW', but usually, in the house a 'W' delivers enough TX power to get the message across. It might be a good idea to make your gateway with a 'HW'.

Hope this gets you a bit further. Good luck and show us your results!

Well, that's embarrassing... I gave these tips last week, but it appears now that I have been surpassed by updates to the MyS library. The sleep command i issued here now leads to a loop, the node will not sleep. The changes to the library are intentional, as they make MySensors compliant with the designrules from Atmel/MicroChip.
I have tried another library by the same author (EnableInterrupt) but to no avail.

Back to the sketchboard...

Can you post a picture of het back of your RFM module? That way we can eliminate the definitions you won't need.
I run on 2.1.1 with 868MHz versions of both HW and low power. No problems whatsoever. I'm getting very curious as to why I keep reading about users facing issues with the RFM based nodes.

I stand corrected about the footprints.
But wouldn't it be an idea to choose the non "C" version for your PCB?
The price should be exactly the same (at least it is at the supplier here in NL where I get mine from) at the cost of a slightly bigger footprint (3.7 mm wider in one direction, the other is the same).

Sorry again for the confusion caused.

Hello. New kid on the block here.

I am starting to build my sensor network to use with pimatic, based on this framework. I have chosen for the RFM69 on 868 MHz because of my living arragements. I live in an apartment block with 160 units. Most of these have a WiFi router in the 2.4GHz band, so it would be kinda stupid to try and squeeze my sensors in that band with the NRF. My actuators are in the 433MHz band and my current sensors are also based on 433MHz. Sometimes the actuators miss commands because of sensor data floods. Highly annoying.

Now my problems: I've built my gateway from a Moteino USB R5. Using V1.5, the gateway runs normal, apparently. I get normal messages in the serial monitor.
The node is built from a clone Pro Mini 3.3V (this one uses a beefy AMS1117 regulator, capable of 1A), a DHT22, and a RFM69HW running at 868MHz. I have already soldered a 4,7µF cap directly on the Vcc and Gnd pins of the radio.

When the gateway and node are 1 meter apart they communicate perfectly. When the distance grows beyond 2 meters: nothing....

I have tried different antennae: on the gateway I started with a stub of coax to a SMA connector with a 1/4 rubber antenna. I later changed that to a tuned coil (bought prefab for 868MHz). On the node I started with a piece of wire(delivered with the moteino) later changed to the tuned coil.

Power to the Moteino: directly from a computer through the on-board regulator(MCP1703; 250mA).
Power to the node: through FTDI adapter. First the regulator on the FTDI bypassing the AMS1117, later changed to 5V from the FTDI using the AMS on the Pro Mini.

Browsing the forum I found that people have better results when using the dev-branch. I had hoped to stay away from that.

What am I doing wrong? Hardware or software?

A step up in price from the RTL-SDR you'd find the RF-explorer; price from $270.

• Hardware with display.
• Free (and also payed) software to get a better picture of the situation.
• sub-1GHz and 2.4 GHz in the same device.

Not affiliated with the company, but I have used one and was pleasantly surprised