to be clear the One wire bus is physically connected to D2
We're in agreement.
Unfortunately, I cannot get the sketch to compile / verify.
Perhaps @lburelli will chime in at some point.
There is something really strange.
Can you post a picture of your real device where you have marked to which physical pins you have connected your LEDs
And post your actual and complete sketch that uses the LEDs
best regards Stefan
I have to agree, it really is confusing. 
The reason behind all this chaos is that, for a lot of design reasons, what is written on the board as D2 does not match what the CPU thinks is "line 2" (aka "GPIO2") - in this case D2 is actually connected to GPIO5 (as per the pinout drawing).
So, if you want to drive the pin labelled D2 HIGH, the code has to, at some point, tell the CPU to raise bit 5 of some appropriate register - there must be a "renumbering" somewhere in the code.
Previous ESP32 cores handled this by leaving this map in the user sketch. They define D2 to the number 5, and the whole API acts on GPIO numbers - it's your responsibility to remember that #define ONE_WIRE_BUS 5 actually means D2. We wanted to improve that!
Legacy Arduino code - not ESP32-related, but Nano-related - even expect to call functions referring to pin D2 with the number 2, making the situation even murkier. Now you have numbers that refer to "Arduino pin Dxx" and numbers that refer to "GPIO line xx" that are impossible to tell apart. For the code, they are all numbers! 
What we did is, we converted the whole official Arduino-ESP32 API so that it would use Arduino pin numbers by default. That explains why digitalWrite(11, ...) acts on D11. That also allows any library or sketch using the same APIs to work immediately, with no modifications.
However, this unfortunately does not apply to libraries that directly access those pins via low-level registers, such as OneWire. When they use the same number in Arduino APIs and registers directly, such as here in OneWire::begin(), something will have to break.
To solve this problem, without having to ask library maintainers to patch all libraries, we will soon add a menu option that will allow the Nano to work in ESP32-compatible mode (where D2 is 5). This will restore functionality to all libraries, but break backwards compatibility with previous Nano sketches.
If someone has a better idea on how to fix this TheRightWay™, please come forward! 
Not a different way. Just try to inform new users at the most prominent place about what might help to make it work
Most prominent place is the last and therefore visible lines of the compiler-log.
Use boardnames where the boardname itself says what pin-numbering will be used
old arduino-nano-compatible or nodeMCU-compatible
ifdefs in the corefiles that will print to the compiler-log what is used and what might help to correct a compiler-error
best regards Stefan
1 Like
Hello everyone! Arduino ESP32 core 2.0.12 is out, and it adds a new menu option to use a library-compatible pin numbering scheme. Read all about it here and try it out!
Happy hacking! 
I know this was a year ago, but this comment just saved my night. I was losing my mind! Thank you!
2 Likes
I have spent a few hours tracking down this issue until I realized that for standard Arduino GPIO commands, Arduino numbering is used (such as pinMode() and digitalWrite()), but for one wire, still ESP32 numbers are needed. This breaks sketch compatibility between a nano Every and a nano ESP32 board.
Sadly, yes, but does not work with OneWire (v2.3.8)... True, I saw in the source code that the OneWire library uses direct register access instead of Arduino commands (like pinMode() etc.), that explains it at least.
There was the question how to solve that without breaking backwards compatibility?
My suggestion was to introduce an overloaded Constructor and begin() method of the OneWire class that takes an explicit "mode" code as second argument (or ONE_WIRE_MODE_NATIVE as default, but ONE_WIRE_MODE_ARDUINO as alternative). Depending on that argument, the number is either native to the platform, or will be mapped according to the Arduino scheme.
Hello @ingmarp!
There might be an easier solution to make the sketch compatible between Nanos. The trick is, make sure to use pin labels (e.g. D10) in the sketch, instead of simple numbers (like 10). If you then compile the Nano ESP32 sketch with by GPIO mode selected in the "Pin Mapping" menu, the same sketch should work in both boards, including the OneWire library.
If this does not work, please post your sketch and the core you are currently using.