Best posts made by DavidZH

@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

Right now I'm really banging my head on the wall because I'm lost. I have been using an outdoor sensor unit for the last two years now. The heart is a Moteino on a perfboard carrier. Connected to the Mote are 2 GY boards; a GYBMEP with a Bosch BMP-280 and a GY-49 with a MAX44009 light sensor. The whole device is powered by a 1000mAh LiPo topped up by a small solar panel through a ADA390 solar charger (MCP73871).
See the picture for a little overview.

My problem is this: when de Mote sleeps, I can't get the current consumption of the sensor boards anywhere NEAR the specced values (0,65uA for the MA44009 and 0,1uA for the BME280). I end up at about 800uA for the sensor boards alone. So first I used software to switch off the power and I2C bus to the sensors, but that does not work because the MAX44009 needs 800ms to take a measurement, and to wait almost a second every time for the sensor to finish feels kind of stupid. So powered continuously it is. Should not be a problem with the specified power consumption. I already had removed the linear regulators for both boards to be able to use lower voltages.
So next step; remove the resistors and MOSFets that protect the sensor from overvoltage from the GY boards. A bit of a fiddle because teeny tiny, but I think I succeeded. I dit get a lower current draw, about 300uA. But that's still nowhere near the 1,5uA it should be.

Does anybody around here have had the same sort of phantom draw? And has that person found a way around it outside of using the bare sensor chip? I simply can't solder that stuff.

I know there are some other kinks with this board, the regulator on the Mote goes into some sort of avalanche mode when the battery voltage goes down to Vout + Vdropout. It then passes around 90mA all the time. I've had that happening twice now: a year apart to the day. And the charger board also uses 35uA whatever the state. But that should not be a problem during the day.

I really want to solve this now so that I never have to take a second look to that sensor. Hints are appreciated.

@Luc3as

The forecast script is meant to be running every minute to collect the averaging data. If you run it every 5 minutes, you need to change the dividers in the script to come to a hPa/h value that actually makes sense.

@Yveaux I will try that as soon as I'm back from my winter sports vacation (as far as you can call lush green Alpine meadows that. At least the slopes are well maintained!). I have no access to a node and gateway now.

For me it worked for that sketch as it's main function is reading momentary switches, either on mains power or on battery. As soon as I want to add a sensor that needs to send it's info on a set interval I needed it to be on mains power.

But like I said, I will convert the sketch to 2.1 this week, and next week I'll give the workaround a shot.
Keep you posted!

Thanks Gohan,

there are a few reasons for me to use the BME outside. The most important: power management (and that explains my conundrum now...).
The unit contains a light sensor. That basically controls my lighting in the living room. So that needs to measure quite often to be able to control it with any accuracy. I've chosen every minute as a basis. That was also given when I found a sketch with a weather prediction function based on barometric pressure. That sketch needs to read the pressure every minute. That means that the sensor wakes up every minute. Also the radio. That's a huge load. Not really ideal for battery power. But that meant I was able to add the light sensor very easily.
So now I put them in an outdoor sensor with a solar panel to keep the battery topped up. That still means I have to watch the consumption in sleep. Here in NL we have quit a few overcast days, so the panel will not be able to keep up with the demand on those days.

The solution in place now is to wake up the sensor 1 second before measurement. Power up the sensors, put the controller and radio back to sleep for one second. Then do the measurement stuff, power down the sensor and I2C bus and go into deep sleep. Average current consumption measured over 4 hrs is now 140uA. Sleep current for the whole system is 36uA. That is including the charger board and Moteino voltage regulator.
The unit is now up for 3 weeks and the panel keeps up very good. Most of those days were overcast. So when the cold hits next week with clear skies it should be full all the time.

Battery level is sent every 6 hours. And next to that I have implemented a voltage measurement that signals when the battery is being charged. Energy is coming in, so I am allowed an extra data transfer...

Now see if it dies on me again end of november 2019...

I had exactly the same issue. This UK eBay store sells them per 5. Not sure what they'll ask for sending them across the ocean.
I got them from here (4 days from UK to NL). Got one up in my gateway and that works with a soft signing node. Should be good.

I'd like to ask a follow up question to this old topic:

I have been able to create a set of keys using my GW on a Moteino (16MHz).

Now I'd like to program the keys into a some nodes. A few of these are running a bare 328p at 1MHz as a battery sensor, but a baudrate of 115k is a bit high. I only get garbage in the serial window, so no checking if the keys are stored properly.
Wouldn't it be wise to lower the baudrate of that sketch to be able to accomodate slow battery sensors. I have looked to try to do it myself, but was unable to find where.

@hek

Thanks a lot. Way better that way!

@mfalkvidd said in MY_TRANSPORT_DONT_CARE_MODE:

Could we collect some use cases on where controller availability is useful?

I am changing my main light switches in the house for MySensorized ones to include extra's like notification of the house-state (at home, away, night), remote switching of some lights and the ceiling fan. If the controller (or just gateway for that matter) is down, the WAF would plummet like a boulder dropped from an airplane. Whatever happens, the light switches MUST ALWAYS FUNCTION!

Then when the link returns, the control must be passed over to the controller without states changing. "Oh, I think Pimatic is working again because the light goes off...." <- bad for WAF...

These light switches will be powered by the utility, so they can go search for a parent until hell freezes over, I dont care (as long as the switch function is working).
Battery powered sensors on the other hand do not have that luxury, because of the battery drain. So they could benefit from knowing link status also by searching for a parent once, and if none is found, go back to sleep for their usual schedule in a hurry! Do not even try to read or send a sensor value.

Now I have planned two magentic door sensors on battery. That will prove difficult because these will not have a schedule to send once every few minutes. So I will have to build something for that. These will be part of a personal alarm system (no sirens, just push messages), so lots of empty batteries and false messages will drive down the WAF as well.

This has to be implemented in my controller (Pimatic in my case) as well. If Pimatic stops for some reason, the gateway has to stop as well. But that's something for another forum....

I have the same module, and I initially had issues to get it going.

What I did: I set the BME to single measure mode in the setup with this subroutine:

void startBME()
{
  BME.settings.commInterface = I2C_MODE;
  BME.settings.I2CAddress = BMEaddr;
  BME.settings.runMode = 1;            //  1, Single mode
  BME.settings.tStandby = 0;           //  0, 0.5ms
  BME.settings.filter = 0;             //  0, filter off
  BME.settings.tempOverSample = 1;
  BME.settings.pressOverSample = 1;
  BME.settings.humidOverSample = 1;  
  
  BME.begin();
}

And next to that I call BME.begin(); every time the sensor is read.

Nice and simple sketch by the way!

Yes. Correct. call BME.begin() every time and the subroutine only at the beginning.

And you are also correct about the library. I use the "blue" lib, from Sparkfun. As i can recall correct (it's been over a year since I built the damn thing) I have tried both, and found the Sparkfun more stable.

And you CAN switch off power for this module, but after conversion it goes to sleep and uses less than 1uA. Hardly worth the effort, because the current can find a way over the data lines, and that's a pain in the behind to solve (I tried!).

And if you use wait(100); in stead of delay() you might have even less NACKs!

So I've returned to this thread after 2 months, as I finally found the time to test the workaround @Yveaux suggested on Januari 8th. In the mean time I had updated my library to the latest version (2.1.1).
When I run my sketch now, it never goes to sleep. Actually it does, but wakes up immediately. I use int testInt = sleep(0xff, 0x00, 0xff, 0x00, 0);, testInt returns -1, as in; MCU woke by timer. That is both with and without the workaround, and I am not sure that it's caused by the interrupt definitions. Up to 2.0 that worked fine (I rolled back yesterday to try).

Now I found this other thread where @tekka stated that he corrected some stuff that as out of line with the datasheet for the 328(p).

So what would be the correct way to make a node sleep forever without using the ExternalInterrupts (INT_0 and INT_1)? I am in no rush to get this going, because my first nodes are going to be mains powered, so they will be happily looping along without sleeping. But as this node has 4 buttons, PinChange is a route I'd like to go.

(Now I have to go and retract my statements in another thread, because they are null and void now.)