N
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?