Hi folks! This project sounds so awesome that I decided to build my own. I had some pcbs made and I assembled 2 boards. I’m handy with soldering and burning bootloaders and uploading code, so my EmonPi v1.6 pcbs are good to go, but I chose not to populate the wireless radio portion as I won’t be using any external nodes/sensors.
I successfully flashed the Uno bootloader to the 328, and used an FTDI cable to successfully upload the code (from the firmware folder) to the 328 after that. I guess this second part wasn’t needed as the pi will upload that code for me when running the updater…(?)
My questions are, do I NEED the wireless radio? My dashboard doesn’t show any inputs available. but now I believe I’m missing the next part:
Do I need to power the Raspberry Pi 3 via 5v usb plug AND the EmonPi pcb via 5v usb? Wouldn’t one power the other? So far I’ve just been powering the raspi via usb plug. I see that per the schematic, this is not true…wouldn’t that be an easy thing to do? I’m thinking that maybe powering the EmonPi pcb will power the raspi (have yet to try that; will do that when I get home tonight).
Thanks for this great project! The support is awesome, too
The shop supplied emonPi’s are powered via a single mini-usb socket on the emonpi add-on board, which in turn powers the RPi via the GPIO. The micro-usb on the RPi is not used so hopefully when you try that later you will see some data.
However !!
You may find that the standard sketch will not run without the RFM module populated, this can be easily be changed in the sketch though. But the problem you will then face is that the emonpi updater will over-write any custom sketch you install and whilst you can alter the firmware updater code to not overwrite your sketch or to use your sketch at update time instead, you may find the emonpi updates overwrite those changes to the firmware updater too.
You may have to choose between installing the RFM module or running a non-standard set-up and manually updating etc. For the cost of a RFM module it may just be easier to fit one whether you intend to use it or not.
Ah, thank you Paul. I have a sneaking suspicion that you’re right; I was power the pi via the “wrong” usb port.
I’ll probably look into populating the RFM12B module then if it will prevent future headaches. Is there not a way in the configuration to turn off the RFM12 code? Change a 1 to 0, or True to False somewhere? That would be the easiest…
Not that can persist a firmware update no. It would require the use of the AVR’s eeprom or an additional setting added to emonHub so it can manage the “RFM vs No RFM” setting. But since the emonPi is only supplied with an RFM. I think the demand for such a feature will be almost zero and therefore it just adds complication without adding much value, not to mention the extra work to implement it.
Ok, an update. I used the correct usb plug (the one on the emonPi pcb) to power things but I’m still not seeing any available inputs on the emonPi Dashboard.
I thought maybe adding an rfm12 to the emonPi pcb would help, and I found one laying around (unknown status, though), and soldered it in place; no difference. So the rfm12 I soldered is either broken or has no effect.
I tried using the serial interface to talk to the rfm12 via the pi (via ssh), and it connects (I think) to the /dev/ttyAMA0 port but nothing happens when I send “v”. I tried 9600, 38400, 57600, 115200 and nothing. So my next thought is the firmware on the 328 isn’t the correct stuff…?
I have no problem flashing new bootloader to the 328; I just put optiboot for 32 pin atmega’s on it, isn’t that correct? I saw a “bootloader.hex” file on the pi but I’m not sure how to upload that one (via pi, via ssh). I have another Uno on my desk that I use as an AVR ISP and burned the bootloader on the emonPi pcb via the ISP header. Then I uploaded the “firmware.ino” sketch via the “ftdi” header.
Does the raspi upload the bootloader and/or the sketch when the emonPi Update command is issued via the web interface? I would guess so, but I’m starting to think there’s still an issue somewhere.
I have brand new RFM69 modules coming soon so I will replace my (unknown status) rfm12 chip with those soon.
I also forgot to mention that my emonPi Dashboard log shows (something to the effect) Connecting to MQTT, Connected!, Connection failed, all within 1 second or so. I downloaded the 7 Nov SD image and burned it and things seem to be working…? If I have to redo that, no problem, I can.
So last night I reflashed my sd card with Nov 7 SD image. I also reflashed the bootloader on the emonPi pcb, and uploaded the “firmware.ino” sketch, this time using the ISP header, not the “FTDI” header.
It’s working! Well, I’m seeing data via my inputs now, just not on all inputs. CT2 doesn’t seem to report any data…not sure why, but I’ll tackle that next.
Thanks for the help! This forum is awesome, as well as this product
No, they weren’t. I assumed (incorrectly) that the CT’s were plug-n-play…but now I seem to remember that they need to be plugged in at boot. I’ll try that tonight and I bet you’re right, that CT2 will work now (after reboot).
It’s done to avoid reporting small numbers from noise if there’s no CT present. Absence of a plug grounds the input and that’s detected at start-up, thereafter that input is ignored until it restarts on power-up (I’m not even sure if you can reboot just the Atmel 328 in a Pi).
My emonpi pcb building is almost finish, but I don’t know, how can I burn the bootloader and the firmware the first time to the Atmega? Please, help me!
