I'm too suspicious maybe
-
I figured out a simple way to (I think?) expand the number of nodes on an ESP-NOW mesh network past the supposed maximum of 20 by simply not keeping peers around. Instead, I add a peer, send a message, remove the peer. You can still receive messages from peers when they aren't added, and even if you couldn't you get acks and you could delete the peer on the ack and just poll using a request/response cycle like HTTP. It's too simple of a hack for too much of a win. Simple enough that it makes me wonder why they designed it the way they did (to keep a peer list) instead of just doing it like the above and essentially keeping no list, with everything stateless. You don't need the peer list, you just need a list of mac addresses and you can keep that in a std::map or even a std::vector if you need it (you can avoid that even because the nodes can broadcast their macs and you can pick them out of the air) I don't know if I'm looking a gift horse in the mouth, or if I have the appropriate amount of skepticism about my approach. I wonder if it's a general issue when I code. Maybe I should just take my wins as I find them.
To err is human. Fortune favors the monsters.
-
I figured out a simple way to (I think?) expand the number of nodes on an ESP-NOW mesh network past the supposed maximum of 20 by simply not keeping peers around. Instead, I add a peer, send a message, remove the peer. You can still receive messages from peers when they aren't added, and even if you couldn't you get acks and you could delete the peer on the ack and just poll using a request/response cycle like HTTP. It's too simple of a hack for too much of a win. Simple enough that it makes me wonder why they designed it the way they did (to keep a peer list) instead of just doing it like the above and essentially keeping no list, with everything stateless. You don't need the peer list, you just need a list of mac addresses and you can keep that in a std::map or even a std::vector if you need it (you can avoid that even because the nodes can broadcast their macs and you can pick them out of the air) I don't know if I'm looking a gift horse in the mouth, or if I have the appropriate amount of skepticism about my approach. I wonder if it's a general issue when I code. Maybe I should just take my wins as I find them.
To err is human. Fortune favors the monsters.
Hmm. Issues with race conditions, perhaps? Note that the list of active MAC addresses is a state.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Hmm. Issues with race conditions, perhaps? Note that the list of active MAC addresses is a state.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Indeed the list of mac addresses is, but you don't really need that as you can snatch macs out of the air, at the expense of some time and battery. It's more just an optimization. :)
To err is human. Fortune favors the monsters.
-
I figured out a simple way to (I think?) expand the number of nodes on an ESP-NOW mesh network past the supposed maximum of 20 by simply not keeping peers around. Instead, I add a peer, send a message, remove the peer. You can still receive messages from peers when they aren't added, and even if you couldn't you get acks and you could delete the peer on the ack and just poll using a request/response cycle like HTTP. It's too simple of a hack for too much of a win. Simple enough that it makes me wonder why they designed it the way they did (to keep a peer list) instead of just doing it like the above and essentially keeping no list, with everything stateless. You don't need the peer list, you just need a list of mac addresses and you can keep that in a std::map or even a std::vector if you need it (you can avoid that even because the nodes can broadcast their macs and you can pick them out of the air) I don't know if I'm looking a gift horse in the mouth, or if I have the appropriate amount of skepticism about my approach. I wonder if it's a general issue when I code. Maybe I should just take my wins as I find them.
To err is human. Fortune favors the monsters.
You should not be that paranoid - trust yourself... If it works for you - under fair test load of course - then do not disturb yourself why other done it differently... Possible reasons to choose to manage a peer-list is performance around the management or maybe a race-condition over resources (the time it takes to acquire/release them)
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
-
I figured out a simple way to (I think?) expand the number of nodes on an ESP-NOW mesh network past the supposed maximum of 20 by simply not keeping peers around. Instead, I add a peer, send a message, remove the peer. You can still receive messages from peers when they aren't added, and even if you couldn't you get acks and you could delete the peer on the ack and just poll using a request/response cycle like HTTP. It's too simple of a hack for too much of a win. Simple enough that it makes me wonder why they designed it the way they did (to keep a peer list) instead of just doing it like the above and essentially keeping no list, with everything stateless. You don't need the peer list, you just need a list of mac addresses and you can keep that in a std::map or even a std::vector if you need it (you can avoid that even because the nodes can broadcast their macs and you can pick them out of the air) I don't know if I'm looking a gift horse in the mouth, or if I have the appropriate amount of skepticism about my approach. I wonder if it's a general issue when I code. Maybe I should just take my wins as I find them.
To err is human. Fortune favors the monsters.
Heh,
honey the codewitch wrote:
on an ESP-NOW mesh network
Gives [new meaning](https://www.google.com/search?q=hub-and-spoke+topology) to your [bicycle joke](https://www.codeproject.com/Lounge.aspx?msg=5905474#xx5905474xx) yesterday. :-D
-
I figured out a simple way to (I think?) expand the number of nodes on an ESP-NOW mesh network past the supposed maximum of 20 by simply not keeping peers around. Instead, I add a peer, send a message, remove the peer. You can still receive messages from peers when they aren't added, and even if you couldn't you get acks and you could delete the peer on the ack and just poll using a request/response cycle like HTTP. It's too simple of a hack for too much of a win. Simple enough that it makes me wonder why they designed it the way they did (to keep a peer list) instead of just doing it like the above and essentially keeping no list, with everything stateless. You don't need the peer list, you just need a list of mac addresses and you can keep that in a std::map or even a std::vector if you need it (you can avoid that even because the nodes can broadcast their macs and you can pick them out of the air) I don't know if I'm looking a gift horse in the mouth, or if I have the appropriate amount of skepticism about my approach. I wonder if it's a general issue when I code. Maybe I should just take my wins as I find them.
To err is human. Fortune favors the monsters.
Gun shy, PTSD..... get another? cat. :thumbsup:
