JTK – Notes and Ramblings Things we have found …

10/8/2020

Windows 10 and Iomega Floppy Plus

Filed under: General — taing @ 9:58 am

The Iomega Floppy Plus has been around for quite a while. It has CompactFlash and SD card slots in addition to being a 3.5″ floppy drive. When first plugged into a Windows 10 machine the CF and SD slots appear as drive letters. The Floppy remains silent and does not appear in the drive list.

You need to install drivers. Fortunately, while there are no official drivers from Iomega, there are drivers that work.

From Device Manager:

  • Select the X1DE-USB device from the Other Devices list.
  • Right-Click to Update Driver.
  • Browse My Computer for Driver Software.
  • Let me pick from a list of device drivers on my computer
  • Show All Devices
  • Manufacturer = NEC Systems / Model = NEC USB Floppy
  • Acknowledge the warningthat Windows can’t verify this is the right driver.

The floppy drive should work now. Refer to https://www.techgeekandmore.com/getting-the-iomega-usb-floppy-drive-working/ for a version of these instructions with screenshots.

6/22/2020

Dust – adding the SDS011

Filed under: General,Home Automation — taing @ 11:23 am

A SDS011 dust sensor(datasheet and communications protocol) from Amazon has been added to openhab. There is lots of good info online describing the sensor performance and Arduino(1, 2), ESP32(1, 2) and Raspberry Pi(1, 2, 3, 4, 5) setup. There is even PC based software for testing.

Nettigo has a interesting article on using the sensor with a heater inline to improve performance in high humidity. They use a Sensirion SHT30 to automatically drive a MOSFET to trigger a PTC Heating element.

One of the nice things about the package as purchased is it comes with connectors and an USB/serial adapter to allow for connections using USB, TTL serial or i2c.

In the end, it was simplest to use the brand new Openhab plugin binding. The binding reports both 2.5 and 10 µg/m³. The binding allows for easy setup of reporting mode allowing the sensor to pretty much manage itself. For reporting mode, a reporting interval is set. The unit will wake up every interval and measure for 30 seconds then sleep for interval minus 30 seconds.

Since plugging the sensor directly into the openhab server in the basement wasn’t going to be very useful a modified version of the same method used to remote the Z-Wave dongle was used. This required installing ser2net on the Pi with the sensor and setting the correct comm parameters(9600 8N1) and making copies of /etc/default/socat.conf(updated with the proper device name and IP address of the Pi with the sensor) and /etc/init.d/socat (updated to point to unique .log and .pid files and the new .conf file).

6/21/2020

Update to LaCrosse weather

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

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://jtk-openhab,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/local/bin/rtl_433
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

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

6/20/2020

Migration – a new server for openhab

Filed under: General,Home Automation — taing @ 3:39 pm

It was time to migrate the openhab installation from the Raspberry Pi 3B to the NUC.

Before leaving the Pi a full backup is required. openhab-cli backup name_of_zipped_backup. Details on the backup and restore process can be found in the openhab forums.

The installation starts with a fresh Debian Buster(10.4) console only install. Openhabian was added from git following the guide at https://www.openhab.org/docs/installation/openhabian.html.

sudo apt-get install git screen curl gnupg
sudo git clone https://github.com/openhab/openhabian.git /opt/openhabian
sudo ln -s /opt/openhabian/openhabian-setup.sh /usr/local/bin/openhabian-config

The optional Influx db for persistence and Grafana for graphs were added from the openhabian-config tool. Chronograf 1.8 was also added manually ( sudo apt-get install chronograf ) since Influx after v1.3 doesn’t support the web console anymore. Note this is from the Influx repo which is added by the openhabian-setup tool.

At this point:
Openhab web interface -> http://your_ip:8080
Openhab console (ssh) -> your_ip:8101
Influx web admin (chronograf) -> http://your_ip:8888
Grafana -> http://your_ip:3000

Hopefully, at this point it’s time to restore the backup made earlier on the Pi: openhab-cli restore name_of_zipped_backup

Possible Issues

To resolve the issue of the openhab repo not being properly signed refer to the discussion in the openhab forums. You will need to execute:

wget -qO - 'https://bintray.com/user/downloadSubjectPublicKey?username=openhab' | sudo apt-key <strong>add</strong> -

If you encounter errors in the log file regarding RestDocs, for example, “ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-misc-restdocs’“, refer to the discussion in the forums. The secret is the second set of config files at /var/lib/openhab2/config/org/openhab/addons.config.

If you encounter broken graphs in the Openhab UI with error messages similar to [WARN ] [org.eclipse.jetty.server.HttpChannel] - /chart
java.lang.Error: Probable fatal error:No fonts found
refer to the discussion in the forums. The trick here is to install fontconfig for 32 bit arch even on a 64 bit machine: sudo apt-get install fontconfig:i386. A restart of the openhab service will be required after installing fontconfig: sudo systemctl restart openhab.service.

Remote Z-Wave

One of the main reasons openhab had stayed on the Pi so long was the location of the Pi and the Aeon Labs DSA02203-ZWUS Z-Wave Z-Stick Series 2 USB Dongle. This dongle creates /dev/ttyUSB0 for the z-wave binding. Our solution was to leave the Pi in place with the dongle and handle the serial port connection over Ethernet to the NUC. ser2net gets installed on the machine with the dongle. socat gets installed and run as a service on the openhab server machine. There is a great discussion on the in the openhab forums.

On the Pi:
sudo apt-get install ser2net
pico /etc/ser2net.conf
3333:raw:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT
On the NUC:
sudo apt-get install socat
git clone https://github.com/asaif/socat-init.git
sudo cp socat-init/socat /etc/init.d/
sudo chmod +x /etc/init.d/socat
sudo update-rc.d socat defaults
sudo cp socat-init/defaults/socat.conf /etc/default/

sudo nano /etc/default/socat.conf
OPTIONS="pty,link=/dev/ttyUSB0,raw,user=openhab,group=dialout,mode=777 tcp:ip_of_the_pi:3333"
sudo service socat restart

This will create /dev/ttyUSB0 on the NUC which looks like a serial device to the z-wav binding.

Final Steps

The final steps were to make sure everything that was pointing the to Pi was now pointing to the NUC.

The RFM69HCW 915MHz radio on the original openhab Pi remained in place listening to the Moteinos and sending mqtt but needed to have the destination updated. This required recompiling Gateway.c. Somehow the appropriate libraries weren’t already on the Pi for this: sudo apt-get install libmosquitto-dev libmosquittopp-dev. The recompile then when fine: g++ Gateway.c rfm69.cpp -o Gateway -lwiringPi -lmosquitto -DRASPBERRY -DDEBUG.

The code on the Pi sending outside temperature and humidity via mqtt from the am2315 i2c sensor needed to be recompiled to send to the proper destination: gcc piGateway.c -o piGateway -lwiringPi -lmosquitto -lam2315 -DRASPBERRY -DDEBUG.

The Pi running the Weather Alert / SAME code needed to have the destination address updated. This is a simple change to the mqtt command line parameter in the script. The same Pi also runs the Seneye aquarium monitor code which needed an edit in suddriver.py to update the mqtt destination.

The Pi running rtl_433 for the LaCrosse weather station integration required an update to rtl_433.conf to point the mqtt data to the new destination. The same Pi also runs the as3935 Lightning detector. A quick modification to the python script to fix the mqtt destination got this back online.

5/18/2020

Earthquake

Filed under: General,Home Automation — taing @ 4:50 pm

An article on the Raspberry Shake got me looking for more on earthquake sensors. I found the Omron D7S. Datasheet here.

The chip can be found at both Mouser and Digikey. It is a small SMT mountable PCB that communicates via i2c. The datasheet provides little info on actually programming the device. Googling about found two libraries that helped shed some light on things.

First, from Omron, a python library on github. The platform of choice is a Pi Zero W with Rasbian Buster Lite. To get started, install git, i2c-tools, python3-smbus, and python3-rp-gpio. Clone the repo and the software is ready.

Connecting the sensor to the Pi only needed four wires – 3.3v, gnd, SDA, SCL. 10k pull-up resistors are used for SDA and SCL. A 10k pull-up was also added for the sensor “settings” pin. Both Vcc and both Ground pins on the sensor need to be wired.

  • Pi pin 1 – Vcc to Sensor pins 1 & 9
  • Pi pin 1 – Vcc to 10K pullup resistors to sensor pins 4, 5 & 7
  • Pi pin 9 – Ground to Sensor pin 6 & 10
  • Pi pin 3 – SDA to sensor pin 5
  • Pi pin 5 – SCL to sensor pin 4

Sensor pins 2 and 3 provide optional interrupts. Pin 3 goes low when a quake is in happening. Pin 2 goes low to signal suggested shutdown due to expected significant damage. These pins are not used in this setup.

sudo i2cdetect -y 1 showed the chip at address 0x55. sudo python3 sample_d7s ran as advertised.

I added a few line of code to have the output go to a Google Sheet and set the unit up in the basement. Details on how this works can be found in an earlier post.

The second library is for Arduino. It appears to provide much greater detail on the registers and parameters on the chip but I have not tested it.

An additional article on How to Make an Earthquake Alarm is a alternative approach.

The chip measures quake intensity not magnitude. The measurement correlates strongly with the Japan Meteorological Agency seismic intensity scale. A discussion on various seismic intensity scales can be found here or copied here.

Omron shared a more detailed datasheet.

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/6/2020

VirtualHere remote USB

Filed under: General — taing @ 2:16 pm

We have used VirtualHere before. This time I thought it might be fun to try it for the iPlayer3 and SmartJackPro. This would involve both ColorPlay3 and QuickPlayPro. The good news is it works. I was able to upload a show to the iPlayer and output DMX from the SmartJackPro. I have not yet tried addressing a fixture via the SmartJackPro.

The remote is a Raspberry Pi 3 running Raspbian Lite Buster(2020-02-14).

The PC is running Windows 10 64-bit.

Server Side

VirtualHere has a download for ARM that runs quite well on the Pi 3 on their Linux server download page. A simple wget https://www.virtualhere.com/sites/default/files/usbserver/vhusbdarm into the folder of your choice followed by chmod +x ./vhusbdarm and sudo vhusbdarm -b and you are set on the server side.

The VirtualHere FAQ describes how to have the server setup to start as a service. The steps for a Pi are pretty straighforward: First you need to copy the server over to /usr/bin: sudo mv vhusbdarm /usr/sbin. Then you will need to create /etc/systemd/system/virtualhere.service with these contents.

[Unit]
Description=VirtualHere USB Sharing
Requires=networking.service
After=networking.service
[Service]
ExecStartPre=/bin/sh -c 'logger VirtualHere settling...;sleep 1s;logger VirtualHere settled'
ExecStart=/usr/sbin/vhusbdarm
Type=idle
[Install]
WantedBy=multi-user.target

Then the following commands will setup the service to run at boot.

systemctl daemon-reload
systemctl enable virtualhere
systemctl start virtualhere

NOTE: a license is required to 1) share more than one device with the server or 2) use the CPU optimized versions of the server or 3) sell VirtualHere with your hardware. As of April 2020 the license cost $49. The license key is tied to the hardware of the server.

Details on advanced configuration of the server can be found here.

Client Side

The client is downloaded from the VirtualHere site. There are versions for Linux, OSX and Windows. The download is a single executable file. The first run will install the VirtualHere client drivers and will require admin rights.

The documentation on running the client as a service can be found here. You can not use the client as a service unless the server has a license installed.

The client will offer to install Bonjour, it the server is not already installed, for its auto-discovery feature.

Advanced configuration information and command line parameters are described here.

Open Lighting

Filed under: General — taing @ 10:10 am

Installing Open Lighting Architecture on a Raspberry Pi 3.

We start with a clean install if Rasbian Buster Lite. As of April 2020 the raspian repo has the latest version – 0.10.7 so a simple sudo apt-get install ola will suffice. You can confirm the version in the repo with apt show ola. There is additional info on using ola installed from apt here. The info is older but still useful.

If you want to do things the hard way, follow the instructions for a Linux install from git. The Raspbian images for OLA are several years out of date. We will install a bunch of prerequisites first, checkout the project from git, then config and build.

sudo apt-get install libcppunit-dev libcppunit-1.13-0 uuid-dev pkg-config libncurses5-dev libtool autoconf automake g++ libmicrohttpd-dev protobuf-compiler python-protobuf libprotobuf-dev libprotoc-dev zlib1g-dev bison flex make libftdi-dev libftdi1 libusb-1.0-0-dev liblo-dev libavahi-client-dev python-numpy

sudo apt-get install git
git clone https://github.com/OpenLightingProject/ola.git ola
cd ola
autoreconf -i

If there are config changes to make of modules to enable. The sample below shows enabling RDM test.

./configure --help
./configure --enable-rdm-tests

Now we are ready to build. This will take a bit of time.

make
make check
sudo make install
sudo ldconfig

If everything went well we are ready to start ola.

olad -l 3

You can view the web gui at http://<host>:9090.

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

Something for the future – Roku

Filed under: General — taing @ 12:45 pm

bwarden has also got a git repo for the python control of the roku which is a fork of https://github.com/jcarbaugh/python-roku. It seems to support basic control and discovery. The discovery code is SSDP which may prove useful elsewhere.

For openhab integration there is a good forum discussion

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.

« Newer PostsOlder Posts »

Powered by WordPress