Isn't it so, that this code block makes the node unresponsive for UPDATE_INTERVAL 60 s? The only exception would be the digital input 3 (PIR pin).
// Sleep for a while to save energy
sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, UPDATE_INTERVAL); nsert Code Here
@hek said:
Hard to say anything about quality, but the following is at least in proper casing.
Have bought couple of similar ones. They are veeery noisy.... just something (depending on the use case) that might require extra components to compensate.
Excellent project. However, have you considered any possibility of condensation of humid air in the attic? At least where I live, that would become a problem.
To give a definite answer would require investigating the signals with an oscilloscope! Noisy signals can be seen quite easily, and also the effects of adding caps.
Note, that often a combination of a larger and smaller cap is needed to solve these issues. Think that larger one smooths out the slower changes (in the power line) while smaller ones smooth out higher frequency components.
I've ended up in some cases, depending on the power supply and the rest of the circuit, having a number of caps all over the circuit. Not pretty, not pro, but needed to stabilize the node sometimes..
These are most often related to noise of the power supply or other transient noise/spikes in the circuit (due to a relay for example).
To be more specific, I'd first remove the relay from the circuit and just use a led instead. If the node works then without problems for longer time, the reason indicates it's a noise issue from the relay section.
Similar examples can be found, e.g. http://forum.arduino.cc/index.php?topic=186879.15
Generally these are solved by separating the power supplies, or 'de-coupling'. A good read illustrating the situation, please read it through: http://www.thebox.myzen.co.uk/Tutorial/De-coupling.html
I have bunch of nodes that are troublesome. So fat it's been due to noisy somewhere in the circuit. Also, noticed that some nodes start to malfunction after few years due to low quality capacitors. And that is painful to cure...
In some cases it is also useful to force the NodeId of the repeater to be the parent (obvious, still took some time to understand it)
@Fat-Fly Nice, interested to try this also.
Any idea how long the batteries will last? Electricity meters tend to blink quite often, so not that much sleep..
Out of curiosity....what is your use case for this? [just thinking new ways to expand my system]
Ahh, thanks!
I have ack set to false (the last installed sensor version), so this rules out the search function, I assume!
Hi there!
Been struggling with my mailbox sensor radio coverage for a while (tried various radios, antenna modifications etc the normal route to insanity while having lots of fun).
Now wondering how the radio initialization routine works: if parentNodeId setting is AUTO (the default), does the node find the 'best' parent every time the node is reset/rebooted, or is it merely a one time process?
"Classic" way to rule out the power source + relay related issues is to replace the relay with a led.
Noise in power lines may stop the NRF module, but also Arduino can get messed up due to spikes in power supply.
You could try connecting all the ground pins of the Arduino together -- this helped me with one clone board.
I've noticed with some of the RGB nodes around the house an annoying flickering problem. It occurs when none of the R G B channels is driven at full brightness. This is especially disturbing when a lower light level is desired.
Tried to find out a reason for this. It was not related to the Arduino used, whether it being a Nano, Uno, official or not. Also not related to using gw.wait or delay in the main loop. Or adding resistors to the fet data pins.
Turns out it is related to the Arduino PWM not being very optimal. Tried to solve the problem by using a different approach, softPWM [e.g. https://github.com/Palatis/arduino-softpwm] but they conflicted with servo library (that uses various timers also, as soft pwms do).
Jeelabs brought a solution; tweaking the frequency of some timers. Just tested it, and seems that the flickering is totally gone AND still the servos AND the MySensor communication works. Very happy with the result.
This is the blog post describing the issue, the solution I used is in the comments http://jeelabs.org/wp-content/uploads/2011/11/8/fixing-the-arduinos-pwm/index.html.
So, flickering fixed by adding TCCR2A = _BV(COM2A1) | _BV(COM2B1) | _BV(WGM21) | _BV(WGM20) to the setup. Will need to update a few nodes now!
I think this is the way to go and learn:
http://forum.mysensors.org/topic/2597/combining-mysensors-examples
Very interesting module indeed. Not only decrease the profile but more importantly, it could be behind the wall(!). Have to place an order right away, thanks.
Maybe using increment operator causes your problem [https://www.arduino.cc/en/Reference/Increment]
Replacing pin++ with pin=pin+1 in your code should fix it.
It would be so useful to be able to measure the supply voltages with an oscilloscope. So far all my transmission problems have been related to the power supplies. Only after using a scope I fully realized that. No more freezing or poor function of the nodes.
Also, using a brand supply doesn't necessarily mean a clean signal. This (again) is an illustrative post about USB supplies, worth to take a look at:
http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple-is.html
@patrick-schaerer said:
It should work. The variable1 appears in vera after the sensor had requested var1. (But Im not completely shure about that ... )
Oh yeah, works as you suggested. Thanks!
First I didn't get it to work, but re-reading your answer solved it. One really needs to request the variable to make it appear in the controller (Vera, that is in this case).
Where did you buy the relay -- any documentation for that?
Looks like it has options for isolating the power source from the arduino power, see e.g. http://www.forward.com.au/pfod/HomeAutomation/OnOffAddRelay/index.html
(Can't see the markings really on the module to see what each pin refers to)
@patrick-schaerer said:
in the advanced tab all the way down at the bottom there are should be Variable1. Put a value in the field and save.
the next time your device requests the variable, the new value will be sent.
Thanks, though so, too.
So the next question is, is it possible to add variables to sensor types that don't have those to begin with? In my case I'd like to add few variables to window covers (S_COVER in http://www.mysensors.org/download/serial_api_15). Can't test now, but would this gw.present(CHILD_ID_OF_BLINDS, V_VAR1) work in adding this property to the blinds?
Eh, how do you define or set a value for, let's say, V_VAR1 in Vera?
*The *board that should be implemented is just arduino nano connections to NRF module. Very simple, yet, haven't gotten to do it.. anyone?
@samppa Yeah, one another, again. Personally, started with Pachube a few years ago. Gone, a long time ago.
It was, in the end and again, a power issue. I didn't mention that I included an RGB control to the node, so I'm feeding the whole nest with a 12v low grade supply. And the servo gets its power via Nano -- no external regulator for that.
All in all, caps in the power supply, radio, nano 5V and 3.3V, aaaallll works now 
BTW, now that you've had your blinds automated, have you been happy with them? All blinds MySensorised yet?
Oh well, it can be actually extremely complicated. But, basically, add a larger cap + a small one together. Larger one acts as a power reservoir and smaller one filters high voltage spikes. Basically like that, as I understand the situation. Large ones are in the range of micro Fs, smaller ones nano Fs.
Adding some cap to the arduino itself could help, i.e. between 5V and gnd. I've been able to get rid of some reboots by doing that. Power supplies can output rather noisy outputs.
Darn. When I connect the servo to the setup the Arduino loses it. Any idea how to tackle this? I've tried various capacitors all over the places
How do you use gw.wait(ms) with the library version 1.4? [http://www.mysensors.org/download/sensor_api_14]
Is it implemented at all in this version? Switching to 1.5 at this point (of miserable HW development) is not appealing at all
Just in case...make sure you use capacitors to stabilize the power to the nRF circuit , not the actual antenna connection.
[http://www.mysensors.org/download/sensor_api_15] 'Nodes that expects incoming messages, such as an actuator or repeating nodes, must check for new messages frequently'.
Any idea how often gw.process() should be called to not miss any messages?
Any update on this?
Asking since I also have a multisensor that locks up every now and then. Thinking of some way to reset the radio a couple of times per day.
Any suggestions how to implement this?
Exactly that is the reason. Yep.
You can still use it without problems for sensors.
You should probably draw a circuit diagram about your connections?
Excellent project report, Thanks!
It made soo easy to order the required parts
I suppose I should post my project, once it's been done, too... these things just tend to take their time (ofter years---to infinity).
@samppa Yep, works now, thanks!
The problem turned out to be the actual value I wanted to send. Need to figure out how to read MySensors based values in LUA...
Uh...oh...still.. do you need to initialize the graph or what? Still not getting this to work, sorry for being such a dummie :-E
Excellent, thanks! This is much needed.
For some reason, can't get this to work...LUA error.
I'm trying to send MySensors data to Plotly...
Anyway, does e.g. <username> mean that you write username, or <username> to the script? (Oh yeah, username referring to the actual username )
It could also be a better time now for the T-shirt campaign! Combine donating and getting a cool t-shirt..
@Konrad-Walsh said:
I am currently finalising a 5 in 1 sensor... just testing and so far its working fantastic
Hum-temp-motion-light-???
(might be a silly question..) How do you clean the eeprom? Is it not enought to write another sketch to the chip?
Upper picture: a repurposed old movement alarm unit, was on sale for 2€ several years ago on a local store.
Lower one: from dx.com (http://www.dx.com/p/wall-mount-pir-motion-detector-with-80db-alarm-siren-7-10-meter-110-degrees-15278), just swapped the internals. A bit small for my spider net constructions, though.
I found out quite marked difference between different setups! On the surface of the enclosure there's >3C warmer than few centimeters further from the enclosure, see pictures
First picture: temp, light level, door sensor, movement, patio PWM led lightning. DS sensor on the bottom of the enclosure
(temp, light level, movement)
Second: temp, light, movement
How often your sketch is sending? Just thinking that if it send continuously, things get piled up.
Not bad for that much of goodies.
Soldering iron, it's a bit tricky. The price range is from couple of bucks to ... alot. I got a used Weller, which is great. Genarally, I'd look for something that had at least a stand integrated and possibility to replace tips. Over the years I bought something like 5 cheapos before settled with used Weller...
This is a lot of fun diy home automation.
Out of curiosity, what was the total for all the fun stuff? Did you forget temp (+hum) sensors from the list..
@korttoma Hey, that looks good! Where did you get the enclosure?
@TroyF I've noticed that plugging/unplugging a sensor quite often changes the units between Metric and Imperial. Wonder why?
Hmmm... how can one override this statement to be METRIC?
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?TemperatureSensors.getTempCByIndex(CHILD_ID_TEMPERATURE_FIRST+i):TemperatureSensors.getTempFByIndex(CHILD_ID_TEMPERATURE_FIRST+i)) * 10.)) / 10.;
@soward Nice one. What sort of range you get? Just thinking the wires around the radio antenna. And myself having short range probably partly due to wire mess..
Hey! Any pictures of scene controller installations? I'm planning on DIY'ing some "aesthetically pleasing" ones
(Haven't used the particular component, yet) Did you connect the grounds of different power sources together?
Hi, on to-do-list here, too..
Please check this thread http://forum.mysensors.org/topic/115/implementing-multiple-sensors/27 'wannabee' shares a link to his RGB+RFID code!
Cell phone chargers in use here...
This is an interesting read, commenting also the output quality (spikes etc):
http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple-is.html
Might require some sort of advertising, at least I decided to get one (max size :-)) now that this topic was poked.
@egbertje Good Question It would be nice to learn from existing working sketches..
Out of curiosity...how did you solve this?
Thanks!
Got some extra energy to continue wondering why oh WHY... turned out that my own 1-wire library from 2010 conflicted with the official onewire library! Different directory name, but the same filename... Go figure!
Hope someone learns from this
Hi,
could anybody confirm that DallasTemperatureSensor is compiling under Arduino 1.0.5 using MySensors v1.3?
I'm getting this error, cannot understand how to overcome it:
In file included from C:\Program Files (x86)\Arduino\hardware\arduino\cores\arduino/Arduino.h:192,
from C:\Users\Documents\Arduino\libraries\DallasTemperature\DallasTemperature.cpp:9:
C:\Program Files (x86)\Arduino\hardware\arduino\cores\arduino/WString.h:116: error: declaration of C function 'StringSumHelper& operator+(const StringSumHelper&, const char*)' conflicts with
C:\Program Files (x86)\Arduino\hardware\arduino\cores\arduino/WString.h:115: error: previous declaration 'StringSumHelper& operator+(const StringSumHelper&, const String&)' here
C:\Program Files (x86)\Arduino\hardware\arduino\cores\arduino/WString.h:117: error: declaration of C function 'StringSumHelper& operator+(const StringSumHelper&, char)' conflicts with.....
**
and so on and so on!