@mfalkvidd said in Dynamic change of variable name:

int myarray[5] would have positions 0 thorugh 4. Position 5 would be outside the array. In the code above, position 0 is never used.

So either make the array 1 element larger than actually needed (with position 0 unused), or let i start at 0:

In fact, I interpreted it more like @skywatch
Notice the <=

 int value[5];
 for (i=1; i<=5; i++){
   value[i] = debouncer[i].read();
 }

I just made something like this for indexing sensors in a node, where idx 0 was the node itself, and thus already filled before the loop.

Voilá.
And it maintains a live inventory of clients.
Some points are so difficult to achieve. But I was looking at message identification as a response to the sequence switch problem.

@rozpruwacz said in Build retry funtionality into the mysensors library:

But MQTT broker is not running on the 1kB ram mcu

I'm not saying to make a mqtt broker run on an arduino. Just picking the process logic as a guideline.
MQTT is not a protocol made for raspberries, it's only that often run on them.

@mfalkvidd said in Build retry funtionality into the mysensors library:

How do you handle if the same actuator is changed multiple times before the earlier changes have been reliably delivered?

How MQTT qos 1 does? I think it should be similar to it.

Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.

In my attempts to become a better C++ (Arduino) developer, so I can make those advanced nodes I'm thinking on, I often dismantle and see inside of big avr projects.
In case of MyS, I can't understand how, in an archiectural point of view, can work.

Let me explain: I created a new project in Platformio for ESP8266. Then I took the bare minimum from MyS lib, to be able to debug send a message, and stripped all other content. Even removing the ability for hook setup and loop, removing MyHwHAL and replacing with normal functions.
So it has a main.ino with setup and loop that calls mysensorscore setup and loop.
Other files, with content stripped that still remain are main mysensors.h, myconfig.h and hal for 8266. Nothing more. In hal I only leave debug related content, initilizing serial in hwInit() (called in core without conditional inclusion).

As is, it never compiles. It throws error for two reasons. Core.cpp doesn't see content in hwHal (hwInit, DEBUG macros), and files in hwHal doesn't see the serial macros defined in config.
I tried 4 and 5 times, with fresh projects and I can't make it work. I even thought it was something with the linux/platformio compiler, so switched to VS+vsmicro and then arduinoIDE without any success.

Yesterday I took all the content and incorporated "as is" in order of call in the Mysensors.h file, and it compiled. Then I took out all the files one by one to reveal those two avobe problems in cpps.
Then I took another copy of the bare project and eliminated the mysensors-mysensorscore level. I moved the coding from core to mys.h and it worked well and solved 1 problem. But Still have to reference myconfig in myhwesp8266 for it to see the debug macros.

I'm sure it's my ignorance, so perhaps someone more expert in avr-c++ can explain me how mys library ignores those problems?

@kimot said in My experiences with MySensors:

But you can use one AP for your computers and TV and etc. and other for your sensors.
AP hw is cheap....

Or you can get a VLAN compliant Wifi access point, do the things as should be and implement a separate VLAN for your IoT devices and services.
If you buy, for example an ubiquity AP, you can configure as many SSIDs as you need, each one on it's own VLAN, and even you can specify that the IoT network should only be N-type increasing the range.
By using only one access point you also reduce radio interferences. Radio appliances are not perfectly made and cheap ones tend to be noisy and get worse with the age.

I'm not particulary an ubiquity fan, in fact I only have the ap_ac_pro one, but I'm so satisfied with it that I would recommend their switch+router solution. The web management is awesome.
For my adventures I prefer having an ordinary 10gb d-link switch and a custom opnsense router.

Range of the ap_ac_pro inside a 20m radius house with 25cms stone walls is just in the limit. Just one in the very center. A long range unit would cover anything, but mine is freaking fast.

@tbowmo Thanks Thomas, I was trying to make an ENC28J60 module work with RF24 then RFM69, and I was getting crazy at it. Finally the module was a failed one. I'm so embarrased, as I was convinced I first tested the module on arrival, and I missed the point.
I've already ordered a W5100, but it may take weeks.

I've been fiddling with the radio alone (serial gw), softspi and changing pins, and I think there's something else here.
Well those are my findings:

With this base definition and without the module wired:

#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER
#define MY_IS_RFM69HW

#define MY_DEBUG_VERBOSE_RFM69

#define MY_GATEWAY_ENC28J60

It works as expected.

0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1
4 TSM:INIT
5 TSF:WUR:MS=0
6 RFM69:INIT
7 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0
11 RFM69:PTX:LEVEL=5 dBm
13 TSM:INIT:TSP OK
15 TSM:INIT:GW MODE
16 TSM:READY:ID=0,PAR=0,DIS=0
19 MCO:REG:NOT NEEDED
72 GWT:TIN:IP=192.168.50.211
1075 MCO:BGN:STP
1077 MCO:BGN:INIT OK,TSP=1
1081 TSM:READY:NWD REQ
1083 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
1088 RFM69:CSMA:RSSI=-98
1090 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

If I try to change CS pin to any other with #define MY_RFM69_CS_PIN 4 for example, I always get:

0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1
4 TSM:INIT
5 TSF:WUR:MS=0
6 RFM69:INIT
7 RFM69:INIT:PIN,CS=4,IQP=2,IQN=0
11 RFM69:PTX:LEVEL=5 dBm
13 TSM:INIT:TSP OK
14 TSM:INIT:GW MODE
16 TSM:READY:ID=0,PAR=0,DIS=0
19 MCO:REG:NOT NEEDED

So I revert the CS pin change and activate softspi and change irq #define MY_SOFTSPI and #define MY_RFM69_IRQ_PIN 3 And it works well:

0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1
4 TSM:INIT
5 TSF:WUR:MS=0
6 RFM69:INIT
7 RFM69:INIT:PIN,CS=10,IQP=3,IQN=1
11 RFM69:PTX:LEVEL=5 dBm
13 TSM:INIT:TSP OK
15 TSM:INIT:GW MODE
16 TSM:READY:ID=0,PAR=0,DIS=0
19 MCO:REG:NOT NEEDED
72 GWT:TIN:IP=192.168.50.211
1075 MCO:BGN:STP
1077 MCO:BGN:INIT OK,TSP=1
1079 TSM:READY:NWD REQ
1081 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
1086 RFM69:CSMA:RSSI=-98
1091 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

Then I add the eth module and I get:

0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1
4 TSM:INIT
5 TSF:WUR:MS=0
6 RFM69:INIT
7 RFM69:INIT:PIN,CS=10,IQP=3,IQN=1
11 RFM69:PTX:LEVEL=5 dBm
13 TSM:INIT:TSP OK
15 TSM:INIT:GW MODE
16 TSM:READY:ID=0,PAR=0,DIS=0
19 MCO:REG:NOT NEEDED

And stays here forever.

Of course all those test are made using a double (5v+3v3) good power source, a level shifter... and changing the wires accordingly.

I have some questions:

• Its normal MY_RFM69_CS_PIN not having effect and breaking the radion connection?
  Without being able to change this, I don't know if it's spi interference.
• In the last test, it seems to halt when initialising the network. Doesn't it?
  Is there a way I can further know if the problem is with the eth module? I've tried it alone with the nano and it works.

I would thank guidance for debugging this.