💬 Ikea Molgan Hack

LastSamurai

Thanks, haven't really looked in that file since the upgrade to mysensors 2. Doing it all in the sketches now. I'll test it and get back to you.

Anticimex

@LastSamurai I do not think the timeout is the issue here, but worth a try anyway. The memory usage is in the red zone if over 70% I'd say so I suspect the hmac key gets corrupted by a stack that grows into the heap. You can test that by adding a debug print in the soft signing backend that dumps your hmac key before it is set. Assuming you run the latest stable release you'd want to place the print just before this line. You can copy this line and replace _signing_hmac with _signing_hmac_key. Also change the HMAC text to HMAC KEY to tell them apart (and don't post your printed key here ;))
This to verify that the key used is the key you personalized and that it has not been corrupted.

LastSamurai

@Anticimex So adding this around the line 325 should do the trick, right?

// Feed "message" to HMAC calculator
	DEBUG_SIGNING_PRINTBUF(F("HMAC key debug: "), _signing_hmac_key, 32);
	_signing_sha256.initHmac(_signing_hmac_key,32); // Set the key to use

The output of that is

HMAC key debug: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

which is definitly not my HMAC key!

PS Changing the timeout did not change this.

Anticimex

@LastSamurai alright, so there are now three options:

Your device is not properly personalized
Your key has been overwritten in eeprom by some other part of your sketch during runtime
Your key has been erased by stack growth (unlikely since it very much look like eeprom reset value)

You can test the various scenarios by moving your newly added print to various places in the backend. For instance, adding it just after the value is fetched from eeprom in the init function of the backend would tell you if the value is bad in eeprom or is erased in ram at a later stage.

LastSamurai

The HMAC key seems to already have been FFFFF.... when read from EPROM. While testing some more I somehow seem to have bricked the atmega328 though :( I just soldered a new board and will to some more testing tomorrow.

Anticimex

@LastSamurai alright. Perhaps the molgan sketch does some eeprom operations which inadvertently erases the key. You could try to read the key from eeprom early in the sketch after it was personalized just to confirm it had the key at some point at least.

LastSamurai

Hah success! Until now I was programming the chip directly via an USBasp (ignoring any bootloaders). I guess thats how I "bricked" the other chip (accidentally burning fuses that indicate an external clock...).

Today I burned a bootloader (with the right fuses) to the new board and uploaded the securityPersonalizer and the molgan sketch via serial... and everything is working! It takes some (re)tries to get the signing up and running but after ~2 seconds the molgan board showed up in the gateway log. Now I'll only have to connect the new board to the molgan pcb and hope that everything still works.

I still don't know why it wasn't working before though. I have some other chips that I programmed via ISP and they work well with signing too...

Anticimex

@LastSamurai nice. My best bet is that you somehow erased your eeprom after personalizing it. But anyway, nice that you are fully up and running now :)

Jan Gatzke

@LastSamurai How exactly did you flash it? I am using an USBasp, too. As it seems I have bricked 2 atmega328p and one Arduino Pro mini already. :dancer:
This is what I did:
"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe" -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -B 40 -c usbasp -p m328p -b 11520 -P usb -V -v -U efuse:w:0xFE:m -U hfuse:w:0xDA:m -U lfuse:w:0xE2:m

"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe" -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c usbasp -p m328p -b 115200 -P usb -V -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex

After this I am not able to flash sketches via the Arduino IDE. Any ideas?

Jan Gatzke

Never mind, it's working now. I soldered a completely new pcb and this time it runs without problems. I still have no idea, why it did now work on first try. But I guess it has something to do with the fact, that I used hot air and solder paste for the first time. :)

Edit: I have assembled all the stuff and the node is kind of working. It presents itself to the gateway perfectly. What does not work is the motion sensor. The pin is always high. When I pull it down manually and release it again, the node sends its message.
I have removed the light sensor and R17. I have replaced R11 with a 1k resistor because that was the smallest one I had. Could this be a problem?

Edit: Ok, found the problem. Seems like I have accidentally unsoldered R2 when I removed the light sensor. From your pictures I found out, that there has to be a 470k resistor. Now it works. :)

LastSamurai

@Yveaux Short question: the zener diode only caps the voltage of the trigger so that the atmega328 can read it safely, right? Wouldn't a 3.3V zener diode work just as well then? Only asking because I am currently having a hard time finding a matching zener diode on aliexpress.

AWI

@LastSamurai As long as you can be sure the Vcc of the Arduino stays around 3.3v you can use a 3.3v zener. If you power as indicated (2 AA cells) voltage can drop below 2V and that cannot be considered safe. As an alternative to the zener you can have a resistor voltage divider (or stack a few normal diodes).

Marek

Works like a charm!

Yveaux

@marek great to hear! :+1:

p359

Here's a random question, has anyone made or considered if possible even, an RFM69 radio version? I'm considering moving to RFM69 from NRF24 due to some range issues.. maybe.. Will need two gateways or something along those lines to keep using these fantastic nodes, have 3. Any thoughts back would be terrific, is there for example some show stopper I'm missing or just a matter of space and creative wiring!?

aramko aramko

This post is deleted!

magpern

I have finally finished the PCB of two Molgans (withou the actual Molgan). I spent several hours trying to figure out why the sensor did not register with Domoticz.
I had it plugged in to the FTDI which powered it, but nothing... device talked, gateway listened, but device ignored responses from gateway.
I just dealt with with problem on some other nodes, and it was the channel id that was inappropriate. But now I had the correct channel id, and still the same problem.
I checked for shorts, but nothing.
Measured the voltage. It says 3v3 on the FTDI but was actually 3v5. But that should be ok.
Finally I figured, power it through the + and - pads instead of FTDI. So, I set up a 3v3 power supply.. and voila.. it registered with the gateway.

I don't understand why, power is power... but apparently power is different.
So, for future builders, if you run this, you know what I did.

Need to head to IKEA and get some more Molgans!!

Yveaux

@magpern the instructions on openhardware.io state that the Molgan must be battery powered while programming:

"Remove the batteries and connect a standard FTDI serial cable (the ones used to program an Arduino Pro-Mini) to the FTDI connector of the add-on PCB. Replace the batteries and plug the FTDI cable in your PC."

magpern

@yveaux said in 💬 Ikea Molgan Hack:

@magpern the instructions on openhardware.io state that the Molgan must be battery powered while programming:

Well, then I can confirm that you don't have to power the Molgan from batteries just for programming. Burning the bootloader works fine with just power from the ISP port and programming it through FTDI works fine if power comes from the FTDI.

What I found wierd is that the atmega328 had power, the radio had power, it wrote debug messages to the FTDI - when powered through the FTDI, it send radio messages etc, but it just did not receive messages.
Messages where not received until I supplied power to the + / - pads (battery pads).

I did read the instructions on openhardware.io, but I didn't follow then to the t. :)

💬 Ikea Molgan Hack

21

11.7k

11.2k

113.1k