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.
@gohan Oh, I missed that bit. It wasn't essential until now, though, as it seems, since with the ESP gateway, there wasn't even an answer to the parent request.
Then I'll try and connect it to my openhab.
For further testing, I have set up two Pro Mini now. With these, I get some communication.
SerialGateway:
0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RRNGA---,VER=2.2.0
0;255;3;0;9;4 TSM:INIT
0;255;3;0;9;6 TSF:WUR:MS=0
0;255;3;0;9;10 TSM:INIT:TSP OK
0;255;3;0;9;14 TSM:INIT:GW MODE
0;255;3;0;9;16 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;22 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.2.0
0;255;3;0;9;28 MCO:BGN:STP
0;255;3;0;9;34 MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;3753 TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;3760 TSF:MSG:BC
0;255;3;0;9;3764 TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;3768 TSF:CKU:OK,FCTRL
0;255;3;0;9;3770 TSF:MSG:GWL OK
0;255;3;0;9;5695 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;6993 TSF:MSG:READ,255-255-0,s=192,c=3,t=3,pt=0,l=0,sg=0:
255;192;3;0;3;
0;255;3;0;9;9218 TSF:MSG:READ,255-255-0,s=161,c=3,t=3,pt=0,l=0,sg=0:
255;161;3;0;3;
0;255;3;0;9;11239 TSF:MSG:READ,255-255-0,s=79,c=3,t=3,pt=0,l=0,sg=0:
255;79;3;0;3;
0;255;3;0;9;13258 TSF:MSG:READ,255-255-0,s=49,c=3,t=3,pt=0,l=0,sg=0:
255;49;3;0;3;
Client:
16 MCO:BGN:INIT NODE,CP=RRNNA---,VER=2.2.0
26 TSM:INIT
28 TSF:WUR:MS=0
30 TSM:INIT:TSP OK
32 TSM:FPAR
1253 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1374 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
1380 TSF:MSG:FPAR OK,ID=0,D=1
1576 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
1779 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
3262 TSM:FPAR:OK
3262 TSM:ID
3264 TSM:ID:REQ
3274 TSF:MSG:SEND,255-255-0-0,s=192,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
5281 TSM:ID
5281 TSM:ID:REQ
5494 TSF:MSG:SEND,255-255-0-0,s=161,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
7503 TSM:ID
7503 TSM:ID:REQ
7514 TSF:MSG:SEND,255-255-0-0,s=79,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
9521 TSM:ID
9521 TSM:ID:REQ
9531 TSF:MSG:SEND,255-255-0-0,s=49,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
11538 !TSM:ID:FAIL
11540 TSM:FAIL:CNT=1
11542 TSM:FAIL:DIS
11544 TSF:TDI:TSL
It looks like they exchange packages about the parent, but the gateway never answers the id request for some reason.
I have quoted all lines regarding inclusion mode in the gateway sketch.
Is this because no controller is configured?
Interestingly, falshed as a node, the ESP8266 now also shows up on the gateway, with the same issues.
@anticimex Didn't expect that either, but better safe than sorry.
Ok, I have quoted that line for completeness. No change. I have also set MY_SIGNING_SIMPLE_PASSWD on both nodes to try to rule out issues with encryption:
These are my radio related precompiler statements right now:
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY (RFM69_868MHZ)
#if defined ARDUINO_ARCH_ESP8266
#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_CS_PIN D8
#elif defined ARDUINO_ARCH_AVR
#define MY_RFM69_IRQ_PIN 2
#define MY_RFM69_CS_PIN 10
#endif
#define MY_IS_RFM69HW
#define MY_RFM69_NETWORKID (83)
#define MY_SIGNING_SIMPLE_PASSWD "MyInsecurePassword"
//#define MY_RFM69_MAX_POWER_LEVEL_DBM (10u)
//#define MY_RFM69_ENABLE_ENCRYPTION
//#define MY_RFM69_SPI_SPEED (800000ul)
As far as I understand the documentation, I still have ATC enabled, as I did not set #define MY_RFM69_ATC_MODE_DISABLED
With MY_RFM69_MAX_POWER_LEVEL_DBM, i could go up to 14dBm for my local legislation, but I stayed a little below it, because I wasn't sure about the antenna gain on the gateway. Do you actually think 10mW compared to the legally possible 25mW are the problem, given that I test at 50cm and 5m line of sight?
Looking at the Radiohead sketch
rf69.setTxPower(14, true);
it rather looks like I used it with more power. But then also, I tested Radiohead between 50cm and the abovementioned 20m+wall+ceiling, while ich tested MySensors with 10dB at 50cm and 5m LoS
In the last test , they where 5m apart. With radiohead, they work both 20cm away and 20m away with one concrete wall and one ceiling.
Seems like I have to decide soon if it is easier to dust off the logic analyser and find out what is going on, or to implement HMAC with Radiohead
Do you mean this with output power?:
@elcaron said in Cannot get RFM69 connection between ESP8266GW and Pro Mini Sensor:
#define MY_RFM69_MAX_POWER_LEVEL_DBM (10u)
I use exactly the same includes in both sketches, hence the precompiler if statement. Apart from that, there are of course the very different antennas, but with Radiohead, this test setup has a range and wall penetration that can at least rival my 2.4GHz Wifi (works through a concrete ceiling + wall). I have also moved the sensor a few meters away from the gateway now, no difference.
you have disabled encryption on both the node and the GW? If one of them has it enabled and the other not, they can't communicate.
As I said, I use exactly the same precompiler defines shown above in both sketches. I have tried it with both encryption activated and deactivated. I tested how encryption behaves using the Radiohead lib and understand that it has to match.
BTW, I am the guy from two weeks ago who had problems with the ATSHA, but I decided to first get the basic stuff sorted
Guess I have to dig out another Pro Mini to test if at least that communication works.
Hi, I build my first two test devices on breadboard a while ago, one Wemos D1 mini and one Arduino Pro Mini.
The D1 is flashed with the GatewayESP8266MWTTClient sketch. The Wifi and MQTT connecion works fine, and it seems to start listening:
59 MCO:BGN:INIT GW,CP=RRNGE---,VER=2.2.0
63 TSF:LRT:OK
64 TSM:INIT
65 TSF:WUR:MS=0
68 TSM:INIT:TSP OK
70 TSM:INIT:GW MODE
72 TSM:READY:ID=0,PAR=0,DIS=0
74 MCO:REG:NOT NEEDED
scandone
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 6
cnt
connected with DiscoveryOneIoT, channel 1
dhcp client start...
ip:10.165.20.87,mask:255.255.240.0,gw:10.165.16.1
578 GWT:TPC:CONNECTING...
580 GWT:TPC:IP=10.165.20.87
583 MCO:BGN:STP
5
5
15
15
584 MCO:BGN:INIT OK,TSP=1
588 GWT:TPC:IP=10.165.20.87
590 GWT:RMQ:MQTT RECONNECT
664 GWT:RMQ:MQTT CONNECTED
667 GWT:TPS:TOPIC=home-le/rfm69gateway/out/0/255/0/0/18,MSG SENT
pm open,type:2 0
The numbers after 583 are Serial.prints of D1, D8 and the respective MySensors defines, indicating that I actually configured the correct pins - the connection tutorial seems to list a wrong IRQ port, so I became very careful with this stuff. Or rather, the default port 2=GPIO2=D4 in the library is badly chosen, because it is a boot pin of the ESP and it didn't actually boot when I connected it.
The Pro Mini is flashed with the light sensor sketch (because it just reads an analog pin), and tries to connect but seems to fail. The GW does not report anything at the same time:
__ __ ____
| \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| | | | |_| |___| | __/ | | \__ \ _ | | \__ \
|_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/
|___/ 2.2.0
16 MCO:BGN:INIT NODE,CP=RRNNA---,VER=2.2.0
26 TSM:INIT
28 TSF:WUR:MS=0
30 TSM:INIT:TSP OK
32 TSM:FPAR
1253 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3262 !TSM:FPAR:NO REPLY
3264 TSM:FPAR
4483 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6492 !TSM:FPAR:NO REPLY
6494 TSM:FPAR
7712 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
9721 !TSM:FPAR:NO REPLY
9723 TSM:FPAR
10942 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
12951 !TSM:FPAR:FAIL
12953 TSM:FAIL:CNT=1
12955 TSM:FAIL:DIS
12957 TSF:TDI:TSL
I am using the following defines in both sketches before including MySensors.h:
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY (RFM69_868MHZ)
#if defined ARDUINO_ARCH_ESP8266
#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_CS_PIN D8
#elif defined ARDUINO_ARCH_AVR
#define MY_RFM69_IRQ_PIN 2
#define MY_RFM69_CS_PIN 10
#endif
#define MY_IS_RFM69HW
#define MY_RFM69_NETWORKID (83)
#define MY_RFM69_MAX_POWER_LEVEL_DBM (10u)
//#define MY_RFM69_ENABLE_ENCRYPTION
Without touching the hardware, I can a reliable connection when I flash the rf69_server/client examples of the RadioHead library, with RH_RF69 rf69(D8, D1); on the D1 and RH_RF69 rf69; on the Pro Mini, so on the hardware side, everything seems to be fine.
I did run the SecurityPersonalizer sketch on both devices, when I thought this would work with less issues, seting soft signing and a matching AES key, but as you can see above, I did not enable encryption. I am only mentioning this, because at least on the ESP the MySensors library seems to have issues with persistent configurations. The SecurityPersonalizer for example alwas tries to connect to my Wifi on the ESP.
I am pretty much out of ideas. Anyone?
Here are some picture, not sure how helpful they are:
Haven't managed to do more tests today. Was trying to get a simple sensor + Gateway2MQTT config running, but the gateway just didn't receive any messages, despite the fact that Radiohead can use my RFM69HW hardware with at least 2.4GHz Wifi range. But let's not highjack my own thread I'll start a new one next weekend when I'll also try to run the personalizer without Wifi.
@anticimex WDT resets are usually indicated on the console. They happend a lot after the 2.1.1 sketch, but I haven't seen them after.
I was more optimistic about the Wifi thing, before I tested a module that wasn't contaminated with an old MySensors config and didn't obviously try to connect.
Are you using interrupts in the driver? If not, maybe disable them? As soon as I find time, I will try with calling
WiFi.disconnect();
WiFi.mode(WIFI_OFF);
WiFi.forceSleepBegin();
At the beginning of the setup function.
That doesnt yield an immediate solution though, because we will need signing to work with Wifi. But it could give a hint.
Some more findings:
ESP8266 board code now fresh from Github. Again, I had similar issues with the ESP and the single wire interface of the DHT22. The ESP is a single core that runs wifi functions in the background. It just might not be up to the task of keeping these timings accurate.
I ordered an ESP32 module last week, that should have one core dedicated to the sketch. Until then, I will use soft signing on the gateway. If anyone would like something tests, I can try, though.
I'll try another D1 Mini tomorrow. I have already tried it before when it just failed with 2.1.1, but this time, I'll investigate further.
I think the ESP looses sync at some point. in 2.1.1 immediately, when I first tested with 2.2.0 between detection of ATSHA and key generation, now between wakeup acknowledgement and ATHSHA detection (serial and such)
Spoke too soon.
I tried to generate AES and HMAC keys, but I think it it cannot hold the connection reliably:
+------------------------------------------------------------------------------------+
| MySensors security personalizer |
+------------------------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| Configuration settings |
+------------------------------------------------------------------------------------+
| * ATSHA204A based personalization |
| * Will generate HMAC key using ATSHA204A |
+------------------------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| Hardware security peripherals |
+--------------+--------------+--------------+------------------------------+--------+
| Device | Status | Revision | Serial number | Locked |
+--------------+--------------+--------------+------------------------------+--------+
| ESP8266 | DETECTED | N/A | A6EE1400EF401800AA | N/A |
+--------------+--------------+--------------+------------------------------+--------+
| ATSHA204A | NOT DETECTED | N/A | N/A | N/A |
+--------------+--------------+--------------+------------------------------+--------+
+------------------------------------------------------------------------------------+
| Key generation |
+--------+--------+------------------------------------------------------------------+
| Key ID | Status | Key |
+--------+--------+------------------------------------------------------------------+
| HMAC | FAILED | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
+--------+--------+------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| Key copy section |
+------------------------------------------------------------------------------------+
#define MY_HMAC_KEY 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
+------------------------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| EEPROM |
+--------+--------+------------------------------------------------------------------+
| Key ID | Status | Key |
+--------+--------+------------------------------------------------------------------+
| HMAC | RESET | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
| AES | RESET | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
| SERIAL | N/A | Device unique serial, not stored in EEPROM |
+--------+--------+------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| This nodes whitelist entry on other nodes |
+------------------------------------------------------------------------------------+
{.nodeId = <ID of this node>,.serial = {0x01,0x23,0xD7,0xA6,0xFB,0x0C,0x55,0x23,0xEE}}
+------------------------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| Execution result |
+------------------------------------------------------------------------------------+
| SUCCESS |
+------------------------------------------------------------------------------------+
I see more data transmitted here than when it fails immediately. It is also different from when I just pull the cable:
+------------------------------------------------------------------------------------+
| MySensors security personalizer |
+------------------------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| Configuration settings |
+------------------------------------------------------------------------------------+
| * ATSHA204A based personalization |
| * Will generate HMAC key using ATSHA204A |
+------------------------------------------------------------------------------------+
+------------------------------------------------------------------------------------+
| Hardware security peripherals |
+--------------+--------------+--------------+------------------------------+--------+
| Device | Status | Revision | Serial number | Locked |
+--------------+--------------+--------------+------------------------------+--------+
| ESP8266 | DETECTED | N/A | A6EE1400EF401800AA | N/A |
+--------------+--------------+--------------+------------------------------+--------+
| ATSHA204A | NOT DETECTED | N/A | N/A | N/A |
+--------------+--------------+--------------+------------------------------+--------+
+------------------------------------------------------------------------------------+
| Execution result |
+------------------------------------------------------------------------------------+
| FAILURE (last ATSHA204A return code: 0xE7) |
+------------------------------------------------------------------------------------+
For a while I was able to also read the serial number of the ATSHA, but I cannot get there anymore. Electrically, everything seems fine, flanks have rise and fall times of <5ns.
After the setup, my ESP tries to connect to an SSID which I don't have anymore every second. This is despite the fact that I ran the ClearEepromConfig sketch. Maybe that one also is not ESP8266 compatible
2.2.0 looks fine by now, but the hardware in general still behaves randomly until it is at least halfway clear why this very strange behavior in 2.1.1 occures.
Anyway, its just the gateway, not lots of nodes. I'll go ahead with this, Can still change it if more issues come up.
Thanks for the great work on this.
Correcxtion: My bad, seems to work. Still really weird and looks random. How did code that is not called before everything should be finished influence the result?
I have been using 2.1.1, just updated to 2.2.0 with the Arduino library manager.
It seems I am still getting
+------------------------------------------------------------------------------------+
| Execution result |
+------------------------------------------------------------------------------------+
| FAILURE (last ATSHA204A return code: 0xE7) |
+------------------------------------------------------------------------------------+
with the unaltered (only hardcoded const int sha204Pin = D2;) sketch. Have to check with oscilloscope this evening., will report back.
I have little time this afternoon, but I'll try to find more tomorrow. For documentation purposes, timing counted in ms from the triggering falling edge of the wake pulse:
Working, reproducible
0 falling
0.0725 rising
3.1638 falling
3.1694 rising
3.1790 falling
3.1846 rising
Non working, not exactly reproducible, only in the fact that the middle pulse is longer, instead of equal to all following pulses.
0 falling
0.0685 rising
3.1557 falling
3.1653 rising
3.1748 falling
3.1804 rising
What is strange is that my change in the code is the LAST line of the setup function. It happens AFTER the "Personalization complete" line. I don't see how it should change anything, without any serious compiler voodoo.
I have commented and uncommented the additional line at least 10 times, with multiple subsequent resets each, and there is no doubt it's that effect.
Ok, this is madness. With the default SecurityPersonalizer sketch, it fails pretty reproducably.
If I add another Serial.print statement at the end of the setup funktion (I initially printed "Looping", but copying "Serial.println(F("Personalization is now complete."));" also works), it works pretty reliably.
In the oscilloscope I see reproducable timing of the wakeup pulse and the first following pulse in the second version, but in the first, original version, the two measurements had different timings. Qualitatively, in the nonworking version, the first pulse after the wakup is longer than the following one, in the working version, it has the same length.
Again, the only difference is commenting and uncommenting the additional Serial.print statement. ATSHA is on D2.
If nobody has an idea how o reliably prevent this, I conclude that I cannot use the ESP8266 with the ATSHA, since I might run into the issue any time again under uncleared circumstances.
I'll hook up my oscilloscope next week end. I hoped to get some response if people have the ATSHA running with the ESP8266 and if it was in any way tricky. If it is, it maybe should be documented somewhere to save other people some time, given that the ESP is e.g. part of the main wiring documentation and probably the choice for a gateway.
I haven't changed anything but the pin definition in the Personalizer sketch, so if there is a problem in that regard, it is a general one (and even if people have it running out of luck, they may not have a stable config).
Now, this is probably a stupid question, since there are PCBs and all around, so it seems to work, but how are the experiences on the ESP8266/Wemos D1 Mini, especially with the ATSHA204?
I made an RFM69HCW/ATSHA204A breakout, it works with an Arduino Pro Mini, but I am completely unsuccessful with my Wemos D1 Mini that was supposed to be the gateway.
With the ESP8266, I saw one successful run from the SecurityPersonalizer, but could never reproduce it.
I am a little bit out of ideas. The error, "Failed to wake device. Response: E7", stays the same when I change to a different pin.
The only other lib I found was the Sparkfun lib, which only compiles after one change of uint8_t->uint32_t in the header file, but also does not give successful results.
I DO remember, though, that I also have mixed results with the DHT22, so it seems the timing required for one-wire devices on the ESP8266 is a bit rubbish.
Any experiences?
And if not: is there even a security advantage in an ATSHA on the gateway, which is stored safe in my attic, or would software signing on the comparably fast ESP be just as good?
Quick followup: After I started looking for them, i saw quite a few traces like this. A lot of them put rows of vias in the groundplane along the trace. I see that this would change the impedance taken from the calculator if they are close (since there is more ground around), but should there be any closeby connection between top and bottom ground? At the beginning and/or end, e.g.?
@MiKa If you happen to have time, could you test the range with
I am really not happy with the HT7333 solution, since the shelf life of the keyfob will be limited and the quite expensive LIR2032 can easily be damaged by undervoltage.
If the second test works, I could fit 4 220uF 6.3V tantalums next to the LED.
Else I would give the step-up thing another go. There are low profile inductors, but I didn't find any for cheap (shipping) at Aliexpress.
@MiKa Version with pullup is pushed to Github
So apparently it it will be a while until I can do active testing. Right now I am struggling to get my network running at all.
I'll quickly post it here in case someone has an idea, else I'll open a thread next week when I actually have time to react to suggestions.
I have flashed the GatewayESP8266MQTT sketch to my gateway (Wemos D1 Mini + RFM69HCW). This is the output:
0;255;3;0;9;TSF:LRT:OK
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
scandone
f 0, scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 3
cnt
connected with MySSID, channel 1
dhcp client start...
...ip:192.168.2.127,mask:255.255.255.0,gw:192.168.2.1
.IP: 192.168.2.127
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
IP: 192.168.2.127
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;MQTT connected
0;255;3;0;9;Sending message on topic: home-le/mysensors/868/in/0/255/0/0/18
pm open,type:2 0
The message is successfully published on the MQTT server.
I flashed the LightSensor sketch on another breadboard node (Arduino Pro Mini + RFM69HCW). This outputs
0 MCO:BGN:INIT NODE,CP=RRNNA--,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
8 TSM:INIT:TSP OK
10 TSM:FPAR
141 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2148 !TSM:FPAR:NO REPLY
2150 TSM:FPAR
2281 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4290 !TSM:FPAR:NO REPLY
4292 TSM:FPAR
4423 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6432 !TSM:FPAR:NO REPLY
6434 TSM:FPAR
6565 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8574 !TSM:FPAR:FAIL
8577 TSM:FAIL:CNT=1
8579 TSM:FAIL:PDT
Which apparently indicated that no parent could be found. The gateway doesn't output anything.
I did not make any changes to the gateway sketch except for password and name stuff (especially no inclusion mode). Devices are a meter apart, one with a spring antenna, the other with a big screw-on antenna.
@Anticimex Oh, forget what I said. I thought that the whitelisting was on network access basis. But the doorlock has to trust the id via whitelisting, and of course it wouldn't trust a patio motion sensor.
@Anticimex The idea is to let one accessible node alone. Just get the id out and leave it where it is. So there would be no reason to take that node's id off the whitelist.
@Anticimex Ok, I see my misunderstanding. But that would mean that a lost node (to obtain the ATSHA) and an accessible node (to extract a whitelisted ID but then left in place) combined would give access, wouldn't it?
@MiKa Suspected that. Will put it in.
the PSK is programmed into the atsha. If it is stolen, the PSK is still in the atsha.
Of course.
And if you use black listing, how do you ensure the attacker does not simply just use a different serial by customizing the firmware?
My understanding was that the fixed ATSHA ID goes into the signature inside the closed signing process in the ATSHA. So one ATSHA can only provide signatures with its unique, unchangeable id. If signatures with that id are blacklisted, then the ATSHA is worthless.
Is that not the case? Can an ATSHA be used to create a signature with an id that is not it's own?
@Anticimex Ok, let's take encryption out of the equation. I still don't get it.
As long as the PSK is not transmitted, I don't see how HMAC could be broken. If a soft-signing device is lost, the PSK could be read. But if an ATSHA device is lost, the PSK cannot be read. An attacker could only use the PSK in combination with the fixed ID of that ATSHA; that could be un-whitelisted or blacklisted (I really would like to see blacklisting because of that, I think.)
Can you sketch a valid attack with a known Id, but without a leaked PSK, or a way how my PSK could leak if I generally only expose ATSHA devices?
@MiKa That is very low. I am not an expert for tantalums, but I guess 6.3V should be save, shouldn't it? You get 100uF at that size and voltage. I even managed to stack 2 of them. It might even be possible to squeeze an 220uF 3528 in there, not sure.
Perhaps I should use the space on the back of the battery opposite of the HT7333 for an array of big tantalum caps.
Could you maybe test the range with a strong external supply at 2.7V?
I got feedback for my project that programming via ICSP is not possible with the RFM69 radio attached. Since it is basically SPI, I don't really see a reason for that. Can anybody explain that? Do I need to pull CS for the radio high, maybe, or is there something deeper to it?
@MiKa The LIR2032 have much smaller capacity, tough. The 4uA quiescent current of the HT7333 alone will suck them dry in about a year. Probably even destroy them, due the lack of undervoltage protection 
The solution is far from optimal.
What tantalum cap capacity did you use? How low is the range?
I thought security was given because a badguy cannot change the ATSHA id and also cannot extract the PSK. SO the id doesn't seem private.
@MiKa BTW, thanksfor testing. I have very little time right now, so I am glad I don't have to do the tests AND update the PCB. I still haven't finished my adapter from my 10 pin usbAVR to the 6 pin ISCP header ...
@Anticimex If the personalizer can read it indefinitely, can't I just send it out over the radio?
@MiKa What? Unsoldering the radio is terrible ... I really don't see a reason for that, it should be SPI and the radio should do nothing ... maybe we need to pull CS low to make sure the radio is not selected? Someone here should know that ...
Regarding wake up: Yes, THAT I know about All the button pins are on PCINT1_vect: https://playground.arduino.cc/Main/PinChangeInterrupt
Consider setting a mask to limit it to the 5 button pins.
@Anticimex Ok, I see ...
Well, good that we have TX now If my current version works, I'll personalize the ATSHA outside of the board. It's really easy to solder with a hot air gun.
@Anticimex Why? I thought there is SKIP_UART_CONFIRMATION. I have to set USER_KEY, but isn't that generated once for the whole network? I figure it doesn't have to be the keyfob node that does that ...
@MiKa I have made a big new push to the repository. Here are the changes from the commit:
I would have liked to put a step-up converter on there, but I have not found a possibility for one that does not need an inductor that is too bit to fit on there.
Thanks, I'll change that.
BTW, I found another reason against adding a serial programming interface: To safe power, brownout detection should be disabled. If the battery runs low, erratic behavior may occur, which includes jumping to arbitrary addresses in flash. If a bootloader is still there, there is code to write to the flash, which might damage the programming. On the other hand, I highly doubt that a failing mcu will manage to go through the full process of sending an authenticated button pres, especially since high current RF tasks are involved.
So it is probably generally advisable to not have the Arduino bootloader on there.
@MiKa The SPX3819M5-L-3-3 has massive (well, comparably) quiescent current. Ten times the HT7333. That alone will suck a LIR2032 empty in about a month. I think I can fit the SOT-89 of the HT7333 package next to the LED. Alternatively, one could conider boosting with a MCP16252.
Serial flashing capabilities requires one more capacitor and resistor ... And the routing is also already pretty difficult. What is the avantage? As far as I can see, it is just another flashing device ...
I do intend, though, to add 2 pins rx/tx to the icsp header. How did you do that one, by the way? Does your version already have the bigger holes? In the most recent version, it is intended to take a machined female header. with that, it fits into the enclosure. I am still thinking about changing it over to SMD pads, which I would interface with pogo pins.
Oh, A7, yeah, I remember something like that. Does the LED flash with the coin cell? The one I took from an RGB strip doesn't light up on blue at 3V because of the required forward voltage. I fear green might have the same fate when the battery voltage drops ...
Looks like V1.1 is required.
Looking forward to hearing from the actual radio tests. Depending on that V1.1 might get some more caps or a HT7333 so it is possible to use a LIR2032.
@MiKa Hi, have you already received your PCBs? Mine came friday. on The bright side: Mechanically, everything fits fine into the keyfob enclosure. Nothing shakes, buttons fit accurately.
Unfortunately, I have more issues with the QFN package than I hoped. So I cannot tell anything electrically. Do you ahve it running? I am increasingly concerned that the coin cell will not be able to provide the necessary voltage and current spikes for a reasonably long time ...
@hek Ok, awesome. I am doing that. Does it update automatically?
Oh, cool! That seems to be exactly what I was looking for. I'll add my projects as soon as I received them and tested them working. Thanks!
Can you link me to what the Github import function expects?
... or any other good way for searching PCBs for sensor projects? I just started with a few things, and by now, I found it easier to click something together in KiCAD, than to look for other peoples contributions. Mostly searches drown in "question threads", libraries, "I want to make" threads that do not lead to anything, or in projects on prototyping boards (but given todays PCB prices, I rather save the time for that and get a neat, small sensor with SMD components that I do not have to place in a shoebox for space ...). Of course, all of these are fine, valid and even helpful, I am just missing a good way to find what I am looking for. Keywords like "pcb" or "KiCAD" didn't help much. The best thing I could think of are filtered searches in the MyProject subforum, but they didn't really help me: MQTT - nothing like I was looking for, Wemos - a guy basically just saying that the Wemos exists and he uses it. BME280 returns something in the way I am looking for, but people seem to post pictures of their PCBs. Can't really send those to a manufacturer, are you kidding me? (Or did I overlook the link?)
I built a keyfob, an MQTT gateway and an RFM69+SMA-antenna-connector/ATSHA204A breakout like that, though I am SURE that stuff is around already. I mean come on, SOMEONE must have used the obvious way of connecting MySensors to the network and not have bothered with wireing all the connections themselves ...
So, next things are supposed to be door sensors with reed switches and BME280 temp/hum sensors. Just so big that the sensor, RFM69HCW, SMD ATMEGA, ATSHA and battery fit on the two sides of the PCB. Pretty much like the keyfob linked above. Is there anything, and especially, is there a structured way to find it?
Don't misunderstand me, this is not a rant. Depending on what the actual situation is, this is:
@MiKa No, I didn't. This goes into my attic, so I didn't really care for that. But it is square, 38x72mm^2. Shouldn't be hard to find a box to throw it in.
Since I wanted to get a gateway into the same shipment and only found the shield type gateway for the Wemos D1 Mini, which I didn't like, I quickly clicked together a PCB for that, supporting the RFM69HW (with 50Ohm impedance trace to an SMA connector), the through-hole NRF24L01 module and the SMD version with the ceramic antenna. (And of course an ATSHA204A.)
It can be powered over the D1 Mini or alternatively with up to 24V over a switching regulator.
I guess there are dozens of those things around, so I won't spam another topic (as long as nobody disagrees), but I'll put it here for completeness.
https://github.com/kvoit/MySensors_SecureD1MiniGateway
Since I cannot find it in the ducumentation: What is the preferred pin to connect an ATSHA204 chip to a Wemos D1 mini? I see that I can set manually, but since I am doing a design from scratch anyway, why not do it properly. I guess D3 would suggest itself, since it has the pull-up already built in, while it is not connected to the LED.
@MiKa said in Secure 5-button keyfob with enclosure (was: 8-button keyfob):
before last finalization by You)
You should be fine. The antenna might need a little bending at the base, because the cutout didn't fit perfectly, but it is just a matter of <<1mm. The other changes, as far as I remember, were a purely cosmetic shift of the RGB LED and a little modification to keep the clearings for the v-cuts for the panelization.
If you have issues, I could send you a PCB for shipping costs. With the panelization, I'll have more PCBs than I ever could use.
@MiKa Thanks, lets hope so. Did one of you have a close look for issues, at least on the schematic? It's actually my first (MySensors/Ultra low power/THAT small) project.
Anyway, Seeed just dropped the price for 10 10x10cm^2 PCBs to 5$ plus shipping, so there is not much to loose except for 3 weeks waiting. I'll report any success or failure. Until then, the design is to be considered untested.
I'm a little afraid of the TQFP package Hope I can handle it with my rework station, don't have a toaster oven ...
@Anticimex Yes, that was the whole point. Someone else already posted a link to a PCB for the same keyfob enclosure without an ATSHA. The ATSHA is next to pin6 of the RFM69.
The other PCB also doesn't have dedicated space for an antenny, so I suspect they just somehow shove a wire in there. My design has a cutout for a spring antenna (already tested that it fits into the enclosure), with a defiined 50Ohm impedance trace leading to it.
If anybody cares, I have improved a few things - rgb led (choose the standard 505 that is used on RGB strips), impedance to antenna, button footprints ... It is all pushed to Github. There is also a branch with gerbers for a panelized version with v-cuts.
I will order it tomorrow evening. (Hint: I'll sit on 60 PCBs for this, soon. Location Germany.)
Awesome, understood. I had a little misconception about impedance, assuming it should contain the length, but thinking about it, I remember an exercise in university about that.
Changed the impedance to 50Ohm by adjusting the trace width and the clearance of the ground plane in that area.
That looks interesting. Do you think I should take that into account for this project? I planned to send the PCB to production next weekend and I am not sure if I will have time to understand that by then. Trace in question is top right.
Hi, I am laying out the PCB with a trace from the RFM69 to a throughhole pad for a spring antenna, 868MHz.
The trace is very short, the Antenna is as close to the RFM69 as possible, so not much more than half the antenna diameter plus half the pad width. I strongly assume that about 3mm trace do not matter with lambda/4 = 8.6 cm, but THEORETICALLY, how would I best layout that trace? Impedance as low as possible, so uninterrupted ground plane behind it? Angthing else?
I am just trying to learn a few RF basics here, so answers "yeah, that doesn't matter" do not help at all.
Yeah, I could do that. No free PWM pins, though. But one could use Software PWM on A0/A1/A7, those woud be easy to route.
Any footprint+Aliexpress/EBay link ready for a suitable LED?
I have created a 5 button version that fits into the keyfob enclosure. I put the KiCAD project and a dxf file with the PCB measures on GitHub. I'll add an image later.
https://github.com/kvoit/MySensors_SecureKeyfob/commits/master
Schematic attached. I would like some comments before I put this into production.0_1492625836524_MySensors_SecureKeyfob.pdf
Does anyone have a footprint for the RFM69HCW? The git library only seems to contain the RFM69HW.
@mfalkvidd Thanks, that is what I feared. Then as far as I understand, it would be a really bad idea to move it away from D2, at least not to anything else than D3. But i guess when the ATMEGA is sleeping, the RFM69 will also be deep asleep, so there is nothing to expect from it to trigger PCINT2_vect. And D3-D7 on the same port is just enough for my 5-button keyfob, so I'll connect it to D2.
Yes, I was referring to that page. If it is used as an interrupt, then moving it to another pin other than D2 or D3 on an ATMEGA328 is not a good idea, because only those can be used as interrupts (https://www.arduino.cc/en/Reference/attachInterrupt).
In which situation is this used? Is it additional functionality that isn't available on the NRF24 (where IRQ isn't implemented, according to above mentioned page), or is it needed for normal operations?
I am working on a keyfob that is supposed to wake up on key presses on PCINT2_vect, which is D0-D7. It is supposed to be deep sleeping the rest of the time.
Hi,
I am currently laying out a first project with an RFM69. The manual suggests to connect DIO0 to D2, while for the NRF24L01, the additional "non SPI" port is connected to D9. Is there any reason to this? I would prefer keeping all the radio pins on port B, such that I have port A free for interrupts. Would this have any disadvantages except for the necessity to explicitly define the port in the sketch?
What is the purpose of DIO0 anyway? If I set an interrupt on port D (PCINT2_vect) in a deep sleep setup, would I have to expect any issues with DIO0 on there, too?
@mtiutiu For me, D doesn't do anything at all. m acts as set in the dialog.
Found it out myself: In the interactive router dialogue is a dropdown for that. On my workstation it works, on my notebook with Intel graphics, it crashes KiCAD.
@Anticimex AES is a big plus. I already looked for coiled antennas on Aliexpress and as far as I can see, these will fit into the case. i will make a cutout in the PCB for that. I hope my Reichelt shipment will arrive on Saturday, so I can test it with some coiled 433MHz antennas I have lying around. Diameter is probably the same, I should even be able to clip them off to convert them.
I know I can make footprints. But if there was a footprint for that type of contact, I would rater use that. Since I am neither a professional nor a native speaker, I don't really have an idea what to look for ...
Pity that the OSHPark guy chose to name himself after a transistor, that doesn't really make finding him easier ...
@MiKa I was a little skeptical at first because it seemed the enclosure wasn't that easily available for me in Germany. Now, however, I found out that it seems to be identical to the RND 455-00014 that is e.g. sold at Reichelt for less than 4€. They also have a datasheet with good documentation of the measures. I will not have the keyfob from above made but attempt a redesign over eastern for that enclosure.
Two questions for the general public:
I think I found the problem. For some reason KiCAD puts the symbol of my version into he schematic, despite the fact that I am clearly choosing it from the MySensors lib. We chose different pin numbering. Apparently, KiCAD cannot deal with parts of the same name in different libraries.
Hi, I just found the KiCAD components library, just after I made my first design, so I already had a footprint made.
Since I assumed that the footprints in the library are better controlled (I don't even have the device yet) I exchanged mine and found out that the two footprints are mirrored ... in mine, when looking at the module from the top, antenna on top, VCC is left. In the MySensors library, it is right.
I made my footprint according to the image in the description of this auction I googled: http://www.ebay.com/itm/2Pcs-2-4G-NRF24L01-PA-LNA-Wireless-Module-Ceramic-Antenna-1-27mm-2-2-3-6V-/271968125413
From the position of the antenna, I would say that VCC left ist the correct way, but I am surprised that the MySensors library is wrong ...
@MiKa Hm, having an enclosure ready is a major benefit. Pitty it doesn't have KiCAD files available, so I would have to measure everything ...
Hey, I just got to like the push and shove routing A LOT (so the interactive router is working and I know how to set the modes). What I couldn't figure out is how to move a trace (not just a segment, disconnecting it from the rest of the trace) around. Can anybody give me a hint?
Awesome, one point off the list.
You are right, I'll giving it another try. But again, I'll change the routing quite considerably, so there is not much use for the KiCAD project yet.
EDIT: Nope, the ZIP upload doesn't seem to work. I'll find another possibility for the finalized next version. Go for the schematic PDF for now.
Older 8-button version, abandoned since no case exists. Never tested, but I am not aware of issures.
Changelog:
Most recent version:
Schematic: 0_1491890133730_keyfob.pdf
KiCAD project v3.0 (it seems I cannot upload ZIP files?)
Not sure if you can open the KiCAD project without my custom libraries.
While most of my home is made smart using ESP8266s, I plan to dive into MySensors for more energy critical stuff. The first project is a keyfob.
Attached is a first design for a 8-button keyfob mit hardware HMAC authentication via an ATSHA204, running on a CR2032 coin cell and fitting into a commercially available keyfob enclosure (see README on github repository).
The ATMEGA is supposed to run in power-down mode (400nA with disabled ADC, internal oszillator @ 8MHz), the powered down RFM69HCW should take 100nA in sleep mode and the ATSHA <150nA in sleep mode, so the overall standby consumption should be well below the self-discharge rate of the coin cell.
In standby, the buttons will have interrupts attached via PCINTx_vect, so that a button press will wake the ATMEGA.
Before I send out the PCB order, perhaps somebody is interested in having a closer look ... this is both my first MySensors project and my first low power project. Also, it is probably the most compact thing I have ever clicked together. (I am so glad about KiCAD's push and shove router ...)
Any comments? Tips? Ideas? Errors?
I would hate to send this to production and end up with 80 unusable PCB (Taking about PCBs, I will have a lot of spare ones in Germany, is anybody is interested ...)
The major issues I could currently think of are:
KiCAD project on github: https://github.com/kvoit/MySensors_SecureKeyfob/commits/master
Schematic: 0_1492625836524_MySensors_SecureKeyfob.pdf
