JTK – Notes and Ramblings Things we have found …

The Raspberry Pi 3 running the flight tracker and rtl_433 for weather station and driveway alarm data was in need of an update. Past articles include Update to LaCrosse weather, Adding LaCrosse weather to garage-pi, Mighty-Mule and LaCrosse update, Mighty Mule driveway alarm, Updates and a new rtl-sdr,
More flight tracking adding Radarbox, Updates to flight tracking.

Updating the Raspberry Pi OS Bookworm 32 bit installation to Trixie proved more complex than expected. With Trixie, 64-bit is the expected choice by quite a few things. Even Openhab 5.x has removed 32-bit support. This means that not everything we wanted to install had a 32 bit Trixie option. After getting pretty well tangles the best choice was to start over again with a new Raspberry Pi OS 32-bit Bookworm Lite SD card. Using the Raspberry Pi Imager allows you to predefine hostname, localization, username/password, WiFi if needed, and enable ssh.

rtl_433 /weather station data / driveway alarm

First we will update everything and install the rtl_sdr libraries and setup to listen at 433.92Mhz for the LaCrosse weather station and the Mighty Mule driveway alarm:

sudo apt update
sudo apt upgrade

sudo apt install rtl-sdr rtl-433

At this point we need to update the udev rules to allow for the proper discovery of the rtl-sdr devices. The rtl-sdr file can be found at https://github.com/osmocom/rtl-sdr/raw/master/rtl-sdr.rules

curl https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules >rtl-sdr.rules
sudo cp rtl-sdr.rules /etc/udev/rules.d/rel-sdr.rules
sudo udevadm control --reload-rules
sudo udevadm trigger

Next the serial numbers of the rtl-sdr devices need to be unique. If not already set previously, this is done by plugging the devices in one at a time and using rtl_eeprom.

#only plug in the rtl-sdr for 433 weather station/Mighty Mule
sudo rtl_eeprom -d 0 -s 433 # set the serial number for the rtl-sdr device
#only plug in the rtl-sdr for 1090 adsb
sudo rtl_eeprom -d 0 -s 1090
#only plug in the rtl-sdr for 978 UAT reception
sudo rtl_eeprom -d 0 -s 978

There is a sample rtl_433.conf file with the serial number set to 433, mqtt output in json format set and Mighty Mule decoder included. Grab a copy into your home directory, rename it to rtl_433.conf and give things a test.

rtl_433

If things appear to work and your mqtt broker is receiving messages it’s time to make this a service. First let’s create the service definition file at /etc/systemd/system/rtl_433-mqtt.service:

[Unit]
Description=rtl_433 to MQTT publisher
After=network.target
[Service]
ExecStart=/usr/bin/rtl_433
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

Then we need to copy the config file into place, enable and start the service and check its status

sudo mkdir /etc/rtl_433
sudo cp rtl_433.conf /etc/rtl_433/
sudo systemctl enable rtl_433-mqtt.service
sudo systemctl start rtl_433-mqtt.service
sudo systemctl status rtl_433-mqtt.service
sudo journalctl -u rtl_433-mqtt.service # for additional logging display

Flight Tracking and Feeding

readsb

The setup for ADS-B and UAT listening and aggregation has quite a few steps. First up is readsb as an alternative to dump1090-fa or dump1090-mutability. The basics are:

sudo bash -c "$(wget -O - https://github.com/wiedehopf/adsb-scripts/raw/master/readsb-install.sh)"
sudo readsb-set-location 50.12344 10.23429 # set long and lat
sudo nano /etc/default/readsb # edit config if needed
sudo systemctl restart readsb # restart the service after config edits

The config file will definitely need --device 1090 added to the RECEIVER OPTIONS line in the config file. If you know the ppm deviation for you rtl-sdr you can add it there, too.

RECEIVER_OPTIONS="--device 1090 --device-type rtlsdr --gain auto --ppm 0"

tar1090

Next up is tar1090 to let us see what’s up there on a map. Once installed view your map at http://your_ip/tar1090.

sudo bash -c "$(wget -nv -O - https://github.com/wiedehopf/tar1090/raw/master/install.sh)"
sudo nano /etc/default/tar1090 # edit config file if needed
sudo systemctl restart tar1090 # restart the service after config edits
sudo apt install -y lighttpd # if connection refused when trying http://host_ip/tar1090

graphs1090

graphs1090 is a nice utility to add for displaying stats and graphs. The installation follows a similar pattern to the previous software. Once installed view your graphs at http://your_ip:graphs1090

sudo bash -c "$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)"
sudo nano /etc/default/graphs1090 # edit the config as needed
sudo cp /usr/share/graphs1090/default-config /etc/default/graphs1090 # restore original settings

FlightAware

Now is the time to start adding the aggregators to share the ADS-B data with. FlightAware has simple instructions online. You’ll add their repository and install piaware using apt. Once its up an running you visit their website to claim the feed.

wget https://www.flightaware.com/adsb/piaware/files/packages/pool/piaware/f/flightaware-apt-repository/flightaware-apt-repository_1.2_all.deb
sudo dpkg -i flightaware-apt-repository_1.2_all.deb
sudo apt update
sudo apt install piaware

ADSBExchange

ADSBExchange is also pretty simple.

ccurl -L -o /tmp/axstats.sh https://www.adsbexchange.com/stats.sh
sudo bash /tmp/axupdate.sh

Once it is installed you can check your feed at https://www.adsbexchange.com/myip/. They also have an optional stats package you can install.

curl -L -o /tmp/axstats.sh https://www.adsbexchange.com/stats.sh 
sudo bash /tmp/axstats.sh

FlightRadar24

FlightRadar24 has a simple one-liner installation.

wget -qO- https://fr24.com/install.sh | sudo bash -s

Since we are feeding to multiple sites we should follow their advice and disable mlat in fr24feed.ini. FlightRadar24 feed stats can be viewed locally at http://your_ip:8754. You can also visit https://www.flightradar24.com/account/data-sharing.

Airnav / Radarbox

Airnav / Radarbox also has simple to follow instructions.

sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
sudo nano /etc/rbfeeder.ini # refer to file below

[client]
network_mode=true
log_file=/var/log/rbfeeder.log
[network]
mode=beast
external_port=30005
external_host=127.0.0.1

Once setup and connected for a few minutes use sudo rbfeeder --showkey to reveal your key and the visit their site to claim your feed.

AirplanesLive

AirplanesLive has instruction’s on github. Once installed you can check your status at https://airplanes.live/myfeed.

curl -L -o /tmp/feed.sh https://raw.githubusercontent.com/airplanes-live/feed/main/install.sh
sudo bash /tmp/feed.sh 
pico /etc/default/airplanes # edit the configuration
sudo systemctl status airplanes-feed # display feeder service status
sudo systemctl status airplanes-mlat # display mlat service status

Planefinder

Planefinder also has instructions online for a variety of clients. This is the summary for the 32 bit Raspberry Pi 3. Find the appropriate Debian package on their page and copy the link. Retrieve the file with wget. The commands will look something like those below. Follow the link provided once the install completes – http://your_ip:30053.

wget http://client.planefinder.net/pfclient_x.x.x_armhf.deb
sudo dpkg -i pfclient_x.x.x_armhf.deb # update filename to reflect actual download

UAT / 978

We skipped adding the UAT 978 sections along the way. Now we need dump978-fa. This is best installed using the FlightAware instructions. Assuming you already have the FlightAware repos installed from the previous steps:

sudo apt install dump978-fa

You will want the update /etc/default/dump978-fa to include driver=rtlsdr,serial=978 on the RECEIVER_OPTIONS line. It may be necessary to update your /etc/piaware.conf file to include the lines below. Refer to the PiAware Advanced Config page for more info. Once installed you can view the UAT map at http://your_ip/skyaware978

uat-receiver-host 127.0.0.1
uat-receiver-type sdr

ADBSExchange has a simple config script for the UAT addition. Once added you can view you map UAT map at http://your_ip/ax978.

sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/adsbxchange/adsbexchange-978/master/install.sh)"
sudo adsbexchange-978-set-location your_lat your_long

The FlightRadar24 add your data page has a UAT tab with instructions. Provided you are already sharing ADS-B 1090 data with them it is as simple as sudo fr24feed-signup-uat.

RadarBox will need a couple of lines added to /etc/rbfeeder.ini. These are discussed in a couple of forum post: MLAT and dump978 and RBFeeder on RPi config network connection to FlightFeeder 978 UAT.

[dump978]
dump978_enabled=true
dump978_port=30979

You may need to update /etc/collectd/collectd.conf so that graphs1090 will use and display the UAT data. In the module graphs1090 section add URL_978 "http://localhost/skyaware978". more information can be found in /etc/default/graphs1090.

Once it is all done these local links should work:

http://your_ip/tar1090
http://your_ip/dump1090
http://your_ip/graphs1090/
http://your_ip:8754/
http://your_ip:30053/map.html
http://your_ip/ax978
http://your_ip/skyaware978

These links to the aggregation sites should also work:

https://www.flightaware.com/adsb/stats/user/
https://www.adsbexchange.com/myip/
https://map.adsbexchange.com/mlat-map/
https://www.flightradar24.com/account/data-sharing
https://planefinder.net/account/receivers
https://www.airnavradar.com/stations/
https://airplanes.live/myfeed

It turns out there is another Mighty Mule Driveway Alarm somewhere in the neighborhood so the config from our previous article needed to be updated. The other signal is weak but it triggers frequently and requires the config to be a bit more sophisticated. The first step was to update the rtl_433.conf file to send the MQTT messages as a JSON packet:

output json
output mqtt://broker_ip_address,events=rtl_433/garage[/model]

The result looks something like(after I prettied it up with a bit of formatting):

rtl_433/garage/MightyMule-FM231 {
	"time":"2023-01-24 18:37:05.994411",
	"model":"MightyMule-FM231",
	"count":1,
	"num_rows":1,
	"len":9,
	"data":"ff8",
	"battery_ok":"0",
	"id":15,
	"motion":"true",
	"mod":"ASK",
	"freq":433.89011,
	"rssi":-9.5411,
	"snr":12.69084,
	"noise":-22.2319
}

It’s all the same data but in one message. The Openhab config gets changed to have a String Channel for the MQTT JSON packet, an String Item linked to this and two additional String Items a new rule will manipulate. The rule checks the if the id matches our unit and then updates the appropriate items. The id is set on the transmitter and receiver with the dip switches. The rule is very basic but it does the job:

rule "Driveway Alarm" when
  Item Mighty_Mule_JSON received update
then
  var jsonval = Mighty_Mule_JSON.state.toString
  var id = transform("JSONPATH", "$.id", jsonval)
  var time = transform("JSONPATH", "$.time", jsonval)
  if (id == "5") {
    MightyMule_Driveway_Motion.postUpdate("ON")
    MightyMule_Driveway_Motion_Change.postUpdate(time)
  }
end

Changing the rtl_433 MQTT output to be JSON also required updating the channels for the LaCrosse Weather station. Previously the Generic MQTT Thing had channels for individual MQTT messages for temperature, humidity, wind speed and wind direction. Now the JSON messages from the weather station require the channel to have a JSONPATH transformation. The weather station will send two messages, one with temperature and humidity and one with wind speed and direction:

rtl_433/garage/LaCrosse-TX141W {
	"time":"2023-01-24 18:09:36.626950",
	"protocol":73,
	"model":"LaCrosse-TX141W",
	"id":149742,
	"channel":0,
	"battery_ok":1,
	"temperature_C":-0.8,
	"humidity":74,
	"test":0,
	"mic":"CRC",
	"mod":"ASK",
	"freq":433.87334,
	"rssi":-0.135693,
	"snr":22.09624,
	"noise":-22.2319
}

rtl_433/garage/LaCrosse-TX141W {
	"time":"2023-01-24 18:09:36.626950",
	"protocol":73,
	"model":"LaCrosse-TX141W",
	"id":149742,
	"channel":0,
	"battery_ok":1,
	"wind_avg_km_h":4.5,
	"wind_dir_deg":139,
	"test":0,
	"mic":"CRC",
	"mod":"ASK",
	"freq":433.87334,
	"rssi":-0.135693,
	"snr":22.09624,
	"noise":-22.2319
}

A MQTT channel with a topic of rtl_433/garage/LaCrosse-TX141W will receive both messages. The trick is in the JSONPATH transformation. To extract temperature, for example, use JSONPATH:$.temperature_C. This means there are four channels with the same MQTT topic and different JSONPATH transformations. The log file will get warnings that you can’t extract wind speed from the temp/humidity message or temp/humidity from the wind message.

NOTE: Our LaCrosse S81120-INT includes the LaCrosse TX145WSDTH which sends messages as LaCrosse-TX141W.

?

Back in April I mentioned adding some Roku remote control. At this point I’m thinking more javascript than Python.

Roku has a good External Control Protocol reference online.

Sending commands

Unfortunately, the Roku API will not accept Cross Origin Request. This is not an issue if communicating from Node or Python but from the browser using xhr or fetch() you will get CORS errors. When sending POST for button presses you don’t care about the response for a “mode:’no-cors’ ” will work.

let resp = await fetch("http://roku-ip:8060/keypress/play", {method:'POST', mode:'no-cors'})

For the GET for status from the browser one option is a “proxy” add the “Access-Control-Allow-Origin” header. Borrowing the idea from https://medium.com/gitignore/building-a-roku-remote-web-app-1c0db0056be4 we set our Apache web server.

sudo pico /etc/apache2/apache2.conf to edit the config file and add the following lines:

<Location /roku>
    ProxyPass "http://roku-ip:8060/"
    ProxyPassReverse "/" 
    Header add "Access-Control-Allow-Origin" "*"
</Location>

You will need to have several modules loaded in Apache for this to work: headers and proxy_http. This can be done with:

sudo a2enmod proxy_http
sudo a2enmod headers
sudo systemctl restart apache2

Deep Links

A very important link for launching directly into netflix content is https://unogs.com/search/. From this site you can find the contentid for much of the netflix content.

This allows for directly linking to content with something like:

curl -d '' "http://roku-ip:8060/launch/12?contentid=70136120&mediatype=series"

This is a simple POST to the URL with no body.

The folks at unofficial Netflix online Global Search also provide an API.

We get started with the Sparkfun WRL-15031. The hook-up guide is a good place to start. I am using the  IR Controller ESP8266 firmware.

I don’t have PlatformIO installed so I used the standard Arduino IDE. This was my first time with the ESP8266 so I needed to add the ESP8266 Arduino Core. In the current Arduino IDE this can be done by adding https://arduino.esp8266.com/stable/package_esp8266com_index.json to  the File>Preferences>Additional Boards Manager URLs field of the Arduino IDE. Then using the Board Manager from the Tools > Board menu you can install the esp8266 platform.

Once you have the IDE installed and the board set to Generic ESP8266 you need to make sure you have some libraries installed. ESP8266WebServer, ESP8266WiFi and WiFiManager but you may need to install ArduinoJson, Time and IRremoteESP8266.

It’s time to load the sketch, compile and upload.

The key here is to make sure you set the IO pin definitions correctly.

const int pinr1 = 13; // Receiving pin
const int pins1 = 4; // Transmitting preset 1
const int pins2 = 12; // Transmitting preset 2
const int pins3 = 12; // Transmitting preset 3
const int pins4 = 12; // Transmitting preset 4
const int configpin = 0; // Reset Pin
const int ledpin = 5;

I changed getExternalIP = false; and removed the user_id related and Alex integration code. I set ntpServerName to my internal NTP server. I changed the ntp sync time from 5 minutes to 12 hours near the end of the setup() function: setSyncInterval(43200);.

Once the code is compiled and loaded some testing is needed. On the initial run the ESP will be in AP mode with a SSID of IR Controller Configuration. You can connect and set access point info, hostname, static IP, subnet mask, port, default gateway and passcode.

Once you’re able to connect it is time to find some IR codes. There is a bit of good info in the Tasmota IR page. I found Sony DVD player remotes and some of the IR controlled LED votive candles. There is also good info for Samsung and Vizio TVs online. The codes from http://remotecentral.com often need to be manipulated before they are compatible with the ESP IR library. I created a Excel spreadsheet with worksheets for Vizio, Sony and Samsung.

Once we have the codes we can start controlling things from the web. For example:

http://someip:port/msg=msg?code=E0E040BF:SAMSUNG:32&pass=1234&simple=1

will send a power on/off command of 32 bits in SAMSUNG format. After testing a bit of this I created a simple webpage to send a variety of codes.

There is more Arduino IR blaster info at Ken Shirriff’s blog – post 1 and post 2. For more info on Sony codes refer to https://www.sbprojects.net/knowledge/ir/sirc.php and http://www.hifi-remote.com/sony/.

For the record: Toshiba remote: SE-R0047, Vivio Remote unmarked, Sony Remote RMT-B119A, JVC Remote: RM-S212U.

Sometimes it would be nice to have screen start a detached session at start-up. This isn’t complicated. There are two steps. The first is to create a script to be run in the detached session and make it executable. We’ll call it start.sh.

pico start.sh
chmod +x start.sh

The second is to edit /etc/rc.local to have the script run inside screen at start-up. Add the following line before the exit 0 line.

su - pi -c "screen -dm -S pistartup ~/start.sh"

That’s all there is to it. I found notes on this at https://coderwall.com/p/quflrg/run-a-script-on-startup-in-a-detached-screen-on-a-raspberry-pi.

While these updates were made a while ago they weren’t documented. In the original post on the LaCrosse Weather station, rtl_433 sends mqtt data to our openhab server. On github we found a simple means to get rtl_433 to run as a service.

The core is to update /etc/rtl_433/rtl_433.conf. There is a sample file at conf/rtl_433.example.conf. Most important is the output mqtt... line for example:

output mqtt://your_broker_here,devices=rtl_433/garage[/model]

If the Pi has multiple dongles you will also need to confirm the device line. Then create /etc/systemd/system/rtl_433-mqtt.service:

[Unit]
Description=rtl_433 to MQTT publisher
After=network.target
[Service]
ExecStart=/usr/bin/rtl_433
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

Enable the service with systemctl enable rtl_433-mqtt.service.

Continuing the weather radio development. I found some notes on to try sox instead of lame for the encoding for ezstream. This requires installing the mp3 library for sox with sudo apt-get install libsox-fmt-mp3. This appears to provide for somewhat better sound quality.

This means we replace

lame --bitwidth 16 --signed -s 22050 --lowpass 3500 --abr 64 --scale 8 -r -m m - -

with

sox -t raw -r 22050 -b 16 -e signed -c 1 -v 7 - -r 22050 -t mp3 -c 1 -C 64 - sinc -3.5k

The final line:

rtl_fm -f 162550000 -s 22050 -p 14 | tee >(sox -t raw -r 22050 -b 16 -e signed -c 1 -v 7 - -r 22050 -t mp3 -c 1 -C 64 - sinc -3.5k |ezstream -c ezstream.xml) | multimon-ng -t raw -a EAS /dev/stdin | python ~/tg-dsame/dsame.py --no-text --mqtt jtk-pi2 --json output.json

The weather radio scripts from before had issues. The live stream from the SDR was working but the alerts were never being triggered so further work was needed.

There are now at least two other forks of the original dsame project. From nivex we have some reworking of the main dispatch routine. And from bwarden we have a reworking of the parser.

I have cloned bwarden as the new starting point and merged a portion of the nivex changes. A copy of this version of dsame.py can be found here. Or you can look at my fork on github.

Step 1 was to get the output into a json format without the text. Fortunately, this is pretty much built it. For a test using the sample txt file:

python dsame.py --no-text --json /dev/stdout <sample\ alert/WXR-RWT.txt

This has the added bonus of writing to standard out immediately and not waiting/buffering until process end.

With this working lets try to update dsame.py to output to MQTT. I’m working from a machine that already has Mosquito installed along with the Python paho library.

Let’s try adding a bit to the dsame code. The big piece looks like:

            if mqtthost:
                try:
                    import paho.mqtt.publish as mqtt
                    import json
                    data=kwdict(ORG=ORG, EEE=EEE, TTTT=TTTT, JJJHHMM=JJJHHMM, STATION=STATION, TYPE=TYPE, LLLLLLLL=LLLLLLLL, COUNTRY=COUNTRY, LANG=lang, event=get_event(EEE), type=get_indicator(EEE), end=fn_dt(alert_end(JJJHHMM,TTTT)), $
                    mqtt.single('raw/weatherAlert',json.dumps(data), hostname=mqtthost)
                except Exception as detail:
                        logging.error(detail)
                        return

Hopefully he output looks something like this(extra linefeeds added for clarity):

{"LANG": "EN", 
 "organization": "National Weather Service", 
 "end": "07:30 PM", 
 "JJJHHMM": "3650000", 
 "LLLLLLLL": "KEAX/NWS", 
 "COUNTRY": "US", 
 "PSSCCC": "020103-020209-020091-020121-029047-029165-029095-029037", 
 "seconds": 1800, 
 "PSSCCC_list": ["020091", "020103", "020121", "020209", "029037", "029047", "029095", "029165"], 
 "start": "07:00 PM", 
 "length": "30 minutes", 
 "STATION": "KEAX", 
 "TTTT": "0030", 
 "location": "Pleasant Hill, Missouri", 
 "date": "Thu Apr  2 20:44:27 2020", 
 "type": "T", 
 "EEE": "RWT", 
 "ORG": "WXR", 
 "MESSAGE": null, 
 "TYPE": "NWS", 
 "event": "Required Weekly Test"}

The new command line to stream and send mqtt looks like:

rtl_fm -f 162550000 -s 22050 -p 14 | tee >(lame --bitwidth 16 --signed -s 22050 --lowpass 3500 --abr 64 --scale 8 -r -m m - - |ezstream -c ezstream.xml) | multimon-ng -t raw -a EAS /dev/stdin | python ~/tg-dsame/dsame.py --no-text --mqtt hostname_here --json output.json

1. receive from the SDR dongle
2. split stdin – tee redirects to
   1. lame
   2. ezstream
3. tee pipes to
   1. multimon-ng
   2. dsame script – sends to
      1. mqtt
      2. json appends to output.json file

A different option to multimon-ng might be minimodem. I claims to convert SAME audio to text and back again.