JTK – Notes and Ramblings Things we have found …

5/13/2020

Lightning + Google

Filed under: General,Home Automation — taing @ 1:45 pm

Based on the trick seen here we have added Google Sheets logging to the lightning Python script.

A copy of the example sheet in the original GitHub with a few changes to the column headers, publish the API and that side is all set.

For the Python side we needed to “import urllib.request” and request the url. Then is was as simple as “r = urllib.request.urlopen(urlStr+outStr)”. In this case urlStr is the url from Google and outStr is the data. For example, ‘?type=”Strike”&distance=32&energy=200’.

When publishing the Google Sheet Web API the simple choice is anonymous. I have not looked at handling credentials for Google login in the Python script.

Lightning

Filed under: General,Home Automation — taing @ 1:18 pm

My original Embedded Adventures MOD-1016v8 lightning detector based on the as3935 failed. I ordered a replacement from Sparkfun. The Sparkfun hook-up guide discusses the sensors I2C interface being not as reliable as the SPI interface. Sparkfun also has a github for the PCB. Originally I was using code based on a Python I2C library. So a change is needed.

My first thought was to port the Sparkfun Arduino library over to Raspberry Pi using wiringPi. It should be noted that as of August 2019 the author of wiringPi is no longer supporting it. This was a bit frustrating but after a bit of testing with the scope and bus pirate and a lot of googling. This issues seem to be resolved.

At first there was data on MOSI but nothing coming back. After attaching the Bus Pirate using the setup below:

m 5 (for SPI mode)
Speed: 125khz
Clock polarity: Idle low (default)
Output Clock Edge: Active to idle (default)
Input sample phase: End (NOT default)
CS: /CS (default)
Output type: Normal

I was able to communicate. Notice the Input Phase angle being set to “end”. When it was set to “middle”, the default, writes worked but reads shifted the result one bit to the right effectively dropping the LSB. This turns out to be vital for the wiringPi code also. The standard SPI help page for wiringPi doesn’t mention anything about mode or phase. But our friend google gave me a discussion about possible modes. So instead of the basic wiringPiSPISetup(channel, speed) function I needed to use wiringPiSPISetupMode(channel, speed, mode). Bit 0 is clock phase, bit 1 is clock polarity. The other bits are not possible via wiringPi but as discussed elsewhere can be set by a direct ioctl call.

I also slowed the speed down toe 125khz from the original 2Mhz.

For wiringPi i used the following pins:

GND: pi pin 25
SCK: pi pin 23 (SCLK)
MISO: pi pin 21 (MISO)
MOSI: pi pin 19 (MOSI)
3.3v: pi pin 17
INT: pi pin 15 (GPIO 22)
CS: pi pin 24 (CE0 / GPIO 8)

I considered a version using bcm2835 but didn’t go very far down this road. No work has been done on that front.

I also decided to play a bit with Sparkfun and CircuitPython and sparkfun-circuitpython-qwiicas3935 1.0.3. The complete CircuitPython bundle is on github. The as3935 bundle can also be found on github.

The Pi I was working with is a Pi II with Jesse installed. Installing Python 3.5 or higher on Jesse is more work than simply making a newer Buster Lite sd card. Then it is a matter of following the Sparkfun / AdaFruit instructions to get all of the necessities installed:

sudo apt-get install python3-pip
sudo pip3 install --upgrade setuptools
pip3 install RPI.GPIO
pip3 install sparkfun-circuitpython-qwiicas3935

The secret to getting this to work is realizing that you can’t use CE0/GPIO 8 for CS with the code provided. Circuit Python Bus Device(documentation) can’t manage the pin directly when SPI is in use and the hardware doesn’t handle it correctly either. Using Pi Pin 13 / GPIO 27 / circuit Python board.D27 as CS and things work fine.

An alternative is to change the _read_register() function to use write_readinto() in place of write() followed by readinto(). Using these the system manages CE0 just fine for CS.

The library file sparkfun_qwiicas3935.py is installed at /usr/local/lib/python3.7/dist-packages. My mods can be found here. The key bit is:

<code>self._spi.write_readinto(bytearray([addr,0]), result</code>)
# self._spi.write(bytearray([addr]))
<code># read the next byte after writing the address</code>
# self._spi.readinto(result)

The modified code also comments out the manual CS line manipulation.

Additional resources can be found at Instructables.

A copy of the AS3935 datasheet can be found here.

4/3/2020

Weather radio part 4

Filed under: General,Home Automation,RTL-SDR — taing @ 1:23 pm

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

Weather Radio Part 3

Filed under: General,Home Automation,RTL-SDR — taing @ 10:19 am

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.

4/2/2020

Doorbell and Gas meter

Filed under: Home Automation,RTL-SDR — taing @ 3:51 pm

In looking for the Honeywell doorbell, model RCWL330A, FCC ID HS9-51459SL, which should be at 916.8MHz I found my gas meter (rtl_433 device 149). The output looks like:

time      : 2020-04-02 14:04:27
model     : ERT-SCM      Id        : 5458xxxx
Physical Tamper: 3       ERT Type  : 24            Encoder Tamper: 0         Consumption Data: 525682
Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2020-04-02 14:05:02
model     : ERT-SCM      Id        : 5600xxxx
Physical Tamper: 0       ERT Type  : 8             Encoder Tamper: 0         Consumption Data: 208204
Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2020-04-02 14:07:28
model     : ERT-SCM      Id        : 5458xxxx
Physical Tamper: 3       ERT Type  : 24            Encoder Tamper: 0         Consumption Data: 525682
Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2020-04-02 14:07:55
model     : ERT-SCM      Id        : 5458xxxx
Physical Tamper: 3       ERT Type  : 24            Encoder Tamper: 0         Consumption Data: 525682
Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

I’ve modified the Id field to but this above shows both my meter and the neighbors. A quick check of wikipedia gives a few more details on the data. Github also has a project targeting these meters – rtlamr. Grid Insite has more detail on the technology and history of these meters.

Now, back to the doorbell. I was hoping this might be a built in device for rtl_433 but further searching reveals it might be different from the predefined devices 115 & 116. Strangley I see nothing from the doorbell but is still rings. Further testing obviously needed.

4/1/2020

Updates to flight tracking

Filed under: General,Home Automation,RTL-SDR — Tags: , — taing @ 3:21 pm

After not changing the pi for the outdoor temp/humidity I2C sensor, I decided to use the Pi 3 to replace the older Pi 2 that was doing the ads-b flight tracking and feeding on FlightRadar24. This started with rtl_433 already and installed and working as described in an earlier post. rtl_433 is not required but having installed it I’m sure rtl_sdr is installed and the udev rules for the dongle are already in place. I decided to try readsb instead of dump1090-fa. And dump1090-mutability is now marked as maintained.

I found automated scripts for both dump1090-fa and readsb. The script for readsb seems to have worked. I have the webpage at both http://<host>/radar and http://<host>:8080. Script archived here.

The enhanced tar1090 web interface is installed next. The new interface can be seen at http://<host>/tar1090.

Adding a bit of config info:

Set your location with sudo readsb-set-location 50.12344 10.2342.

sudo pico /etc/default/readsb to edit the main config file.

In the case of more than one RTL-SDR dongle in the Pi you may need to modify the line RECEIVER_OPTIONS="--device 0 --device-type rtlsdr --gain -10 --ppm 0" for the correct device number.

sudo pico /usr/share/readsb/html/script/readsb/defaults.js to edit the default webinterface config.

sudo pico /etc/default/tar1090 to edit the tar1090 web interface configuration. A restart with sudo systemctl restart tar1090 is needed after any changes.

Next we’ll add PiAware so we can feed FlightAware some of our data.

wget https://flightaware.com/adsb/piaware/files/packages/pool/piaware/p/piaware-support/piaware-repository_3.8.1_all.deb
sudo dpkg -i piaware-repository_3.8.1_all.deb

sudo apt-get update
sudo apt-get install piaware

sudo piaware-config allow-manual-updates yes

If you are upgrading/replacing and existing site you can use piaware-config feeder-id 12345678-1234-1234-1234-123456789abc to set the site id. You will need to restart the service after making the change.

Confirm your FlightAware feed at https://flightaware.com/adsb/stats. You can make an account and update your position. The service status can be seen with sudo service piaware status.

Next we will add ADSB Exchange feeder:

sudo apt-get install git
sudo rm adsb-exchange -rf
git clone https://github.com/adsbxchange/adsb-exchange.git
cd adsb-exchange
sudo bash setup.sh

If that is successful you should be able to find yourself at https://www.adsbexchange.com/myip/

Now we can add the ADSBX stats package for feeders:

cd /home/pi
git clone https://github.com/adsbxchange/adsbexchange-stats.git
cd adsbexchange-stats
chmod +x install.sh
sudo ./install.sh

Flightradar24 instructions from their forums are not 100%. The contents of the script referenced does not completely match the manual steps. There are alternative but similar instructions in a different forum post.

sudo apt-key adv --recv-key --keyserver pool.sks-keyservers.net C969F07840C430F5
sudo nano /etc/apt/sources.list

then add the following line to the file (/etc/apt/sources.list)

deb http://repo.feed.flightradar24.com flightradar24 raspberrypi-stable
sudo apt-get update
sudo apt-get install fr24feed
fr24feed --signup
sudo systemctl restart fr24feed.service

There might be a warning you that there is no dump1090 installed and that one will be installed by fr24feed when it starts. This did not appear to happen.

You can monitor status for the fr24feed with fr24feed-status or at http://<host>:8754.

Next we add graph1090 following the install instructions in the readme. The graphs are then available at http://<host>/graphs1090 or http://<host>/pref.

The graph1090 instructions recommend reducing the number of sd card writes for a pi. Below with reduce the writes to once every 10 minutes.

sudo tee /etc/sysctl.d/07-dirty.conf <<EOF
vm.dirty_ratio = 40
vm.dirty_background_ratio = 30
vm.dirty_expire_centisecs = 60000
EOF

3/31/2020

Adding Lacrosse Weather to Garage Pi

Filed under: General,Home Automation,RTL-SDR — taing @ 6:54 pm

The sdr stick we are using is the NooElec R820T.

Following the instructions from https://morioh.com/p/fd9b47cbc020 :

# install dependencies
sudo apt-get install libtool libusb-1.0.0-dev librtlsdr-dev rtl-sdr cmake

# clone rtl_433 Git Repository
git clone https://github.com/merbanan/rtl_433.git

# change to directory
cd rtl_433/
# make build folder
mkdir build
cd build/
# compile
cmake ../
# make
make
# install
sudo make install
# test if rtl_433 was properly installed
rtl_433 -h

After this we copied the udev rules from https://github.com/osmocom/rtl-sdr/raw/master/rtl-sdr.rules to /etc/udev/rules.d/rel-sdr.rules. This resolves the permission issue access the dongle when not root.

A test of rtl_433 then see the LaCrosse Technologies TX145WSDTH remote temp/humidity/wind speed/wind direction sensorthat came with the S81120 base station.

rtl_433 -F mqtt:<host>:1883 is enough to get things going to the mqtt broker on the destination machine.

Sample Output as seen on the destination PC using mosquitto_sub -v -t '#' :

rtl_433/jtk-garage/events {"time":"2020-03-31 16:31:10","model":"LaCrosse-TX141W                                                                                                                                                             ","id":303173,"channel":0,"battery_ok":1,"temperature_C":5.1,"humidity":75,"test                                                                                                                                                             ":0,"mic":"CRC"}
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/time 2020-03-31 16:31:10
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/id 303173
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/channel 0
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/battery_ok 1
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/temperature_C 5.1
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/humidity 75
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/test 0
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/mic CRC
rtl_433/jtk-garage/events {"time":"2020-03-31 16:31:10","model":"LaCrosse-TX141W","id":303173,"channel":0,"battery_ok":1,"wind_avg_km_h":3.5,"wind_dir_deg":351,"test":0,"mic":"CRC"}
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/time 2020-03-31 16:31:10
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/id 303173
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/channel 0
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/battery_ok 1
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/wind_avg_km_h 3.5
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/wind_dir_deg 351
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/test 0
rtl_433/jtk-garage/devices/LaCrosse-TX141W/0/303173/mic CRC

Now we can edit the openhab files to make use of this info…

3/29/2020

Updating Garage Pi

Filed under: General,Home Automation — taing @ 9:58 pm

The original garage pi was a model 1 – 26 pin GPIO, 2 USB A, composite video, full size SD card. It served admirably for many years but I was looking to add to its responsibilities. So a Raspberry Pi 3 is replacing it.

The Pi 3 had been in the drawer for a year or so with raspian from late 2018. A full sudo apt-get update/upgrade/dist-upgrade later and we are ready to start.

sudo apt-get install mosquitto mosquitto-clients libmosquitto-dev gets MQTT ready to go.

The outdoor i2c temp sensor will need the library from https://bitbucket.org/loblik/libam2315/src/master/ . So wget https://bitbucket.org/loblik/libam2315/get/701be2837287.zip downloads the archive, a quick unzip and we are ready to install.

sudo make install is the magic for installing the AM2315 library we will need for the sensor.

Using the gateway C code we long ago modified from the original RFM69 Gateway Pi port, we compile with first gcc -lam2315 am2315-get.c -o am2315-get and then gcc piGateway.c -o piGateway -lwiringPi -lmosquitto -lam2315 -DRASPBERRY -DDEBUG.

A simple shell script to start things and we are done with the temp/humidity sensor. sudo ~/piGateway2/piGateway /dev/i2c-1

For clarity – the connection to the sensor uses the Pi I2C connection:

  • Pin 4 – Vcc (5v) [orange & orange/white]
  • Pin 6 – GND [brown & brown/white]
  • Pin 3 – SDA1 (GPIO2) [green]
  • Pin 5 – SCL1 (GPIO3) [green/white]

Update: So all of that is brilliant but the real reason for the upgrade was to use the RTL-SDR – well the reception is very poor from the garage so we are back to the original Pi 1 Model B V 2.0.

1/14/2019

Further Weather Alerts

Filed under: General,Home Automation — taing @ 8:48 am

The code at https://github.com/K2DLS/noaacap looks like a good start on grabbing the relevant Weather Alerts from https://alerts.weather.gov.

For my current location I am using https://alerts.weather.gov/cap/wwaatmget.php?x=OHC055&y=1 or https://alerts.weather.gov/cap/wwaatmget.php?x=OHZ013&y=1. Changing the parameter y=1 to y=0 will yield the atom/xml feed instead of the html.

Weather Radio Part 2

Filed under: General,Home Automation,RTL-SDR — taing @ 8:40 am

Continuing from http://jtkdev.com/wp/2019/01/03/pi-weather-radio-w-same/.

Using the code from http://jtkdev.com/wp/2019/01/03/pi-weather-radio-w-same/ to decode the SAME alerts in the broadcast. The current current script:

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

Notice the sample rate has been reduced to match what is expected by multimon-ng.

It was necessary to download and install multimon-ng. We also installed sox (sudo apt-get install sox) to test the dsame code with the included sample.

1/3/2019

Pi Weather Radio w/SAME

Filed under: General,Home Automation,RTL-SDR — taing @ 11:35 pm

So I have been planning to use the SDR dongle as a weather radio for some time. The goal was to stream the audio AND capture the digital SAME messages to signal weather alerts.

I found several useful references online: https://github.com/tim273/weather_radio_scripts, https://github.com/cuppa-joe/dsame, https://www.dynode.nl/streaming-radio-receivers-with-the-raspberry-pi/ and https://www.wxforum.net/index.php?topic=31396.msg314826#msg314826.

I installed rtl-sdr, lame, icecast2 and ezstream.

sudo apt-get install rtl-sdr lame icecast2 ezstream

I created 20.rtlsdr.rules in /etc/udev/rules.d/

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"

I created /etc/modprobe.d/rtlsdr-blacklist.conf

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

After rebooting I was able to use rtl_test successfully. Using the NOAA website I was able to look up the require frequency for my location. It took a bit of fiddling to get the proper frequency setting for the dongle to actually tune the desired channel. The desired frequency for me is 162.55Mhz. I ended up using 162.298M to truly tune 162.55M.

rtl_fm -f 162298000 -s 48000 -p 14

Piping this to lame results in an MP3 stream.

rtl_fm -f 162298000 -s 48000 -p 14 | lame --bitwidth 16 --signed -s 48000 --lowpass 3500 --abr 64 --scale 8 -r -m m - - > test.mp3

The next step was to create a config XML file to ezstream and test the stream. A little touch-up is required for the sample below.

exstream.xml
<ezstream>
<url>http://your-ip:8000/weather</url>
<sourcepassword>xxxxxxxx</sourcepassword>
<format>MP3</format>
<filename>stdin</filename>
<!--
Important:
For streaming from standard input, the default for continuous streaming
is bad. Set <stream_once /> to 1 here to prevent ezstream from spinning
endlessly when the input stream stops:
-->
<stream_once>1</stream_once>
<!--
The following settings are used to describe your stream to the server.
It's up to you to make sure that the bitrate/quality/samplerate/channels
information matches up with your input stream files.
-->
<svrinfoname>Weather test stream</svrinfoname>
<svrinfourl>your-ip</svrinfourl>
<svrinfogenre>weather</svrinfogenre>
<svrinfodescription>Weather test stream</svrinfodescription>
<svrinfobitrate>32</svrinfobitrate>
<svrinfoquality>2.0</svrinfoquality>
<svrinfochannels>1</svrinfochannels>
<svrinfosamplerate>48000</svrinfosamplerate>
<!-- Turn off YP directory advertising -->
<svrinfopublic>0</svrinfopublic>
</ezstream>
rtl_fm -f 162298000 -s 48000 -p 14 | lame --bitwidth 16 --signed -s 48000 --lowpass 3500 --abr 64 --scale 8 -r -m m - - | ezstream -c ezstream.xml

The test icecast2 stream can be found at http://your-ip:8000/weather. The icecast2 config can be edited at /etc/icecast2/icecast.xml. Documentation for the config file can be found at http://icecast.org/docs/icecast-2.4.1/config-file.html.

Next I’ll be working to integrate the python from https://github.com/cuppa-joe/dsame handle the digital side of the stream. For now we have the stream going to the icecast2 stream and also piping to the next thing.

rtl_fm -f 162298000 -s 48000 -p 14 | lame --bitwidth 16 --signed -s 48000 --lowpass 3500 --abr 64 --scale 8 -r -m m - - |tee >(ezstream -c ezstream.xml) | cat >test1.mp3

Seneye Home on the Pi – Part 2

Filed under: General,Home Automation — taing @ 10:52 pm

After getting the Python sorted out to read the Seneye Home it was time resolve a few outstanding issues with the unit. Seneye has only released the partial API discussed previously. This API lacks the ability to 1) register a slide 2) clear the “offline” readings stored in the unit.

Following ideas found online I setup VirtualHere. There is a Raspberry Pi server and a Windows 10 client. The free version will allow for a for sharing a single device. The free version also doesn’t support running the client as a service on Windows 10. Neither of these limitation was a problem for our setup.

I setup a cron job to run every 30 minutes. It calls a shell script which stops the VirtualHere server, runs the Seneye Python code to send reading to Openhab via MQTT and restarts the VirtualHere server.

crontab -e
*/30 * * * * ~/fish.sh
fish.sh
date >>~/Seneye-MQTT/suddriver.log
sudo killall vhusbdarm
sleep 10
python ~/Seneye-MQTT/suddriver.py >>~/Seneye-MQTT/suddriver.log
sleep 10
sudo ~/VirtualHere/vhusbdarm -b

It would be nice not to need sudo in this script but at the moment I haven’t noodled out the permissions required to get the VitrualHere server to run without sudo.

« Newer PostsOlder Posts »

Powered by WordPress