AussieMakerGeek

Yeah that's a good point too - You could sleep the microcontroller and only wake on key input.I was so inspired by this, I've mangled some of your ideas and code into an existing project that I have which is a door access module based on an RFID reader to now give multi factor access with OTP.I am using:ESP32 (may be adaptable to ESP8266)DS3231 RTCWiegand RFID reader (stores 20+ cards + MFA secret)TTP229 16 button capacitive touch keypad.I have also implemented:'Master' access code via the keypad - Silently ignores bad codes etc-> Will work without wifi and/or MFA so it is a fallback code.Uses the same time library but only to sync time on the RTC - OTP codes are generated from RTC time.Defaults to just RTC if no internet but keeps trying every hour.Generates 3 codes (last, current and…

Yeah that's a good point too - You could sleep the microcontroller and only wake on key input.I was so inspired by this, I've mangled some of your ideas and code into an existing project that I have which is a door access module based on an RFID reader to now give multi factor access with OTP.I am using:ESP32 (may be adaptable to ESP8266)DS3231 RTCWiegand RFID reader (stores 20+ cards + MFA secret)TTP229 16 button capacitive touch keypad.I have also implemented:'Master' access code via the keypad - Silently ignores bad codes etc-> Will work without wifi and/or MFA so it is a fallback code.Uses the same time library but only to sync time on the RTC - OTP codes are generated from RTC time.Defaults to just RTC if no internet but keeps trying every hour.Generates 3 codes (last, current and next) to compare the entered code against-> Allows for up to 90 secs of time skew, this is how most TOTP systems work.Still some polishing to do and perhaps make a custom PCB for the setup but it's completely functional as-is. I'll probably publish it as my own instructable a bit later.Thanks so much for the inspiration!

This is awesome! I'm thinking of adding a version of this to my safe for sure! I remember looking a while ago for an OTP implementation on Arduino but it didn't exist then.I currently use RFID (my own implementation) so I could add this too, as true 'MFA'.Tip - I would highly recommend adding a DS3231 RTC chip to the project. Then you can just sync the time every now and then to the RTC so it will work even without wifi. Gives you a little extra backup.Also, perhaps an 8 digit, single use 'override' code might be handy?

Re-Read step 9...

In the schematic for the Neopixel output, the cap is in the wrong orientation

FYI, the level shifter is not needed for the strips. Yes, its out of spec but it works fine directly from the ESP8266. Alternatively, all you have to do is drive the first led at 3v and the rest at 5v (cut the + between the first 2 leds and inject 5v at the second led) This brings it back into spec and the output of the first led will 'clean' the signal.Source: My personal experience running 20,000 leds for a christmas light display...Love to see it in action!

Yep, 1000w 48v scooter motor running at 12v (HP server power supply) with 3 X BTS7960 in parallel to handle the 80+ amp peaks at full lock. I run it at about 50%. Much more than that and it becomes painful.

What's the actual error you are getting?

Even better - I'm not sure when he will be releasing the NRF support but from what I can tell he has it working already. There has not been a release for a few months so hopefully it's not too far away. I doubt you'd be wasting your time on the TX side for the moment using my code though as chances are it would be an atmega doing the TX in his solution (or could be adapted if he went STM32 but it would be massive overkill - You could ask...). I was running MMOS for my wheel/pedals but it's old and felt wrong. The original EMC for Arduino Leonardo was abandoned ages ago - I'm not sure how the new one came about but I don't think Ebolz was the original EMC author, regardless, what he has done with it now is miles ahead of where it was. I have been running it for about 18 months now on an…

Even better - I'm not sure when he will be releasing the NRF support but from what I can tell he has it working already. There has not been a release for a few months so hopefully it's not too far away. I doubt you'd be wasting your time on the TX side for the moment using my code though as chances are it would be an atmega doing the TX in his solution (or could be adapted if he went STM32 but it would be massive overkill - You could ask...). I was running MMOS for my wheel/pedals but it's old and felt wrong. The original EMC for Arduino Leonardo was abandoned ages ago - I'm not sure how the new one came about but I don't think Ebolz was the original EMC author, regardless, what he has done with it now is miles ahead of where it was. I have been running it for about 18 months now on an STM32F407VGT6 dev board I bought for $12

Ah, I see the problem - I must have accidentally messed up the file before I updated it. The line BEFORE the joystick declaration is missing a ';'int CSNPin = 9;

I use rotary encoders but not on my wheel. I know Ebolz Magy (EMC Developments) is working on adding NRF support to his FFB wheel controller/code (based on STM32 which I also use for my wheel). I developed this before that even existed but once it goes live, it might even be worth migrating over. I'm pretty sure he will implement encoders in that code.

I found that if you take the lens off of the PIR, it decreases the sensitivity and makes them more like a beam sensor. You can even put a small tube over them to limit it more.

Have you used this arduino for something else before? Perhaps there is data in the EEPROM that is wrong. That would be my guess. If there is data there that is outside of the bounds within this program it may not work right. Run a sketch to clear the EEPROM and see what happens.

Ask what?

I have tried this several times but found it too inconsistent. Yes it's faster but often the egg cooks evenly (not unevenly like you want) i.e if the White is cooked enough, the yolk is hard too, purely because of the way a microwave works. I'll stick to the traditional method, yes it's longer but consistent results - Boiling water with a little vinegar and 3 mins on the stove produces a perfect poached egg.

Great work! Just curious as to why you would not implement IR receiver into the same unit? That would make more sense. Also, this would work 'off the shelf' with Tasmota firmware. I made a similar device Tasmota -> Mqtt -> OpenHab. Openhab also has a cloud connector and works with google assistant.

This hardware + Tasmota Firmware + Openhab = Google assistant.You can also buy an inexpensive $15 IR blaster by lenovo that has built in GA compatibility.

Very well written and documented. Great afternoon project. Well done!

Once again, encoder is not a button, you can't read it like that.Normally, you attach an interrupt onto one of the pins, then in the interrupt routine you check the other pin's state. If it is high, it will be one direction, low, the other.Atmega238 only has 2 interrupt pins (2 and 3). You can move those to A6/7 for the matrix but if you want more than one, then you still need more pins for the 'B' pin on the encoder. These could be sacrificed from the 4 analog inputs.

You will need to add constraints on the encoder value to ensure it does not go negative or more than 1023 but keep the interrupt routine(s) as small as possible.

Here is some example code. Not checked for full correctness:

Well encoders are not buttons - They will always have one contact connected. This code is not designed for encoders.