EmonCMS, EmonHub and Bluetooth

pb66 · 2021-01-04T23:54:22.814Z

Robert.Wall:

lrwxrwxrwx 1 root root 7 Dec 31 20:26 /dev/serial0 -> ttyAMA0

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

Robert.Wall:

lrwxrwxrwx 1 root root 5 Dec 31 20:26 /dev/serial1 -> ttyS0

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?

pb66 · 2021-01-05T00:26:59.081Z

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.

pb66 · 2021-01-05T00:33:40.041Z

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

Robert.Wall · 2021-01-05T00:50:29.904Z

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

pb66 · 2021-01-05T01:00:59.189Z

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

Robert.Wall:

noting I’m not running a Pi 3 or 4:

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

Robert.Wall:

bt looks clobbered right at the end

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.

Robert.Wall · 2021-01-05T01:04:05.766Z

Robert.Wall:

noting I’m not running a Pi 3 or 4:

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

pb66:

Yep, that isn’t “stock”

Not my doing.

borpin · 2021-01-05T07:16:11.058Z

Robert.Wall:

it’s decided to update itself again.

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)

github.com

openenergymonitor/emonhub/blob/317f86ec31a995703d86e4bfce818aac75b63f13/install.sh#L24-L44


      
          if [ "$emonSD_pi_env" = "1" ]; then
              # Only install the GPIO library if on a Pi. Used by Pulse interfacer
              pip3 install RPi.GPIO
              # Need to add the emonhub user to the GPIO group
              sudo adduser emonhub gpio
          
              # RaspberryPi Serial configuration
              # disable Pi3 Bluetooth and restore UART0/ttyAMA0 over GPIOs 14 & 15;
              # 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
          
              # We also need to stop the Bluetooth modem trying to use UART
              sudo systemctl disable hciuart
          
              # Remove console from /boot/cmdline.txt
              sudo sed -i "s/console=serial0,115200 //" /boot/cmdline.txt
          
              # stop and disable serial service??
              sudo systemctl stop serial-getty@ttyAMA0.service
              sudo systemctl disable serial-getty@ttyAMA0.service
              sudo systemctl mask serial-getty@ttyAMA0.service

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.

dlongson · 2021-01-05T11:21:31.409Z

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]

pb66 · 2021-01-05T11:59:41.112Z

dlongson:

I have followed @borpin suggestion of just adding a bluetooth dongle to my Pi with Shield.

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.

pb66 · 2021-01-05T12:28:57.597Z

borpin:

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

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.

pb66 · 2021-01-05T12:32:26.731Z

Robert.Wall:

My Top Tip is install a pair of key files,

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.

pb66 · 2021-01-05T12:39:42.679Z

borpin:

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

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

github.com

openenergymonitor/emonhub/blob/317f86ec31a995703d86e4bfce818aac75b63f13/install.sh#L27-L28


      
          # Need to add the emonhub user to the GPIO group
          sudo adduser emonhub gpio

Way before the emonhub user is created 24 lines later!

github.com

openenergymonitor/emonhub/blob/317f86ec31a995703d86e4bfce818aac75b63f13/install.sh#L52-L52


      
          sudo useradd -M -r -G dialout,tty -c "emonHub user" emonhub

I’m not sure how that could work!

dlongson · 2021-01-05T12:40:15.863Z

pb66:

Ok, so shall we leave pursuing the onboard BT?

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!

pb66:

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

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:

dlongson:

please use 3 backticks on the lines before and after code blocks and avoid trying to use bold and/or itallics within code blocks

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

Robert.Wall · 2021-01-05T12:45:00.187Z

dlongson:

please use 3 backticks on the lines before and after code blocks and avoid trying to use bold and/or itallics within code blocks

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

pb66 · 2021-01-05T12:51:33.678Z

dlongson:

and as a linux newbie I’m a drag rather than as asset to the solution!

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.

dlongson:

Am I right in understanding that the logs don’t persist after a re-boot?

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.

dlongson:

I’ve failed to use ticks in my quotes. Sorry.

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

dlongson:

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

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

Robert.Wall · 2021-01-05T12:56:53.203Z

pb66:

Indeed, I has no idea it wasn’t in there, or maybe it’s hidden elsewhere?

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

dlongson:

I’m a drag rather than as asset

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.

borpin · 2021-01-05T13:33:52.365Z

pb66:

experience says nothing is that “obvious” round these parts, but thank you for the link.

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.

pb66:

issuing a
sudo systemctl enable --now hciuart
command will both enable and start the service in one move, providing the ports are sorted.

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 · 2021-01-06T04:09:33.787Z

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

chrissg6eui · 2021-03-05T21:25:53.180Z

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

borpin · 2023-09-27T06:59:02.276Z

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