💬 Ikea Molgan Hack

[openhardware.io]

https://www.mysensors.org/view/274/Ikea-Molgan-Hack

[Yveaux]

MySensors sketch is still missing. After polishing I will add it to the repo

[scalz]

Sweet

[GertSanders]

hi Ivo, very nice to see this on OpenHardware.io
Any chance you find the time to reverse engineer the Molgan board, or did someone already do that ? I would like to see a schematic of the original board, to recreate it with some additions.

[Yveaux]

@GertSanders I made a start with it but didn't finish it. It is quite a standard design.

[Cliff Karlsson]

Are the components in the top right corner not needed?

[Yveaux]

@Cliff-Karlsson it's for a sha204. Only needed if you use hardware signing.

[Yveaux]

Added a basic sketch to the repo. Enjoy!

[david fagotin]

@openhardware.io

Hello
I would like to know if the pcb sold its virgin or mount.
Thank you in advance and congratulations for the work done...

[Yveaux]

@david-fagotin From what I understand the 10xPCB order is for bare PCB's.
A kit is in preparation from one of out suppliers, but I don't think it'll have the SMD parts mounted.
And ofcourse you can always make a donation to me

[david fagotin]

@Yveaux said:

From what I understand the 10xPCB order is for bare PCB's.
A kit is in preparation from one of out suppliers, but I don't think it'll have the SMD parts mounted.
And ofcourse you can always make a donation to me

If your kit goes out soon I will wait and I would give you a donation at that time !

[LastSamurai]

Some short questions as I will start to assemble one of these very soon. Great work @Yveaux !

• What are the SJ1 and 2 parts on the pcb?Just some measurement points where I can cut the trace?
• Why did you put in the pullup for the CS line on the NRF? Never saw that one before
• The wire to the batterie spring is need to be able to use only 2 batteries for the addon pcb, right?
• But you use 3 batteries and both connection points to the main pcb still?
• Any particular reason why you did not make your pcb bigger so that it reaches the + from the main pcb too?

[Yveaux]

@LastSamurai

• What are the SJ1 and 2 parts on the pcb?Just some measurement points where I can cut the trace?

The solder jumpers are to support ATmega328PB. You need to open them when mounting an PB version.

• Why did you put in the pullup for the CS line on the NRF? Never saw that one before

Habit With multiple SPI devices on a bus it's good practise to have a pullup on all of the CS lines. Here it isn't really required though.

• The wire to the batterie spring is need to be able to use only 2 batteries for the addon pcb, right?

Yes, the addon runs on 2xAAA, the PIR on 3xAAA
By powering the addon with 2xAAA it can be powered directly without an extra voltage regulator.

• But you use 3 batteries and both connection points to the main pcb still?

The original connection points are still required to power the bottom PIR PCB. Both PCB's share a common ground.

• Any particular reason why you did not make your pcb bigger so that it reaches the + from the main pcb too?

This size I could fit more sub-PCB's in a panelized design for the board house. And, as said, the addon PCB doesn't require the + on the main PCB.

[GertSanders]

This one made it on the Adafruit blog:

https://blog.adafruit.com/2016/11/30/add-nrf2401-arduino-functionality-to-hacked-ikea-molgan-led-lamp-ikeausa/

Great Success Yveaux !!!

[Yveaux]

@GertSanders Awesome! Thanks for the tip man!

[LastSamurai]

I finished my first hacked molgan 2 days ago and it's detecting motion really well (and looks so much better than my custom builds).
So overall I love it but it also seems to have one problem: batteries...

I started it about 48h ago and the first reading was 2.119V but within some hours it dropped to 2.072V, though today it climbed back up to 2.096V. Thats still 23mV in ~2 days though.
Is this just the discharge curve and some imprecise readings? @Yveaux Whats the consumption of your modules?

[Yveaux]

@LastSamurai I don't have the exact figures at hand, but I had a look at the reported battery consumption of one of them. It dropped from 81% in August to 70% today.
I'd just let it run for a while and see how it goes.

[LastSamurai]

So yesterday my molgan started to constantly trigger, which I think might indicate that the voltage is too low. It has dropped down to 1950mV. I will try it with new batteries later today, but the power consumption still seems to be way too high compared to yours @Yveaux.
I have removed R17 to disable all leds and I have changed the fuses and used your sketch. Any idea what might have gone wrong?

[Yveaux]

@LastSamurai can you measure the consumption of individual parts? E.g. The Molgan hardware, the arduino and the radio?

[LastSamurai]

@Yveaux Ok I will try to do that. I did try other (new) batteries though and got the same values (about 2V strangely). Then it started to continuously trigger. I described the problem here.
It's so frustrating, but something seems to be wrong with my whole network I guess....

[Yveaux]

@LastSamurai how did you measure 2V? Measured with a DMM 2XAAA fresh alkaline batteries should be more in the 3V range. This makes a big difference, as at around 2V the Pir starts to behave weird, as you already experienced.

[LastSamurai]

@Yveaux I used the vcc library to let the atmega328 measure the voltage and send it as a sensor value to my controller. I guess I will have to investigate that too. Measuring the batteries outside the case with a multimeter I got 1.5V for each one (without any load though).

[LastSamurai]

PS I just measured with the multimeter and the measurements are strange. The board voltage is at about 2.9V (so more like expected) and reaches the atmega as well as the NRF. Overall voltage is at about 4.8V.
The trigger pad seems to be constantly high though (~2.7V) and the node doesn't seem to show up at the gateway anymore. I guess some serial debugging is needed now. Perhaps some component has died... falsy NRF modules would perhaps explain the errors with my nodes

PPS now the sensor is sending again (strange). The trigger pad is still constantly high though. I guess I will have to desolder the pcb again to have a look at the PIR pcb. Perhaps somethings wrong there...

[LastSamurai]

So I took some measurements and and the molgan pcb on its own works just fine. The mysensors pcb with a stable 3.3V power source worked too. When I wanted to measure the power consumption I realized that a fuse in my multimeter was defect... so I am still waiting for a replacement. Will post an update once its here.

[LastSamurai]

Sorry for the spam here but I have the fuse now and have just been measuring the pcbs.

• Molgan PIR pcb: 17mA triggered, 7mA otherwise
• mysensors PCB: 18mA sending, 6uA sleeping

The second one looks fine to me but the molgan pcb draws way to much power for battery usage, right?! @Yveaux did you measure the power consumption of yours? I just realized that I did not change the resistor that controls the trigger time. I thought 30s are fine but that makes it draw more power too...

I will also start to test with the second molgan I bought. Really want this to work

[Yveaux]

@LastSamurai said in Ikea Molgan Hack:

Sorry for the spam here but I have the fuse now and have just been measuring the pcbs.

No worries, that's what this thread is for, right?

The second one looks fine to me but the molgan pcb draws way to much power for battery usage, right?! @Yveaux did you measure the power consumption of yours?

I did measure it (when I found out the power usage was less with the regulator, than without) but I can't seem to find the results anymore...
@dynamite mentioned in this thread "The powerconsumption of the PIR when not triggered is approx. 60 uA and when triggered 160 uA.".

I just realized that I did not change the resistor that controls the trigger time. I thought 30s are fine but that makes it draw more power too...

Only marginally I guess, unless it triggers all the time.

I will also start to test with the second molgan I bought. Really want this to work

Please do so, at least for comparison.

[LastSamurai]

I measured with the new molgan and got nearly the same results. Perhaps my cheap multimeter isn't accurate enough though.
I moved the mysensor pcb to the new molgan pcb and tried this out. Strange result: at first it only send the initial messages but no triggers. After some minutes the opposite happened: it started to randomly trigger (or at least send them). Then after some more time the random triggers stopped and now its working as intended.
Perhaps it just the setup time of the PIR or the warmer air coming from a heater nearby... I will keep an eye on it the next days.

[LastSamurai]

Ok I did some more testing and the error seems to be pretty random. Sometimes the PIR works as intended for some time, sometimes it just keeps triggering constantly. I am pretty sure sleeping/waking up or sending the message is somehow influencing the PIR (don't know what else it could be).
Does anyone have an idea how to fix this (some wait() code or some cap somewhere perhaps)?

[scalz]

i've not looked at the molgan..but for fixing this:

• if capa to place, that would be directly to the PIR sensor VCC pin (100uf), ideally close to it.
• or by software : ignoring false triggers, or disable the irq when it's not needed, or slow down a little bit clock during these false trigger.

[gohan]

Agreed on the capacitor on the vcc, I had some random triggers on a pir sensor and they were gone when I added a cap to the 5v pin

[LastSamurai]

@scalz and @gohan thank you very much! I added a 47uF electrolytic cap which helped a little. Afterwards I also added another 22nF ceramic cap. After that it seems to working just fine (for about 2 days now).
@Yveaux perhaps you could create a new version including some caps to fix this problem for anyone? I am still glad to finally be able to use this good looking cheap sensor. Thanks again for your work

[Yveaux]

@LastSamurai Great to hear it runs stable so far!
As I understood the capacitor is placed on the Molgan PCB, and that's a PCB I cannot redesign...
Where execactly did you plave the capacitor? Could you post a picture, so I can add it as a hint to the build guide.

[LastSamurai]

As the Molgan PCB works fine without the addon PCB it has to be its "fault" so I guess it makes sense to add them there. I placed the caps between GND and VCC of your pcb (which is linked to the molgan pcb). I also noticed that your pcb doesn't have any caps at the radio (right?). Normally you would add a 47uF caps there. Might that be part of the problem?

Here is a quick picture. I can take a better one later.

[Yveaux]

@LastSamurai said in Ikea Molgan Hack:

As the Molgan PCB works fine without the addon PCB it has to be its "fault" so I guess it makes sense to add them there. I placed the caps between GND and VCC of your pcb (which is linked to the molgan pcb).

Well, not too sure about that. In your case the PIR seems to suffer from disturbances introduced by the addon board (quick conclusion), so I would try to buffer there.
The PIR seems already buffered at two places (red & green caps):

Adding an extra cap in parallel to the existing one(s) on the PIR-side of the PCB could be a simple solution.
I have to dive into the Molgan's PCB layout to see if that's possible.

I also noticed that your pcb doesn't have any caps at the radio (right?). Normally you would add a 47uF caps there. Might that be part of the problem?

The radio has 100nF for decoupling on its own PCB.
I never mount a 47uF buffering cap (or some similar value) for battery powered sensors.

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