@oniric said in NRF24l01+, EEPROM and shared SPI = brick module ?:

if i wipe my eeprom with 0x0, it might be wrong cause at boot it will think I'm Node_0, my parent is Node_0...) ?

This might not be wrong, it is wrong to write zeros, causing the node acting as a GW: Node_0, no further transport over nRF-air required...)

@oniric Which clear EEPROM sketch did you use?
There are two of them, this is the reason I put the (!) behind the MySensors version. This one writes "FF" (meaning: we don't have an NodeID and first have to ask for that at boot time) the other one "00" (meaning: I'm Node_0, my parent is Node_0...).

You seem to have directly accessed the EEPROM; as you already have found out, there is only a specific area reserved to store from sketch side and some functionality provided to do it in a "save" way. So you will have to split your information on the card ID's and use the "MySensors"-way...

If the Node isn't working, I don't believe you bricked the nRF but the node will not boot or get correct communication info from EEPROM. So just use the MySensors (!) clear EEPROM sketch and reflash the Arduino...

On I_DEBUG: Just set the option in the sketch; the letter is used to identify the type of request at runtime ("payload"). "E" will just erase some basic info afaik, especially NodeID and ParentnodeID.

Hope this makes the picture more clear.

@inso
Thanks for the feedback, sorry for your ineffective messin around with mysensors. I completely agree to your conclusion using MQTT directly on more powerfull boards able to communicate directly via WiFi.

@inso said in Building a WiFi Gateway using ESP8266:

Seems working with ESPs is reluctantly seen here on the forum.?

I can only speak for myself but indeed, I absolutely dislike having (regular) WiFi devices integrated in my home automation. My personal concept is to use as much wires as possible (thus I really love the RS485 stuff here!) and use different RF technologies whereever possible - and connect the corresponding GW's using a USB plug!

So atm I exactly have 2 ESP8266-based devices integrated: One is a bridge for my MiLight stuff (avoid that type of devices, but in case if, use the sidoh-firmware!), one is a IR-Device to play around...

But everybody has to find his own way. Just my personal thoughts on that topic

Sorry, I'm not familiar with the ESP32; perhaps you have a look around for other more powerful platforms on MySensors, starting here: https://forum.mysensors.org/topic/6961/nrf5-action.

The problem within MySensors afaik is a double one:

• First you have to make sure the GW get's the message. Eg. in FHEM, this is a problem, as one node basically is only identified by it's NodeID. As already described, internally there's a distinction between the GW part and the Sensor (node-) part. And the Sensor part gets unavoidably (at least afaik) the NodeID 0 - so for the controller all the Children are located at the same Node.
  As the controller notes just one IO (aka GW) per Node, Messages to the "unified" Node 0 will always be routed to the same GW. If this is different when using MQTT as transport layer and not serial or IP communication? (could be, as more clients can subscribe to a "Node 0"-topic...)

• Second thing then is to make sure to not mess up messages intented for different GW's when doing some "broadcasting" by MQTT. Means: use different ChildID's for all the GW's sensors and actuators.

Best success!

@inso said in Building a WiFi Gateway using ESP8266:

Setting a node Id is ignored, ID is 0 and can´t be changed, so it is recognized as a gateway at domoticz.

Imo using ESP8266-based devices all as GW's with locally attached switches (or other actively addressed children) conflicts also with other controller types (e.g. FHEM also doesn't like that on more than one GW).
If you want to use that type of hardware, better use a different firmware like ESPEasy or Tasmota. The later seems to be a good fit for any installation using a MQTT-Server. (I personally don't like that kind of setup, wifi shouldn't be used for HA purposes imo).

Just my2ct.

Seems I'm running out of ideas. If you are sure to have flashed succcessfully the new BL and won't get any sync afterwards to upload any sketch built using that board def, most likely you shoud open an issue in github wrt that.

(I myself went the other way round and modified the MYSENSORS modules in FHEM to make use of a second Gateway for flash purposes only - this GW with the standard channel (etc.) settings... Testing is ongoing, but seems to work)

@danielef said in Recompiling for different channels:

I'm using a micro 3.3V 8MHz and MYSBootloader DEV branch.

Sorry, didn't realize this when first reading through it.
So are you using a ATmega328p as mcu (pro mini) or in fact a pro micro (ATMega32U..)?
The BL project seems to be limited to the first mcu type (L8 of MYSBootloader.c). Porting to the other mcu most likely is much more work, as this should support upload through USB also.

@danielef OK, seems your changes have been ok.
I didn't check any dependencies, just saw tekka's remark in Line 4 of MYSBootloader.c.

Did you add anything in your boards definitions in Arduino IDE for the new BL? Or tried to use the BL definitions from boards.txt included already in the repo?

@danielef Didn't find any option to change CLK and imo this should not be necessary (hope all the three versions are build and you have just to choose the right one for your board).
As the file states, it was build using the 2.2 MySensors version. Perhaps you have to downgrade first (and then go back after BL is build successfully).