EmonCMS, EmonHub and Bluetooth

Ahh so that’s where they are, ok, I’d agree that is a better place but experience says nothing is that “obvious” round these parts, but thank you for the link.

This comment and code snippet added 2 years ago shows the current position

    # Review should this be: dtoverlay=pi3-miniuart-bt?
    sudo sed -i -n '/dtoverlay=pi3-disable-bt/!p;$a dtoverlay=pi3-disable-bt' /boot/config.txt

using dtoverlay=pi3-disable-bt does what is says on the tin!

using dtoverlay=pi3-miniuart-bt would be a small step in the right direction as it would enable the BT albeit using the lesser serial port.

The correct approach would be to do nothing, leave it as it was, delete that whole block. It would mean changing the addres used in emonhub.conf to serial0 but that should be done regardless as the GPIO serial port (serial0) is always used regardless of model Pi, regardless of whether BT is onboard/used, regardless of how the serial ports are configured and regardless of which overlay is used(or not).

All that is needed is “enable_uart=1” added to the end of the config.txt to ensure the ttyAMA0 port is enabled depite the console being disabled (by removing “console=serial0,115200” from cmdline.txt of course). The prescience of “enable_uart=1” in config.txt disables the “turbo boosting” functions of the MCU which was the cause of the inconsistent serial baud rates on ttyS0 when the Pi3 was first launched, as it was linked to a variable clock speed. That has not been an issue for years now, we do not need any clock speed adjustments, serial port swaps, BT disabling etc.

Ahh! @dlongson, a penny just dropped, as well as enabling the serial port, you would have also needed to enable the hciuart service to use the on-board BT (if you hadn’t already) as it appears to be belt and braces disabled in these lines (again not needed if this was reviewed)

    # We also need to stop the Bluetooth modem trying to use UART
    sudo systemctl disable hciuart

issuing a

sudo systemctl enable --now hciuart

command will both enable and start the service in one move, providing the ports are sorted.

Absolutely, that is the ultimate top-tip. I have been doing that for years, since the Pi2+hdd image days prior to the oemgateway and then emonhub, it makes so much sense, it’s far easier to auto log in and so much safer too, a real no brainer if you have ssh enabled and yet there is no mention of it in any of our guides AFAIK.

Interesting that the install script tries to add the emonhub user to the gpio group

Way before the emonhub user is created 24 lines later!

I’m not sure how that could work!

It seems a shame to not use an onboard option - so much of the OEM works so remarkably well. But I’m aware that all involved volunteer, and as a linux newbie I’m a drag rather than as asset to the solution!

Am I right in understanding that the logs don’t persist after a re-boot? Just had a look in var/logs/emonhub, and all in there seems to be freshly baked…

Finally (for the mod today) - I’ve failed to use ticks in my quotes. Sorry. I had a hunch I’d read about that, looked in the FAQs and found nothing. Might be worth adding:

to the FAQ in the ‘How to ask for help’ section, as a bullet, particularly as the FAQ encourages quotes and snippets

1 Like

To the instruction to add the backticks, I add
“If it is something like php you can add a language identifier after the first 3 backticks:” ```php " or even " ```text " if you don’t want any language markup applied."

Not at all! I think users that are willing to learn or at the very least invest time in following advice and answering questions are the only way the project can improve these things. Often, users get advice like “just sidestep that like this” or “a easy workaround is” etc. My preference is always to locate and fix the issue whilst you have a willing candidate because some issues cannot be replicated and/or some applications differ to the mainstream.

Not entirely! the logs are persited hourly and at a proper shutdown. So if the Pi crashes the logs won’t be persisted and/or if you pull the power. If you “reboot” correctly via the command line (or reset button on the emonPi) then they should be retained. BUT only the most recent logs are kept in ram, the reason you see only new logs is probably because they are rotated frequently to disk, check /var/log.old for older logs.

No problem, it’s a frequent issue, don’t worry it happens.

Indeed, I had no idea it wasn’t in there, or maybe it’s hidden elsewhere? sorry on behalf of the forum that it’s not obvious :grin:

Like a lot of things, the fact that it’s missing isn’t obvious to us Moderators who never need to look for things like that. (So another reason why

is something I too wholly disagree with.)

@Bill.Thomson is the de facto maintainer of the FAQ, there’s a PM on its way to him. So it should appear in there before long.

By obvious I meant that the changes are only necessary for emonhub operation but equally are necessary for emonhub. When it was in the main scripts, the install of emonhub as a stanbdalone didn’t work.

You need to unmask it first IIRC.

I have moved this to an issue on GitHub to discuss what should actually be done.

@Bill.Thomson is the de facto maintainer of the FAQ, there’s a PM on its way to him. So it should appear in there before long.

FAQ updated 5 Jan 21.

1 Like

Did this ever get resolved or changed?

I’m having the same issues trying to get bluetooth to work on a 4B, I’m currently running the Pi as an emonbase, although I’ve not yet fitted the RFM pcb yet, so none of the serial ports should be in use.

I’ve tried commenting out the last line of “config.txt” (dtoverlay=pi3-disable-bt) and I get this:

pi@emonpi:~$ ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null
lrwxrwxrwx 1 root root          7 Mar  5 21:03  /dev/serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204, 64 Mar  5 21:04  /dev/ttyAMA0
crw-rw---- 1 root dialout 188,  0 Mar  5 21:03  /dev/ttyUSB0

Prior to commenting it out I get this:

pi@emonpi:~$ ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null
lrwxrwxrwx 1 root root          7 Mar  5 20:49  /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root          5 Mar  5 20:49  /dev/serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Mar  5 20:49  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Mar  5 20:49  /dev/ttyS0
crw-rw---- 1 root dialout 188,  0 Mar  5 20:49  /dev/ttyUSB0

Chris

2 posts were split to a new topic: Hciuart service fails to start