Best posts made by ricorico94

Thanks a lot for your clear explanations ! Very useful !
and.. bravo ! for all your work

Hi,
I finally got it working ! Thanks to 3 changes.. Two which I understand why, the other, well, not really..
Here's what I did or let's say, my findings..(well, I did much more than that, multiplying tests during several hours.. ).

1. I had thought that since S_INFO was displayed in Domoticz, everything was OK in domoticz. Actually not, and on top of presenting this Child, it seems you need to send whatever value to Domoticz as V_TEXT to initiate that variable. I had read some allusions to that fact (in message from dbemowsk for example) without understanding that it had to be done not for the S_INFO but also for each variable (V_TEXT , V_VAR1,.. any to be used). In sketch I showed I was sending that command for V_VAR1, but when I was trying similar skecth for V_TEXT , I was still ending only to V_VAR1. Once I tried to send the message to V_TEXT, I could see a value V_TEXT appearing in Domoticz under the S_Info line.
2. As per my previous post, I was not seeing any READ statement in serial monitor after the initial setup phase. Here, I tried to add a "wait" command after the request, instead of looping immediately as per the sketch of Pulse Water sensor. So my loop is now:

if (!pcReceived) {
      request(CHILD_ID_SLEEP_S, V_TEXT);
      Serial.print("Requested time sleep from gw TEXT");
      wait(5000,2,V_TEXT); // wait for 5s or until a message of type V_TEXT is received
}

and now, I can see READ messages and also receive and handle them !
I don't know why I must add this wait statement whereas the Pulse Water Meter sketch can work without it. Maybe linked to hardware used (I did not try to upload that sketch to my sensor to see if it would work). I also removed the "return" command which was present in Pulse Water sketch and which was preventing the rest of the loop() to be executed.

1. Instead of trying to use V_VAR1 as per the Water Pulse Meter sketch, I use V_TEXT everywhere. In fact, I found a unique, old (in 2015) and very short comment on a forum (I can't remember if it's here on another one.. I searched so many times..) that V_VARx can not be setup or read by Domoticz and they can only be modified by a sensor and read by that sensor or another sensor to store information on the controller side. So, indeed, that works for the pulse water meter, but not for my need since I need interactions with the controller.

So now it works. Learning curve was painful, but I think I understand the mechanism.

If one of the admins of Mysensor reads my post, I could suggest the following:

• in the Controller webpage, instead of stating Y* and "* limited functionality" for V_VAR1..5 variables, you could add a different comment Y*** "can be used for storing values on controller side, but can not be modified/read by Domoticz once it has been initialized with "send" command" and for V_TEXT : Y* "**** only variable which can be used for exchanging data between Domoticz and sensors in both ways and need an initial initialisation by sensor node by send command"
• in Pulse Water Meter sketch, since it is often referred to as an example, you could add a few comments on why it is using V_VAR1 and not V_TEXT and why V_VAR1 can not be used for exchanging info with Domoticz controller. Also, I would add a comment in the !pcreceived loop proposing to add a "wait" command in case it does not work that way.

If you plan to write a tutorial on this topic, I can propose my help.

Thanks a lot to the persons who tried to help me.

br,
ricorico94

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

Hi,
This seems a great job, but despite I had a look at many posts (yes, many out of the dozens of pages.. ), I still can't figure out some questions..

• Beyond the obvious advantage of saving an arduino (and power supply, space..), is there an advantage for having the gateway hosted by the raspberry PI hosting my Domoticz ? (like more CPU available for handling communications or for signing ? or on the opposite more risks to overload the PI CPU -despite only a couple persons have complained about high CPU load))
• the default setup is Ethernet. What are the pros and cons of ethernet vs serial setup ? (speed? reliability ? possibility to move to other gateway?..)
• Is signing now implemented in this setup ? I didn't see it explicitely described, but some posts seem related to signing.
• if I want to use an external antenna and the high power NRF24, should I use an aother power source than raspberry PI ? (or maybe sharing the same USB charger, but diverting the power in parallel of the PI ?)
• is there a tutorial somewhere detailing how to uninstall and migrate to an external gateway ? During such migration, would I need to "touch" again my sensors and would I lose history logs of these sensors in Domoticz ?

Sorry for all these questions..

br,
Ricorico94

Re: Selecting a Gateway

Hi,

There's something I did not understand in how a Mysensors network should be organised : how can we use various frequencies depending on sensors ?

For instance, I built my gateway by installing a NRF24 on my raspberry PI (already used for Domoticz) and I have several sensors using also NRF24.
Now, I'd like to add LoRa radio to handle some sensors which are a bit too far: should I create a second gateway (ethernet gateway for instance on standalone arduino) with the Lora radio, and this second gateway would also be integrated in Domoticz ?
Or should I create a new sensor with repeater capabilities, attached to my current NRF24 gateway, meaning the new repeater sensor should have both NRF24 and Lora modules ?

br,
ricorico94

Hi,
I found the cause of the error..
Since 2.3.0, we shouldn't write anymore:

#define MY_ESP8266_SSID "MySSID"
#define MY_ESP8266_PASSWORD "MyVerySecretPassword"

but:

#define MY_WIFI_SSID "MySSID"
#define MY_WIFI_PASSWORD "MyVerySecretPassword"

I found because I discovered than compiling was OK with 2.2.0 and not anymore with 2.3.0 (even without the MyNetDebug library) and I looked at the example in the 2.3.0 library..
I had been misleaded by the fact than in release description, it was stated that 2.3 is backward compatible and that network had not to be modified.. So I had thought that no change was required in the sketch..

I could test the library MyNetDebug and it seems working: the only thing is that it seems slow. Letters show up one after the other fairly slowly (much more slowly than if Serial Monitor used alone). I hope it's not disturbing radio communication..
But it's great to be able to catch debug messages without plugging the ESP8266 in a computer ! I'll have to investigate if the debug status can be switched on/off by a remote command to the ESP8266 gateway to avoid overloading the device if not necessary.

Thanks again for your efforts!

Thank you for this explanation. So I guess in my case, I have the gtw as server since I had to fil in Domoticz the IP address of the gtw (even though it was 127.0.. as local IP).
Is there any difference of behavior between the 2 settings ? Like if the Mysensor gtw is in server mode, it means that multiple controllers could connect to it and receive the sensors flux ?
I tried to find some documentation on that but no success so far. It's more for my own curiosity at this stage.

Thanks to another arduino forum, I found what was wrong.. probably indeed a stability of power due to step-up converter. In that forum, they were explaining that receiving is more sensitive to power noise than sending data and that in such case, it's good to add a 100uF capacitor on 3.3V and GRD of radio module. I tried 100uF and it worked.. I then tried with 47uF and it's still working. (I had tried with 0.47uF and it was not working at all)

In the "Connect Radio" guidelines, of Mysensors, it is stated that a capacitor of 0,47-47uF is improving reliability but that "the exact size usually doesn't matter" which was misleading in my case.
Could I suggest to rephrase that sentence into "the exact size usually doesn't matter, but you can try 47uF if 0.47uF still doesn't work, especially if sending data works well and not receiving data." ?

Edit for Erratum: please read 4.7-47uF instead of 0,47uF-47uF. Tests I had made were with 4.7uF as well, not 0.47uF
br,
Ricorico94

Thank you for the clarification !