EmonCMS, EmonHub and Bluetooth

Emoncms
12

The GPIO UART is mapped to the higher quality “/dev/ttyAMA0” serial port

and BT is mapped to the lower quality “/dev/ttyS0” serial port

So the BT serial port should be accessible on both “/dev/ttyS0” and “/dev/serial1” whilst configured this way and the emonpi/rfm2pi are addressed at “/dev/ttyAMA0” and “/dev/serial0” whilst configured this way.

Best to always use “/dev/serial1” for BT and “/dev/serial0” for GPIO IMO but the current OEM practice is to always use “/dev/ttyAMA0” for the GPIO rather than edit the emonhub.conf.

It would appear the current config uses the “swap BT and GPIO” overlay now (I’ll look up the proper name in a min).

BT should work, but it maybe let down by the lower quality (slower) port, either port would suffice for the relatively low requirements of the emonpi/rfm2pi boards so I’m not sure why they get swapped. Personally I assume that the RPF know a thing or 2 about Pi’s and swap the high quality port to the BT for a reason?

1 Like
13

Is there a line

dtoverlay=pi3-miniuart-bt

or

dtoverlay=miniuart-bt

in /boot/config.txt?

I have just been looking through the emonscripts repo and can’t find where the ports are remapped. In fact I can’t find any active ref to the config.txt (there’s a bit commented out about arm_freq), I’ve searched the repo for “miniuart-bt” and “dtoverlay” with zero results. I have no idea how the emonSD image is not as per the standard raspIO image in this respect, maybe it’s an undocumanted edit during production?

Can you post your /boot/config.txt content please.

14

Top-tip!

If (as I do) you run this command line just once

printf 'alias lsser="ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null"\n' >> ~/.bash_aliases && source ~/.bashrc

it will simplify keeping an eye on the serial ports as you can then use just lsser (like ls or lsusb but for serial info)

pi@Pi4:~ $ lsser
lrwxrwxrwx 1 root root          5 Jan  4 21:17  /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root          7 Jan  4 21:17  /dev/serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204, 64 Jan  4 21:17  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Jan  4 21:17  /dev/ttyS0

very handy when swapping serial ports around or when plugging in arduino’s or programmers via USB etc

1 Like
15

:angry: I’d powered it down, now restarting it, it’s decided to update itself again. It’s a good job it’s past midnight and I’ve got free Internet, because it’s a bit naughty downloading and updating without asking. And overwriting my CM front end again.
(How do you get a WiFi signal strength of 140%?)

Here’s the file - bt looks clobbered right at the end - noting I’m not running a Pi 3 or 4:

pi@emonpi:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
dtoverlay=pi3-disable-bt

And given that it’s just done an update, here’s:

pi@emonpi:~ $ ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null
lrwxrwxrwx 1 root root          7 Jan  4 23:54  /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root          5 Jan  4 23:54  /dev/serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Jan  5 00:34  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Jan  4 23:54  /dev/ttyS0

[unchanged]

My Top Tip is install a pair of key files, then the machine you’re connecting to the Pi gets access, and if you didn’t set a password on the key file, you don’t need the SSH password again (until you access it from a different machine, or delete the private key).

16

Yeah I was just about to hit the hay too, sorry.

So what are you running? It looks like it has 2 serial ports.

Yep, that isn’t “stock” the at last line has been added without a comment or even a spacing line. I can’t see that in the emonscripts anywhere.

17

Oops - yes I am, I was thinking I’d got the Pi 2B, and I haven’t. :sleepy:

Not my doing.

1 Like
18

What is updating - emoncms or Rasbian/Raspberry OS?

I am still on the previous SDImage - emonSD-17Oct19

pi@emonpi:/opt/openenergymonitor/emonhub/service $ ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null
lrwxrwxrwx 1 root root          7 Dec 12 11:17  /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root          5 Dec 12 11:17  /dev/serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Dec 12 12:14  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Dec 12 11:17  /dev/ttyS0

Changes to the config.txt are now done in the emonhub install (for obvious reasons)

This means all the bits about freq changes etc have been dropped as it just modifies the installed file.

Note some of the comments - what is done might not be correct or for the correct reasons based on other posts.

19

Hi @pb66.
One of my My RPi 3B (set up as an emonBase 24July20 version) has come up with:

lrwxrwxrwx 1 root root 7 Dec 21 23:17 /dev/serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204, 64 Dec 22 18:06 /dev/ttyAMA0

and the other RPi3B (set up as an RPi with shield, 24July20 version) comes up with

pi@emonpi:~ $ ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null
lrwxrwxrwx 1 root root 7 Jan 5 10:17 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jan 5 10:17 /dev/serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Jan 5 11:09 /dev/ttyAMA0
crw-rw---- 1 root dialout 4, 64 Jan 5 10:17 /dev/ttyS0

I have followed @borpin suggestion of just adding a bluetooth dongle to my Pi with Shield. That has worked in so far as I was able to follow all the instructions in the section on emonHub interfacers for the SMA (EmonHub Interfacers - Guide | OpenEnergyMonitor) and it reported correctly to the local copy of emonCMS (result!). However, any attempt to restart the hub after adjusting settings crashed the pi, and indeed it crashed anyway about 30 mins after I left it alone last night. So I’m progressing. Slowly

[mod - edited code quotes for readability, please use 3 backticks on the lines before and after code blocks and avoid trying to use bold and/or itallics within code blocks]

[mod - edit 2, still doesn’t look right as the tabs have been lost along the way. It is so much better for all if you just copy and paste code/logs etc and add the triple ticks for and aft, thank you]

20

Ok, so shall we leave pursuing the onboard BT? I don’t want to confuse things if your happy with that approach. I would have been nice to sort this once and for all but I have no idea if there is any appetite for changes in the OEM approach.

Regards the crashing you would probably need to look at the emonhub logs for info.

21

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.

22

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.

23

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!

24

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
25

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

26

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:

27

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.

28

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.

30

@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
31

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

32

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