Hi, first post on the forums, I’d just received my OEM equipment, and am keenly looking to get it all working.
My intention was to use one of my older 1B Pi units that I have at hand, rather than buying an updated one (even though onboard WiFi would solve a lot of issues). However, initial tests using Raspbian 9 wouldn’t allow the Pi to boot with the EmonBase unit fitted to the GPIO header (tested across two separate SD card images).
Before I go too much further, can I get confirmation of whether the EmonBase RF unit is compatible with the older 26 pin Pi IO?
Yes is the short answer. RPis are all pin compatible (just the early ones had less pins). I have an RF unit on an Orange Pi (which again is pin compatible).
You say “Raspbian 9” - do you mean just a new Raspbian Lite image?
It might be an overlays issue & if so I think @pb66 is your man.
Awesome, was expecting as much. Yes, it’d be a Lite image, that’s generally what I deploy. I’ll pursue further and see if I can’t find out what’s going on.
As far as I am aware, all it gets is power and UART connections. However, I know the UART setup did change on later models. I would have thought the first boot of the Raspbian Lite would detect a 1B and set it up appropriately.
Are you booting with a fresh Raspbian lite image? Do you do the initial boot without the RFM module connected (I’d suggest not)? Have you disabled the serial console?
Behaviour appears consistent across both Raspbian Buster (10) Lite and Stretch (9) Lite. Plug the header unit in and in won’t boot, with an endless stream of errors across the screen. I did get it to (partially) boot with the latest EmonSD image though, although it appeared to hang before it finally gave me a command prompt.
Remove the header and it’ll boot successfully. I’ll double check any possible UART changes, its possible that this is already set and not an issue for the EmonSD image.
I’ll ask again - have you disabled the serial console?
Look at this readme, and search for ‘console’. I’m pretty sure you need to do this. There are also some instructions on editing the cmdline.txt file as well.
As Brian suggests, it will most likely be the GPIO uart being used by the add-on board to pass date whilst the Pi is still configured to use the serial console. The net result is the OS is getting lots of stuff it doesn’t understand being pushed via the command line.
You need to either flash the sdcard, edit cmdline.txt and then boot the Pi with the add-on board attached. Or do as you have been and boot without the add-on until you disable the serial console, then add the add-on board.
You shouldn’t need any overlays on a Pi 1b because there is only one accessible serial port.
Ok, after some partially related playing around with SD cards and so on I got it all to work. You were both correct; thanks for the assisance, the serial-getty service needed to be disabled, it all behaved after that.
I did have some more fun following the instructions to get emonHub working but have managed to eventually succeed. One thing I did discover, the inputs are now a Module (Devices) and it took me a little while to work out that I needed to install this separately, it wasn’t in the base instructions.
I’m now receiving data from two separate sensors, and will get around to actually installing the gear so I can monitor power.
Actually, I’m now thinking I should have pointed you in that direction in the first place
[edit] @TrystanLea - may need to add a note to the scripts readme to tell users not to install the RFM / EmonBase board until after the system has been installed - possibly on older RPis only.
Happy to review, I think I’ve still got an almost working Buster install on a card that I can look at too. Obviously the packages (PHP, MariaDB etc) were incorrect for the later PHP and MariaDB versions required, but I managed to get past that.
I’ve also got a spare SD card or two, I’ll have another attempt at install from scratch and see if I can’t note down the extra steps I needed to take.
