Over two years have passed and I have started another try, with no more success than last time. There seems to be a Sparkfun library that very close to the one in the SecurityPersonalizer script, but doesn't run with the ESP32 at all, despite being marked so in PlatformIO. ow are these related and could there be other version that are better adjusted to the ESP32?
Has anyone ever made any progress on this in the past 2 years?

Found some time again. Could not solve the issue with disabling Wifi. Further, I got a bunch of ESP32, which should have a dedicated core for Wifi, and I still cannot get it working.

I have recorded the traces with a logic analyzer, compared to a Pro Mini and after the initial pulse, the timings seem to be vastly different. I only have sigrok pulseview available, and I find it hard do do any further analysis with it (including exporting it into any sensible format to import it to e.g. MATLAB ...)
Here are the Sigrok session files for a Wemos LOLIN32 and an Arduino Pro Mini, if anybody is interested.

I have also scoped the waveforms, they are pretty fine in both cases. The Pro Mini is on the same breadboard and powered by the LOLIN, they both have the same code fresh from Github (only change is ATSHA pin to pin 4) and the only thing I did between the two recordings is plug a jumper cable from pin 4 of one device to pin 4 for the other.

@dbemowsk It is not if you know and keep it attached. It is just terrible design in general, that would never be approved.

@dbemowsk I have not flashed it. You can get one with a connector, but keep in mind that the exposed connector in the base is probably dangerous.

@dbemowsk There are a lot of reviews around. Some units are fine, some have exposed metal parts connected to the powerplug (which can put mains phase on them at least in countries with unkeyed outlets, and some have the wand attached with a connector and habe mains phase on a connector pin that can be exposed

Apart from that, I am quite happy with mine. There is even custom firmware.

@dbemowsk That is actually what I meant, and what my warning was about. Some of these are deathtraps.

I would suggest to get solder paste and a hot air gun (I have one of those 40$ thingys, which works fine after checking that it is not one of the units that have mains potential on the metal parts :D).
Maybe also stencils. I just had one made at jlcpcb for 7$ + shipping, it is still in the mail, though.
If you only have two left hands and no serious condition, that should make soldering them quite trivial.

@gohan Can't, as I said I don't know from which of multiple shipments it came. Only noticed when I used it.

A thought I had recently: Those moisture pitchforks are usually HASL coated. Do I really want that in the soil of a plant I probably want to eat? Any thoughts anyone?

It indeed does. Thanks for the overview, looks different from the HopeRF website (seems to actually be the CW version). Certainly have not ordered that.

As far as I understand, I am not allowed to user 20dBm in Germany anyway, so 13dBm isn't that bad. Will try to run it later. There are a few nodes close to the gateway for which it will be enough.

As my MySensors world is growing, I ordered a few more RFM69HW modules from China. When I set up a new node yesterday, I had connection issues and a closer look revealed that the modules have less components than usual:

In comparison, this is a usual one:

Did that ever happen to anyone? Any idea what is missing there? Anyway, keep an eye on your shipments, for me it is too late to go for a refund, as I got a few pairs from different suppliers and do not know who shipped these.

Ok, my setup is running now (including personalization, encryption, and soft signing) and stuff is published to mqtt.
Thanks everyone for the help! I really like this community.

Now I need to resolve the issue with the OpenHAB binding but that's no topic for here.

As a * that resolves to above mentioned note directly in the table:
D1* | DIO0 | Gray
...
Below: * Different from code default and examples

As I said, one doesn't necessarily expect that defaults have to changed an ESP-specific example sketch.

@mfalkvidd Maybe a "* Different from code default and examples"?
You do not really expect that you have to change defaults when you get a wiring guide from the official site associated with the code, especially when running an example that is explicitly for the platform (the ESP8266 gateway sketch).

In hindsight, this was probably stupid, but I didn't even look at the defines below the table, because I thought I was running a working example specifically for the ESP8266 and only needed to find the right pins.

@mfalkvidd said in Cannot get RFM69HW connection between ESP8266GW and Pro Mini Sensor:

When I verified the rfm69 wiring and wrote the instructions, I decided to not use the default IRQ pin

Maybe note this in the instructions? This cost me 1 year (in which I did not touch the stuff after i didn't work immediately) and a weekend of checking wireing and so on (because with a missing IRQ on the gateway, it looks like nothing is working, while the issue is quite easy to find on a node).

Ok, PR is filed, I also fixed it for the RFM95, which had the same issue.

I have already created an issue, but you are right, I could do a pull request.

Ok, I see ...

#define DEFAULT_RFM69_IRQ_NUM                   digitalPinToInterrupt(DEFAULT_RFM69_IRQ_PIN)

So it indeed has to be set separately. I don' really see why this isn't set to

#define DEFAULT_RFM69_IRQ_NUM                   digitalPinToInterrupt(MY_RFM69_IRQ_PIN)

MyConfig.h is included before, so tha should work.

@elcaron said in Cannot get RFM69HW connection between ESP8266GW and Pro Mini Sensor:

MY_RFM69_IRQ_PIN

So both MUST be defined? I thought NUM was prety much an override, since it can be programmatically derived from the pin. Undfortunaely, it does not seem to be documented.

Quick update: Setting #define MY_RFM69_IRQ_NUM 5 (D1=GPIO5, the ESP has interrupts on (almost) all GPIO pins and the interrupt number equals the pin number) - that is, skipping the digitalPinToInterrupt() function - seems to work. That should pretty much localize the problem.

Ok, I have finally identified the issue.

I did some more testing with the switched roles, ESP8266 as (light) sensor, Pro Mini as serial gateway, hardcoded MY_NODE_ID. According to the logs, the ESP sends the parent quest, the Pro Mini answers, but never gets an ACK. The ESP does not report any answer. Ergo, the interrupt doesn't work.
So I scoped it, electrically, everything was fine. I tried D2 instead of D1, no change. Then I remembered that the default in the code was GPIO2, which is D4. This is a really stupid choice, because if you connect it like that, the ESP will not boot. GPIO2 needs to be pulled up during boot, and DIO0 from the RFM69 pulls it down. What works though is to first boot, then connect the cable.
Lo and behold - everything suddenly worked. So either I am the idiot and #define MY_RFM69_IRQ_PIN D1 is not how you set the interrupt, or whoever thought that it was clever to default the interrupt to a pin that prevents booting also decided to ignore the configured value ...

I'll dig into the code to find out, but of course wouldn't mind if anybody who knows the code better would be faster :)
Will file an issue or pull request if I find something.