💬 Ikea Molgan Hack

[LastSamurai]

I still have the second molgan on my desk waiting to be finished. I will experiment with that one adding caps in parallel to the once you marked and/or adding one directly across the +/- pads.

[LastSamurai]

So I finally came around to testing with the second molgan. I put a small 22nF cap in parallel to the (in your picture) red cap on the board just on the backside of it. I also added a bigger 47uF electorlytic cap to the green one.
I have only had it running for about a day now and it helped at least partly. It doesn't seem to get into constantly triggering anymore (although this only happened after longer periods of time with the other one) but I still get multiple triggers every time. If I shortly move inside the range I get 2-3 triggers (30s pause). So I guess the problem isn't fixed yet. I will wait some time to see how this works out and then try to add a cap between the + and - pads of the pcb.

Any other ideas? (Btw I find it strange that its working for you without any problems while I have the same problem with bost molgans)

[Yveaux]

@LastSamurai said in Ikea Molgan Hack:

I find it strange that its working for you without any problems while I have the same problem with bost molgans

I'm sorry that you're experiencing problems, but mine are running rock solid for months. Maybe there's variation in the Molgans produced by Ikea?
What PIR's do yours have? Mine are marked "PIR D203B" on top.

I do have some issues with an outdoor D-SUN HC-SR501 based sensor.
This node starts to produce random bursts of triggers every now and then, which I tried to fix by replacing every part of the sensor.
After help from @scalz I found out the 47uF capacitor C102 (see schematics below, supposedly the schematic of the HC-SR501 from http://www.electrodragon.com/w/PIR_sensor) was only 100nF.

I replaced C102 with 100uF and added an extra cap to GND (connected to R1), to stabalize the power to the PIR.
First results show it runs stable, but time will have to tell if it keeps running that way.

Maybe the Molgan also contains some cost reductions (like replacing C102 by 100nF).
To know for sure the schematic of the Molgan has to be known first... Any volunteers?

[LastSamurai]

I just spend an hour tracing the routes on the pcb. I am pretty sure I missed some (and there might be some errors) but here are my results for now. Ill redo them with KiCad later. Can someone measure the capacitors? They are unlabeled.

[scalz]

@LastSamurai
i already said it but you can try to solder a capa (100uf) to the Drain "Vcc" pin and the GND pin of the PIR sensor itself.
Maybe you could tweak R9 on your schema, even if i don't think it's exactly connected like this in real.
Why?
Combined with the resistor, the capa does filtering and buffering/storing energy.
You can find infos on google, this is about the capacitor RC time constant.
So, increasing res&capacitor value, you will increase the time it takes for charging capacitor (so the time to settle the PIR at startup), and what you want, it will take more time to discharge, regarding for example power consumption spikes etc..
Ideally, it gives better result by using the right resistor, but if you're not sure about the resistor and the schematic, easy route is to increase the capa like i said. At the right place, the sensor ic, also easier because it's through hole . Molgan board was not created for handling another circuit i think, so the hack.

[LastSamurai]

@scalz Yes, I am pretty sure the part of my schematics around the pir isn't complete yet.
I'll try the capacitor. Does it have to be the 100uF value? Atm I only have a 47uF cap that might be small enough to fit under the pcb.

[scalz]

you can try, that could help, sure.

[Samuel235]

@Yveaux - Get yourself on the adafruit show and tell series dude! I for one, watch this series with intent to learn and discover new devices and how to recreate them for myself. I'm pretty sure that most of the audience that join into those are there for the same reason as me. Congrats on making it to their site full stop though

[Yveaux]

@Samuel235 said in Ikea Molgan Hack:

Get yourself on the adafruit show and tell series dude!

Which episode? I normally don't watch them

[Samuel235]

@Yveaux - This is the series that i'm talking about SHOW-AND-TELL Google+ LIVE Hangout! 3/1/17 (video) @adafruit #adafruit – 17:31
— Adafruit Industries

They just have random people on video link talking about their products. Might even get some more interest into the MySensors movement let alone your own hardware. Its your choice on what product to get on there i suppose

They normally give you a slot on their air time to just explain your product - not sure how you get on though, application maybe? Let us know if you decide to go for it!

Check out their other series, something else may be more interest to your hardware or personal interest.

[Yveaux]

@Samuel235 Ah, I misunderstood; thought it was featured on the series already
Anyway, today my outside sensor felt like proving I didn't fix its issues yet:

The yellow spikes is one continuous burst of roughly 4 hours in which it continuously triggers. After that it resumes normal operation...
Again, not a Molgan but an HC-SR501. However electronics are comparable.

[AWI]

Thanks @Yveaux for the Molgan Hack board. I was my first experience in soldering an smd atmega Conclusion... need some more exercise. Finally got the thing working and now ready for the next steps. Some considerations:

• The PIR is very sensitive to power fluctuations. Voltages below 3.1V will certainly cause instability.
• I want to keep the light feature of the Molgan but make it accessible from MySensors. Same with the light sensor.
• Power the Molgan with low selfdischarge rechargeable batteries (The led's will drain the batteries faster)
• Maybe add a few other sensors (temp/ hum/ light effects)

With the help of the excellent analysis work of @LastSamurai I'm thinking of the following "Ikea Molgan Hack Hacks"

• add a 3.3V ldo (XC6206, 1uA ldd, 0.08V dropout) to power the Hack board and sensors.
• a voltage divider for measuring real battery voltage.
• drive the Led's from a pwm output on the base of transistor connected to R17
• Measure the photodiode voltage one way or another.
• breakout the SCL and SDA pins for more sensors.

Any suggestions? (for sure a breadboarding exercise)

[LastSamurai]

@Yveaux did you find a fix for your spikes in the pir readings?

I now have the molgan with the 2 caps added in parallel to the existing one running for some weeks and it works reliably. It still triggers several times though when I only move once.
Some days ago I also added a small electrolytic cap of 10uF (biggest value I had for the small form factor) directly across the gnd/power pin of the pir on the second molgan and ... it seems to do exactly the same as the first one (perhaps even slightly worse with nearer to 4-5 triggers for every real trigger, where the other one produces ~3).
Has anyone tried something different? I mean this solution works reasonably well but its not really perfect... and just a hack imo.

@AWI welcome to the "molgan club" ;). How did you solder the smd atmega? I found out that using flux helps a lot but it still takes way too much time and effort to solder by hand
Your ideas sound nice! Though it might be a little difficult to design the pcb to fit inside the case...

[Yveaux]

@LastSamurai I just kept it running unmodified and it seems to behave better now.
I have a feeling it might be related to environmental humidity. I'll monitor it over a longer period and see if I can find a pattern.

[Yveaux]

@LastSamurai I recently fixed a couple of bugs in the external interrupt handling for sleeping sensors.
In short, the sensor could wake within a few milliseconds after going to sleep, because of an interrupt that occurred in the past. For details see this thread.
I'm not completely sure, but this could be the cause of your Molgan triggering all the time.
Could you give the development branch a try and see if things improve?

[LastSamurai]

@Yveaux said in Ikea Molgan Hack:

@LastSamurai I recently fixed a couple of bugs in the external interrupt handling for sleeping sensors.
In short, the sensor could wake within a few milliseconds after going to sleep, because of an interrupt that occurred in the past. For details see this thread.
I'm not completely sure, but this could be the cause of your Molgan triggering all the time.
Could you give the development branch a try and see if things improve?

Wow, great! Thanks for telling me. I'll try it out in the next days.

[LastSamurai]

It seems to have helped! I have now upgraded the code one both molgans and both seem to work without a problem now! Thank you very much @Yveaux
Only thing I am still strugling with is getting signing to work with the molgans. Works on neither one yet.

[Yveaux]

@LastSamurai well, that's great news!
Regarding signing, did you mount an atsha204 and does it give issues, or does it seem software related?

[LastSamurai]

I did not use a atsha204. I used the (new) personalizer to set the HMAC key (like I did with many other nodes) and activated signing:

Log from gateway:

0;255;3;0;9;422688514 TSF:MSG:READ,16-16-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;422688520 TSF:MSG:BC
0;255;3;0;9;422688523 TSF:MSG:FPAR REQ,ID=16
0;255;3;0;9;422688527 TSF:PNG:SEND,TO=0
0;255;3;0;9;422688531 TSF:CKU:OK
0;255;3;0;9;422688534 TSF:MSG:GWL OK
0;255;3;0;9;422689331 Skipping security for command 3 type 8
0;255;3;0;9;422689366 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=8,pt=1,l=1,sg=1,ft=0,st=OK:0
0;255;3;0;9;422690740 TSF:MSG:READ,16-16-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;422690746 Skipping security for command 3 type 24
0;255;3;0;9;422690752 TSF:MSG:PINGED,ID=16,HP=1
0;255;3;0;9;422690756 Skipping security for command 3 type 25
0;255;3;0;9;422690774 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=25,pt=1,l=1,sg=1,ft=0,st=OK:1
0;255;3;0;9;422690965 TSF:MSG:READ,16-16-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0101
0;255;3;0;9;422690972 Skipping security for command 3 type 15
0;255;3;0;9;422690977 Mark node 16 as one that require signed messages
0;255;3;0;9;422690984 Mark node 16 as one that do not require whitelisting
0;255;3;0;9;422690991 Informing node 16 that we require signatures
0;255;3;0;9;422690997 Informing node 16 that we do not require whitelisting
0;255;3;0;9;422691004 Skipping security for command 3 type 15
0;255;3;0;9;422691013 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0101
0;255;3;0;9;422691115 TSF:MSG:READ,16-16-0,s=255,c=3,t=16,pt=0,l=0,sg=0:
0;255;3;0;9;422691121 Skipping security for command 3 type 16
0;255;3;0;9;422691127 Signing backend: ATSHA204Soft
0;255;3;0;9;422691145 Skipping security for command 3 type 17
0;255;3;0;9;422691168 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=OK:882ED3D3B94E6236CCB4FF241128DB984C93F39707EEAC6B7E
0;255;3;0;9;422691180 Transmitted nonce
0;255;3;0;9;422691464 TSF:MSG:READ,16-16-0,s=255,c=0,t=17,pt=0,l=10,sg=1:2.2.0-beta
0;255;3;0;9;422691471 Current nonce: 882ED3D3B94E6236CCB4FF241128DB984C93F39707EEAC6B7EAAAAAAAAAAAAAA
0;255;3;0;9;422691556 HMAC: AC275AA68FF2B3B3689F68DD285F1BFEF8D3F329CCF6E714EEF9E100967B1677
0;255;3;0;9;422691564 Signature bad
0;255;3;0;9;422691567 Signature verification failed!
0;255;3;0;9;422691572 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;422691577 TSF:MSG:READ,16-16-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;422691584 Skipping security for command 3 type 16
0;255;3;0;9;422691589 Signing backend: ATSHA204Soft
0;255;3;0;9;422691608 Skipping security for command 3 type 17
0;255;3;0;9;422691616 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:404FD7260F4410E17E0AD6C07A9A1D04306079F24F9F96CDA1
0;255;3;0;9;422691629 Transmitted nonce
0;255;3;0;9;422691902 TSF:MSG:READ,16-16-0,s=255,c=3,t=6,pt=1,l=1,sg=1:0
0;255;3;0;9;422691909 Current nonce: 404FD7260F4410E17E0AD6C07A9A1D04306079F24F9F96CDA1AAAAAAAAAAAAAA
0;255;3;0;9;422691994 HMAC: 0A7E2867AD7650B15268AC1EF73D37394AC3499733CDD43838D762BA69295B5D
0;255;3;0;9;422692002 Signature bad
0;255;3;0;9;422692005 Signature verification failed!
0;255;3;0;9;422692011 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;422694036 TSF:MSG:READ,16-16-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;422694042 Skipping security for command 3 type 16
0;255;3;0;9;422694048 Signing backend: ATSHA204Soft
0;255;3;0;9;422694067 Skipping security for command 3 type 17
0;255;3;0;9;422694075 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:6AEE2250F8701E4E2B0ABF997B5A8EC57C57793EBC9B09F689
0;255;3;0;9;422694087 Transmitted nonce
0;255;3;0;9;422694386 TSF:MSG:READ,16-16-0,s=255,c=3,t=11,pt=0,l=11,sg=1:Molgan Flur
0;255;3;0;9;422694393 Current nonce: 6AEE2250F8701E4E2B0ABF997B5A8EC57C57793EBC9B09F689AAAAAAAAAAAAAA
0;255;3;0;9;422694478 HMAC: C9B71FFDB9E225BFB122680DADF0B4C4CF23765378A927279C05A751E4C62D45
0;255;3;0;9;422694487 Signature bad
0;255;3;0;9;422694490 Signature verification failed!
0;255;3;0;9;422694495 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;422694499 TSF:MSG:READ,16-16-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;422694506 Skipping security for command 3 type 16
0;255;3;0;9;422694511 Signing backend: ATSHA204Soft
0;255;3;0;9;422694530 Skipping security for command 3 type 17
0;255;3;0;9;422694538 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:F652D897B520B026844F8B8B09417A5C0144B6A1F2ABF01623
0;255;3;0;9;422694550 Transmitted nonce
0;255;3;0;9;422694829 TSF:MSG:READ,16-16-0,s=255,c=3,t=12,pt=0,l=8,sg=1:08042017
0;255;3;0;9;422694836 Current nonce: F652D897B520B026844F8B8B09417A5C0144B6A1F2ABF01623AAAAAAAAAAAAAA
0;255;3;0;9;422694921 HMAC: CCBF0048F9783EBC55219D7F1CFDE6ED46452B4E8897A0393A80EC9F4F20E7F8
0;255;3;0;9;422694929 Signature bad
0;255;3;0;9;422694932 Signature verification failed!
0;255;3;0;9;422694937 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;422694941 TSF:MSG:READ,16-16-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;422694948 Skipping security for command 3 type 16
0;255;3;0;9;422694953 Signing backend: ATSHA204Soft
0;255;3;0;9;422694972 Skipping security for command 3 type 17
0;255;3;0;9;422694983 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:25D2B687E9850102C83439698CA1261AC775BD8E1D6D78D662
0;255;3;0;9;422694995 Transmitted nonce
0;255;3;0;9;422695262 TSF:MSG:READ,16-16-0,s=1,c=0,t=1,pt=0,l=0,sg=1:
0;255;3;0;9;422695268 Current nonce: 25D2B687E9850102C83439698CA1261AC775BD8E1D6D78D662AAAAAAAAAAAAAA
0;255;3;0;9;422695353 HMAC: 189EC417FAF4A2C51F2C03916FF1ABB14C8DD29D78B88681E250FC0F07F7CB4B
0;255;3;0;9;422695361 Signature bad
0;255;3;0;9;422695364 Signature verification failed!
0;255;3;0;9;422695369 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;422695374 TSF:MSG:READ,16-16-0,s=2,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;422695380 Skipping security for command 3 type 16
0;255;3;0;9;422695386 Signing backend: ATSHA204Soft
0;255;3;0;9;422695404 Skipping security for command 3 type 17
0;255;3;0;9;422695413 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:4E135F3710AC0AD6A13A985A81BA4A4EF209A3E57E42717E49
0;255;3;0;9;422695425 Transmitted nonce
0;255;3;0;9;422695687 TSF:MSG:READ,16-16-0,s=2,c=0,t=30,pt=0,l=0,sg=1:
0;255;3;0;9;422695693 Current nonce: 4E135F3710AC0AD6A13A985A81BA4A4EF209A3E57E42717E49AAAAAAAAAAAAAA
0;255;3;0;9;422695778 HMAC: B566AB83CDF3342FE31F3CDC068B7E40AB51E6796F602710D26994D19B39D2AF
0;255;3;0;9;422695786 Signature bad
0;255;3;0;9;422695789 Signature verification failed!
0;255;3;0;9;422695794 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;422695798 TSF:MSG:READ,16-16-0,s=255,c=3,t=26,pt=1,l=1,sg=1:2
0;255;3;0;9;422695805 Skipping security for command 3 type 26
0;255;3;0;9;422695811 Skipping security for command 3 type 16
0;255;3;0;9;422695819 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
0;255;3;0;9;422695827 Nonce requested from 16. Waiting...
0;255;3;0;9;422695953 TSF:MSG:READ,16-16-0,s=255,c=3,t=17,pt=6,l=25,sg=1:B7E56807628A0BB459E81226A682E7C3C3B40087E4B7BE05EA
0;255;3;0;9;422695963 Skipping security for command 3 type 17
0;255;3;0;9;422695969 Nonce received from 16.
0;255;3;0;9;422695973 Proceeding with signing...
0;255;3;0;9;422695977 Signing backend: ATSHA204Soft
0;255;3;0;9;422695983 Current nonce: B7E56807628A0BB459E81226A682E7C3C3B40087E4B7BE05EAAAAAAAAAAAAAAA
0;255;3;0;9;422696067 HMAC: 9EF18CC260F8C4CDEB29C1E277F989482B1C08AB37C6FE9AA39146D8BEBC50AA
0;255;3;0;9;422696075 Message signed
0;255;3;0;9;422696079 Message to send has been signed
0;255;3;0;9;422696110 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=27,pt=1,l=1,sg=1,ft=0,st=OK:1

Log from the node:

129 TSM:INIT:TSP OK
149 TSM:INIT:STATID=16
174 TSF:SID:OK,ID=16
196 TSM:FPAR
243 TSF:MSÿ1040 TSF:MSG:READ,0-0-16,s=255,c=3,t=8,pt=1,l=1,sg=1:0
1097ð”*ô=ø2318 TSM:FPAR:OK
2334 TSM:ID
2349 TSM:ID:OK
2363 TSM:UPL
2383 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2457 TSF:MSG:READ,0-0-16,s=255,c=3,t=25,pt=1,l=1,sg=1:1
2516 TSF:MSG:PONG RECV,HP=1
2545 TSM:UPL:OK
2564 TSM:READY:ID=16,PAR=0,DIS=1
2605 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0101
2680 TSF:MSG:READ,0-0-16,s=255,c=3,t=15,pt=6,l=2,sg=0:0101
2746 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=16,pt=0,l=0,sg=0,ft=0,st=OK:
2820 TSF:MSG:READ,0-0-16,s=255,c=3,t=17,pt=6,l=25,sg=0:882ED3D3B94E6236CCB4FF241128DB984C93F39707EEAC6B7E
3088 TSF:MSG:SEND,16-16-0-0,s=255,c=0,t=17,pt=0,l=10,sg=1,ft=0,st=OK:2.2.0-beta
3174 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
3248 TSF:MSG:READ,0-0-16,s=255,c=3,t=17,pt=6,l=25,sg=1:404FD7260F4410E17E0AD6C07A9A1D04306079F24F9F96CDA1
3514 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=6,pt=1,l=1,sg=1,ft=0,st=OK:0
5593 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
5666 TSF:MSG:READ,0-0-16,s=255,c=3,t=17,pt=6,l=25,sg=1:6AEE2250F8701E4E2B0ABF997B5A8EC57C57793EBC9B09F689
5935 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=11,pt=0,l=11,sg=1,ft=0,st=OK:Molgan Flur
6025 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
6098 TSF:MSG:READ,0-0-16,s=255,c=3,t=17,pt=6,l=25,sg=1:F652D897B520B026844F8B8B09417A5C0144B6A1F2ABF01623
6365 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=12,pt=0,l=8,sg=1,ft=0,st=OK:08042017
6449 TSF:MSG:SEND,16-16-0-0,s=1,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
6520 TSF:MSG:READ,0-0-16,s=255,c=3,t=17,pt=6,l=25,sg=1:25D2B687E9850102C83439698CA1261AC775BD8E1D6D78D662
6789 TSF:MSG:SEND,16-16-0-0,s=1,c=0,t=1,pt=0,l=0,sg=1,ft=0,st=OK:
6862 TSF:MSG:SEND,16-16-0-0,s=2,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
6934 TSF:MSG:READ,0-0-16,s=255,c=3,t=17,pt=6,l=25,sg=1:4E135F3710AC0AD6A13A985A81BA4A4EF209A3E57E42717E49
7204 TSF:MSG:SEND,16-16-0-0,s=2,c=0,t=30,pt=0,l=0,sg=1,ft=0,st=OK:
7274 MCO:REG:REQ
7294 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=26,pt=1,l=1,sg=1,ft=0,st=OK:2
7368 TSF:MSG:READ,0-0-16,s=255,c=3,t=16,pt=0,l=0,sg=1:
7460 TSF:MSG:SEND,16-16-0-0,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:B7E56807628A0BB459E81226A682E7C3C3B40087E4B7BE05EA
7610 TSF:MSG:READ,0-0-16,s=255,c=3,t=27,pt=1,l=1,sg=1:1
7821 !TSF:MSG:SIGN VERIFY FAIL
7854 MCO:BGN:STP
7872 MCO:BGN:INIT OK,TSP=1
7901 MCO:SLP:MS=86400000,SMS=0,I1=1,M1=1,I2=255,M2=255
7958 TSF:TDI:TSL

This is done while the node is powered by the usb-to-serial converter so power should be steady.
Any idea why this is not working? The HMAC that the gateway mentions in the log is wrong btw (is this what it gets from the node?)

PS Other nodes are working well with singing (and the same HMAC obviously).

[gohan]

I would not trust USB serial converter voltage regulator if I were you.

[LastSamurai]

@gohan Thanks, but I just tested it with a real power supply and I get the same errors.
PS I just tested a node where signing is working and the gateway logs also contains these false HMAC keys.. Strange, where are they coming from?

[Yveaux]

@LastSamurai Maybe @Anticimex can explain what's going on?

[Anticimex]

@LastSamurai I am not sure what you mean by hmac keys in the log? Hmac key is never shown in the log. Where is this hmac key you mention? I only see nonce data and that is (or should be) random.
Edit: the log from the GW shows the resulting hmac signature. Not the key. I guess your personalized keys differ between gw and node.

[LastSamurai]

@Anticimex What's a hmac signature? And personalized keys = serial number? So this is working as intended?
Any idea where the error could be? Software setup should be right and the power supply is big enough (its actually an old pc power supply), so why is the signing not working with this one node?

Sketch settings:

#define MY_NODE_ID 8
#define MY_RADIO_NRF24
#define MY_DEBUG    // Enables debug messages in the serial log
#define MY_BAUD_RATE  9600 // Sets the serial baud rate for console and serial gateway
#define MY_SIGNING_SOFT // Enables software signing
#define MY_SIGNING_REQUEST_SIGNATURES // Always request signing from gateway
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // floating pin for randomness

[Anticimex]

@LastSamurai hmac signature is just that, the signature. The concepts are described in the documentation for signing.
And I don't understand what you mean with key = serial. Key and serial are two different things. One needs to be identical on all nodes and the other should be unique and is only used for whitelisting. This is also described in detail in the documentation.

[LastSamurai]

Yes the HMAC key has to be the same on all nodes. I did use the same HMAC key on all nodes.
So you mean that the logs indicate that the HMAC keys on gw and node aren't the same?

[Anticimex]

@LastSamurai no, I am saying that the hmac key is never shown in the log. The hmac signature is. Hmac key and hmac signature are two different things.
The log say that verification fails which means the hmac signature is calculated differently at sender vs receiver. That means one of these options:

1. Hmac key is different at sender and receiver
2. Message has been tampered during transit
3. Sender and/or receiver are using whitelisting but it is incorrectly configured. I recommend you only enable whitelisting if you are sure you know what you are doing, and I see no such indication from the snippets that you have provided.

You can enable verbose signing debug on the node to see what hmac signature is calculated at that end. Most likely it will be different compared to the hmac signature printed on the GW (for the same message).

[Anticimex]

There is also a fourth option, one I have only seen on gateways, only when memory is near full and with verbose prints active and only on a feature branch based on the development where I have seen the hmac key getting corrupted (this case is only for soft signing). I believe it is due to the stack growing into the heap. So you could try to disable verbose logging, or logging altogether on the GW and see if that affects things. It is a long short but worth a try if you are 110% sure you use identical hmac keys on node and gw.

[LastSamurai]

I just tested everything again. Enabled/disabled any debugging on the gw side and reuploaded HMAC and serial keys to both the molgan and the gw (using the same sketch with unchanged HMAC and changed serial). Whitelisting isn't used here (although I am using it with some of my RGBW controller nodes and its working just fine there).
Sadly it did not work .

The molgan node is using slightly different fuse settings only running at 8 Mhz and with 1.8V BOD (fuses: L 0xE2, H 0xDA, E0x06). Could this impact the software signing process? Also are different baudrates for the personalizer sketch supported? When I ran it I only got rubbish on the 115200 baud console (though the rough outline of the normal output). So I searched around in the code and finally added this at the beginning:

...
#define MY_BAUD_RATE 9600
#define MY_CORE_ONLY
#include <MySensors.h>
...

redefining the baud rate. Afterwards the 9600 baud console printed out the expected values. This has only be done on the molgan, not the gateway. Could this somehow have interfered with signing?

@Yveaux , @AWI and others did you (successfully) use signing with the molgan?

[Anticimex]

@LastSamurai baud rate has no impact on the signing, it's only for serial log.
Clock frequency should not have impact on soft signing, it can have on atsha204a as it uses bit banging. But I have run successfully both soft and atsha signing on 8 and 16 MHz. What arch is used? AVR? That is what I use for my development, although it should work on all supported archs.

[LastSamurai]

Its an Atmega328P, so an AVR processor if thats what you mean.

[Anticimex]

@LastSamurai ok, and what about memory? Do you have a percentage of how much ram there is left after programming?

[Anticimex]

@LastSamurai I find it slightly disturbing that you say 115200 baudrate does not work. That would suggest the clock is not running as it should. I can run 115200 just fine on my Nano (16MHz) and Pro mini (8Mhz).
The personalizer on the development branch uses the baudrate set by the MyConfig.h setting (MY_BAUD_RATE) so you define it using that flag (as you found out).

[Yveaux]

@Anticimex the Molgan Hack uses the internal oscillator, not an external crystal like the nano and pro mini.
The internal oscillator is less accurate, hence the lower baud rate.

[Anticimex]

@Yveaux ah, ok. That explains that then. But to my knowledge there is no timing dependency for software signing, except the signing timeout. But I think there is a debug message if that fires. If not, perhaps @LastSamurai could try to increase the timeout (currently at 5000 ms).

[LastSamurai]

Ok for the molgan sketch the arduino IDE spits this out:

• list item22.602 Bytes (73%) of memory
• list itemglobal variables 56% of dynamic memory

How do you change the timeout? Quick googling only turned up requests to make it configurable...

[Anticimex]

@LastSamurai it is configurable, and clearly visible where all signing configuration parameters are located in MyConfig.h. Look for MY_VERIFICATION_TIMEOUT_MS.

[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:

1. Your device is not properly personalized
2. Your key has been overwritten in eeprom by some other part of your sketch during runtime
3. 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.
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!

[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.