Development

@dbemowsk Thank you! This is what I was looking for. Especially the code in your thread.

Hello, you can probably get some inspiration from this project made by students ;) https://youtu.be/tPrO4Gg0kNM

You're very welcome @kisse66 I hope others find this useful too!

@gohan Lol you're absolutely right! I should have thought of that earlier - thanks!

@donnacarter0103 The third way to reset an Arduino is to use watchdog (Need to flash another bootloader as the default have disabled watchdog), enable watchdog, and remember to reset it often in your code, else it will reste the Arduino

Hi, Thanks a lot ! This is precisely what I hadn't understood when reading various websites about arduino language and C language. Now I understand the difference between the #define and the definition of variables. So thanks again for this pragmatic explanations. br, ricorico94

I am well aware of the facts that all these wonderful stuff is created by volunteers. If it was not clear: I really want to thank all of the people who made this possible. It is a great and remarkable project. That said: since I am at the very very ( did I mention very?) early stage of playing with the MySensors, I am not in the position to create, add or edit any content at this moment. But I hope since this all is new to me, that if I find something strange, or something that I cannot find, to mention it. It is not criticism, but a honest view of what a newbie like me faces when starting with the project. Perhaps in a later stage I will try to add/change for example the documentation. But that goal for now are a few yards too far away. So also,I really want to thank the people who are replying to, perhaps perceived as dumb questions', at this forum. That information really got me some further. To read the fields used in the serial protocol in the receive function of the node: serial field format: node id;child_sensor_id;command;ack;type;payload void receive(const MyMessage &message) { //child_sensor_id message.sensor; //command message.getCommand(); //ack message.isAck(); //type message.type; //payload message.getBool(); //in case of variable type boolean } Regarding using of Sonoff's: I've seen some video's on youtube. It is absolute an incredible featured device with the correct firmware on it. Perhaps in the future I will be using it, but for now I want to focus on the open structure of the mySensors. Next step is to try to connect a controller mechanism. Because of the fact I want to use only MQTT as transport protocol, mainly to keep things open, I thought of putting MyController and OpenHab together. Primary to use OpenHab as controller ( also my knowledge of this system is about zero), and use MyController only to be able to upload new firmware. After reading the suggested forum threads, I am scared this won't work because of the fact that when a node ask something to the controller, the node would get up to 2 answers. Only the answer of OpenHab should be used, but as far as I know right now there is no filter or selection option possible.

@BulldogLowell it is just not the way I expected to do it.

Make a route for irq with a couple of pads that you can bridge them to enable the irq to either d2 or d3 so that you can disable the irq feature in case you need those pins for something else.

@gohan said in nRF24 would not transmit when connected to Nano, but works fine with Mega: voltage regulators usually can not keep up LP2985 on Mega gives 150mA, which is at least in double excess of the highest nRF24 +LNA+PA can consume. It should do fine without the cap. On Nano it is not a voltage regulator. FTDI chip converts serial to USB. And for Nano I did use the caps 4, 10 and 20 uF - none helped. Honestly, I haven't noticed any effect of these caps so many on the forum talk about. If it works, it works, if not - bad luck. I can believe in a very rare case the extra charge of a 20uF cap could topple the scale, giving illusion that this is a solution. When I reduced from RF24_PA_MAX to RF24_PA_HIGH it started to work sometimes. When down to RF24_PA_LOW it works stable. However I transmit 7 bytes only, the payload can be up to 32 bytes. This will further increase power requirements and will further short 3V3 output. In order to save MySensors lib from ungrounded suspicions (which I had) and simply to act professionally we should admit that on Nano the 3V3 output should not be used. Otherwise the behavior is undefined. Even without PA. The spec for nRF24 says 14mA at transmission. The spec for FTDI says it 15mA typical, 24mA max. It is an unacceptable low margin for expecting stable communication.

For this special application I use MyController. In the controller the string is displayed correctly, but in the serial monitor of the node I only see this distorted version (But sending them by sketch works, so it's not a problem of the serial monitor in general). I will ask at the MyController forum, maybe the dev can help.

@fhenryco for me, the benefit of the A6 is that I have one on my desk :) @gohan I'm not fixed on using a MQTT gateway. Not after learning that a regular Ethernet Gateway can be used as a Client. Actually I would very much prefer using it as an Ethernet Gateway if I can. So far I have not managed to get MySensors to play ball. Even though I have an internet connection up and running and a port to connect to, I'm not seeing any incoming connections. Must dig deeper.

@gohan said in no controller, no gateway: you didn't put the "MY_PARENT_NO_ID 100" that I saw in the video: is it ok? yes this is normal, this def is not needed. just forgot to delete when recording a video two-way sending is done in the above application, this is also not in the video. you just asked about it earlier.

thank you for your answere @mfalkvidd

@Anticimex cool, thanks! In that case the relevant link is https://www.mysensors.org/apidocs-beta/group__RoutingNodeSettingGrpPub.html#ga45b4f1c868b8cb5d7396cdfb4939559c