OpenHAB 2 MQTT Adafruit.io

Paper UI: Extensions-->bindings--> add MQTT Broker
Create/edit the file /opt/openhab2/conf/Services/mqtt.cfg

Sample mqtt.cfg

adafruit.url=tcp://io.adafruit.com:1883:1883
//client ID - unique string - anything
adafruit.clientId=48c70a89dbf3eff670d6db18bc804504

//username - your ADAFRUIT IO username
adafruit.user=myusername

//password is your AIO KEY
adafruit.pwd=1234567834567dfghjrtyuvb

//other items can be left alone

Sample ITEM definition, for a NUMBER feed from the Adafruit feed key "templogger1"

Number temperaturelog "temperature [%.1f]" {mqtt="<[adafruit:myusername/feeds/templogger1:state:default]"}

note that compared to the demo in the  documentation, there is no leading / on the topic. This caused me a big headache!

Sample SITEMAP

Text item=temperaturelog label="Adafruit temperature feed"


There is an issue with the system remembering old MQTT broker settings. You can clear out all previous MQTT settings via the openhab2 Karaf console:
Adjust your mqtt.conf as needed, then in the console
config:edit org.openhab.mqtt
config:property-list
config:delete

restart openhab2

Lighwaverf OpenHAB 2 (And amazon echo dot)

Ubuntu 14.04LTS x64
Java 1.8.0_111
Openhab2 2.0.0b4 2.0.0 -SNAPSHOT build #560 offline manual install, as per http://docs.openhab.org/installation/linux.html#manual-installation
(therefore my openhab2 is installed under /opt/openhab2) - adjust where necessary. 1.x compatibility was already enabled in this release

1 - create file opt/openhab2/conf/Services/openhab.cfg and populate with the sample lighwaverf binding configuration as per
https://github.com/openhab/openhab/wiki/LightwaveRF-Binding
I left alone - the default IP using the broadcast address worked for me.

2 - copy the lighwaverf binding jar (version 1.9.0) from snapshot build (link below), into /opt/openhab2/addons/
https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastSuccessfulBuild/artifact/bundles/binding/org.openhab.binding.lightwaverf/target/
When I copied the .jar file over, my lightwave hub immediately started blinking saying "add app?", so I clicked YES.
The default settings for looking for the device on the broadcast IP 255.255.255.255 worked!

Depending on how you copied the file over (I used filezilla from my windows machine to the linux server) You might have to check permissions are set properly; I configured it as per manual install to run under user:group openhab, and changed owner of conf/services/openhab.cfg and addons/opt.xxxx.lighwavexxxx.jar to openhabuser&group

3 - create an Openhab "Item" in /opt/openhab2/conf/Items (I appended the demo.items file) - one line for each of your switches/dimmers etc - this is where you need to customise your individual device/switch/dimmer/mood. here's a sample switch in room 2, device 3: (sudo nano /opt/openhab2/conf/Items/demo.items)
Switch LWRF_light1 "bedside light" { lightwaverf="room=2,device=3,type=SWITCH" }

4 - create a switch in a Sitemap, so you can control it from the GUI:
Switch item=LWRF_light1 label="Bedside Light"

that's it - check the events.log or log:tail command

The above creates the OpenHAB lightwaverf switch

You also need to create a Hue Switch in OpenHAB that can be detected by the Amazon Echo
(the Amazon Echo OpenHAB bridge turns your OpenHAB into an emulated Philips Hue system, which Echo then detects/controls)
Then you can link the Lightwaverf switch to the Hue switch using a Rule (or probably some more elegant method)
updated guide below:
1) install OpenHAB2 somewhere on your home network
http://docs.openhab.org/installation/
From the PaperUI interface to openHAB2
2) Install Amazon Echo Bridge (Philips Hue emulation)
Extensions–>Misc–>Hue Emulation
(further reading) http://docs.openhab.org/addons/io/hueemulation/readme.html
3) Install Lighwaverf binding 1.9.0 (not fantastically userfriendly at the moment in openHAB2) see
https://community.openhab.org/t/lightwaverf-openhab2/13717/5
4) Create an Item in OpenHAB conf/items, that will control the Lightwaverf switch
Switch LWRF_light1 “bedside light” { lightwaverf=”room=2,device=3,type=SWITCH” }
5) Create an emulated HUE Item in OpenHAB, that Echo can control – see https://github.com/openhab/openhab2-addons/tree/master/addons/io/org.openhab.io.hueemulation. e.g.
Switch HUE_LWRF_light1 “bedside light Echo” [ "Switchable" ]
6) create a rule in /opt/openhab2/conf/rules (e.g. demo.rules), to update your lightwaverf switch state when you update the Echo/hue switch
**there will probably be a more elegant way of doing this, using bindings or something **

// ECHO TO LIGHTWAVE – when Amazon Echo switch is updated, also update the lightwaverf switch
rule “LWRF bedside light”
when
Item HUE_LWRF_light1 received command
then
println (“command”)
sendCommand(LWRF_light1, receivedCommand)
end

7) Turn on Pairing in OpenHAB (Configuration–>Services–Hue Emulation–>Start
8) Ask alexa “Alexa, discover devices”. It will then discover the new HUE switch, that you control using the description you gave to the item (e.g. “Bedsite light”)
9) Create a switch in your openhab Sitemap, if you also want to control via your openHAB gui. Create it for the HUE switch rather than the LWRF switch and it will mirror the commands sent via Echo.
Switch item=HUE_LWRF_light1 label=”Bedside Light”

find my iphone using amazon dash button openhab

Using Amazon Dash Button and OpenHab2 to find my iphone

2.0.0-SNAPSHOP build #560
instructions as per
https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.amazondashbutton

follow install pcap4j, including permissions for running as non-root:

then for the java path I did
whereis java
then ls -l /usr/bin/java
ls -l /etc/alternatives/java
then

setcap cap_net_raw,cap_net_admin=eip /usr/lib/jvm/java-8-oracle/jre/bin/java

started openHAB script
sudo su -s /bin/bash -c '/opt/openhab2/start.sh' openhab

let it run 15 mins - check GUI ok, then restarted it

on my router, I noted down all current DHCP leases, then followed the dash button setup until the point of choosing button, then stopped, then looked for new DHCP lease and found the MAC address AC-63-BE-XX-XX-XX, gave it a fixed IP assignment then blocked it in the router firewall for WAN access.

enable amazon dash binding in Paper UI - click install

when happy, press the button and the Dash button appears as a Thing in inbox!
click the tick in the Inbox to add the dash button as a Thing.
make a note of the CHANNEL that the dashbutton publishes its events to, something like
amazondashbutton:dashbutton:ac-63-be-xx-xx-xx:press

Now you can just add a rule in /opt/openhab2/conf/rules
e.g.
sudo nano dashbuttons.rules

rule "Dash button pressed" when Channel "amazondashbutton:dashbutton:ac-63-be-xx-xx-xx:press" triggered then
println("The Dash button has been pressed") end


change owner to openhab as per the install guide,

sudo chown openhab:openhab dashbuttons.rules

What got me was that the usual approach of Thing < -- bind with channel --> Item isn't followed. The dash button is a pure Thing with channel trigger - no Item to bind to - no Item State/Command to run in a rule

Discussion here:
https://community.openhab.org/t/amazon-dash-button-as-openhab-trigger/3622/52


Now, get the PHP 'find my iphone' library
as per
http://blog.qnology.com/2015/11/voice-control-home-automation-via.html
(adapted for OH2)

cd /opt/openhab2/conf/scripts

sudo git clone git://github.com/albeebe/PHP-FindMyiPhone

sudo cp PHP-FindMyiPhone/class.findmyiphone.php .

UPDATE Jan 2017 - ensure you use version of pull request 12th Jan 2017 or later as API has changed.

You may also need to install/configure PHP for SSL certificates

edit php.ini and add/uncomment line

curl.cainfo=/etc/ssl/certs/cacert.pem
then download the https://curl.haxx.se/ca/cacert.pem and save to above store.
If on windows, then replace with something like
curl.cainfo="C:\certs\cacert.pem"

http://stackoverflow.com/questions/6400300/https-and-ssl3-get-server-certificatecertificate-verify-failed-ca-is-ok

sudo wget --no-check-certificate http://dl.dropbox.com/u/42238/debian/openhab/custom_scripts/listiclouddevices.php

sudo wget --no-check-certificate http://dl.dropbox.com/u/42238/debian/openhab/custom_scripts/turnoniphone.php

sudo wget --no-check-certificate http://dl.dropbox.com/u/42238/debian/openhab/custom_scripts/turnoffiphone.php

#FIND MY IPHONE SETUP
#CONFIGURE SAMPLE SCRIPTS
#Edit listiclouddevices.php with your iCloud username (email) and password

cd /opt/openhab2/conf/scripts
sudo nano listiclouddevices.php


#Run it to find your deviceID
#DeviceID will be something like Eu4EGWK1Yt5+2JtKM7YNA++hxNtDw4ZzZuwT9BLxYcL2d7FaULCJMuHYVNSUzmXV<
php ./listiclouddevices.php

#Edit turnoniphone.php, turnoffiphone.php
#with username, password and deviceID

sudo nano turnoniphone.php

sudo nano turnoffiphone.php

#Run scripts to test

php ./turnoniphone.php

php ./turnoffiphone.php

Permissions are a sticky point.
After creating php scripts, I changed all files in openhab2 to be owner:openhab, group openhab
for the manual install, this is
sudo chown -hR openhab:openhab /opt/openhab2

I also added my linux user to the group openhab, for ease of editing:
sudo usermod -a -G openhab myusername

Openhab2 beginner's guide

my own hints for starting from scratch with openhab2 - not a step-by-step guide!

openhab2 installation location  (ubuntu 14.04)

depends on whether you manually install or install from repo:

http://docs.openhab.org/installation/linux.html#file-locations

openhab 1 bindings in openhab2?

http://docs.openhab.org/developers/development/compatibilitylayer.html#how-to-use-openhab-1x-add-ons-that-are-not-part-of-the-distribution
in 2.0.0.B4+ (and probably earlier) the 1.x compatibility binding is already enabled.
Copy your 1.x .jar file into /opt/openhab2/addons.
Create/edit /opt/openhab2/conf/Services/openhab.cfg and add your 1.x binding configuration there
check the Karaf log or openhab.log for any issues.

lightwaverf binding openhab2

SEE DEDICATED POST LATER IN BLOG - requires nightly build 1.9.0 of addon.

get openhab1 lightwaverf binding from github
https://bintray.com/artifact/download/openhab/bin/distribution-1.8.3-addons.zip
unzip
copy the openhab binding lightwaverf into /usr/share/openhab2/addons
I did this via filezilla local sftp to my linux box, having first done:
#add my username to the openhab group  (replace myusername as needed)

sudo usermod -a -G openhab myusername

# give the openhab group permissins to the addons folder
sudo chmod g+rws usr/share/openhab2/addons

then I can unzip on windows the 1.8.3 distribution-addons.zip - move the lightwaverf jar across to usr/share/openhab2/addons

at this point, my lightwaverf hub asked immediately to authorise the app - I did nothing else - no config yet!

in /etc/openhab2/services, create file openhab.cfg
copy the supplied lightwaverf config into it, i.e. from
https://github.com/openhab/openhab/wiki/LightwaveRF-Binding

now I'm stuck - not available in bindings in Paper UI - error in log about lightwaverf missing addBinding method...

openhab2 console

- for checking the 1.x compatibility layer is installed - it was by defulat

http://docs.openhab.org/administration/console.html

More up-to-date openhab1 binding for lightwaverf available from openhab nightly build:

https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastSuccessfulBuild/artifact/bundles/binding/

Multiple LoRa clients on one frequency - how to synchronise multiple LoRa transmitters using GPS

Implementing a time division multiple access scheme for single channel non-LoRaWAN access network, we need to synchronise each transmitter's TX window in order to maximise channel capacity.

We start by working out the TX window length (based on payload, LoRa parameters, receiver gain recovery rate etc). 12 bytes of data allows us lat/long to ~10m precision. vBat to 8 bit resolution plus plus other bytes for general purpose flags.

We then use the Semtech LoRa calculator program to determine a tradeoff between on-air time and SNR margin .
* We want maximum SNR to get the best range.
* We want to minimise on-air time as our trackers are moving, and we want to squeeze as many trackers onto one radio channel as possible.
* We want to minimise bandwidth if possible, are our trackers will have greatly varying temperatures and supply voltages/currents so frequency stability might not be great.
* we want our receiver to be able to recover its AGC circuitry and have sufficient processing power/message buffering queue to be able to pick out successive transmissions (if too closely spaced and densely transmitted, the limiting factor might be our receiver, not our transmitters)

We then decide how often we want to receive position updates - a tradeoff in refresh rate and remote battery life.

We then work out how tight a timing/synchronising loop we can achieve using the available hardware (48MHz onboard clock, GPS PPS synchronisation driving hardware interrupts

We can then design our TDMA scheme around these parameters.

For me, 30 second position updates is more than adequate. I would want to fit around 100 devices on one radio channel.
Rounding numbers up gives us 120 devices transmitting once every 30 seconds, or one transmission every 250 milliseconds.

traccar-web with custom offline maps

(incomplete)

traccar-web interface to traccar.org

* allows URL sign-on and better mobile interface

https://github.com/vitalidze/traccar-web/

quick and dirty method - replace opensteetmap tile url with local tilestache server tiles

get file-roller (archive manager):

sudo apt-get install gnome-common

sudo apt-get install yelp

git clone 

https://wiki.gnome.org/Apps/FileRoller

./auto

install traccar.org and traccar-web as per their respective installers - confirm working.

On linux system you can open /opt/traccar/traccar-web.war with archive manager, edit files then re-pack quite easily. https://wiki.gnome.org/Apps/FileRoller (installed default in ubuntu 12.0.4 

We are concentrating on the mobile interface

traccar-web.war/m/index.html:

change any references to CDN cloudflare css or js libraries to point to "js/{name of js" or "css/{name..." as required.

then download and add the css or js file to the traccar-web.war/js/ or /css within the archive and re-pack the grml file

...

raspberry pi lora hoperf python code

clone
https://github.com/mayeranalytics/pySX127x
sudo apt-get install python-dev

wget https://pypi.python.org/packages/source/s/spidev/spidev-3.1.tar.gz
tar xfvz  spidev-3.1.tar.gz
cd spidev-3.1
sudo python setup.py install

sudo pip install Adafruit

sudo pip install httplib2

edit files to account for Uputronics Hoperf board#############

pySX127x/SX127x/board_config.py:

line 33 onwards

change pins for the HAB pi board on CE1:

class BOARD:

  # Note that the BCOM numbering for the GPIOs is used.   

    DIO0 = 16   # RaspPi GPIO 16 = wpi 27 = phys 36 (input)#dio0 on habboard

  #  DIO1 = 12   # RaspPi GPIO 12 = wpi 26 = phys 16 (input)DIO5 on habboard

   # DIO2 = 24   # RaspPi GPIO 24 = wpi 5 = phys 18 (input)#notused

   # DIO3 = 25   # RaspPi GPIO 25 = wpi 6 = phys 22 (input)#notused

    LED  = 13   # RaspPi GPIO 23 = wpi 1 = phys 33 ( make output on ‘internet’ LED)

#################

line 74, in def SpiDev(): and change to

BOARD.spi.open (0,1) #for HOPE module at bus CE1

###################

pySX127x/SX127x/LoRaArgumentParser.py

line 41 onwards

change the default= items in the __init__ self section to the required frequency, spreading factor,bandwidth etc that you are using. Setting them here for 433MHz board means constructing a LoRa object without all the parameters will at least work without defaulting to 868mhz. I have mine set at 434.4mhz

#####################

pySX127x/SX127x/LoRa.py

Line 84 change calibration freq to 433mhz

Line 815 change freq to 433mhz

This just allows the self-test facility to work at 433mhz without supplying further parameters

remove any initialisations for DIO2 onwards

################

you can now run pySX127x/test_lora.py, to see if it works. Do a ‘gpio readall’( part of wiringpi) beforehand, which seems to un-stick it – I guess some wiring pi is not being initialised completely….

#################

I have a blind receiver running continuously, so I just modify the file pySX127x/rx_cont.py:

Line 44: in function

   def on_rx_done(self):

this is where I add my code – and is triggered on each
successful packet reception:IO

installing tilestache on raspberry pi 3

from clean raspbian jessie install
open terminal
sudo pip install tilestache

you may get a warning  re compilation terminated, but read it carefully - this is just for C extension speedups which are not compulsory

make directory to serve tiles from and store tilestache

mkdir /home/pi/src/tilestache
create config file as shown in previous posts
sudo nano tilestache.cfg

change hostname of pi:
start tilestache: (assuming your pi is set for hostname pitracker.local)
tilestache-server.py -c /home/pi/src/tilestache/tilestache.cfg -i pitracker.local -p 8080

Installing traccar.org on raspberry pi 3

from fresh raspbian distribution image
in a terminal

1. expand filesystem and refresh raspbian
raspi-config
follow instructions to expand filesystem to fill SD card
sudo apt-get update
sudo apt-get upgrade
1.a optional - I operate via RDP gui: sudo apt-get install xrdp

2. download traccar.org Linux ARM
currently this version:
https://github.com/tananaev/traccar/releases/download/v3.6/traccar-linux-arm-3.6.zip
extract to e.g. /home/pi/downloads
sudo /home/pi/Downloads/traccar.run

sudo /opt/traccar/bin/traccar start

traccar.org deficiencies

serving traccar.org 3.6 web interface over rpi wifi to mobile device is EXCEEDINGLY slow - read 30 seconds to download all resources, parse java etc on iphone4s.
then, the mobile interface is quite clunky.
given this is a race tracker and the web portal is designed for viewing by general public, we want simple decluttered interface minus logon if possible

traccar.org 3.6 web interface:
pros:

• custom map (for serving our own tiles)
• easy to change html source for referencing offline cdn/js libraries without recompiling

cons:

• web interface is slow to load over rpi wifi and iOS
• mobile interface is poorly fitted to mobile canvas size
• no 'show track' easily available
• no 'no logon/auto logon' available

this project using the old traccar.org web interface package seems to be better suited, but isn't ideal either

https://github.com/vitalidze/traccar-web/
pros:

• auto-logon via http get is possible (we can set a landing page on our rpi captive portal to auto log on as guest and go to mobile site
• mobile site is very good on mobile device
• track is shown
• .war file is just a zip - changing code relatively easy

cons

• no custom map layer - will need to recompile .war to add custom map source if possible (replace OSM url's probably...?)
• will need to recompile .war each time to make changes to code..
• not easy to see where libraries are loaded
• device icons are static, not direction-based arrows
• no track shown in mobile layer
• 
  

Making Traccar.org server work without internet connection

/opt/traccar/web/release.html:
download all external references to cloudflare CDN for css and java libraries to a new folder:

need to clone extjs/6.0.1/classic/theme-neptune/resources into ajaxlocal
sudo mkdir /opt/traccar/web/ajaxlocal
cd //opt/traccar/web/ajaxlocal
sudo wget http://{cdn css or js library to download} 
you will also need to download http://cdnjs.cloudflare.com/ajaz/libjs/extjs/6.0.0/classic/locale/locale-en.js (if this is your chosen language

http://cdnjs.cloudflare.com/ajax/libs/extjs/6.0.1/classic/theme-neptune/resources/theme-neptune-all_1.css
http://cdnjs.cloudflare.com/ajax/libs/extjs/6.0.1/classic/theme-neptune/resources/theme-neptune-all_2.css

theme-neptune-all_1.css
and
theme-neptune-all_2.css
(probably a more elegant way of doing it)
download fontawesome from fontawesome.io version 4.6.3 (or whatever version is called by script - check the debug console of your browser for network resources it tries to load.
extract font-awesome css and font-awesome.min.css into the new /ajaxlocal folder
make a new folder
sudo mkdir /opt/traccar/web/fonts/

extract font-awesome/fonts into /opt/traccar/web/fonts/
cd /opt/traccar/web/fonts
sudo cp /home/pi/Downloads/font-awesome-4.6.3/fonts/* ./


edit /opt/traccar/web/locale.js to point to your ajaxlocal/locale-en.js as downloaded above so the line looks like
Ext.Loader.loadScript('ajaxlocal/locale-' + Locale.languages[Locale.language].code + '.js);

Making Traccar.org server work without internet connection

/opt/traccar/web/release.html:


download all external references to cloudflare CDN for css and java libraries to a new folder:

sudo mkdir /opt/traccar/web/ajaxlocal
cd //opt/traccar/web/ajaxlocal
sudo wget http://cdnjs.cloudflare.com/ajax/libs/ol3/3.17.1/ol.css
sudo wget http://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css
sudo wget http://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.css
sudo wget http://cdnjs.cloudflare.com/ajax/libs/ol3/3.17.1/ol-debug.js

get extjs 6.0.1 GPL, download via signup at:
https://www.sencha.com/legal/gpl/

copy ext-6.0.1-gpl\ext-6.0.1\build\*.* into
/opt/traccar/web/ajaxlocal/

(final structure is /opt/traccar/web/ajaxlocal/build/,,,,


download fontawesome from fontawesome.io version 4.6.3 (or whatever version is called by script - check the debug console of your browser for network resources it tries to load.
extract font-awesome css and font-awesome.min.css into the new /ajaxlocal folder
make a new folder
sudo mkdir /opt/traccar/web/fonts/

extract font-awesome/fonts into /opt/traccar/web/fonts/
cd /opt/traccar/web/fonts
sudo cp /home/pi/Downloads/font-awesome-4.6.3/fonts/* ./


edit /opt/traccar/web/locale.js to point to your ajaxlocal/build/locale-en.js as downloaded above so the line looks like
Ext.Loader.loadScript('ajaxlocal/build/classic/locale/locale-' + Locale.languages[Locale.language].code + '.js);

Raspberry Pi GPS Tracker with Openstreetmap offline tiles

1) save OSM tiles to raspberry pi using maperitive in mbtiles format
  I needed to use the windows version to download the tiles, then copy to raspberry pi

2) use Tilestache to serve the tiles
my config file is in the previous post. The layer I called "osm" and is used in the map config in Traccar.
I needed to bind the tilestache server to my pi LAN IP for traccar to connect: start tilstache with the command
tilestache-server.py -i 192.168.1.19 -p 8080
adjust as necessary for your ip and port.

3) edit Traccar in TWO places
  run traccar, login as admin, then click

Settings-->Server--> Map Layer: custom map
custom map :http://192.168.1.19:8080/osm/{z}/{x}/{y}.png

change ip and port to suit, and layer name (osm) if needed if you called your tilestache layer something else

you also need to change the USER to use the custom map
Settings-->USERS-->click on your user, click edit (pencil icon)
change map layer to Custom map.

back on the tilestache console you should then see requests being logged for different zooms.

Raspberry Pi Openstreetmap tile server - tilestache config

Tilestache mbtiles example config  file
{
  "cache":
  {
    "name": "Test"
  },
  "layers":
  {
    "osm":
    {
        "provider": {"name": "mbtiles", "tileset": "/home/pi/src/tilestache/tiles/map.mbtiles"}

    }
  }
}

LoRa race tracker - base receiver/display

Raspberry Pi 3 as wifi hotspot with captive portal.

Saving OpenSteetMap tiles for offline serving
Maperitive (http://maperitive.net/) used to download openstreetmap tiles to raspberry pi.
Linux (ubuntu 14.x x64) failed with error when running generate-mbtiles , so used Windows version to generate mbtiles instead.

Serving OSM tiles offline on raspberry pi
Trying out Tilestache to serve the mbtiles locally on the pi, for consumption by tracking app.
tilestache.org (installed via pip)
http://tilestache.org/
config file for tilestache:

GPS Tracking application / user portal
trying Traccar.org in the first instance. Server install for ARM is available. Hopefully will be able to configure it to consume the locally served OSM tiles. Alternatively will try OpenGTS.

Receiving race unit positions
Race unit positions are received by HopeRF RFM98 modem on the same Raspberry pi, and converted into suitable sentences by python script.

LoRa Receiver board for Raspberry pi
hardware: https://store.uputronics.com/
software: Python: base don  https://github.com/mayeranalytics/pySX127x
Python needs to be adapted for uputronics board pinouts - got it working but with a random crash of Pi every now and then when running for the first time.....will post code on git when I get a minute.

Raspberry Pi as Wifi access point and captive portal (redirecting users straight to tracking server web front end)
I have used this method in the past: DHCP+DNS+hostapd server
https://learn.adafruit.com/setting-up-a-raspberry-pi-as-a-wifi-access-point/overview
Captive portal via DNS catchall - probably a better way to do it.

Race tracker for remote locations using LoRa and Raspberry Pi

Bike/Running Race tracking software for remote locations (with no mobile/internet coverage).

Competitor unit:
GPS board
LoRa modem
Power (battery - possibly passthrough from competitor's bike light.
Ant.
Panic button
Enclosure for mounting on bike (waterproof, saddlebag?)

Demo unit uses Adafruit Feather M0 LoRa and GPS featherwing.
Device is given a DeviceID, from this is derived a transmit slot (TDMA) using GPS PPS for synchronisation.
Position, battery level, panic button status are transmitted periodically to receiver/base station

Base Station Unit
Designed to be 12v powered inside e.g. motorhome or support vehicle.
Raspberry Pi 3 set up as wifi hotspot and captive portal.
LoRa radio receives position reports from competitor units.
Traccar or OpenGTS open-source GPS tracker server.
OpenStreetmap tiles are served from offline cache to connected clients.
Spectators can view progress on smartphone/tablet by connecting to wifi hotspot.

dAISy off-grid receiver

Off-grid AIS Station is now live on marinetraffic:
Receiver altitude is approx. 230m ASL, so should be better

Station coverage:
https://www.marinetraffic.com/en/ais/details/stations/910/

Remote unit battery level monitor real-time
https://thingspeak.com/channels/113422
https://io.adafruit.com/steve098/aismon

Compare the receiption to the Moxon square RTL-SDR receiver in my loft at sea level,
https://www.marinetraffic.com/en/ais/details/stations/1618/

The remote receiver picks up vessels in Oban Bay more reliably (not surprising as it can see over the top of several hills compared to my home station), and sees 'around the corner' into the Sound of Mull better, being able to track the Loch Fyne CalMac ferry on most of its route from Lochaline to Fishnish on the Isle of Mull.

It sacrifices coverage up Loch Creran.


Todo:
* convert daisy to 3.3v operation. I have received advice from Adrian Studer on how to fix excess power drain when operating the dAISy at 3.3v by isolating the 3.3v LDO reg.
* convert the AIS parser script that powers the Twitter feeds @ObanAIS and @ObanSARwatch to accept AIS sentences from the remote receiver.

Raspberry Pi SDR AIS receiver to marinetraffic.com image - more info

CPU usage of the Raspberry Pi AIS image.

Raspberry Pi 2 model B.

Main CPU usage are the threads for the dual channel AIS reception using gr-ais (called from /usr/local/bin/ais_rx in the below snapshot).

There is still headroom to run a console-to-browser debugger (rTail) and a simple AIS parser and database backend.

Raspberry Pi RTL-SDR AIS marinetraffic image

Here is a Raspberry Pi SD card image that will decode AIS messages on VHF radio using an RTL-SDR dongle.

It will upload the data to marinetraffic.com (you will need to sign up to marinetraffic.com for this) and also broadcast the AIS sentences on your local area network.

This way, you can use the Raspberry Pi and RTL-SDR as an AIS receiver for OpenCPN

I have shrunk the image to fit on Dropbox.

Image file (.zip) for Raspberry Pi: *8GB SD card*

https://www.dropbox.com/s/pflj3xtczzfb2p2/marinetraffic_rtl_sdr01.zip?dl=0

Edit July 2017 - new link:

https://www.dropbox.com/s/p4wqacko4ru3jpl/marinetraffic_rtl_sdr01.zip?dl=0

~1.6GB download

Instructions for copying an image to SD card are given here:
https://www.raspberrypi.org/documentation/installation/installing-images/windows.md

Setup Instructions:

https://www.dropbox.com/s/nez9zzmkkcxcky4/Raspberry%20Pi%20RTL-SDR%20AIS%20receiver%2001.pdf?dl=0

https://www.dropbox.com/s/1q21f23xkysovd5/Raspberry%20Pi%20RTL-SDR%20AIS%20receiver%2001.pdf?dl=0

[update March 2017 - Fitipower FC0012/13 chips have different gain ranges than the suggested values in the notes. My notes are for RT820x based RTL receivers. To see your receiver's allowable gain values, 1) log into Pi via SSH2) stop the AIS code from auto running:   sudo nano ~/ais.sh 
   change line to GO=0
3) reboot the Pi (sudo reboot)
4) log in again, and run the commands:
    cd /usr/local/bin
    rtl_test
   (exit with CTRL-c)
This will list the allowable gain values for your device. Edit ~/ais.sh to use your new gain value.

I am by no means an expert. This image works for me. YMMV. I welcome feedback and improvements.

You might consider using KPLEX http://www.stripydog.com/kplex/examples/marinetraffic.html to distribute AIS to marinetraffic as well as local network addresses, instead of the 'pipe tee' method used on the image.

source code on GIT

source code for the AIS receiver/repeater (Teensy 3.1):
https://github.com/beinnlora/AIS-repeater

credit to Stuart Robinson for the base LoRa code
https://www.dropbox.com/sh/na2d9yt09nr91f7/AADqSNprExezpBEcqIxewDpBa?dl=0


source code for the Raspberry Pi LoRa gateway:
https://github.com/beinnlora/lora-gateway

credit to Dave Ackerman for the base LoRa code
https://github.com/PiInTheSky/lora-gateway

remote AIS receiver/repeater - part 9 - more power measurements

[prev]     [first]     [next]  

I have moved the dAISy to being powered via the 5v pad direct from Vbat (3.7-4.2V) since the power consumption is (perversely) much lower at 5V than 3V

I have changed the threshold for the microcontroller to send everything to sleep up to 3.6V.

Total system current now idles at 38mA @ 4V which is a great improvement.

The Teensy is drawing around 19mA at 4V. This will be the next target for power optimisation.

There may be a way of putting the teensy into micro sleeps - if we can profile the AIS traffic in an area and perhaps predict from the protocol timing if we can sleep at a given moment by sacrificing position update frequency for high-data-rate vessels for example, that would be an OK tradeoff

There is an odd anomaly with the dAISy when powering via 3.3V pad vs 5V pad - configuring the dAISy to output at 9600 baud is ignored when powering at 3.3V - serial data rate is 38400. However, move to powering via the 5V pad and the baud rate setting is reduced to 9600 as per the setting. The manufacturer is looking into it.

remote AIS receiver/repeater - part 8 - more dAISy current measurements

[prev]     [first]     [next]  

powering the dAISy from the 3.3v pad and current consumption for the dAISy runs at about 71mA (234mW)

powering the dAISy from the 5v pad at 4.1V takes about 17mA (70mW)

Some difference!

However, if I power the dAISY from the 3.3v, the battery can get down to about 3.2V before the dAISy stops receiving, but from the 5v pad, it gets flaky at 3.6V

I guess strictly I shouldn't be dragging the 18650 cells down this low, but it is all extra capacity useable down from 3.6 to 3.3Vbat, but what a power difference.

Threshold for system sleep is 3.3Vbat at present. I think I will up this to 3.6V, power the dAISy on the 5V pad and hope for the best.

I could do some calculations comparing the lost capacity vs overall consumption...

remote AIS receiver/repeater - part 7 - current measurements

 Overall power consumption measurements

[prev]     [first]     [next]

Overall system current @ battery voltage (3.7-4.2V). Active=transmitting LoRa, Standby=listening.

dAISy current measured at 3.3V (via output of onboard 3.3v Regulator on Teensy) Active = receiving/parsing. AIS sentence. Standby = listening

Teensy current  @ battery voltage with no peripherals powered up, taken from internet (not yet measured)

HopeRF not measured

	active	standby	sleep
Overall	110mA	95mA	0.2mA
dAISy	77mA	74mA  0
Teensy	~20mA	~20mA	0.2mA
Hoperf			~0mA

Our challenge is to tame the dAISy which is someway off the published spec (<20mA @ 5V i.e.  100mW; we are seeing 74mA @ 3.3v i.e. 250mW)

remote AIS receiver/repeater - part 6 - power performance

Power budget

  [prev]     [first]     [next]

The dAISy has arrived. A quick comparison with the RTL-SDR and the RF sensitivity is about the same. (geography is my main limiting factor)

I am powering the dAISy via 3.3v header on the PCB rather than USB, and receiving AIS sentences via the hardware TX pin. The dAISy utility seems to ignore me setting the onboard serial data rate to 9600baud, and continues to spit out at 38400, but the Teensy can handle this fine.

The remote unit periodically spits out its voltage over the LoRa link, whereby the Raspberry Pi logs this to the cloud to see battery performance over time

I am logging the voltage of the battery to thingspeak, which are plotted below. Values below are raw ADC values (12 bit input. 4.2V battery voltage scaled to 1.2V to match the Teensy 3.1 internal Vref ), and averaged over the last 10 readings

.

Readings are currently send from the remote device every 20 seconds, but at present the Raspberry Pi receiver crashes about once a day when a corrupt packet is received.

I am uploading to marinetraffic.com which gives some (delayed) statistics on AIS message rate to give me some idea of the number of AIS sentences I am likely to  transmit

Current draw from the battery is 90mA @ 4.1v (0.37Watts)  idle, rising to about 120mA (0.5W) on LoRa transmit, but not measured very precisely. Most of this is the dAISy

When the battery voltage drops below about 3.6V, I have the Teensy turn off the dAISy receiver and put the HopeRF  into sleep, before itself sleeping for 20 seconds.

Every 20 seconds it wakes to measure the battery voltage, then sleeps again if needed.

Sleeping current is around 200uA, which can be improved with some effort

 , but should not be significant

remote AIS receiver/repeater - part 5 - base station

 [prev]     [first]     [next]

TL;DR

Raspberry Pi LoRa gateway

* Raspberry Pi 2/3 with HopeRf RFM98 shield from store.uptronics.com
* antenna can be yagi
* software on Pi adapted from Dave Ackerman's LoRa gateway software for High-altitude baloons
http://www.daveakerman.com/?p=1719
* Pi receives messages from LoRa and reconstructs full sentences (!AIVDM header is stripped from the on-air backhaul to save size, so is reconstructed on the Pi before pushing to the LAN over UDP
* pi also receives battery level from the remote receiver and publishes to IoT cloud e.g adafruit.io

remote AIS receiver/repeater - part 4 - LoRa data link

  [prev]     [first]     [next]

TL;DR

LoRa data link

* Transmitter HopeRF RFM98 433MHz HopeRF RFM98W-433S2
* code adapated from various sources listed on  kh-gps.de/lora.htm

Antenna is just 1/4 wire at the moment, but could be directional yagi/moxon, given that it need only point in one direction.

remote AIS receiver/repater - part 3 - power management

[prev]     [first]     [next]

TL;DR
* 10W 12V solar panel
* 2x18650 LiPo
* LT3652  based Solar LiPo charge contoller
* Teensy 3.1 microcontroller for power management.


I want about 5 days of solar redundancy to allow for Highlands weather.

Instead of having a transparent serial link whereby all AIS sentences are just packetised and transmitted over the LoRa, we waste a lot of energy on partially-full LoRa packets, redundant AIS sentences and possible brownout at night. We want to be able to control the LoRa radio state too by using sleep mode to minimise current draw (we don't need it to receive any messages over LoRa just yet)

If we control the LoRa transmissions and AIS reception with a microcontroller, we can optimise power usage by pre-filtering sentences and packaging up several AIS sentences in on LoRa data frame (max 258bytes - could get perhaps 3 AIS sentences in one LoRa packet ). We can also monitor the power and switch off the AIS receiver when the battery is low or rate limit packets as the input current allows. There is a tradeoff between the extra draw of a microcontroller and that saved by optimising packets. We don't have to receive any information back through the LoRa link (unless we want to at a later date), so we can put it to sleep outside transmissions.

I have a few Teensy 3.1 controllers knocking around which are more than overkill for the job,but they seem suitable because
* 3.3v power possible for low current
* underclock easy for low current
* Snooze library good for low power mode
* good HW serial support for buffering AIS sentences
* good number crunching abilities should we wish to add AIS decoding/prefiltering

Some fag packet calculations. I have made up some assumptions on AIS packet data rates. The LoRa parameters are critical for power consumption - different coding rates, spreading factors etc all vary the packet transmission duration significantly, so I have just made a guess here based on some mid-range figures from the Semtech LoRa calculator

		Device	On state	Sleep State
		LoRa	130	2	mA
		Teensy	20	1	mA
		Ais	20		mA
		Teensy duty cycle		0.75
		time per sentence		0.15	s
		sentences per min		120
		sentences per hour		7200
		tx time per hour		1080	s
	calculated lora	duty cycle		0.3
LoRa mean current over 1 hour				40.4	mA
Average total current draw over 1 hour				75.4	mA
energy used in 1 day				1809.6	mAh
battery capacity				5500	mAh
battery duration (no solar input)				136.1	hours
				5.67	days
solar panel Current @Pmax				550	mA
sunshine per day				4	hours
solar input per day				2200	mAh
time to full charge @ max flux				10	hours

I happened to have a 12V 10W solar panel going spare, so used this. I have a stash of 18650 cells too. Two in parallel give me 5500mAh.

The solar charge controller - I would have liked this from Adafruit  https://www.adafruit.com/products/390 but it is not available locally and only handles a 6V panel

but it didn't handle the 12V (20V open circuit) from my existing solar panel, so I chose one based on the LT3652 charge controller chip

https://www.sparkfun.com/products/12885

out of the box it required a bit of tinkering to get going. The board is set for a 4 hour timer using a 1uf cap on pin 6 of the LT3652 . I bypassed this to allow full current to the board (connected in parallel with the battery) when the sun is shining. Battery charge is then current - rather than time - limited.
There are options on the board for current sense resistors, which I could use to rate-limit the AIS backhaul based on available current should I so desire at a later date