DD-WRT Upgrade part two

The upgrade of DD-WRT that I performed this last Saturday brought the version from a 2019 release to a 2022 release. DD-WRT always recommends doing a factory reset of settings before and after flashing a new firmware. As far as I’ve been able to find out, DD-WRT doesn’t provide any way to back up the settings in any form other than a binary download that is not compatible between versions. This shortcoming makes upgrading a router with many customized settings a difficult process.

dd-wrt status screen

I performed the flash upgrade without resetting everything to defaults. It wasn’t until I was going to bed on Saturday night that I realized not all things were working properly. All of the ipv4 services appeared to be working properly. The ipv6 services were not working properly on my internal network clients.

I have a Microsoft Windows Server 2016 Essentials machine running several services including file sharing on my internal network. I also have my Windows 10 desktop, and several Raspberry Pi machines. Some of the Pi machines access the file shares on the server for both reading and writing.

I’ve found that when ipv6 is not allocating global addresses for the windows server and clients, file sharing doesn’t work properly. This is an issue I don’t understand, and don’t want to change the default operation of the windows server or windows client machines, which might create more long term maintenance headaches.

Among the customizations I have set in the router:

  • Router Name
  • Domain Name
  • Local IP (v4) address is 192.168.0.1 instead of 192.168.1.1
  • close to 35 DHCP reservations for machines that run on my internal network.
  • IPv6 enabled and configured for DHCPv6 with Prefix Delegation
  • DDNS service configured as in previous post.
  • Wireless SSID
  • Wireless Password
  • SSH access to the router with rsa keys entered for allowed machines.

I figured out that the primary settings for DHCP and DNS resolution are run using dnsmasq, and the configuration file can be viewed by looking at /tmp/dnsmasq.conf in the ssh console. All of the dns reservations are listed in the form of:

dhcp-host=b0:39:56:78:83:b0,GS108Tv2,192.168.0.123,1440m
dhcp-host=28:c6:8e:09:30:cb,GS108Tv2-LR,192.168.0.125,1440m
dhcp-host=04:a1:51:b0:a6:9a,GS108Tv2-OW,192.168.0.124,1440m

Copying all of them out of the console as one entry and adding them to the Additional Dnsmasq Options field was much easier than pasting MAC addresses, Hostnames, and IP addresses into separate field for each entry.

After adding them via the web interface here, they look exactly like the entries created in the static leases section of the interface. I was hoping that the system would parse them and display them in the static leases section, but it doesn’t seem to do that.

My SSH terminal program is configured to send a series of commands to the console each time I connect which reminds me of the current setup as well as how to examine it after a long time when I’ve not worked on the device.

  • date ; uptime
  • route -A inet
  • route -A inet6
  • ip6tables -vnL
  • cat /tmp/dnsmasq.conf
  • cat /tmp/dhcp6c.conf
  • cat /tmp/radvd.conf
  • ifconfig

I’m currently not dumping the iptables (v4) output simply because there are a large number of rules that don’t get used which takes up a lot of extra space scrolling by.

I’ve compared the ipv4 and ipv6 routes from when ipv6 was not working, and they are identical.

root@Netgear-R7000:~# route -A inet
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         br1-mballard-v1 0.0.0.0         UG    0      0        0 vlan2
24.35.91.128    *               255.255.255.192 U     0      0        0 vlan2
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
192.168.0.0     *               255.255.255.0   U     0      0        0 br0
root@Netgear-R7000:~# route -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
2604:4080:1304::/64                         ::                                      UA    256    0        0 vlan2   
2604:4080:1304:8010::/60                    ::                                      U     256    0        0 br0     
fe80::/64                                   ::                                      U     256    0        0 eth0    
fe80::/64                                   ::                                      U     256    0        0 vlan1   
fe80::/64                                   ::                                      U     256    0        0 eth1    
fe80::/64                                   ::                                      U     256    0        0 eth2    
fe80::/64                                   ::                                      U     256    1       23 br0     
fe80::/64                                   ::                                      U     256    0        0 vlan2   
::/0                                        fe80::22c:c8ff:fe42:24bf                UGDA  1024   2      302 vlan2   
::/0                                        ::                                      U     2048   2       38 vlan2   
::/0                                        ::                                      !n    -1     1      372 lo      
::1/128                                     ::                                      Un    0      3       15 lo      
2604:4080:1304::/128                        ::                                      Un    0      1        0 lo      
2604:4080:1304:0:b27f:b9ff:fe83:6590/128    ::                                      Un    0      3       75 lo      
2604:4080:1304:8010::/128                   ::                                      Un    0      1        0 lo      
2604:4080:1304:8010:b27f:b9ff:fe83:6591/128 ::                                      Un    0      3       64 lo      
fe80::/128                                  ::                                      Un    0      1        0 lo      
fe80::/128                                  ::                                      Un    0      1        0 lo      
fe80::/128                                  ::                                      Un    0      1        0 lo      
fe80::/128                                  ::                                      Un    0      1        0 lo      
fe80::/128                                  ::                                      Un    0      1        0 lo      
fe80::/128                                  ::                                      Un    0      1        0 lo      
fe80::b27f:b9ff:fe83:658f/128               ::                                      Un    0      1        0 lo      
fe80::b27f:b9ff:fe83:658f/128               ::                                      Un    0      1        0 lo      
fe80::b27f:b9ff:fe83:6590/128               ::                                      Un    0      3       61 lo      
fe80::b27f:b9ff:fe83:6591/128               ::                                      Un    0      1        0 lo      
fe80::b27f:b9ff:fe83:6591/128               ::                                      Un    0      3       24 lo      
fe80::b27f:b9ff:fe83:659e/128               ::                                      Un    0      1        0 lo      
ff00::/8                                    ::                                      U     256    0        0 eth0    
ff00::/8                                    ::                                      U     256    0        0 vlan1   
ff00::/8                                    ::                                      U     256    0        0 eth1    
ff00::/8                                    ::                                      U     256    0        0 eth2    
ff00::/8                                    ::                                      U     256    2      580 br0     
ff00::/8                                    ::                                      U     256    2       12 vlan2   
::/0                                        ::                                      !n    -1     1      372 lo      

I’ve looked at the ip6tables, and it also appears identical, beyond the counters.

root@Netgear-R7000:~# ip6tables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   12  2289 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    5   376 ACCEPT     icmpv6    *      *       ::/0                 ::/0                
    0     0 ACCEPT     all      *      *       fe80::/64            ::/0                
    0     0 ACCEPT     all      br0    *       ::/0                 ::/0                
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    0     0 ACCEPT     all      *      vlan2   ::/0                 ::/0                
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128 limit: avg 2/sec burst 5
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                

Chain OUTPUT (policy ACCEPT 31 packets, 4287 bytes)
 pkts bytes target     prot opt in     out     source               destination         

I’d tried disabling Radvd on the IPv6 configuration gui and adding “enable-ra” to the Additional Dnsmasq Options, but that didn’t fix my problems. The current configuration has matching radv.conf files to the non working version.

root@Netgear-R7000:~# cat /tmp/radvd.conf
interface br0
{
 IgnoreIfMissing on;
 AdvSendAdvert on;
 MinRtrAdvInterval 3;
 MaxRtrAdvInterval 10;
 AdvHomeAgentFlag off;
 AdvManagedFlag off;
 AdvOtherConfigFlag on;
 AdvLinkMTU 1452;
 prefix 2604:4080:1304:8010::/64 
 {
  AdvOnLink on;
  AdvAutonomous on;
  AdvValidLifetime 30;
  AdvPreferredLifetime 20;
 };
 RDNSS 2607:f060:2::1 2607:f060:2:1::1{};
};

I spent a lot of time reading up on IPv6 and reminding myself of things I’d known in the past and forgotten. https://blog.dorianbolivar.com/2018/09/going-full-ipv6-with-dd-wrt.html?lr=1 is a well written post with links to more sources that I found especially helpful as it was written specifically using DD-WRT and IPv6. My only issue is that it was written nearly four years ago and may not have the same options in the DD-WRT gui as are currently available.

One of the items I added to the Additional Dnsmasq Options was a couple of host entries so that dnsmasq would resolve IPv6 addresses for my windows machines. It seems to speed up the IPv6 name discovery of my windows server while still pointing default DNS resolution at the router.

host-record entries

My conclusion is that I don’t understand what was different in the non-functioning setup I had with holdovers from the older version of DD-WRT, and going through the pain of re-installing from factory fresh configuration after each upgrade is worth the trouble. I’m still not satisfied with the best way of retrieving all of the configuration data into a text file that I can later run a difference test to see what’s changed, or needs to be changed.

Govee H5074 and VPD data

I was playing with a couple of brand new H5074 devices and realized that the iOS app now includes two new charts, Dew Point, and VPD.

VPD

The new devices report as hardware version 2.00.01 firmware version 1.00.01. My older devices all report hardware version 1.00.01 and firmware version 1.01.00.

The pressure and dew point are available in both the new and old H5074 devices, but not with any of the other units I’ve got connected. (H5177 or H5075)

I’ve not been able to find details on the data. I don’t know if it’s packed into the BLE advertising data, or only available in the connected download data.

Govee H5183 Bluetooth Wireless Meat Thermometer

GVH5183

I recently came across the Govee Meat Thermometer on sale at amazon and decided to give it a try and see if the communication protocol was similar to any of the other Govee thermometers I’ve bought, the H5177, H5075 or H5074.

The Bluetooth communication protocol is different from any of the other devices I’ve got, but after a day of staring at raw data I was able to figure out some of the details and add support to my monitoring program https://github.com/wcbonner/GoveeBTTempLogger/ . The Bluetooth announcements from the device include both the current temperature and the set alarm temperature. I’ve not yet figured out the battery strength data. The phone app displays the battery, so I know it should be available.

There’s an orange button on one side to turn the unit on. Hold for three seconds. It will beep indicating it’s on. The LED will start flashing green, and the device will periodically send Bluetooth announcements including the temperature and alarm temperature. If you connect to the device with the phone app, the LED will switch to flashing blue, indicating that it’s in a connected state. While the device is in a connected state, it doesn’t not send out announcements. To return it to standard mode, simply exit back to the top level of the app. The app will still alarm when the probe gets to set temperature. Holding the button for three seconds when it’s on will turn it off, with beeps to confirm the change.

A nice feature of this device is that it has a magnet built in, enough to hold the device to the front of a metal oven.

Details from the Amazon listing:

  • Useful Smart Alerts: If temperatures fall out of your preset range, an alarm will sound, and you will get a phone alerts notification via the Govee Home app. The probe measuring range is 0° to 300°C /32° to 572°F. Note: press and hold the orange button for 3 seconds to power on.
  • Convenient Remote Monitoring: Tired of waiting near a hot grill, With a 230ft/70m smart Bluetooth wireless control range(no obstructions), you are free to relax and check your temperatures on your smartphone at a glance. Remember to remove the protective tip before use.
  • Performance Review: Detailed temperature data and easy-to-read charts are generated within 2 hours. (Charts can’t be stored/downloaded) Perfect for a quick review or an in-depth analysis of temperature performance. Improve your cooking and temperature with calibration at ±5°C.
  • Temperature Made Easy: 28 temperature recommendations for 14 types of foods take the hassle out of cooking. Ideal for both beginner cooks and pro chefs.
  • Practical Features: Temperature switching between Fahrenheit and Celcius. (The default unit is Fahrenheit) Mute alarm function and countdown timer on the Govee Home app. The magnetic back can easily be attached to the refrigerator, oven or grill, or any other metal surface. Note: Please keep the meat thermometer unit safe from heat sources and very hot surfaces to protect its internal batteries and exterior shell.
  • Part Number: B5183011

Raspberry Pi GPSD with Pepwave MAX Transit

I’ve been wanting to do some GPS data programming with the Raspberry Pi that’s on my boat. The Pi is connected to the NMEA 2000 network, and so should be able to retrieve GPS coordinates from either my chartplotter or my AIS unit when they are powered on, but it should also be able to get the GPS data from my Max Transit cellular gateway device.

It turns out that configuring gpsd to retrieve the data from the max transit was fairly easy. I edited the file /etc/default/gpsd to include the internal address and port of my router and restarted gpsd and now the Pi has the correct location.

/etc/default/gpsd

The devices section was initially empty. I added tcp://192.168.50.1:60660 between the pair of double quotes. After that, I was able to run gpsmon with no parameters and it connects to the local machine and reports the gps statistics.

gpsmon

I’d verified that I can read the device directly over the network with the command gpsmon 192.168.50.1:60660 but I wanted to be able to write my programs without needing to know where the gps was located.

gpsmon

Access Windows Share from Raspberry Pi (revisited)

Last year I described a simple method of automounting a directory from my windows server to my Raspberry Pi. Since then I’ve gone down a couple of paths to simplify rebuilding my Raspberry Pi machines.

The method I used last year required modifying the /etc/hosts file, the /etc/fstab file, pre-creating the mount points, and creating a credentials file to store the windows login credentials.

My new method doesn’t require modification of the /etc/hosts or /etc/fstab files, or pre-creating the mount points. Instead I’m relying on two features, Multicast DNS and systemd.automount unit files.

In the old method, to find the windows server, I added it to the local hosts file on the raspberry pi.

192.168.0.12 Acid

Using Multicast DNS, if I simply recognize that I can reach the server with the name Acid.WimsWorld.local the raspberry pi will find the server on the local network. My first step was to modify my /etc/fstab enty to use the local address and clean up my hosts file.

//acid.wimsworld.local/web /media/acid/web/ cifs credentials=/etc/wimsworld.smb.credentials,noauto,x-systemd.automount,x-systemd.idle-timeout=2min,_netdev 0 0

I’d never been happy with modifying the /etc/fstab file as part of my system configuration because in newer installations it is unique to each machine, specifying the boot partitions by their formatted serial number:

proc            /proc           proc    defaults          0       0
PARTUUID=142ff4e3-01  /boot           vfat    defaults          0       2
PARTUUID=142ff4e3-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

In my recent programming projects I’ve been working with systemd unit files to control my service processes and have come to understand how they work for automounting directories as well. I like that each directory has its own unit files meaning that a modification is less likely to cause problems for the system as a whole.

The single line from the /etc/fstab file above is removed and replaced by two unit files, /etc/systemd/system/media-acid-web.mount and /etc/systemd/system/media-acid-web.automount.

[Unit]
Description=Acid Web

[Mount]
What=//acid.wimsworld.local/web
Where=/media/acid/web
Type=cifs
Options=credentials=/etc/wimsworld.smb.credentials,vers=2.1

[Install]
WantedBy=multi-user.target

and

[Unit]
Description=Automount Acid Web

[Automount]
Where=/media/acid/web
TimeoutIdleSec=120

[Install]
WantedBy=multi-user.target

I still had to create the credentials file for this to work, since I wanted the credentials file to be only root readable in a different location. /etc/wimsworld.smb.credentials

username=WindowsUsername
password=WindowsPassword
domain=OptionalDomainName

After the three files are created, systemd needs to reload its database with the systemctl daemon-reload command, the automount needs to be enabled with the systemctl enable media-acid-web.automount command, and then started with the systemctl start media-acid-web.automount command.

The naming of the mount files is important, and described explicitly in the man pages for each of mount and automount. In my case, /media/acid/web gets named media-acid-web.mount and media-acid-web.automount. I didn’t need to create mount points in the /media directory, as systemd automatically takes care of that.

I was able to create all of the above with a simple paste into my terminal with the following string:

sudo bash
cat > /etc/systemd/system/media-acid-web.mount <<EOF
[Unit]
Description=Acid Web

[Mount]
What=//acid.wimsworld.local/web
Where=/media/acid/web
Type=cifs
Options=credentials=/etc/wimsworld.smb.credentials,vers=2.1

[Install]
WantedBy=multi-user.target
EOF
cat > /etc/systemd/system/media-acid-web.automount <<EOF
[Unit]
Description=Automount Acid Web

[Automount]
Where=/media/acid/web
TimeoutIdleSec=120

[Install]
WantedBy=multi-user.target
EOF
cat > /etc/wimsworld.smb.credentials <<EOF
username=WindowsUsername
password=WindowsPassword
domain=OptionalDomainName
EOF
chmod 0600 /etc/wimsworld.smb.credentials
systemctl daemon-reload
systemctl enable media-acid-web.automount
systemctl start media-acid-web.automount
exit

With the standard Raspberry Pi setup, the cat command is not available as a sudo command while the bash shell is. I’m taking advantage of that by running the bash shell as root and then all of the other commands with root privileges.

tp-link Smart Plugs with Energy Monitoring

Several years ago I picked up a TP-Link HS110 switch so that I could turn lights on and off on a schedule. It had an interesting feature of being able to monitor energy usage as well.

The HS110 has an unfortunate design that covers the second socket in a wall outlet and makes it unusable. I purchased several HS105 units over time because two can be plugged into a standard outlet with the only drawback being the extra distance the normal plug extends from the wall. The HS105 was on sale as multipack on a somewhat regular basis. The drawback of the HS105 is that it doesn’t offer energy monitoring.

I came across the HS300 power strip that offers six switched outlets plus energy monitoring for each outlet. It has a flat angled plug, allowing two devices to fit in a standard wall outlet.

Each of these devices seems to be rated at 15A (1875W) total. That should be fine, since most of the standard wall plugs they would be plugged into aren’t rated for more than that, but it’s interesting that the current handling of the largest devices is the same as the smallest.

The energy monitoring was an interesting feature, and I was hoping to get around to doing more than glancing at it from my phone occasionally. Nearly three years after my first purchase I finally got around to writing a program to do what I wanted to log the energy usage.

I’d come across https://www.softscheck.com/en/reverse-engineering-tp-link-hs110/ when I first bought the HS110, and thought I would get around to doing what I wanted quickly, but as with so many projects, it was set aside as less important. With the transient nature of the web, I’m glad that this site is still visible, and the resulting github repository tools proved invaluable for me getting my project working. https://github.com/softScheck/tplink-smartplug

There are several python projects for communicating with these devices which I also found useful, but I was hoping to build a small program with very few dependencies. Part of what I wanted to know was the communication protocol over the ethernet, and that took the most time to decipher.

https://github.com/wcbonner/KasaEnergyLogger is my project, with all of the work done in a single threaded C++ file. I’ll hopefully describe what I know of the protocol in the future. As it is, I’m pulling data from multiple devices and logging it using MRTG. I know there are significantly better graphics dashboards available, but this requires very little infrastructure, and I’m logging the raw data in case I ever really want to revisit it.

MRTG graph of AC Power Usage

For most people these devices connect to Alexa or Google Home and the scheduling plus voice controls are all that they will ever use.

I was very happy with having lamps set to turn on at sunset and turn off at specific times. The fact that I live at a latitude where sunset changes from after 9pm in the peak of summer to before 5pm midwinter was plenty for me. I also use them for controlling fans to adjust the climate in my home when I’m not relying on air conditioning.

From a system monitoring perspective I’ve considered having two Raspberry Pi, each plugged into a HS105, monitoring each other and power cycling the other device if it can’t be reached for a designated period of time.

Here are some of the other sites I found useful in getting to my current state:

GoveeBTTempLogger as a Debian Package

After getting my program to listen and log Bluetooth Low Energy advertisements from Govee thermometers running reliably, I needed to figure out how to make the program automatically start when my Raspberry was rebooted. I was led down two paths to get things working, systemd unit files, and debian package files created with dpkg-deb.

The final file structure I came up with is visible in https://github.com/wcbonner/GoveeBTTempLogger but still can use some explanation as to what I did.

To create the debian package, I created a file structure under my source repository that mimicked what I wanted to put on the target system.

\GOVEEBTTEMPLOGGER\GOVEEBTTEMPLOGGER
├───DEBIAN
│       control
│       postinst
│       postrm
│       prerm
│
├───etc
│   └───systemd
│       └───system
│               goveebttemplogger.service
│
├───usr
│   └───local
│       └───bin
│               goveebttemplogger
│
└───var
    └───log
        └───goveebttemplogger
                gvh507x.txt

I had decided I wanted my executable to be located in /usr/local/bin. It’s the file named goveebttemplogger. I wanted it to write log files into /var/log/goveebttemplogger/ and the easiest way to make sure that directory was created was to put a zero length file in that directory, gvh507x.txt.

The files in the DEBIAN directory are used by the dpkg-deb program when building the distributable package. More on those later.

To get the program configured to automatically run when the machine boots, and properly stop when it shuts down, I settled on the systemd unit files as the both the easiest and most reliable method. I’ve been around linux long enough to first think of /etc/rc.local manipulation, then script files for various runlevels in the /etc/init.d/ directories, and was amazed at both the power and ease of setting up to use the systemd unit files. The hardest part was figuring out what other services my program must have already started. I knew it was dependent on Bluetooth, but the specific services was a bit of a guess.

# Contents of /etc/systemd/system/goveebttemplogger.service
[Unit]
Description=GoveeBTTempLogger service
After=bluetooth.target dbus-org.bluez.service network.target
Requires=bluetooth.target
KillSignal=SIGINT

[Service]
Type=simple
Restart=always
ExecStart=/usr/local/bin/goveebttemplogger -v 0 -l /var/log/goveebttemplogger/

[Install]
WantedBy=multi-user.target

After creating that file in the specified location, I was able to issue the following commands to make systemd start the program.

sudo systemctl daemon-reload
sudo systemctl enable goveebttemplogger.service
sudo systemctl start goveebttemplogger.service

The most unique bit of my unit file is that I specifically want my program to be sent the SIGINT signal to kill it, since I will recognize that and flush the log files before exiting. The ExecStart line is the command line to run my program, which I’m also specifying the log directory as one of the parameters.

I had the systemd unit file and the initial DEBIAN/control file figured out pretty easily. I’d come across this https://linuxconfig.org/easy-way-to-create-a-debian-package-and-local-package-repository article which helped understanding the control file.

Package: GoveeBTTempLogger
Version: 1.20200725-1
Section: custom
Priority: optional
Architecture: armhf
Essential: no
Installed-Size: 95
Maintainer: wcbonner@users.noreply.github.com
Description: Listen and log Govee Thermometer Bluetooth Low Energy Advertisments
Depends: libbluetooth3

What took me a while to figure out was how to get the systemctl commands to be run after the files were put in place by the package manager. There are four script commands, which I’m using three. preinst, postinst, prerm, and postrm. Each of them is a simple script and needs to be marked executable in the file system. They are each run at various stages by the package manager, Pre-Installation, Post-Installation, Pre-Removal, and Post-Removal.

#!/bin/sh
# POSTINST script for goveebttemplogger

echo "\033[36m HI I'M A POSTINST SCRIPT `date +"%s"` \033[39m"
systemctl daemon-reload
systemctl enable goveebttemplogger.service
systemctl start goveebttemplogger.service

exit 0

After installation of my program and the systemd unit file, I reload the systemd database, enable my service, and start my service.

#!/bin/sh
# PRERM script for goveebttemplogger

echo "\033[36m HI I'M A PRERM SCRIPT `date +"%s"` \033[39m"
systemctl stop goveebttemplogger.service
systemctl disable goveebttemplogger.service

exit 0

Before removal of my program, I stop the service and disable the service.

#!/bin/sh
# POSTRM script for goveebttemplogger

echo "\033[36m HI I'M A POSTRM SCRIPT `date +"%s"` \033[39m"
systemctl daemon-reload

exit 0

After removal of my program, I reload the systemd database, to make sure it’s not got my unit file in its database any longer.

When I retrieve a copy of my code with the command git clone https://github.com/wcbonner/GoveeBTTempLogger I then have a subdirectory below the GoveeBTTempLogger that is also named GoveeBTTempLogger. That deeper directory is the structure that will be created into the package.


GoveeBTTempLogger/usr/local/bin/goveebttemplogger: goveebttemplogger.cpp
        mkdir -p GoveeBTTempLogger/usr/local/bin
        g++ -lbluetooth goveebttemplogger.cpp -o GoveeBTTempLogger/usr/local/bin/goveebttemplogger

deb: GoveeBTTempLogger/usr/local/bin/goveebttemplogger GoveeBTTempLogger/DEBIAN/control GoveeBTTempLogger/etc/systemd/system/goveebttemplogger.service
        mkdir -p GoveeBTTempLogger/var/log/goveebttemplogger
        touch GoveeBTTempLogger/var/log/goveebttemplogger/gvh507x.txt
        chmod a+x GoveeBTTempLogger/DEBIAN/postinst GoveeBTTempLogger/DEBIAN/postrm GoveeBTTempLogger/DEBIAN/prerm
        dpkg-deb --build GoveeBTTempLogger

I made the very simple makefile above to both compile the code and build the debian package with the simple command of make deb. It produces the package ‘goveebttemplogger’ in ‘GoveeBTTempLogger.deb’.

I can then install the package and start it running with the command sudo apt-get install ./GoveeBTTempLogger.deb

I can stop and either remove it or purge it with the command sudo apt-get remove goveebttemplogger or sudo apt-get purge goveebttemplogger.

Govee H5075 and H5074, Bluetooth Low Energy, and MRTG

I have been wanting a method of keeping track of temperatures for a long time. Last week I acquired a Govee H5075 Bluetooth Thermometer Hygrometer. It communicates with an app from Govee on my iPhone using Bluetooth Low Energy (BLE).

I’ve now learned some details on BLE, and have written a program that listens for BLE advertisements from either type of thermometer and logs the temperature and humidity in a text file. The code for my project is available on GitHub. https://github.com/wcbonner/GoveeBTTempLogger

The same program can also be called to get the last value from the log and produce output compatible with MRTG. MRTG is not the best method for graphing these temperatures, because all graphs start with zero on the Y axis, and neither the temperature or humidity is likely to be near zero.

MRTG graph of Temperature and Relative Humidity

My program seems to receive advertisements from each thermometer about every ten seconds. I’ve had a friend running the code in his location with a different set of thermometers and it doesn’t get advertisements nearly as frequently. I don’t know if that’s just because environment is different, or if there’s something else going on.

Govee GVH5075 Thermometer Hygrometer

Last week I came across a deal on a small thermometer with display and Bluetooth access for under $10 so I had to give it a try. The fact that the data is available via bluetooth instead of via a web service was a major selling point for me. I am hoping to be able to to log the data via a Raspberry Pi4.

GVH5070 near my Raspberry Pi4

I installed the Govee Home app on my iPhone and it was able to find the device, communicate with it, and pull both current and accumulated data.

When I attempted to find it from my Pi4 it was much more difficult. I live in an apartment with units all around. I’m not just dealing with my own devices that may be visible, but my neighbors as well.

I managed to find the device using linux command line tools, but was not able to successfully connect. A friend suggested BLE Scanner 4.0 for my iPhone for discovering the details, and it was at least able to confirm what I should be looking for using the linux command line tools. I still had timeout issues with the iPhone app, but at least was able to confirm that I could connect to the device and retrieve GUID information.

This is my first time attempting to gather data from a Bluetooth device. I’m still in the research and test phase. I’m listing a bunch of the URLS I’ve found that have been helpful.

https://www.reddit.com/r/Govee/comments/e8ljbp/work_to_access_data_from_a_govee_h5075_indoor/
https://www.jaredwolff.com/get-started-with-bluetooth-low-energy/
https://github.com/neilsheps/GoveeTemperatureAndHumidity
https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=241686
https://www.cnet.com/how-to/how-to-setup-bluetooth-on-a-raspberry-pi-3/
https://www.real-world-systems.com/docs/hcitool.1.html

From the command line on my Pi4 I already had the tools installed to try several Bluetooth commands. I believe they were installed as part of the bluez package. The first two commands below get details on the Raspberry Pi Bluetooth hardware, then the hcitool lescan command produced a lot of devices, and I found the line referencing the GVH5075 so I could use the address in further commands.

pi@WimPi4:~ $ sudo hcitool dev
Devices:
        hci0    DC:A6:32:1C:B5:74

pi@WimPi4:~ $ sudo hciconfig -a
hci0:   Type: Primary  Bus: UART
        BD Address: DC:A6:32:1C:B5:74  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING 
        RX bytes:21284 acl:25 sco:0 events:791 errors:0
        TX bytes:4401 acl:26 sco:0 commands:172 errors:0
        Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: RSWITCH SNIFF 
        Link mode: SLAVE ACCEPT 
        Name: 'WimPi4'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous, 
        HCI Version: 5.0 (0x9)  Revision: 0x13b
        LMP Version: 5.0 (0x9)  Subversion: 0x6119
        Manufacturer: Cypress Semiconductor Corporation (305)

pi@WimPi4:~ $ sudo hcitool lescan
LE Scan ...
7B:F9:68:96:C4:92 (unknown)
57:FA:0A:E7:61:A4 (unknown)
A4:C1:38:37:BC:AE GVH5075_BCAE
A4:C1:38:37:BC:AE (unknown)
15:FF:0C:3F:E7:35 (unknown)
57:FA:0A:E7:61:A4 (unknown)

pi@WimPi4:~ $ sudo hcitool leinfo A4:C1:38:37:BC:AE
Requesting information ...
        Handle: 64 (0x0040)
        LMP Version: 4.2 (0x8) LMP Subversion: 0x22bb
        Manufacturer: Telink Semiconductor Co. Ltd (529)
        Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Another command that I attempted before I used the hcitool command was the bluetoothctl command. It scrolls a lot of data, but now that I have an idea what I’m looking at, I may be able to see announcement data from the thermometer periodically in the stream by filtering just to see the data coming from the MAC address.

pi@WimPi4:~ $ sudo bluetoothctl
Agent registered
[bluetooth]# scan on
Discovery started
[CHG] Controller DC:A6:32:1C:B5:74 Discovering: yes
[NEW] Device 57:75:EA:B6:EC:2B 57-75-EA-B6-EC-2B
[NEW] Device E7:E7:B4:AB:4A:1F 846B219FB80338A3E9
[NEW] Device 48:56:2E:FF:59:45 48-56-2E-FF-59-45
[NEW] Device 46:53:2F:D4:6F:A1 46-53-2F-D4-6F-A1
[NEW] Device 5C:C9:C5:C9:70:5F 5C-C9-C5-C9-70-5F
[NEW] Device 48:CF:F7:19:4A:3A 48-CF-F7-19-4A-3A
[NEW] Device 4E:30:D1:5D:0F:48 4E-30-D1-5D-0F-48
[NEW] Device 7D:4A:A3:81:32:22 7D-4A-A3-81-32-22
[NEW] Device 7E:0F:63:2B:DC:3E 7E-0F-63-2B-DC-3E
[NEW] Device 7F:5D:37:A2:4E:BA 7F-5D-37-A2-4E-BA
[NEW] Device 7F:6B:44:CD:3A:E5 7F-6B-44-CD-3A-E5
[NEW] Device 00:07:80:37:BD:35 00-07-80-37-BD-35
[NEW] Device 04:52:C7:BC:1C:E3 LE-Bose Revolve SoundLink
[NEW] Device 4F:84:D2:AC:59:FF 4F-84-D2-AC-59-FF
[NEW] Device 4E:F0:6A:DD:3D:7E 4E-F0-6A-DD-3D-7E
[NEW] Device 75:25:34:3F:B9:29 75-25-34-3F-B9-29
[NEW] Device 60:EC:A4:49:B6:67 60-EC-A4-49-B6-67
[NEW] Device 98:D6:BB:20:EB:3B 98-D6-BB-20-EB-3B
[NEW] Device 78:13:28:A8:0A:FF 78-13-28-A8-0A-FF
[NEW] Device 56:6F:B2:E0:40:E3 56-6F-B2-E0-40-E3
[NEW] Device 69:D9:38:44:5C:04 69-D9-38-44-5C-04
[NEW] Device 56:63:50:90:82:D6 56-63-50-90-82-D6
[CHG] Device A4:C1:38:37:BC:AE RSSI: -43
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Key: 0xec88
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Value:
00 03 32 62 64 00 ..2bd.
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Key: 0x004c
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Value:
02 15 49 4e 54 45 4c 4c 49 5f 52 4f 43 4b 53 5f ..INTELLI_ROCKS_
48 57 50 75 f2 ff c2 HWPu…
[CHG] Device 75:25:34:3F:B9:29 RSSI: -83
[NEW] Device 47:10:2F:15:99:2E 47-10-2F-15-99-2E
[NEW] Device B8:31:B5:8B:12:D2 ETOBAN386
[NEW] Device F0:6E:0B:D1:1B:BF ELRWLK345
[CHG] Device 75:25:34:3F:B9:29 RSSI: -72
[CHG] Device 7D:4A:A3:81:32:22 RSSI: -89
[CHG] Device 7D:4A:A3:81:32:22 RSSI: -81
[CHG] Device 98:D6:BB:20:EB:3B RSSI: -94
[NEW] Device A4:83:E7:20:06:5B A4-83-E7-20-06-5B
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Key: 0x05a7
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Value:
03 13 31 68 39 63 51 6f 4b 76 54 34 00 ..1h9cQoKvT4.
[NEW] Device 00:07:80:37:CA:7D 00-07-80-37-CA-7D
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Key: 0x05a7
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Value:
03 12 78 4d 32 49 31 6d 31 6a 6f 32 67 ..xM2I1m1jo2g
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Key: 0x05a7
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Value:
03 10 01 99 44 de ad be ef 00 0a 00 ca ….D……..
[CHG] Device 4E:30:D1:5D:0F:48 ManufacturerData Key: 0x004c
[CHG] Device 4E:30:D1:5D:0F:48 ManufacturerData Value:
10 06 10 1e b0 2a e1 be …..*..
[CHG] Device 98:D6:BB:20:EB:3B RSSI: -85
[NEW] Device 00:07:80:37:BE:C9 523
[CHG] Device 5C:C9:C5:C9:70:5F ManufacturerData Key: 0x004c
[CHG] Device 5C:C9:C5:C9:70:5F ManufacturerData Value:
10 06 5a 1e 56 a0 e1 eb ..Z.V…
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Key: 0x05a7
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Value:
03 13 31 68 39 63 51 6f 4b 76 54 34 00 ..1h9cQoKvT4.
[CHG] Device 75:25:34:3F:B9:29 RSSI: -81
[NEW] Device 6B:C2:D2:28:1E:A5 6B-C2-D2-28-1E-A5
[CHG] Device 5C:C9:C5:C9:70:5F ManufacturerData Key: 0x004c
[CHG] Device 5C:C9:C5:C9:70:5F ManufacturerData Value:
0c 0e 00 41 32 56 c8 79 5a 01 9d 63 d5 79 c7 80 …A2V.yZ..c.y..
10 06 56 1e 56 a0 e1 eb ..V.V…
[CHG] Device A4:C1:38:37:BC:AE RSSI: -35
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Key: 0xec88
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Value:
00 03 32 61 64 00 ..2ad.
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Key: 0x004c
[CHG] Device A4:C1:38:37:BC:AE ManufacturerData Value:
02 15 49 4e 54 45 4c 4c 49 5f 52 4f 43 4b 53 5f ..INTELLI_ROCKS_
48 57 50 75 f2 ff c2 HWPu…
[CHG] Device 48:CF:F7:19:4A:3A RSSI: -76
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Key: 0x05a7
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Value:
03 10 01 99 44 de ad be ef 00 0a 00 ca ….D……..
[NEW] Device 78:11:F9:E8:7A:DA 78-11-F9-E8-7A-DA
[CHG] Device 47:10:2F:15:99:2E RSSI: -84
[CHG] Device 69:D9:38:44:5C:04 RSSI: -83
[CHG] Device 47:10:2F:15:99:2E ManufacturerData Key: 0x004c
[CHG] Device 47:10:2F:15:99:2E ManufacturerData Value:
10 06 1c 1e 9a e0 28 9b ……(.
[CHG] Device 5C:C9:C5:C9:70:5F ManufacturerData Key: 0x004c
[CHG] Device 5C:C9:C5:C9:70:5F ManufacturerData Value:
0c 0e 00 42 32 7b fc b2 b6 a1 46 31 82 0f 67 02 …B2{….F1..g.
10 06 56 1e 56 a0 e1 eb ..V.V…
[CHG] Device 75:25:34:3F:B9:29 RSSI: -73
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Key: 0x05a7
[CHG] Device E7:E7:B4:AB:4A:1F ManufacturerData Value:
03 13 31 68 39 63 51 6f 4b 76 54 34 00 ..1h9cQoKvT4.
[CHG] Device 47:10:2F:15:99:2E ManufacturerData Key: 0x004c
[CHG] Device 47:10:2F:15:99:2E ManufacturerData Value:
10 06 14 1e 9a e0 28 9b ……(.
[NEW] Device 5C:53:86:8D:A4:61 5C-53-86-8D-A4-61
[NEW] Device 42:32:EC:5F:59:C5 42-32-EC-5F-59-C5
[bluetooth]# scan off
Discovery stopped
[CHG] Device E7:E7:B4:AB:4A:1F TxPower is nil
[CHG] Device E7:E7:B4:AB:4A:1F RSSI is nil
[DEL] Device E7:E7:B4:AB:4A:1F 846B219FB80338A3E9
[CHG] Controller DC:A6:32:1C:B5:74 Discovering: no
[CHG] Device 42:32:EC:5F:59:C5 TxPower is nil
[CHG] Device 42:32:EC:5F:59:C5 RSSI is nil
[CHG] Device 5C:53:86:8D:A4:61 RSSI is nil
[CHG] Device 78:11:F9:E8:7A:DA TxPower is nil
[CHG] Device 78:11:F9:E8:7A:DA RSSI is nil
[CHG] Device 6B:C2:D2:28:1E:A5 TxPower is nil
[CHG] Device 6B:C2:D2:28:1E:A5 RSSI is nil
[CHG] Device 00:07:80:37:BE:C9 RSSI is nil
[CHG] Device 00:07:80:37:CA:7D RSSI is nil
[CHG] Device A4:83:E7:20:06:5B RSSI is nil
[CHG] Device F0:6E:0B:D1:1B:BF TxPower is nil
[CHG] Device F0:6E:0B:D1:1B:BF RSSI is nil
[CHG] Device B8:31:B5:8B:12:D2 TxPower is nil
[CHG] Device B8:31:B5:8B:12:D2 RSSI is nil
[CHG] Device 47:10:2F:15:99:2E TxPower is nil
[CHG] Device 47:10:2F:15:99:2E RSSI is nil
[CHG] Device A4:C1:38:37:BC:AE RSSI is nil
[CHG] Device 56:63:50:90:82:D6 RSSI is nil
[CHG] Device 69:D9:38:44:5C:04 TxPower is nil
[CHG] Device 69:D9:38:44:5C:04 RSSI is nil
[CHG] Device 56:6F:B2:E0:40:E3 TxPower is nil
[CHG] Device 56:6F:B2:E0:40:E3 RSSI is nil
[CHG] Device 78:13:28:A8:0A:FF TxPower is nil
[CHG] Device 78:13:28:A8:0A:FF RSSI is nil
[CHG] Device 98:D6:BB:20:EB:3B RSSI is nil
[CHG] Device 60:EC:A4:49:B6:67 TxPower is nil
[CHG] Device 60:EC:A4:49:B6:67 RSSI is nil
[CHG] Device 75:25:34:3F:B9:29 TxPower is nil
[CHG] Device 75:25:34:3F:B9:29 RSSI is nil
[CHG] Device 4E:F0:6A:DD:3D:7E TxPower is nil
[CHG] Device 4E:F0:6A:DD:3D:7E RSSI is nil
[CHG] Device 4F:84:D2:AC:59:FF TxPower is nil
[CHG] Device 4F:84:D2:AC:59:FF RSSI is nil
[CHG] Device 04:52:C7:BC:1C:E3 TxPower is nil
[CHG] Device 04:52:C7:BC:1C:E3 RSSI is nil
[CHG] Device 00:07:80:37:BD:35 RSSI is nil
[CHG] Device 7F:6B:44:CD:3A:E5 TxPower is nil
[CHG] Device 7F:6B:44:CD:3A:E5 RSSI is nil
[CHG] Device 7F:5D:37:A2:4E:BA TxPower is nil
[CHG] Device 7F:5D:37:A2:4E:BA RSSI is nil
[CHG] Device 7E:0F:63:2B:DC:3E TxPower is nil
[CHG] Device 7E:0F:63:2B:DC:3E RSSI is nil
[CHG] Device 7D:4A:A3:81:32:22 TxPower is nil
[CHG] Device 7D:4A:A3:81:32:22 RSSI is nil
[CHG] Device 4E:30:D1:5D:0F:48 TxPower is nil
[CHG] Device 4E:30:D1:5D:0F:48 RSSI is nil
[CHG] Device 48:CF:F7:19:4A:3A TxPower is nil
[CHG] Device 48:CF:F7:19:4A:3A RSSI is nil
[CHG] Device 5C:C9:C5:C9:70:5F TxPower is nil
[CHG] Device 5C:C9:C5:C9:70:5F RSSI is nil
[CHG] Device 46:53:2F:D4:6F:A1 TxPower is nil
[CHG] Device 46:53:2F:D4:6F:A1 RSSI is nil
[CHG] Device 48:56:2E:FF:59:45 TxPower is nil
[CHG] Device 48:56:2E:FF:59:45 RSSI is nil
[CHG] Device 57:75:EA:B6:EC:2B TxPower is nil
[CHG] Device 57:75:EA:B6:EC:2B RSSI is nil
[DEL] Device 57:75:EA:B6:EC:2B 57-75-EA-B6-EC-2B
[DEL] Device 48:56:2E:FF:59:45 48-56-2E-FF-59-45
[DEL] Device 46:53:2F:D4:6F:A1 46-53-2F-D4-6F-A1
[DEL] Device 5C:C9:C5:C9:70:5F 5C-C9-C5-C9-70-5F
[DEL] Device 48:CF:F7:19:4A:3A 48-CF-F7-19-4A-3A
[DEL] Device 4E:30:D1:5D:0F:48 4E-30-D1-5D-0F-48
[DEL] Device 7D:4A:A3:81:32:22 7D-4A-A3-81-32-22
[DEL] Device 7E:0F:63:2B:DC:3E 7E-0F-63-2B-DC-3E
[DEL] Device 7F:5D:37:A2:4E:BA 7F-5D-37-A2-4E-BA
[DEL] Device 7F:6B:44:CD:3A:E5 7F-6B-44-CD-3A-E5
[DEL] Device 00:07:80:37:BD:35 00-07-80-37-BD-35
[DEL] Device 04:52:C7:BC:1C:E3 LE-Bose Revolve SoundLink
[DEL] Device 4F:84:D2:AC:59:FF 4F-84-D2-AC-59-FF
[DEL] Device 4E:F0:6A:DD:3D:7E 4E-F0-6A-DD-3D-7E
[DEL] Device 75:25:34:3F:B9:29 75-25-34-3F-B9-29
[DEL] Device 60:EC:A4:49:B6:67 60-EC-A4-49-B6-67
[DEL] Device 98:D6:BB:20:EB:3B 98-D6-BB-20-EB-3B
[DEL] Device 78:13:28:A8:0A:FF 78-13-28-A8-0A-FF
[DEL] Device 56:6F:B2:E0:40:E3 56-6F-B2-E0-40-E3
[DEL] Device 69:D9:38:44:5C:04 69-D9-38-44-5C-04
[DEL] Device 56:63:50:90:82:D6 56-63-50-90-82-D6
[DEL] Device 47:10:2F:15:99:2E 47-10-2F-15-99-2E
[DEL] Device B8:31:B5:8B:12:D2 ETOBAN386
[DEL] Device F0:6E:0B:D1:1B:BF ELRWLK345
[DEL] Device A4:83:E7:20:06:5B A4-83-E7-20-06-5B
[DEL] Device 00:07:80:37:CA:7D 00-07-80-37-CA-7D
[DEL] Device 00:07:80:37:BE:C9 523
[DEL] Device 6B:C2:D2:28:1E:A5 6B-C2-D2-28-1E-A5
[DEL] Device 78:11:F9:E8:7A:DA 78-11-F9-E8-7A-DA
[DEL] Device 5C:53:86:8D:A4:61 5C-53-86-8D-A4-61
[DEL] Device 42:32:EC:5F:59:C5 42-32-EC-5F-59-C5
[bluetooth]# exit

I’m posting all of this here and hopefully will be able to make progress on retrieving the data in the next few days.

Monitoring Raspberry Pi with MRTG

I’ve used MRTG for simple monitoring for years. It’s easy to get working and dependent on very few packages. It stores it’s data in simple files. This both limits it, and makes it easy to move or duplicate.

I wanted to monitor each of my Raspberry Pi network interfaces because they are connected via WiFi and I can’t monitor a particular switch port for each device. I’ve spent nearly a year searching for the reason that MRTG didn’t enumerate the interfaces before coming up with a simple snippet fixing my problem.

Adding this line to the end of my /etc/snmp/snmpd.conf file and restarting the snmpd allowed me to run cfgmaker and see my network interfaces.

view   systemonly  included   .1.3.6.1.2.1.2

Quick and dirty addition and query:

sudo echo view   systemonly  included   .1.3.6.1.2.1.2 >>/etc/snmp/snmpd.conf
sudo systemctl restart snmpd

/usr/bin/cfgmaker --no-down --zero-speed=100000000 public@localhost
Thanks to https://www.seei.biz/cpu-temperature-of-a-raspberry-pi-via-snmp/ for giving me the simple answer that I’d been trying to figure out for over a year.