General Discussion

@sundberg84 Got it all to work after using a new Atmel328 chip on a extra Arduino Uno board I had. I'm guessing the clone board, from china, I was trying to use has some kind of issue with eeprom or some other issue. Couldn't get it to responded to on or off signal or couldn't get the radio strength issue worked out either. Again Thank you so much for your help!

@ahmedadelhosni Yes - sorry, didnt read carefull enough.

I loved Michael Ossmann's SDR series, so this is a great find. Thanks for sharing!

Just found out that influxdata, is now making builds for armhf platform, from version 0.11.. So no need to compile stuff yourself for that part.. News are on their blog here https://influxdata.com/blog/announcing-influxdb-0-11-ga-kapacitor-telegraf/ And install instructions for ubuntu / debian is here https://docs.influxdata.com/influxdb/v0.9/introduction/installation/#ubuntu-debian

No, sensorId is also a byte (UINT8). https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/core/MyMessage.h#L313

@hek Pretty familiar with NTP/NTPD, but I'm doubtful that I can get a response time in milliseconds for activating the program. It will probably take a second or two. That's ok to begin some sort of flashing sequence by clicking a single button, but the colorpicker sends messages nonstop while moving around the wheel. I've seen those messages get queued and take many seconds to catch up after color selection has stopped. As quick as it is, it's just not quick enough! Then there is the precision. I wonder how well 13 devices can be synchronized on time? Milliseconds in difference will cause patterns to break, of course.

I'm studding the possibility of making the speech recognition with a raspberry pi zero and google stt api! Then I would publish a MQTT string to control my MySensors with OpenHab. The main problem of this approach is the delay time between the request and the action, because the audio must be translated by google and return to analises.

this is my node to node program: // Enable debug prints #define MY_DEBUG #define SWITCH_PIN 2 // Enable and select radio type attached #define MY_RADIO_NRF24 //#define MY_RADIO_RFM69 boolean state=false; #include <SPI.h> #include <MySensor.h> #define MY_NODE_ID 10 #define CHILD_ID_SWITCH 1 MyMessage switchMsg(CHILD_ID_SWITCH, V_LIGHT); void setup() { pinMode(SWITCH_PIN,INPUT_PULLUP); } void loop() { if(digitalRead(SWITCH_PIN)==LOW) { delay(100); if(digitalRead(SWITCH_PIN)==HIGH); { state=!state; if(state) { send(switchMsg.setDestination(2).set(49)); } else { send(switchMsg.setDestination(2).set(0)); } } } } destination node id is 2 destination of type light variable

Hi! Find parent means the node is trying to find its way to the gateway - and if this repeats it cant. Its either a range issue or a power issue. You can start by checking the gateway serial log and see if there is any info. Also, have you added a capacitor on the radios? This is very important since the radio is sensitive to power spikes. It this doesnt work start with changing the power source and check your wirings / ground connection on the node. Also you can try to move the node closer to the gateway - if this works and you have some distance between node and gateway you should consider a repeater.

Use a sensor such as this. http://www.ebay.co.uk/itm/MPX5700DP-Differential-Air-Pressure-Sensor-Freescale-Arduino-MPX5700D-UK-Stock-/121626002591 There are heaps of similar sensors for measuring pressure ( or lack of )

Thank You.

In the MySensors protocol, messageType is also called command (for historical reasons I guess?). So c made sense, at least when the debug output was added to the code. There is a link available in the description in the debug faq to the code where a comment saying "The command field (message-type) defines the overall properties of a message" is available.

I finally got things working, I think the main problem turned out to be some bad dupont jumpers, I ended up just swapping out all of them and the gateway started working right away, pretty cool stuff.. Looking forward to adding more sensors and other things, just waiting for more stuff to come in the mail.. I decided to try my Uno for the node instead of the Nano so I'm hoping the Nano works as well as the Uno did for my next sensor... I have attached a couple screen shots of how the serial gateway should respond with and without an operating node.. [image: 1458177778475-serial-gateway-response.png] [image: 1458177738278-serial-gateway-dht11-response.png] Thanks!

@Yveaux I'm fortunate enough that my emloyee pays the entrance fee. Members of nljug get a discounts though.

You ask the @Global-Moderators I think.

@trollkarlen could you describe which problem you're trying to solve? There might be other solution than using ack.

@jeylites It should have it's own ID. ID = 0 is reserved for the gateway. There can be only 1 gateway for a specific frequency. If a controller allows several hardware to connect, you can have more then 1 gateway, but tgese should each have their own frequency.

@Dominic-Bonneau Hi! Most examples on the mysensors build pages use components suitable for 5 V which is not optimal for a battery driven device. The most common PIR component can be modified to use 3.3 V though. There are lots of advice for building battery driven sensors in the forum and one page on the mysensors web dedicated to this. Many DIY openhardware build PCBs that specialize in battery power can be found on the openhardware site linked in the forum. But I suggest you follow @mfalkvidd 's advice and don't go for too much or too hard in your first build. Just get your first simple sensor together, and take it from there.

In some countries there are limitations :) That may be a reason. I tried to document it a little bit in the dev branch: https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyConfig.h